[Ietf-calsify] Re: Google Speculation, but interesting

[daboo at isamet.com (Cyrus Daboo)]

Hi Cameron,

--On February 27, 2005 7:04:13 PM -0800 Cameron Stillion 
<[e-mail]> wrote:

> While I appreciate the semantic difference between these two application
> verbs - most users are not quite that savvy. The result? Most of the ics
> files published to apple.com (and icalshare.com) are NOT of the
> Export... flavor - and that means most people are not including what is
> needed for interop.  You must admit it is at least user unintuitive, and
> at worst a little sloppy.
>

Sure - if they 'publish' invalid iCalendar data then that is a real interop 
problem. Hopefully someone has complained to them about it and they will 
fix it...

-- 
Cyrus Daboo
From mvl at exedo.nl  Mon Feb 28 08:46:09 2005
From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Feb 28 08:46:12 2005
Subject: [Ietf-calsify] Re: I-D ACTION:draft-daboo-calsify-issues-00.txt
	(fwd)
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

Thanks for your long answer.

Doug Royer wrote:

> Yes. We need more vendors to post their issues. They do not
> want to do that. (see below)

That doesn't make it easier. The goal of calsify is to fix issues with 
ical, but it can't know the issues. How can it fix them?

Maybe it can start by looking at issues in applications that do want to 
publish their list of bug. open-source. (sunbird, kpim and evolution 
come to mind. iirc they have a public bug list)

> (2) Time zones are only needed with recurrence rules.
> Most implementations do not really need recurrence rules
> as they do not do scheduling and do not do METHOD:PUBLISH,
> they just use them.

That is a solution, not a problem. The fact that it can be differently 
doesn't mean there is a problem to fix.

> Do I have to compare your TZID=PST to my TZID=PST to
> see if they are the same? (hint - yes)

Yeah, this one is fun. Maybe it could be solved by namespacing tzid's. 
The ones without a namespace would be from the global registry. Maybe 
also version them. (otoh, that still has issues with old events.)


Michiel


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1SGk9aZ030440 for <[e-mail]>; Mon, 28 Feb 2005 08:46:10 -0800
Received: from [10.0.0.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr9.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1SGk8JQ085699 for <[e-mail]>; Mon, 28 Feb 2005 17:46:08 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 17:46:09 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050214
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: I-D ACTION:draft-daboo-calsify-issues-00.txt (fwd)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 28 Feb 2005 16:46:10 -0000

Thanks for your long answer.

Doug Royer wrote:

> Yes. We need more vendors to post their issues. They do not
> want to do that. (see below)

That doesn't make it easier. The goal of calsify is to fix issues with 
ical, but it can't know the issues. How can it fix them?

Maybe it can start by looking at issues in applications that do want to 
publish their list of bug. open-source. (sunbird, kpim and evolution 
come to mind. iirc they have a public bug list)

> (2) Time zones are only needed with recurrence rules.
> Most implementations do not really need recurrence rules
> as they do not do scheduling and do not do METHOD:PUBLISH,
> they just use them.

That is a solution, not a problem. The fact that it can be differently 
doesn't mean there is a problem to fix.

> Do I have to compare your TZID=PST to my TZID=PST to
> see if they are the same? (hint - yes)

Yeah, this one is fun. Maybe it could be solved by namespacing tzid's. 
The ones without a namespace would be from the global registry. Maybe 
also version them. (otoh, that still has issues with old events.)


Michiel



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1S4moaa031525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 27 Feb 2005 20:48:51 -0800
Received: from [10.0.1.4] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1S4bJ6g023899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Feb 2005 23:37:21 -0500
Date: Sun, 27 Feb 2005 23:48:17 -0500
From: Cyrus Daboo <[e-mail]>
To: Cameron Stillion <[e-mail]>, [e-mail], [e-mail]
Subject: RE: [Ietf-calsify] Re:  Google Speculation, but interesting
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]. corp.microsoft.com>
X-Mailer: Mulberry/4.0.0a6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Calsify <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 28 Feb 2005 04:48:53 -0000

Hi Cameron,

--On February 27, 2005 7:04:13 PM -0800 Cameron Stillion 
<[e-mail]> wrote:

> While I appreciate the semantic difference between these two application
> verbs - most users are not quite that savvy. The result? Most of the ics
> files published to apple.com (and icalshare.com) are NOT of the
> Export... flavor - and that means most people are not including what is
> needed for interop.  You must admit it is at least user unintuitive, and
> at worst a little sloppy.
>

Sure - if they 'publish' invalid iCalendar data then that is a real interop 
problem. Hopefully someone has complained to them about it and they will 
fix it...

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1S34LaZ023627 for <[e-mail]>; Sun, 27 Feb 2005 19:04:22 -0800
Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211);  Sun, 27 Feb 2005 19:04:12 -0800
Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Sun, 27 Feb 2005 19:04:28 -0800
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Feb 2005 19:04:12 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7503.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Re:  Google Speculation, but interesting
Date: Sun, 27 Feb 2005 19:04:13 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Re:  Google Speculation, but interesting
Thread-Index: AcUc2hDrCkcqiuhQSp2tbbKkctJo2gAZ7XWQ
From: "Cameron Stillion" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 28 Feb 2005 03:04:12.0998 (UTC) FILETIME=[2E31A660:01C51D42]
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1S34LaZ023627
Cc: Calsify <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 28 Feb 2005 03:04:24 -0000

While I appreciate the semantic difference between these two application
verbs - most users are not quite that savvy. The result? Most of the ics
files published to apple.com (and icalshare.com) are NOT of the
Export... flavor - and that means most people are not including what is
needed for interop.  You must admit it is at least user unintuitive, and
at worst a little sloppy.

cameron

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Cyrus Daboo
Sent: Sunday.27.February.2005 06.37
To: Cameron Stillion; [e-mail];
[e-mail]
Cc: Calsify; [e-mail]
Subject: RE: [Ietf-calsify] Re: Google Speculation, but interesting

Hi Cameron,

--On February 26, 2005 11:18:05 PM -0800 Cameron Stillion
<[e-mail]> wrote:

> The behavior I have seen in the latest Apple iCal (the product) with 
> regard to timezones is that they are NOT defined in VTIMEZONE blocks, 
> but are named in VEVENTS.  The names seem to match the OSX naming 
> comventions for Time Zones, and notably do not match the Windows
names.
> Since they aren't formally defined, it's difficult to map them.  We 
> are forced to have an internal list of Apple names for the sole 
> purpose of interoping.  (grumble grumble)
>

Right - I just did a test and indeed if you create a new calendar and
add a single event with a timezone, it does not include the VTIMEZONE in
the ics file it creates in its own calendar store. However, if you
'Export' the calendar from the iCal.app, then it does include a
VTIMEZONE. The VTIMEZONE appears to be correct, but contains only the
minimum amount of information to cover the time for the event. Arguably
this is not a bug as it is free to do whatever it wants in its own
calendar store.

WRT naming of timezones on different OS's - hopefully with a
standardised timezone registry we can solve that issue and also remove
the need to always send the VTIMEZONE data by value (as opposed to by
reference to the registry entry).

--
Cyrus Daboo
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1RJjZaa016811 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Sun, 27 Feb 2005 11:45:37 -0800
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 j1RJjU9e020723 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 27 Feb 2005 11:45:32 -0800
Message-ID: <[e-mail]>
Date: Sun, 27 Feb 2005 12:45:30 -0700
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]>, [e-mail]
Subject: Re: [Ietf-calsify] Re:  Google Speculation, but interesting
References: <[e-mail].	corp.microsoft.com> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050703080903040406060204"
Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism)
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 27 Feb 2005 19:45:40 -0000

This is a cryptographically signed message in MIME format.

--------------ms050703080903040406060204
Content-Type: multipart/mixed; boundary="------------040509030501090302090009"

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


Sending static timezone information is a short term solution.
The real problem is access to the latest accurate information.

It does not matter if the VTIMEZONE (or RDF) data you sent to me
six months ago for next months meeting  was accurate at that time.
It matters that we both expect a meeting to start at the same time.

The TZ (they asked me to stop calling it Olson database) database
is the most accurate and kept up database that I can find.
However iCalendar applications already know how to parse
VTIMEZONE data, so my IETF proposal is to sync that TZ database
at IANA and make the latest information available in iCalendar
format. It includes revision information so you can tell
if you have the latest TZ data or not.

I see no reason that IANA could not also create RDF data
at the same time and keep everyone in sync.

The biggest issue might be if everyone goes totally dynamic, the
download load on IANA (or whoever) could go sky high. So
there needs to be some kind of consideration or plan for
sharing the load to regional or vendor servers. (Or not?)

And a simple 'what is the latest rev date on the XXX timezone'
binary protocol needs to be developed. And only then download
the 'latest' VTIMEZONE or RDF data when you are out of sync.

Only then can we stop sending static VTIMEZONE information
for each and every calendar data object transferred.


-- 

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

               We Do Standards - You Need Standards


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

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


--------------040509030501090302090009--

--------------ms050703080903040406060204
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
9w0BCQUxDxcNMDUwMjI3MTk0NTMwWjAjBgkqhkiG9w0BCQQxFgQUP7eEWk9moSk1k0bHuh4p
nSus+gYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAqqKbHbAJSdpKlHpK9YtEXrxXBWQsvoF5ckzrcvzKXjJK5srs8EiTwHBtf/DmUaJq
xZJKBvD5T0d3grEcvctD5VhG/W07kIZvtv9ryhxdevCAUh4VFq7KoVJETwpgEQBDTbL3wd9Q
gLwqWFM25vcWlRfjOwF+So2khrhFfqMlAU72ujrPkbxPg31PT5zop+HjDvbD968ALH7rS3f+
kkyXf9A1tE15erMeCqankdZKPV2VZpYlTxk4dt6S8vY2XBweUE1vC3jqVyGjv1KhwxejSgBc
DP4GdAvPi35gbLdYElAL+Qwe2qc0FvLQ7spIkh77nCxQIy7BKR/d6BZ5XgbVEgAAAAAAAA==
--------------ms050703080903040406060204--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1RJB9aa013852 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Sun, 27 Feb 2005 11:11:10 -0800
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 j1RJB07m020427 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sun, 27 Feb 2005 11:11:04 -0800
Message-ID: <[e-mail]>
Date: Sun, 27 Feb 2005 12:10:59 -0700
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] Re: I-D ACTION:draft-daboo-calsify-issues-00.txt (fwd)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090109040100030200030203"
Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism)
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sun, 27 Feb 2005 19:11:14 -0000

This is a cryptographically signed message in MIME format.

--------------ms090109040100030200030203
Content-Type: multipart/mixed; boundary="------------000806080103090800040808"

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



Michiel van Leeuwen wrote:
> Cyrus Daboo wrote:
> 
>> This draft has a brief summary of interop issues (something I would 
>> like to see expanded) and also lists a number of possible courses of 
>> action in terms of fixing iCal - that list is by no means complete.
> 

Yes. We need more vendors to post their issues. They do not
want to do that. (see below)

> In the two references to interop tests in that document ([6] and [7]) 
> there are only two vendors that participated. That sounds a bit low to 
> draw conclusions from.
> Also, I noticed both vendors supported timezones.
> So the question arises: why all the discussion on timezones? What is the 
> proof that those are problematic?

Issues.

(1) Those of us that have written code to do calendaring
know that not all vendors did it correctly.

(2) Time zones are only needed with recurrence rules.
Most implementations do not really need recurrence rules
as they do not do scheduling and do not do METHOD:PUBLISH,
they just use them.

(3) Some include TZID without VTIMEZONE. Some always include
a bunch of VTIMEZONEs and do not use all of them (is that
a bug?).

(4) Do I have to store all VTIMEZONEs from each and every
appointment you send me?

Do I have to compare your TZID=PST to my TZID=PST to
see if they are the same? (hint - yes)

Is the TZID=PST you sent me in your first VEVENT the same
as the TZID=PST one you sent me for the newest?

Can I always assume that for each unique PRODID value
that TZID=PST will be the same over time?

I can always store 100 TZID=PST VTIMEZONE objects from the 100
VEVENTs that are included in a calendar of events that I
care about for the next years worth of events.

Now to schedule, I have to use the TZID=PST that came
with each of those 100 VEVENTS I got and not my TZID=PST
to figure out when your instances are. Unless each of
those VEVENTs contained EXACTLY the same TZID=PST
as my TZID=PST,

I could write a compare function that checks to see if the
several TZID=PST VTIMEZONEs that I have collected are
the same. When they are not, I still have to write
the fallback code to expand using the other 'PST'.
These cases are rare, however those are the bugs
that people will notice.

And I have to use my TZID=PST and not yours to figure out my
instances.

Then I have to compare the instance times expanded
by the other TZID=PSTs to the instance times from my TZID=PST
to see if there is a conflict.

Then when I METHOD:COUNTER, I need to send it out with
your TZID=PST, because currently some implementations
think that PST always equals PST and they always do
their instances comparisons as if that were true.

Currently there is no revision control on TZIDs, so
when you tell me that you want to meet monthly for the
next year, did you mean in the old TZID or the new one
that did not exist when you sent the VEVENT a month ago?

You send a VTIMEZONE with TZOFFSET value switch dates.
But you want to meet when the wall clock says it is noon.
Is my PST old? Or is yours? is both of ours old?

Or should I have done all of the comparisons above with
the latest PST, the PST you sent, or the one hard coded
into my application? Which one should I COUNTER with?
Do you look at the VTIMEZONE data, or just use your
hard coded one?

Which is one reason I proposed the TZ registry. So that
TZID=/Region/City is known to be the same for registered
TZID's.

And I think that we know what the user wants, they want
to meet at noon PST next month at the correct wall clock
time. And they do not like any application that got
the TZOFFSET wrong. And they do not care if the TZOFFSET
would have been accurate six months ago when you sent
the VEVENT had they not changed it to accommodate
some local and important event.

In the US time zones are quite stable, yet they do change.

Again, these are rare and real issues.

> from 4.1:
>  >    Recurrence and in particular exceptions to recurrences are known to
>  >   be problematic.
> 
> How is that known?

Have you tried to share with and process objects from other vendors?
I have, others have. That knowledge is not from the interops. Also
the interop did say that the two vendors has some kind of issue with 
them and did not specify what.

> What I think I am looking for is a list of applications and servers that 
> calsify should care about, because they have a reasonable number of 
> users. And a list of features in ical that they have problems with.

The vendors will not do that.

(1) It will show their bugs. Some will not acknowledge
that they did it incorrectly.  Others say "I am big - too bad".
Some do not have the resources to fix it or attend an interop.

(2) I have a list that I use. I would like to share it.

(3) If I were to say that vendor X has these bugs and vendor Y has
these other bugs, and I was inaccurate or they just did not like
me talking about it, I could get sued.

But mostly:

(4) I and most on this list want to see vendor X and vendor Y
do iCalendar. So publicly declaring their bug list may not
make them happy (or is my implementation busted and I am the
one with the bugs?).


-- 

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

               We Do Standards - You Need Standards


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

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


--------------000806080103090800040808--

--------------ms090109040100030200030203
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
9w0BCQUxDxcNMDUwMjI3MTkxMDU5WjAjBgkqhkiG9w0BCQQxFgQUq0vbQoUCuBG9RWHutmiI
vV3SCFQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAc1Vs+uLuWtri359qeYAdOg65+GbpIqP19FJrt7ZwTF8PpdbuR7iAidIHp9hsF+V5
vCzY9Wa5gCacyqdruP0fY5mMvVHj2N8PfXkp857UMMRmaQ/fR1mnfqOTunw1wyXtPFF3bYud
bUxaRArOeyOR8vhTSGbaasXvvkMv1wa/lRU4vplY8p4wwrDt6qLhfxbKaIkZg60M5JxHAPL1
YJZMGYT3N9eKVXNdenTJnD5CNnH0KlvhfyNIXzvX3xbGlk0coWZRmNrw6XEOttKMxuDju8Q8
faSZ0b42zyuzB/4LXyUC4mh2/LJMJK8pq3xkg+6Qy5+c5Z1oEEaSZ8kV3RxY/gAAAAAAAA==
--------------ms090109040100030200030203--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1RHZSaZ031260 for <[e-mail]>; Sun, 27 Feb 2005 09:35:29 -0800
Received: from [10.0.0.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr1.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1RHZRTt083692 for <[e-mail]>; Sun, 27 Feb 2005 18:35:27 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sun, 27 Feb 2005 18:35:27 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050214
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: I-D ACTION:draft-daboo-calsify-issues-00.txt (fwd)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 27 Feb 2005 17:35:31 -0000

Cyrus Daboo wrote:
> This draft has a brief summary of interop issues (something I would like 
> to see expanded) and also lists a number of possible courses of action 
> in terms of fixing iCal - that list is by no means complete.

In the two references to interop tests in that document ([6] and [7]) 
there are only two vendors that participated. That sounds a bit low to 
draw conclusions from.
Also, I noticed both vendors supported timezones.
So the question arises: why all the discussion on timezones? What is the 
proof that those are problematic?

from 4.1:
 >    Recurrence and in particular exceptions to recurrences are known to
 >   be problematic.

How is that known?

What I think I am looking for is a list of applications and servers that 
calsify should care about, because they have a reasonable number of 
users. And a list of features in ical that they have problems with.


The url of reference [10] doesn't work for me.


Michiel


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1RFEqaa015990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 27 Feb 2005 07:14:53 -0800
Received: from [10.0.1.4] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1RF3Q6g008790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Feb 2005 10:03:28 -0500
Date: Sun, 27 Feb 2005 10:14:19 -0500
From: Cyrus Daboo <[e-mail]>
To: Libby Miller <[e-mail]>
Subject: RE: [Ietf-calsify] Re:  Google Speculation, but interesting
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]. corp.microsoft.com> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0a6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Cameron Stillion <[e-mail]>, Calsify <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 27 Feb 2005 15:14:54 -0000

Hi Libby,

--On February 27, 2005 2:47:47 PM +0000 Libby Miller 
<[e-mail]> wrote:

>> WRT naming of timezones on different OS's - hopefully with a
>> standardised  timezone registry we can solve that issue and also remove
>> the need to always  send the VTIMEZONE data by value (as opposed to by
>> reference to the registry  entry).
>
> Is it worth using the iCalendar urls for timezones on the W3C site as a
> registry like that?[1] W3C has a policy for url longevity[2]. At the
> moment the timezones are maintained as RDF, but that's a transliteration
> of iCalendar into XML/RDF and could perhaps in any case have iCalendar
> versions added. The urls for timezones are part of experiments in turning
> icalendar into RDF[3].

<http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-01.txt> 
contains a proposal for setting up an IANA registry for iCalendar format 
timezone data. It would probably make sense to have just one 'primary' 
registry for both iCal and RDF versions. Other places could mirror those as 
appropriate. In fact I plan on having our CalDAV server sync to the 
registry at regular intervals and then clients accessing the server could 
sync (or do initial 'provisioning') via the server rather than having to 
have explicit knowledge of the registry.

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1REm7aZ013896 for <[e-mail]>; Sun, 27 Feb 2005 06:48:07 -0800
Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.50) id 1D5Pi5-0006Ef-5e; Sun, 27 Feb 2005 14:47:55 +0000
Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 4.44) id 1D5Pi0-0000SZ-23; Sun, 27 Feb 2005 14:47:48 +0000
Date: Sun, 27 Feb 2005 14:47:47 +0000 (GMT)
From: Libby Miller <[e-mail]>
X-X-Sender: [e-mail]
To: Cyrus Daboo <[e-mail]>
Subject: RE: [Ietf-calsify] Re:  Google Speculation, but interesting
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]. corp.microsoft.com> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: Libby Miller <[e-mail]>
X-Spam-Score: 0 () 
X-Spam-Level: --
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Cameron Stillion <[e-mail]>, Calsify <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 27 Feb 2005 14:48:09 -0000

On Sun, 27 Feb 2005, Cyrus Daboo wrote:

> Hi Cameron,
>
> --On February 26, 2005 11:18:05 PM -0800 Cameron Stillion 
> <[e-mail]> wrote:
>
>> The behavior I have seen in the latest Apple iCal (the product) with
>> regard to timezones is that they are NOT defined in VTIMEZONE blocks,
>> but are named in VEVENTS.  The names seem to match the OSX naming
>> comventions for Time Zones, and notably do not match the Windows names.
>> Since they aren't formally defined, it's difficult to map them.  We are
>> forced to have an internal list of Apple names for the sole purpose of
>> interoping.  (grumble grumble)
>> 
>
> Right - I just did a test and indeed if you create a new calendar and add a 
> single event with a timezone, it does not include the VTIMEZONE in the ics 
> file it creates in its own calendar store. However, if you 'Export' the 
> calendar from the iCal.app, then it does include a VTIMEZONE. The VTIMEZONE 
> appears to be correct, but contains only the minimum amount of information to 
> cover the time for the event. Arguably this is not a bug as it is free to do 
> whatever it wants in its own calendar store.
>
> WRT naming of timezones on different OS's - hopefully with a standardised 
> timezone registry we can solve that issue and also remove the need to always 
> send the VTIMEZONE data by value (as opposed to by reference to the registry 
> entry).

Is it worth using the iCalendar urls for timezones on the W3C site 
as a registry like that?[1] W3C has a policy for url longevity[2]. At 
the moment the timezones are maintained as RDF, but that's a 
transliteration of iCalendar into XML/RDF and could perhaps in any case 
have iCalendar versions added. The urls for timezones are part of 
experiments in turning icalendar into RDF[3].

Libby

[1] http://www.w3.org/2002/12/cal/tzd/
[2] http://www.w3.org/Consortium/Persistence
[3] http://www.w3.org/2002/12/cal/

>
> -- 
> Cyrus Daboo
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1REb9aa012975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 27 Feb 2005 06:37:10 -0800
Received: from [10.0.1.4] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1REPh6g008178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Feb 2005 09:25:45 -0500
Date: Sun, 27 Feb 2005 09:36:37 -0500
From: Cyrus Daboo <[e-mail]>
To: Cameron Stillion <[e-mail]>, [e-mail], [e-mail]
Subject: RE: [Ietf-calsify] Re:  Google Speculation, but interesting
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]. corp.microsoft.com>
X-Mailer: Mulberry/4.0.0a6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Calsify <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 27 Feb 2005 14:37:13 -0000

Hi Cameron,

--On February 26, 2005 11:18:05 PM -0800 Cameron Stillion 
<[e-mail]> wrote:

> The behavior I have seen in the latest Apple iCal (the product) with
> regard to timezones is that they are NOT defined in VTIMEZONE blocks,
> but are named in VEVENTS.  The names seem to match the OSX naming
> comventions for Time Zones, and notably do not match the Windows names.
> Since they aren't formally defined, it's difficult to map them.  We are
> forced to have an internal list of Apple names for the sole purpose of
> interoping.  (grumble grumble)
>

Right - I just did a test and indeed if you create a new calendar and add a 
single event with a timezone, it does not include the VTIMEZONE in the ics 
file it creates in its own calendar store. However, if you 'Export' the 
calendar from the iCal.app, then it does include a VTIMEZONE. The VTIMEZONE 
appears to be correct, but contains only the minimum amount of information 
to cover the time for the event. Arguably this is not a bug as it is free 
to do whatever it wants in its own calendar store.

WRT naming of timezones on different OS's - hopefully with a standardised 
timezone registry we can solve that issue and also remove the need to 
always send the VTIMEZONE data by value (as opposed to by reference to the 
registry entry).

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1R7IEaZ031242; Sat, 26 Feb 2005 23:18:14 -0800
Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211);  Sat, 26 Feb 2005 23:18:03 -0800
Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Sat, 26 Feb 2005 23:18:08 -0800
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 26 Feb 2005 23:18:04 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7503.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Re:  Google Speculation, but interesting
Date: Sat, 26 Feb 2005 23:18:05 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Re:  Google Speculation, but interesting
Thread-Index: AcUcVnbcx+fMCeumTy24or6Im66cowARaVUg
From: "Cameron Stillion" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Feb 2005 07:18:04.0023 (UTC) FILETIME=[7A2DE070:01C51C9C]
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1R7IEaZ031242
Cc: Calsify <[e-mail]>, [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 27 Feb 2005 07:18:15 -0000

The behavior I have seen in the latest Apple iCal (the product) with
regard to timezones is that they are NOT defined in VTIMEZONE blocks,
but are named in VEVENTS.  The names seem to match the OSX naming
comventions for Time Zones, and notably do not match the Windows names.
Since they aren't formally defined, it's difficult to map them.  We are
forced to have an internal list of Apple names for the sole purpose of
interoping.  (grumble grumble)

Cameron


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Saturday.26.February.2005 14.56
To: [e-mail]
Cc: Calsify; [e-mail];
[e-mail]
Subject: Re: [Ietf-calsify] Re: Google Speculation, but interesting

Even more intriguing.  This may actually be good news.  Cool...
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



[e-mail]
02/25/2005 06:02 PM

To
[e-mail]
cc
Calsify <[e-mail]>,
[e-mail], [e-mail] Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting







I would like to apologize. What I had received from apple is limited and

did not have any features introduced by iCalendar.  Timezone the way 
iCalendar uses them was introduced by iCalendar.  VCalendar just had an 
offset which was found to be insufficient. 


[e-mail] 
Sent by: [e-mail] 
02/25/2005 05:36 PM 


To
[e-mail] 
cc
Calsify <[e-mail]>, 
[e-mail], [e-mail] 
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting








Robert, I've been getting some private emails that say it's based on 
iCalendar.  So, now I'm intrigued.  iCalendar is also based on vCalendar

as well.  I'd really love to see them participate on interops so we
could 
see, first hand, what actually does or does not work.



[e-mail] 
02/24/2005 07:35 PM

To
[e-mail]
cc
Calsify <[e-mail]>, 
[e-mail], Tim Hare <[e-mail]>, 
[e-mail]
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting







Actually original was not iCalendar at all.  It  vCalendar 1.0 September

18, 1996 which seems to be what apple uses. 



[e-mail] 
Sent by: [e-mail] 
02/24/2005 07:21 PM 


To
Tim Hare <[e-mail]> 
cc
Calsify <[e-mail]>, [e-mail], 
[e-mail] 
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting








I think the item on the Blog is about iCal - which is the Apple
standard. 
The apple standard is based on the original work but it's not iCalendar.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Tim Hare <[e-mail]> 
Sent by: [e-mail]
02/24/2005 04:51 PM

To
Calsify <[e-mail]>, [e-mail]
cc

Subject
[Ietf-calsify] Re:  Google Speculation, but interesting






This is interesting... some months ago (3-4?) I sent in a suggestion to 
Google that they develop a specialized search for calendar information, 
and 
I specifically suggested that they had such clout that they could boost 
calendar standardization and iCalendar. Maybe one of their software 
engineers got interested on his/her own.  In any event, Google's
interest 
in calendar can only help propel things along.

Cross posted to ietf-calsify and rdf-calendar because I got two separate

posts about this on the same day.




Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1QMtYaZ032230; Sat, 26 Feb 2005 14:55:34 -0800
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Re:  Google Speculation, but interesting
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 26 Feb 2005 17:55:31 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/26/2005 05:55:34 PM, Serialize complete at 02/26/2005 05:55:34 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.235 () HTML_30_40,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Calsify <[e-mail]>, [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 26 Feb 2005 22:55:36 -0000

Even more intriguing.  This may actually be good news.  Cool...
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



[e-mail] 
02/25/2005 06:02 PM

To
[e-mail]
cc
Calsify <[e-mail]>, 
[e-mail], [e-mail]
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting







I would like to apologize. What I had received from apple is limited and 
did not have any features introduced by iCalendar.  Timezone the way 
iCalendar uses them was introduced by iCalendar.  VCalendar just had an 
offset which was found to be insufficient. 


[e-mail] 
Sent by: [e-mail] 
02/25/2005 05:36 PM 


To
[e-mail] 
cc
Calsify <[e-mail]>, 
[e-mail], [e-mail] 
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting








Robert, I've been getting some private emails that say it's based on 
iCalendar.  So, now I'm intrigued.  iCalendar is also based on vCalendar 
as well.  I'd really love to see them participate on interops so we could 
see, first hand, what actually does or does not work.



[e-mail] 
02/24/2005 07:35 PM

To
[e-mail]
cc
Calsify <[e-mail]>, 
[e-mail], Tim Hare <[e-mail]>, 
[e-mail]
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting







Actually original was not iCalendar at all.  It  vCalendar 1.0 September 
18, 1996 which seems to be what apple uses. 



[e-mail] 
Sent by: [e-mail] 
02/24/2005 07:21 PM 


To
Tim Hare <[e-mail]> 
cc
Calsify <[e-mail]>, [e-mail], 
[e-mail] 
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting








I think the item on the Blog is about iCal - which is the Apple standard. 
The apple standard is based on the original work but it's not iCalendar.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Tim Hare <[e-mail]> 
Sent by: [e-mail]
02/24/2005 04:51 PM

To
Calsify <[e-mail]>, [e-mail]
cc

Subject
[Ietf-calsify] Re:  Google Speculation, but interesting






This is interesting... some months ago (3-4?) I sent in a suggestion to 
Google that they develop a specialized search for calendar information, 
and 
I specifically suggested that they had such clout that they could boost 
calendar standardization and iCalendar. Maybe one of their software 
engineers got interested on his/her own.  In any event, Google's interest 
in calendar can only help propel things along.

Cross posted to ietf-calsify and rdf-calendar because I got two separate 
posts about this on the same day.




Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1QMskaZ032166; Sat, 26 Feb 2005 14:54:47 -0800
In-Reply-To: <[e-mail]>
To: "Cameron Stillion" <[e-mail]>
Subject: RE: [Ietf-calsify] Re:  Google Speculation, but interesting
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 26 Feb 2005 17:54:39 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/26/2005 05:54:47 PM, Serialize complete at 02/26/2005 05:54:47 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.683 () HTML_20_30,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Calsify <[e-mail]>, [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 26 Feb 2005 22:54:48 -0000

No it did not.  Nor did it include Microsoft's product as well.  8-) Hint 
Hint.  People are interoperating with the RFC's - icalendar, itip and 
imip.  Others have been with iCal.  This is why we are gathering the 
details and specing out where to make them intersect.  If iCal is based 
more on iCalendar than people had presumed, we may be closer than we 
think.  This is really cool....
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



"Cameron Stillion" <[e-mail]> 
02/25/2005 05:51 PM

To
<[e-mail]>, <[e-mail]>
cc
"Calsify" <[e-mail]>, 
<[e-mail]>, <[e-mail]>
Subject
RE: [Ietf-calsify] Re:  Google Speculation, but interesting






Wow, now I'm intrigued.  You mean to say that the interop we just had
didn't include Apple's product? I think most of the development and
testing I've done in the last year has been interoping with that single
product.  Am I the only one?

By the way, I hate their implementation of timezones.

cameron 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Friday, February 25, 2005 2:37 PM
To: [e-mail]
Cc: Calsify; [e-mail];
[e-mail]
Subject: Re: [Ietf-calsify] Re: Google Speculation, but interesting

Robert, I've been getting some private emails that say it's based on
iCalendar.  So, now I'm intrigued.  iCalendar is also based on vCalendar
as well.  I'd really love to see them participate on interops so we
could see, first hand, what actually does or does not work.



[e-mail]
02/24/2005 07:35 PM

To
[e-mail]
cc
Calsify <[e-mail]>,
[e-mail], Tim Hare <[e-mail]>,
[e-mail] Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting







Actually original was not iCalendar at all.  It  vCalendar 1.0 September
18, 1996 which seems to be what apple uses. 



[e-mail] 
Sent by: [e-mail] 
02/24/2005 07:21 PM 


To
Tim Hare <[e-mail]> 
cc
Calsify <[e-mail]>, [e-mail], 
[e-mail] 
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting








I think the item on the Blog is about iCal - which is the Apple
standard. 
The apple standard is based on the original work but it's not iCalendar.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Tim Hare <[e-mail]> 
Sent by: [e-mail]
02/24/2005 04:51 PM

To
Calsify <[e-mail]>, [e-mail]
cc

Subject
[Ietf-calsify] Re:  Google Speculation, but interesting






This is interesting... some months ago (3-4?) I sent in a suggestion to 
Google that they develop a specialized search for calendar information, 
and 
I specifically suggested that they had such clout that they could boost 
calendar standardization and iCalendar. Maybe one of their software 
engineers got interested on his/her own.  In any event, Google's
interest 
in calendar can only help propel things along.

Cross posted to ietf-calsify and rdf-calendar because I got two separate

posts about this on the same day.




Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1Q2EQaa024826 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 25 Feb 2005 18:14:27 -0800
Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1Q2EIUw015785 for <[e-mail]>; Fri, 25 Feb 2005 18:14:18 -0800
Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1Q2EHcm015773 for <[e-mail]>; Fri, 25 Feb 2005 18:14:17 -0800
Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1Q2EGGL028658 for <[e-mail]>; Fri, 25 Feb 2005 19:14:16 -0700
Received: from [192.168.0.3] (dhcp-amer-rmdc-csvpn-gw4-141-144-96-48.vpn.oracle.com [141.144.96.48]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1Q2EFXk028629 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for <[e-mail]>; Fri, 25 Feb 2005 19:14:16 -0700
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Keith MacDonald <[e-mail]>
Subject: Re: [Ietf-calsify] Re:  Google Speculation, but interesting
Date: Fri, 25 Feb 2005 21:14:14 -0500
To: Calsify <[e-mail]>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 26 Feb 2005 02:14:28 -0000

Hi,

We've done some interop testing with Apple's iCal product.  It's not 
nearly as weird as this thread makes it out to be.  It is iCalendar 
(RFC2445) not vCalendar, and I wouldn't call it an "Apple Standard" 
because it implies that it's very different from RFC2445.

The first versions of the iCal product certainly had some bugs esp. wrt 
  timezones (the timezones were used but not defined) but at least for 
file based import/export my current interop with it is at least as good 
as with other major C&S products.

I do wish they would have saved us all a lot of grief by choosing a 
different product name though...

Cheers,
Keith


On 25-Feb-05, at 6:02 PM, [e-mail] wrote:

> I would like to apologize. What I had received from apple is limited 
> and
> did not have any features introduced by iCalendar.  Timezone the way
> iCalendar uses them was introduced by iCalendar.  VCalendar just had an
> offset which was found to be insufficient.
>
>
>
> [e-mail]
> Sent by: [e-mail]
> 02/25/2005 05:36 PM
>
> To
> [e-mail]
> cc
> Calsify <[e-mail]>,
> [e-mail], [e-mail]
> Subject
> Re: [Ietf-calsify] Re:  Google Speculation, but interesting
>
>
>
>
>
>
> Robert, I've been getting some private emails that say it's based on
> iCalendar.  So, now I'm intrigued.  iCalendar is also based on 
> vCalendar
> as well.  I'd really love to see them participate on interops so we 
> could
> see, first hand, what actually does or does not work.
>
>
>
> [e-mail]
> 02/24/2005 07:35 PM
>
> To
> [e-mail]
> cc
> Calsify <[e-mail]>,
> [e-mail], Tim Hare <[e-mail]>,
> [e-mail]
> Subject
> Re: [Ietf-calsify] Re:  Google Speculation, but interesting
>
>
>
>
>
>
>
> Actually original was not iCalendar at all.  It  vCalendar 1.0 
> September
> 18, 1996 which seems to be what apple uses.
>
>
>
> [e-mail]
> Sent by: [e-mail]
> 02/24/2005 07:21 PM
>
>
> To
> Tim Hare <[e-mail]>
> cc
> Calsify <[e-mail]>, [e-mail],
> [e-mail]
> Subject
> Re: [Ietf-calsify] Re:  Google Speculation, but interesting
>
>
>
>
>
>
>
>
> I think the item on the Blog is about iCal - which is the Apple 
> standard.
> The apple standard is based on the original work but it's not 
> iCalendar.
> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652
>
>
>
> Tim Hare <[e-mail]>
> Sent by: [e-mail]
> 02/24/2005 04:51 PM
>
> To
> Calsify <[e-mail]>, [e-mail]
> cc
>
> Subject
> [Ietf-calsify] Re:  Google Speculation, but interesting
>
>
>
>
>
>
> This is interesting... some months ago (3-4?) I sent in a suggestion to
> Google that they develop a specialized search for calendar information,
> and
> I specifically suggested that they had such clout that they could boost
> calendar standardization and iCalendar. Maybe one of their software
> engineers got interested on his/her own.  In any event, Google's 
> interest
> in calendar can only help propel things along.
>
> Cross posted to ietf-calsify and rdf-calendar because I got two 
> separate
> posts about this on the same day.
>
>
>
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1PN2EaZ003252; Fri, 25 Feb 2005 15:02:15 -0800
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Re:  Google Speculation, but interesting
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_02132005NP February 13, 2005
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2005 18:02:06 -0500
X-Disclaimed: 1
From: [e-mail]
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V70_M4_12222004 Beta 3|December 22, 2004) at 02/25/2005 05:58:29 PM, Serialize complete at 02/25/2005 05:58:29 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 1.057 (*) DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Calsify <[e-mail]>, [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 25 Feb 2005 23:02:16 -0000

I would like to apologize. What I had received from apple is limited and 
did not have any features introduced by iCalendar.  Timezone the way 
iCalendar uses them was introduced by iCalendar.  VCalendar just had an 
offset which was found to be insufficient.



[e-mail] 
Sent by: [e-mail]
02/25/2005 05:36 PM

To
[e-mail]
cc
Calsify <[e-mail]>, 
[e-mail], [e-mail]
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting






Robert, I've been getting some private emails that say it's based on 
iCalendar.  So, now I'm intrigued.  iCalendar is also based on vCalendar 
as well.  I'd really love to see them participate on interops so we could 
see, first hand, what actually does or does not work.



[e-mail] 
02/24/2005 07:35 PM

To
[e-mail]
cc
Calsify <[e-mail]>, 
[e-mail], Tim Hare <[e-mail]>, 
[e-mail]
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting







Actually original was not iCalendar at all.  It  vCalendar 1.0 September 
18, 1996 which seems to be what apple uses. 



[e-mail] 
Sent by: [e-mail] 
02/24/2005 07:21 PM 


To
Tim Hare <[e-mail]> 
cc
Calsify <[e-mail]>, [e-mail], 
[e-mail] 
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting








I think the item on the Blog is about iCal - which is the Apple standard. 
The apple standard is based on the original work but it's not iCalendar.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Tim Hare <[e-mail]> 
Sent by: [e-mail]
02/24/2005 04:51 PM

To
Calsify <[e-mail]>, [e-mail]
cc

Subject
[Ietf-calsify] Re:  Google Speculation, but interesting






This is interesting... some months ago (3-4?) I sent in a suggestion to 
Google that they develop a specialized search for calendar information, 
and 
I specifically suggested that they had such clout that they could boost 
calendar standardization and iCalendar. Maybe one of their software 
engineers got interested on his/her own.  In any event, Google's interest 
in calendar can only help propel things along.

Cross posted to ietf-calsify and rdf-calendar because I got two separate 
posts about this on the same day.




Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1PMpUaZ001989; Fri, 25 Feb 2005 14:51:30 -0800
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211);  Fri, 25 Feb 2005 14:51:25 -0800
Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802);  Fri, 25 Feb 2005 14:51:24 -0800
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Fri, 25 Feb 2005 14:51:23 -0800
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 14:51:20 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7503.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Re:  Google Speculation, but interesting
Date: Fri, 25 Feb 2005 14:51:20 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Re:  Google Speculation, but interesting
Thread-Index: AcUbiqJsZMqI4YjvTzCUydLsRfwAuQAAahIQ
From: "Cameron Stillion" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 25 Feb 2005 22:51:20.0814 (UTC) FILETIME=[860A98E0:01C51B8C]
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1PMpUaZ001989
Cc: Calsify <[e-mail]>, [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 25 Feb 2005 22:51:30 -0000

Wow, now I'm intrigued.  You mean to say that the interop we just had
didn't include Apple's product? I think most of the development and
testing I've done in the last year has been interoping with that single
product.  Am I the only one?

By the way, I hate their implementation of timezones.

cameron 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Friday, February 25, 2005 2:37 PM
To: [e-mail]
Cc: Calsify; [e-mail];
[e-mail]
Subject: Re: [Ietf-calsify] Re: Google Speculation, but interesting

Robert, I've been getting some private emails that say it's based on
iCalendar.  So, now I'm intrigued.  iCalendar is also based on vCalendar
as well.  I'd really love to see them participate on interops so we
could see, first hand, what actually does or does not work.



[e-mail]
02/24/2005 07:35 PM

To
[e-mail]
cc
Calsify <[e-mail]>,
[e-mail], Tim Hare <[e-mail]>,
[e-mail] Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting







Actually original was not iCalendar at all.  It  vCalendar 1.0 September
18, 1996 which seems to be what apple uses. 



[e-mail] 
Sent by: [e-mail] 
02/24/2005 07:21 PM 


To
Tim Hare <[e-mail]> 
cc
Calsify <[e-mail]>, [e-mail], 
[e-mail] 
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting








I think the item on the Blog is about iCal - which is the Apple
standard. 
The apple standard is based on the original work but it's not iCalendar.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Tim Hare <[e-mail]> 
Sent by: [e-mail]
02/24/2005 04:51 PM

To
Calsify <[e-mail]>, [e-mail]
cc

Subject
[Ietf-calsify] Re:  Google Speculation, but interesting






This is interesting... some months ago (3-4?) I sent in a suggestion to 
Google that they develop a specialized search for calendar information, 
and 
I specifically suggested that they had such clout that they could boost 
calendar standardization and iCalendar. Maybe one of their software 
engineers got interested on his/her own.  In any event, Google's
interest 
in calendar can only help propel things along.

Cross posted to ietf-calsify and rdf-calendar because I got two separate

posts about this on the same day.




Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1PMaaaZ000840; Fri, 25 Feb 2005 14:36:37 -0800
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Re:  Google Speculation, but interesting
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 25 Feb 2005 17:36:31 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/25/2005 05:36:37 PM, Serialize complete at 02/25/2005 05:36:37 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.265 () HTML_40_50,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Calsify <[e-mail]>, [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 25 Feb 2005 22:36:40 -0000

Robert, I've been getting some private emails that say it's based on 
iCalendar.  So, now I'm intrigued.  iCalendar is also based on vCalendar 
as well.  I'd really love to see them participate on interops so we could 
see, first hand, what actually does or does not work.



[e-mail] 
02/24/2005 07:35 PM

To
[e-mail]
cc
Calsify <[e-mail]>, 
[e-mail], Tim Hare <[e-mail]>, 
[e-mail]
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting







Actually original was not iCalendar at all.  It  vCalendar 1.0 September 
18, 1996 which seems to be what apple uses. 



[e-mail] 
Sent by: [e-mail] 
02/24/2005 07:21 PM 


To
Tim Hare <[e-mail]> 
cc
Calsify <[e-mail]>, [e-mail], 
[e-mail] 
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting








I think the item on the Blog is about iCal - which is the Apple standard. 
The apple standard is based on the original work but it's not iCalendar.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Tim Hare <[e-mail]> 
Sent by: [e-mail]
02/24/2005 04:51 PM

To
Calsify <[e-mail]>, [e-mail]
cc

Subject
[Ietf-calsify] Re:  Google Speculation, but interesting






This is interesting... some months ago (3-4?) I sent in a suggestion to 
Google that they develop a specialized search for calendar information, 
and 
I specifically suggested that they had such clout that they could boost 
calendar standardization and iCalendar. Maybe one of their software 
engineers got interested on his/her own.  In any event, Google's interest 
in calendar can only help propel things along.

Cross posted to ietf-calsify and rdf-calendar because I got two separate 
posts about this on the same day.




Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1PFDMaa026648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 25 Feb 2005 07:13:23 -0800
Received: from [10.0.1.4] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1PF2j6g001909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 25 Feb 2005 10:02:45 -0500
Date: Fri, 25 Feb 2005 10:13:21 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-calsify] I-D ACTION:draft-daboo-calsify-issues-00.txt (fwd)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 25 Feb 2005 15:13:23 -0000

FYI In case anyone missed this announcement.

This draft has a brief summary of interop issues (something I would like to 
see expanded) and also lists a number of possible courses of action in 
terms of fixing iCal - that list is by no means complete.

Right now the Calsify BOF is scheduled for THURSDAY, March 10, 2005 1 pm - 
3 pm in Minneapolis.

------------ Forwarded Message -----------
Date: February 16, 2005 10:16:07 AM -0500
From: [e-mail]
To: [e-mail]
Subject: I-D ACTION:draft-daboo-calsify-issues-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Problems in Calendaring and Scheduling  Standards
	Author(s)	: C. Daboo
	Filename	: draft-daboo-calsify-issues-00.txt
	Pages		: 9
	Date		: 2005-2-15
	
Current calendaring and scheduling standards are fraught with a
   number of significant problems, that have hindered wide deployments
   of interoperable products.  This informational document lists the
   problems with the current standards documents as a means to help
   identity areas where revisions of the documents are required.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-calsify-issues-00.txt

To remove yourself from the I-D Announcement list, send a message to
[e-mail] with the word unsubscribe in the body of the
message.   You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce  to change your
subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-daboo-calsify-issues-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-daboo-calsify-issues-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---------- End Forwarded Message ----------



-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1PF7YaZ026214; Fri, 25 Feb 2005 07:07:34 -0800
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Re:  Google Speculation, but interesting
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_02132005NP February 13, 2005
Message-ID: <[e-mail]>
Date: Thu, 24 Feb 2005 19:35:16 -0500
X-Disclaimed: 1
From: [e-mail]
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V70_M4_12222004 Beta 3|December 22, 2004) at 02/25/2005 10:03:52 AM, Serialize complete at 02/25/2005 10:03:52 AM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.609 () DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Calsify <[e-mail]>, [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 25 Feb 2005 15:07:38 -0000

Actually original was not iCalendar at all.  It  vCalendar 1.0 September 
18, 1996 which seems to be what apple uses.




[e-mail] 
Sent by: [e-mail]
02/24/2005 07:21 PM

To
Tim Hare <[e-mail]>
cc
Calsify <[e-mail]>, [e-mail], 
[e-mail]
Subject
Re: [Ietf-calsify] Re:  Google Speculation, but interesting






I think the item on the Blog is about iCal - which is the Apple standard. 
The apple standard is based on the original work but it's not iCalendar.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Tim Hare <[e-mail]> 
Sent by: [e-mail]
02/24/2005 04:51 PM

To
Calsify <[e-mail]>, [e-mail]
cc

Subject
[Ietf-calsify] Re:  Google Speculation, but interesting






This is interesting... some months ago (3-4?) I sent in a suggestion to 
Google that they develop a specialized search for calendar information, 
and 
I specifically suggested that they had such clout that they could boost 
calendar standardization and iCalendar. Maybe one of their software 
engineers got interested on his/her own.  In any event, Google's interest 
in calendar can only help propel things along.

Cross posted to ietf-calsify and rdf-calendar because I got two separate 
posts about this on the same day.




Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1P0LLaZ006557; Thu, 24 Feb 2005 16:21:22 -0800
In-Reply-To: <[e-mail]>
To: Tim Hare <[e-mail]>
Subject: Re: [Ietf-calsify] Re:  Google Speculation, but interesting
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 24 Feb 2005 19:21:16 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/24/2005 07:21:22 PM, Serialize complete at 02/24/2005 07:21:22 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.265 () HTML_40_50,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Calsify <[e-mail]>, [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 25 Feb 2005 00:21:25 -0000

I think the item on the Blog is about iCal - which is the Apple standard. 
The apple standard is based on the original work but it's not iCalendar.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Tim Hare <[e-mail]> 
Sent by: [e-mail]
02/24/2005 04:51 PM

To
Calsify <[e-mail]>, [e-mail]
cc

Subject
[Ietf-calsify] Re:  Google Speculation, but interesting






This is interesting... some months ago (3-4?) I sent in a suggestion to 
Google that they develop a specialized search for calendar information, 
and 
I specifically suggested that they had such clout that they could boost 
calendar standardization and iCalendar. Maybe one of their software 
engineers got interested on his/her own.  In any event, Google's interest 
in calendar can only help propel things along.

Cross posted to ietf-calsify and rdf-calendar because I got two separate 
posts about this on the same day.




Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc11.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1OLrNaZ028550 for <[e-mail]>; Thu, 24 Feb 2005 13:53:23 -0800
Received: from computer.comcast.net (pcp02547528pcs.micske01.fl.comcast.net[68.84.21.89]) by comcast.net (rwcrmhc14) with SMTP id <200502242153170140037306e>; Thu, 24 Feb 2005 21:53:18 +0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 24 Feb 2005 16:51:35 -0500
To: Calsify <[e-mail]>, [e-mail]
From: Tim Hare <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-calsify] Re:  Google Speculation, but interesting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 24 Feb 2005 21:53:25 -0000

This is interesting... some months ago (3-4?) I sent in a suggestion to 
Google that they develop a specialized search for calendar information, and 
I specifically suggested that they had such clout that they could boost 
calendar standardization and iCalendar. Maybe one of their software 
engineers got interested on his/her own.  In any event, Google's interest 
in calendar can only help propel things along.

Cross posted to ietf-calsify and rdf-calendar because I got two separate 
posts about this on the same day.




Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1OHKraa028112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 24 Feb 2005 09:20:54 -0800
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j1OHKrAN004132 for <[e-mail]>; Thu, 24 Feb 2005 09:20:53 -0800
Received: from [192.168.1.105] (c-24-18-181-17.client.comcast.net [24.18.181.17]) (authenticated bits=0) by smtp.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j1OHKosS002211 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Thu, 24 Feb 2005 09:20:52 -0800
Mime-Version: 1.0 (Apple Message framework v619.2)
To: Calsify <[e-mail]>
Message-Id: <[e-mail]>
Content-Type: multipart/alternative; boundary=Apple-Mail-5--38053234
From: Oren Sreebny <[e-mail]>
Date: Thu, 24 Feb 2005 09:20:49 -0800
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Fwd: Wild Google Speculation, but interesting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 24 Feb 2005 17:20:55 -0000

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

this is possibly of interest.

Begin forwarded message:

> From: Jim Flanagan <[e-mail]>
> Date: February 24, 2005 8:18:58 AM PST
> To: Oren Sreebny <[e-mail]>
> Subject: Wild Google Speculation, but interesting
>
> http://www.b2blog.com/2005/02/i-know-what-googles-going-to-do-next.htm
>
> Apparently, Google is crawling ical content, perhaps for some sort of 
> event search.

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

this is possibly of interest.


Begin forwarded message:


<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>Jim Flanagan <<[e-mail]>

<bold><color><param>0000,0000,0000</param>Date:
</color></bold>February 24, 2005 8:18:58 AM PST

<bold><color><param>0000,0000,0000</param>To: </color></bold>Oren
Sreebny <<[e-mail]>

<bold><color><param>0000,0000,0000</param>Subject: </color>Wild Google
Speculation, but interesting

</bold>

http://www.b2blog.com/2005/02/i-know-what-googles-going-to-do-next.htm


Apparently, Google is crawling ical content, perhaps for some sort of
event search.

</excerpt>
--Apple-Mail-5--38053234--



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1L5uxaa029236 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Sun, 20 Feb 2005 21:57:03 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1L5utQS003748 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sun, 20 Feb 2005 21:56:58 -0800
Message-ID: <[e-mail]>
Date: Sun, 20 Feb 2005 22:56:55 -0700
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] max-interop vs. min-useful and DTEND (Was Re: What's	wrong with more radical simplification?)
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020000080303020806050106"
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 21 Feb 2005 05:57:06 -0000

This is a cryptographically signed message in MIME format.

--------------ms020000080303020806050106
Content-Type: multipart/mixed; boundary="------------030707000202080601060103"

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



Tantek =C7elik wrote:

> A max-interop evaluation of DTEND would ask the question of how=20
> inteoperable are implementations of DTEND.  I don't know the actual=20
> answer offhand, but I can only surmise that a property so simple would =

> be quite interoperable (please correct me if tests have shown=20
> otherwise).  Therefore DTEND should be included.

Some applications send DURATION others send DTEND.
Even when the endpoints can compute one from the
other, there is no real point to having both.

The reason I proposed DTEND go away over time is
because of the two methods used for expanding recurring
instances. Some set RECURRENCE-ID always equal to DTSTART
(and they adjust DTEND) Others do what iTIP says and DTSTART
and DTEND is the original value and RECURRENCE-ID is the
effective start time of the instance.

By using DURATION, the recipient does not care which method
to use, they just need to add RECURRENCE-ID to DURATION
to compute DTEND. (This works for both)

If you do it the iTIP way DTEND can be before RECURRENCE-ID
and after DTSTART.

Just trying to avoid the next debate over scheduling that
is going to happen some day.

>=20
> P.S. One could make the additional argument that whether a VEVENT has a=
=20
> DTEND
> or a DURATION could be used to keep track of whether the *user*=20
> specified a duration or an absolute end datetime for an event in their =

> calendar user interface, and thus DURATION can't serve as a 100%=20
> replacement for DTEND.  This is merely a theory, I don't know of any=20
> actual implementations that treat DURATION/DTEND with this particular=20
> detail.

So far, I do not think that anyone came up with an example of this.
And it can not be true for appointments that repeat. The first
instance could be valid.

The second instance would have a DTEND before DTSTART if DTEND were
fixed.

For those that set RECURRENCE-ID equal to DTSTART, the sender
MUST adjust DTEND by computing the duration between the
first instances DTSTART and DTEND and then send out
updated DTSTART/DTEND values. So much for a fixed DTEND.
And I think that it proves that all of the time:

    DURATION =3D  DTEND - DTSTART

For those that keep DTSTART and DTEND the same and only
set RECURRENCE-ID equal to the effective start time,
the recipient must subtract DTEND from DTSTART and
add it to RECURRENCE-ID to compute the duration and
find the effective DTEND. So much for a fixed DTEND.

So that point that has been brought up before does not
work for an second or greater instance.


--=20

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

               We Do Standards - You Need Standards


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

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


--------------030707000202080601060103--

--------------ms020000080303020806050106
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
9w0BCQUxDxcNMDUwMjIxMDU1NjU1WjAjBgkqhkiG9w0BCQQxFgQU3G/yMZS7e1v+hliSfHRg
GswJ9q0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAmunq7mx0xyfco9Tu6p0fbECWHP5kLLW+jYa9lmo63jhNRycCbgfFFKOQjQyHraR1
3Yz0t1NvlJ5jqOvs2oO1C786Mu8gy4yEiunsijRucEMhTvthjw2rtvn3hzYU9AfrEozvXosq
FVgAhKAhAJnmh/Vp7Sh+Z7dtQE9HFtypJ0piVRbGonKF1XqOVHyEBAbUaXlHpQcgMISfkcM3
CZtBmhziEGDCY6a02+uzAG5/leEmqWXfzPzKkfMafiDtcIvCdCA7fxN/xvtlwcduMNEcVVzc
FfZbod+rpBP9eu6B9JVbDJqXV+3m0YeDjZ/pFLO/ftRK5tioM2zSR9fG2TpFWgAAAAAAAA==
--------------ms020000080303020806050106--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.technorati.com (mail.technorati.com [209.237.227.245]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1K35aaa029142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 19 Feb 2005 19:05:36 -0800
Received: from [192.168.1.103] (adsl-63-195-114-133.dsl.snfc21.pacbell.net [63.195.114.133]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.technorati.com (Postfix) with ESMTP id A1FC921286E for <[e-mail]>; Sat, 19 Feb 2005 19:05:52 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <[e-mail]>
From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[e-mail]>
Date: Sat, 19 Feb 2005 19:05:29 -0800
To: [e-mail]
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1K35aaa029142
Subject: [Ietf-calsify] max-interop vs. min-useful and DTEND (Was Re: What's wrong with more radical simplification?)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 20 Feb 2005 03:05:37 -0000

I want to re-raise the issue of what is the scope of iCal-Basic because 
I feel that has been lost with the deep-dive into the RRULES 
discussion.

See 1. max-interop vs. 2. min-useful in previous email below.

Another example of  max-interop vs. min-useful is perhaps DTEND.

A max-interop evaluation of DTEND would ask the question of how 
inteoperable are implementations of DTEND.  I don't know the actual 
answer offhand, but I can only surmise that a property so simple would 
be quite interoperable (please correct me if tests have shown 
otherwise).  Therefore DTEND should be included.

OTOH, what is in *-02.txt is perhaps the min-useful perspective, which 
asks whether  DTEND is necessary, and finds that it is not, since 
DURATION can simply be used instead.  Therefore DTEND was removed (or 
in this case deprecated).

However, for the same reasons as before:

  " if current implementations interoperably output feature XYZ, then 
any new implementation will be forced by market forces and competitive 
pressure to accept and support feature XYZ"

I still prefer 1. max-interop and thus prefer to keep DTEND (without 
deprecation).

Regards,

Tantek

P.S. One could make the additional argument that whether a VEVENT has a 
DTEND
or a DURATION could be used to keep track of whether the *user* 
specified a duration or an absolute end datetime for an event in their 
calendar user interface, and thus DURATION can't serve as a 100% 
replacement for DTEND.  This is merely a theory, I don't know of any 
actual implementations that treat DURATION/DTEND with this particular 
detail.



On Feb 10, 2005, at 11:23 AM, Tantek Çelik wrote:

> +1 on what Cameron Stillion wrote.
>
> If the choice is between defining iCal as:
>
>  1. maximum interoperability profile of existing major/popular 
> implementations
>  2. minimum possible useful profile (radical simplification)
>
> From following all the discussions in this thread, and considering 
> practical matters of current implementations and market forces (e.g. 
> if current implementations interoperably output RRULES, then any new 
> implementation will be forced by market forces and competitive 
> pressure to accept and support RRULES), 1. seems like the only 
> realistic choice.
>
> Tantek
>
>
>
> On Feb 10, 2005, at 9:43 AM, Cameron Stillion wrote:
>
>>
>> While I agree with you philosophically, I believe there is also a
>> practical issue to consider:  Any standard which has meaning must have
>> some relevance to the working products that are in frequent or popular
>> usage.  If we were in a state where no product or vendor had yet
>> released significant support of iCal, I would agree with you 
>> completely.
>> However, there are products now shipping and becoming more commonplace
>> that we must also consider.  Apple's iCal (who came up with that
>> original name?) product and their .mac service that hosts published
>> calendars.  Mozilla's product that reads and writes iCal format, and
>> several others - some already out there, and some on the verge of
>> releasing... There are other web services (I use the term loosely, not
>> in the MS.NET sense) that have sprung up around iCal: icalx.com,
>> icalshare.com, and others...  A standard which these products and
>> services do not use is (imho) not all that meaningful.
>>
>> To hit on some of your specific points: removing rrules would not 
>> affect
>> the apps and services that use them currently.  Frankly, I can't 
>> imagine
>> removing support for rrules in our current product, or generating 
>> icals
>> without them.  It would mean more "lossy" conversions, not less.  I
>> can't imagine other vendors doing it either.  Perhaps new systems 
>> could
>> opt for the "simpler" rrule-less standard, but then they would be
>> incompatible with the existing big dogs that use this technology.  In
>> some ways, we are dealing with the tyrrany of schema - you can't take 
>> it
>> back, once it is commonly used.  You can deprecate it, provide a 
>> better
>> replacement, but it is VERY difficult to stop supporting it.
>>
>> I believe that to be successful, we must capture the state of the art
>> that is happening today, perhaps with some tweaks to the more 
>> difficult
>> aspects that thwart integration and interoperability.  Radical
>> simplification to the standard make it theoretically easier for 
>> entrance
>> to the game, but I think the sweet spot here is to capture what's
>> already being played, and then to move on from there.  A Diet-iCal may
>> very well be useful to embedded systems or small devices (maybe) in 
>> the
>> future, but I don't see it as our most pressing objective, or our most
>> promising one.
>>
>> Thoughts?
>>
>> cameron




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1EKGBaa010562 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 14 Feb 2005 12:16:13 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1EKG2t0015088 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 14 Feb 2005 12:16:07 -0800
Message-ID: <[e-mail]>
Date: Mon, 14 Feb 2005 13:16:01 -0700
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] radical simplification, too
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070402010001020006090209"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 14 Feb 2005 20:16:17 -0000

This is a cryptographically signed message in MIME format.

--------------ms070402010001020006090209
Content-Type: multipart/mixed; boundary="------------000703050301090807020600"

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


Another idea is that we make a new parameter (say R-FYI) that *if*
set to true in an RRULE property means that the RDATE's should
be used and that RRULE is just FYI. So you could say in effect,
and the ORGANIZER wants to convey the fact that the meeting is
weekly, but look at the RDATE's for the real instance times.

Now we can keep the organizers intent when implementations care,
and for those that do not care, here are the real instance
times in RDATEs.

Preston Stephenson wrote:
> Just a few comments.
> It would be nice to have a list of iCal properties that were defined explicitly.
> Be it an iCal lite or an iCal best practices.
> If we could come to a consensus of what they were,
> I would be more willing to make the project I work on fit into that consensus.
> 
> If we get into the more difficult ones such as rrule,
> I'm constrained by the architecture of our application.
> I'm limited to fanning out the recurrence rule to a reasonable number of occurrences in the future.
> 
> It would nice to support infinite occurring rules, but I don't see it happening anytime soon.
> 
> All I'm saying is if rrule was part of the iCal basic, I could only support it with certain restrictions.
> It would be nice to have a set of iCal properties that could be supported in all cases.
> 
> Thanks.
> Preston
> 
> 
> 
> _______________________________________________
> 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


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

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


--------------000703050301090807020600--

--------------ms070402010001020006090209
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
9w0BCQUxDxcNMDUwMjE0MjAxNjAxWjAjBgkqhkiG9w0BCQQxFgQUzBPlFHkYO12TvHK4xdJ+
ZRonJHUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAvtyzuJjwTMfxc1+nFKCSavB3x5EsSGV1/9GqMJejbx2SzfiJ765qGvjplxLENJdq
eMuInXZigoZ0eVqfGG/DGxo2wDfrmB4ygqEpa/+sIz9hUBRFmYxINuI2YVpsM6RzBCMrJcUb
o/823aJ9UbGtAvmV12WmOwf5yW4G3WLUmtdwkUplSQ9Xby4rLXlYRs8MvtEh7PQs+oRgWUr4
pk4ITHmz1r2UoGKlShhjtl3R6PCD0/t67YFsHzhVPyWCU8oeSuPjYi9805UlhPtJJFnQ9A5c
0lknSn1FY1liKSYxdBa9sg5rQ1x5WyHx4mDA5nOIRnu04cCM04xylEvBuiCSawAAAAAAAA==
--------------ms070402010001020006090209--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from xgate.provo.novell.com (xgate.provo.novell.com [137.65.47.28]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1EJAnaa025973 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Mon, 14 Feb 2005 11:10:49 -0800
Received: from PROVO7-MTA by xgate.provo.novell.com with Novell_GroupWise; Tue, 15 Feb 2005 12:12:06 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 
Date: Mon, 14 Feb 2005 12:15:23 -0700
From: "Preston Stephenson" <[e-mail]>
To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
X-Spam-Score: 0.374 () DNS_FROM_RFC_ABUSE
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1EJAnaa025973
Subject: [Ietf-calsify] radical simplification, too
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 14 Feb 2005 19:10:50 -0000

Just a few comments.
It would be nice to have a list of iCal properties that were defined explicitly.
Be it an iCal lite or an iCal best practices.
If we could come to a consensus of what they were,
I would be more willing to make the project I work on fit into that consensus.

If we get into the more difficult ones such as rrule,
I'm constrained by the architecture of our application.
I'm limited to fanning out the recurrence rule to a reasonable number of occurrences in the future.

It would nice to support infinite occurring rules, but I don't see it happening anytime soon.

All I'm saying is if rrule was part of the iCal basic, I could only support it with certain restrictions.
It would be nice to have a set of iCal properties that could be supported in all cases.

Thanks.
Preston





X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1EHGRaa023259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 14 Feb 2005 09:16:28 -0800
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j1EHGRr5025415 for <[e-mail]>; Mon, 14 Feb 2005 12:16:27 -0500 (EST) (envelope-from [e-mail])
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j1EHGRiJ025412; Mon, 14 Feb 2005 12:16:27 -0500 (EST) (envelope-from lennox)
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 14 Feb 2005 12:16:27 -0500
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 14 Feb 2005 17:16:30 -0000

On Monday, February 14 2005, "Elias Sinderson" wrote to "[e-mail]" saying:

> Curt Ellmann wrote:
> 
> >I agree that one year is too short-- what is the problem with infinitely
> >recurring events?  There are plenty of examples of events that are
> >infinitely recurring-- holidays, anniversaries, and other celebrations.
> >
> I only suggested one year as a matter of conjecture - the limit could be 
> five years, or ten, for that matter, as long as there is a limit which 
> allows a /finite/ expansion of recurring events.

One only semi-tongue-in-cheek suggestion would be "no events past POSIX
time_t 0x7fffffff" (Tue Jan 19 03:14:07 2038 UTC), as such events would I
imagine cause interoperability problems anyway.

> Note that this was in 
> response to Doug Royers observation that "the only noticable issue is 
> infinate recurring entries." I will also note that the cannonical 
> examples provided for infinitely recurring events have been all-day 
> events, which do not suffer from the timezone issues that have been 
> identified.

Note that the Call Processing Language (RFC 3880) normatively cites
iCalendar's RRULE specification, and the usage there has need for rules like
"working hours", e.g. "9 am - 5 pm Monday - Friday".  Any CPL revision would
want to cite a future full RRULE spec, though, not iCal-basic.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1EGiEaa019264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 14 Feb 2005 08:44:14 -0800
Received: (qmail 7005 invoked from network); 14 Feb 2005 16:44:14 -0000
Received: from dsl081-070-219.sfo1.dsl.speakeasy.net (HELO cse.ucsc.edu) (elias@[64.81.70.219]) (envelope-sender <[e-mail]>) by mail22.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 14 Feb 2005 16:44:14 -0000
Message-ID: <[e-mail]>
Date: Mon, 14 Feb 2005 08:42:27 -0800
From: Elias Sinderson <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 14 Feb 2005 16:44:15 -0000

Curt Ellmann wrote:

>I agree that one year is too short-- what is the problem with infinitely
>recurring events?  There are plenty of examples of events that are
>infinitely recurring-- holidays, anniversaries, and other celebrations.
>  
>
I only suggested one year as a matter of conjecture - the limit could be 
five years, or ten, for that matter, as long as there is a limit which 
allows a /finite/ expansion of recurring events. Note that this was in 
response to Doug Royers observation that "the only noticable issue is 
infinate recurring entries." I will also note that the cannonical 
examples provided for infinitely recurring events have been all-day 
events, which do not suffer from the timezone issues that have been 
identified. As per Dougs' suggestion, the inclusion of a property which 
indicates that a METHOD:REFRESH should be done in the future seems like 
a good idea; simply a way to say 'and so on' or 'sync again later'. I 
cannot think of a situation where a client would need to get the 
infinity of recurrences in a single sync and not be able to sync again 
in the future. Further, regarding the question of the duration placed as 
an upper bound, allowing any given implementation to set its' own upper 
bound on recurrences rather than having it rigidly declared in the 
specification would make it possible for devices with limited profiles 
to play along as well.

It may be useful to step back from this issue for a minute and try to 
identify use cases that require scheduling of recurring events (or any 
event), e.g., five years out. Neither Hotels nor airlines will allow one 
to place reservations that far in advance. The most difficult restaraunt 
to dine at in California (French Laundry) only takes reservations 
several months (4?) out. Business meetings are never arranged in this 
matter, and it only seems a matter of convenience to say that this 
meeting will recur infinitely rather than specify an end date several 
years away. As I mentioned before, even so called 'infinitely recurring' 
weekly project meetings are (semi)regularly rescheduled to accomodate 
attendees constraints and other recurring meetings that are scheduled. 
If anyone can provide a use case which requires an infinitely recurring 
event which is not an all day affair (such as holidays, birthdays, 
anniversaries, etc.), please provide it. Extra credit will be given if 
it isn't some freaky and contrived edge case, but occurs frequently 
enough that it would be an honest inconvenience to a user to schedule 
seperate events.

Deprecating infinitely recurring events and placing a sensible upper 
bound as suggested would allow recurring events to be represented as 
either a RRULE or as a finite sequence of events, and would sidestep the 
issues related to timezones that have been raised previously on the 
list. It would seem that the benefits of this simplification greatly 
outweigh the downside of rescheduling a meeting every couple years (if 
it lasts that long) or similar. Further, if RRULEs become an optional 
part of the specification, as has been suggested before, this approach 
would allow interoperability where one system implements RRULEs and the 
other doesn't, as there won't be a problem in an infinite expansion of 
events.


Cheers,
Elias


>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Michiel van
>Leeuwen
>Sent: Saturday, February 12, 2005 2:58 PM
>To: [e-mail]
>Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping
>the version
>
>Elias Sinderson wrote:
>  
>
>>Would it be reasonable to deprecate infinitely recurring events and 
>>place an upperbound of, say, one year on recurring entries? 
>>    
>>
>
>I think it isn't such a great idea, becasue one year is a magic number. 
>Why one year, and not two years?
>  
>



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp6.wiscmail.wisc.edu (fafner.doit.wisc.edu [144.92.197.155]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1EG3eaa016741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 14 Feb 2005 08:03:40 -0800
Received: from avs-daemon.smtp6.wiscmail.wisc.edu by smtp6.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <[e-mail]> for [e-mail]; Mon, 14 Feb 2005 10:03:34 -0600 (CST)
Received: from Sedna (sedna.doit.wisc.edu [128.104.16.139]) by smtp6.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <[e-mail]>; Mon, 14 Feb 2005 10:03:33 -0600 (CST)
Date: Mon, 14 Feb 2005 10:03:26 -0600
From: Curt Ellmann <[e-mail]>
Subject: RE: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
In-reply-to: <[e-mail]>
To: "'Michiel van Leeuwen'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcURRewDy3HKVfNoTdW/XEq5ttItuQBaGR7A
X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.16.139
X-Spam-PmxInfo: Server=avs-7, Version=4.7.1.128075, Antispam-Engine: 2.0.3.0,  Antispam-Data: 2005.2.14.7, SenderIP=128.104.16.139
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 14 Feb 2005 16:03:41 -0000

I agree that one year is too short-- what is the problem with infinitely
recurring events?  There are plenty of examples of events that are
infinitely recurring-- holidays, anniversaries, and other celebrations.

-curt.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Michiel van
Leeuwen
Sent: Saturday, February 12, 2005 2:58 PM
To: [e-mail]
Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping
the version

Elias Sinderson wrote:
> Would it be reasonable to deprecate infinitely recurring events and 
> place an upperbound of, say, one year on recurring entries? 

I think it isn't such a great idea, becasue one year is a magic number. 
Why one year, and not two years?

Michiel

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1DN2GaZ016622 for <[e-mail]>; Sun, 13 Feb 2005 15:02:16 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr2.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1DN2F2H049056 for <[e-mail]>; Mon, 14 Feb 2005 00:02:15 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 14 Feb 2005 00:02:14 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 13 Feb 2005 23:02:17 -0000

Doug Royer wrote:
> No. No move at all. For recurrence rules things are the same.

I expressed myself poorly. I remember someone making the suggestion to 
move. I think it wasn't accepted. The fact that it isn't backward 
compatible would be a very good reason to not accept it.


>> What I think we need is a list of what you can safely generate. This 
>> would be some recommendation. "if you want to do publishing, you can 
>> use this subset. if you do scheduling, you can do this (possibly 
>> other) subset. if you do generate something that isn't on the list, 
>> you are not violation the spec, but might have problems with interop".
> 
> I think that is what I have been proposing.

The proposal was a new spec, which is the old spec with some thing 
removed. What i am suggesting is to keep the old spec, but create a 
best-practices document. That would include what not to use, and how to 
do certain things (for every use-case of iCalendar). (expand a recurring 
event into rdates, don't use exrule etc)

If some client decides to generate exrule anyway, it isn't violating the 
spec. It is just not a good showing nice behaviour.

Michiel


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1DMXbaa013906 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Sun, 13 Feb 2005 14:33:39 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1DMXXt0031136 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sun, 13 Feb 2005 14:33:35 -0800
Message-ID: <[e-mail]>
Date: Sun, 13 Feb 2005 15:33:32 -0700
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] Re: Comments on radical simplification and bumping the version
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------090801020100020206070408"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sun, 13 Feb 2005 22:33:41 -0000

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



Michiel van Leeuwen wrote:
> Doug Royer wrote:
> 
>> Michiel van Leeuwen wrote:
>>
>>> Yes, it can. (except for the suggestion i've read to move timezone 
>>> information to the rrule)
>>
>> What move?
> 
> I though i have seen a suggestion to put the timezone information on the 
> rrule instead of the starttime. But that is not my main point.

No. No move at all. For recurrence rules things are the same.

I am just suggestion that for bound recurrences, it might not be
necessary to convey anything except RDATEs. So everything can
be in UTC. So I think we need to make a rule:

	For bound recurrences - use UTC and RDATEs
	and never use RRULE or EXRULE.

The above works for published, scheduled, and data-exchange of
bound recurrences. I think that covers a huge percentage
of calendar entries.

And I am suggesting that unbound recurrences might not ever
need to be used. Just pick some upper bound and let
people look. So everything can be in UTC. I do not think
that we need to define the upper limit, that will be application
dependent.

People do not really want time zones, they just want it to work.
And they want to tell their GUI that it is at 2pm in FOO time zone.
They do not care if the GUI converts it to UTC before distributing
a bound recurrence.

Unbound recurrences - that is 'I think', the only real issue left.
And if we really need them, lets reduce RRULE to what is used
and needed. (SECONDLY, MINUTELY - are they used ?)


>>> But a new client will still have to be able to read the 'old' ical 
>>> type events. 
>>
>>
>> True in the short term, however over time the old formats will disappear.
> 
> 
> I'm afraid that short term can be pretty long. For example, look at the 
> web. It is full of 'old' documents, full of quirks etc.
> 
>> Many years ago when SMTP was coming out, there was a rule that went
>> something like, "Be generous in what you accept, and  conservative in
>> what you generate". 
> 
> 
> What I think we need is a list of what you can safely generate. This 
> would be some recommendation. "if you want to do publishing, you can use 
> this subset. if you do scheduling, you can do this (possibly other) 
> subset. if you do generate something that isn't on the list, you are not 
> violation the spec, but might have problems with interop".

I think that is what I have been proposing.

> This list would be based on the current clients. If you don't care about 
> other clients, you can use everything from ical.
> The current list would pretty much look like ical-basic. In the future, 
> it might be expanded. If the majorty of used clients would someday 
> safely understand rrules, the list can be updated. But the real spec 
> won't change!

Yes, I think we agree.

For some reason vendors seem reluctant to describe the recurrence rules
they generate. You can play with their GUI and determine if they
support weekly or what ever. Is what you can not tell from their GUI
is how they make up RDATE, EXDATE, RRULE, and EXRULE.

For example:

	Some never generate EXRULE (do any?) they just generate EXDATEs.

	Some never generate RRULE's, they use RDATE and bound them to
	an upper limit.

	Some never really update their RRULE, they just add RDATEs
	and EXDATEs.

So, the trick with scheduling is going to be to find that acceptable
list of how to generate recurrence rules. So far the large vendors
are not talking. So we have to reverse engineer (not accurate), or
look at their features, propose something, and see if they scream :-)


-- 

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

               We Do Standards - You Need Standards


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

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


--------------090801020100020206070408--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1DLp0aZ010963 for <[e-mail]>; Sun, 13 Feb 2005 13:51:00 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1DLoxvL003752 for <[e-mail]>; Sun, 13 Feb 2005 22:50:59 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sun, 13 Feb 2005 22:50:58 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 13 Feb 2005 21:51:01 -0000

Doug Royer wrote:
> Michiel van Leeuwen wrote:
> 
>> Yes, it can. (except for the suggestion i've read to move timezone 
>> information to the rrule)
> What move?
I though i have seen a suggestion to put the timezone information on the 
rrule instead of the starttime. But that is not my main point.

>> But a new client will still have to be able to read the 'old' ical 
>> type events. 
> 
> True in the short term, however over time the old formats will 
> disappear.

I'm afraid that short term can be pretty long. For example, look at the 
web. It is full of 'old' documents, full of quirks etc.

> Many years ago when SMTP was coming out, there was a rule that went
> something like, "Be generous in what you accept, and  conservative in
> what you generate". 

What I think we need is a list of what you can safely generate. This 
would be some recommendation. "if you want to do publishing, you can use 
this subset. if you do scheduling, you can do this (possibly other) 
subset. if you do generate something that isn't on the list, you are not 
violation the spec, but might have problems with interop".
This list would be based on the current clients. If you don't care about 
other clients, you can use everything from ical.
The current list would pretty much look like ical-basic. In the future, 
it might be expanded. If the majorty of used clients would someday 
safely understand rrules, the list can be updated. But the real spec 
won't change!


Michiel


X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1DHGxaZ021031; Sun, 13 Feb 2005 09:17:00 -0800
In-Reply-To: <[e-mail]>
To: Michiel van Leeuwen <[e-mail]>
Subject: Re: [Ietf-calsify] Re: Comments on radical simplification and bumping	the version
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 13 Feb 2005 12:16:56 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/13/2005 12:17:00 PM, Serialize complete at 02/13/2005 12:17:00 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.235 () HTML_30_40,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 13 Feb 2005 17:17:02 -0000

Michael, I think you have hit on a key issue here.  Interestingly enough, 
there was never a "requirements" document established to use as a guide 
for the three RFCs (2445, 2446, 2447).  One was created for CAP but not 
for these three.  The reason for this, I believe, was because there was 
already a base of document established prior to these RFCs.  The original 
CALSCH charter quoted the following documents for use as input to these 
drafts:

* Distributed Scheduling Protocol (CHRONOS) IETF Working Group 
* ISO/IEC SC18 Distributed Office Application for Calendaring, Scheduling 
and Appointments 
* MHS Alliance Calendaring and Scheduling Interoperability Protocol (CSIP) 

* X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA) and 
Calendaring and Scheduling Interoperabilty Specification (CSIS) 
* X/Open Consortium Calendaring and Scheduling (XCS) Implementor's 
Specification 
* Versit vCalendar format 

I figure if people want to go find these original documents, they can try. 
 I have yet to find a full copy of the XAPIA document, which, I believe, 
is a pretty good start for a stab at requirements.

I don't know if you all will find this helpful, but in the past, I have 
held several surveys with organizations to monitor what people wanted in a 
calendar application.  This may help steer people towards some components 
that should be in a standard.  It won't help with the nitty gritty and 
details of how to describe events, timezones, and such, but it does show 
the kinds of things people want to see in a calendaring app.  Please be 
aware that this document needs to be updated to include what users want in 
today's webcentric environment. 

http://www.egenconsulting.com/calreqs.htm
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Michiel van Leeuwen <[e-mail]> 
Sent by: [e-mail]
02/12/2005 08:03 AM

To
[e-mail]
cc

Subject
[Ietf-calsify] Re: Comments on radical simplification and bumping the 
version






Tim Hare wrote:
> if:  The components and properties presented by a radically simple 
> implementation are a subset of iCalendar, so current implementations 
> _should_, if they are compliant, be able to accept these items.

I got a question about the simplification. Some of the simplifications 
are not compatible with the current spec. (like the way timezones are 
supposed to be moved to an extension. Even with the extension you still 
must store the start time in utc)
On the other side, there is talk about seeing what current clients can 
do, and remove the rest from the spec.
But if the spec will not be compatible, why look at current client? Why 
not start from the start, and see what you would need to do good 
calendaring, instead of looking at the bugs in current clients.

Michiel
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1DGfIaZ017844; Sun, 13 Feb 2005 08:41:19 -0800
In-Reply-To: <[e-mail]>
To: Tim Hare <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 13 Feb 2005 11:41:14 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/13/2005 11:41:19 AM, Serialize complete at 02/13/2005 11:41:19 AM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.235 () HTML_30_40,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 13 Feb 2005 16:41:21 -0000

Ditto to your thoughts Tim (from another end-user).  As for the lowest 
subset, that's what the Min-IOP technical committee is working on in the 
consortium.  I actually owe them a document that "sort of" shows what has 
worked over the last several interops.  It's a start - but not complete.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Tim Hare <[e-mail]> 
Sent by: [e-mail]
02/11/2005 08:26 PM

To
[e-mail]
cc

Subject
Re: [Ietf-calsify] Re: What's wrong with more radical simplification?






Wow - I do seem to have a penchant for stirring up discussion!

I admit, here, that I probably went too far with the simplification idea. 
I 
still really want to see UTC as the common exchange time format, but I can 

see the point of retaining some RRULE idea.

Some of the ideas / discussion in response bring out an important (to me) 
point:

Calsify / iCal-Basic is about finding that least common denominator point 
that everyone can agree to implement so that users do not have to worry 
about their publishing or scheduling of events being accepted. As an 
individual user, I want calendaring to be just as simple as e-mail is now 
- 
there must be a set of functions that I can reasonably expect to be there 
in any calendaring tool I use. I don't want to stop and think about it, I 
just want to create the event/meeting/whatever and click 'OK'

Do we have any way to determine what this common set of functions is right 

now? Do the Interop reports from Calconnect give us enough information 
(yet)?


Tim Hare
Interested Bystander, Non-Inc. 


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1CLnSaa015342 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Sat, 12 Feb 2005 13:49:29 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1CLnLKe019715 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sat, 12 Feb 2005 13:49:24 -0800
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 14:49:21 -0700
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] Re: Comments on radical simplification and bumping the version
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------050503070004030009040709"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 21:49:31 -0000

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



Michiel van Leeuwen wrote:
> Doug Royer wrote:
> 
>> It is my belief that any iCal-Basic object can be understood by
>> all current iCalendar implementations. If not, PLEASE point out
>> why not.
> 
> 
> Yes, it can. (except for the suggestion i've read to move timezone 
> information to the rrule)

What move?

> But a new client will still have to be able to read the 'old' ical type 
> events. Because they can receive them. Users won't accept it if a new 
> client will not be able to accept events from older clients.
> So i think that removing things from the spec won't make writing new 
> clients any easier.

True in the short term, however over time the old formats will 
disappear. Just like most implementations no longer support
the XCS calendar format (pre-iCalendar/vCalendar) any more.

And as there is just as much chance that a new implementation will find
yet another way to correctly represent what the current implementations
correctly and differently represent.

Many years ago when SMTP was coming out, there was a rule that went
something like, "Be generous in what you accept, and  conservative in
what you generate". For the most part we can read each others
email. 20 years ago you could read it, but it sometimes had odd stuff
in it from pre-SMTP mailers (Like UUCP email addresses).

I agree with what you are saying. However the current status is not
quite working and yet MUCH closer than pre-iCalendar. I think (And
PLEASE point out where I am wrong) that for NON-scheduling that
iCal-Basic is close if not right on.



-- 

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

               We Do Standards - You Need Standards


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

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


--------------050503070004030009040709--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1CL1eaZ004932 for <[e-mail]>; Sat, 12 Feb 2005 13:01:40 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr2.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1CL1dCW087906 for <[e-mail]>; Sat, 12 Feb 2005 22:01:39 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 22:01:38 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 21:01:41 -0000

Doug Royer wrote:
> It is my belief that any iCal-Basic object can be understood by
> all current iCalendar implementations. If not, PLEASE point out
> why not.

Yes, it can. (except for the suggestion i've read to move timezone 
information to the rrule)
But a new client will still have to be able to read the 'old' ical type 
events. Because they can receive them. Users won't accept it if a new 
client will not be able to accept events from older clients.
So i think that removing things from the spec won't make writing new 
clients any easier.

Michiel


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1CKwHaZ004746 for <[e-mail]>; Sat, 12 Feb 2005 12:58:18 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr3.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1CKwGd3046795 for <[e-mail]>; Sat, 12 Feb 2005 21:58:16 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 21:58:15 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 20:58:19 -0000

Elias Sinderson wrote:
> Would it be reasonable to deprecate infinitely recurring events and 
> place an upperbound of, say, one year on recurring entries? 

I think it isn't such a great idea, becasue one year is a magic number. 
Why one year, and not two years?

Michiel



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1CKjOaa002301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 12 Feb 2005 12:45:24 -0800
Received: (qmail 32553 invoked from network); 12 Feb 2005 20:45:23 -0000
Received: from dsl081-070-219.sfo1.dsl.speakeasy.net (HELO cse.ucsc.edu) (elias@[64.81.70.219]) (envelope-sender <[e-mail]>) by mail22.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 12 Feb 2005 20:45:23 -0000
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 12:43:18 -0800
From: Elias Sinderson <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 20:45:24 -0000

Doug Royer wrote:

> [...] As far as I can tell the only noticable issue is infinate 
> recurring entries. So could we add a propertry or parameter that says, 
> "and
> there are more so when you run out - send a METHOD:REFRESH to get the 
> next year (or whatever) of them" ?

Given the following:
(a) infinitely recurring meetings aren't really infinite and
(b) people don't last forever anyway
FWIW, the weekly project meetings I've been involved with for the 
several years get shuffled about more than once per year to adjust to 
other scheduling constraints, and I believe this is fairly typical. The 
only things which don't really get shuffled about are things like 
holidays...

Would it be reasonable to deprecate infinitely recurring events and 
place an upperbound of, say, one year on recurring entries? This 
approach seems more reasonable than adding additional methods to the 
base spec, since no existing clients currently implement any methods 
that are added to the spec.


Cheers,
Elias


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1CKODaa032066 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Sat, 12 Feb 2005 12:24:14 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1CKO5Ke018807 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sat, 12 Feb 2005 12:24:08 -0800
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 13:24:04 -0700
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] Re: Comments on radical simplification and bumping the version
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030307090005090600040805"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 20:24:17 -0000

This is a cryptographically signed message in MIME format.

--------------ms030307090005090600040805
Content-Type: multipart/mixed; boundary="------------080302080009000101090608"

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



Michiel van Leeuwen wrote:
> Tim Hare wrote:
> 
>> if:  The components and properties presented by a radically simple 
>> implementation are a subset of iCalendar, so current implementations 
>> _should_, if they are compliant, be able to accept these items.
> 
> 
> I got a question about the simplification. Some of the simplifications 
> are not compatible with the current spec. (like the way timezones are 
> supposed to be moved to an extension. Even with the extension you still 
> must store the start time in utc)

Current implementations can handle start time in UTC. And current
implementations can handle VEVENTS in UTC without a time zone.

So please point out what makes these objects incompatable.

It is my belief that any iCal-Basic object can be understood by
all current iCalendar implementations. If not, PLEASE point out
why not.


> On the other side, there is talk about seeing what current clients can 
> do, and remove the rest from the spec.
> But if the spec will not be compatible, why look at current client? Why 
> not start from the start, and see what you would need to do good 
> calendaring, instead of looking at the bugs in current clients.

Or the other approach. Split out publishing / METHOD:PUBLISH from; data
exchange, scheduling, and storage.

The vast majority of implementations do not do scheduling. So why
not split it out?

As far as I can tell the only noticable issue is infinate recurring
entries. So could we add a propertry or parameter that says, "and
there are more so when you run out - send a METHOD:REFRESH to get
the next year (or whatever) of them" ?

-- 

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

               We Do Standards - You Need Standards


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

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


--------------080302080009000101090608--

--------------ms030307090005090600040805
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
9w0BCQUxDxcNMDUwMjEyMjAyNDA0WjAjBgkqhkiG9w0BCQQxFgQU8o36LQ+UBynWQpV1WNYV
0KCGb6UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAscRHUP0+vZuADf+qS7g5clGvthWfPRqLFpbe1lKqFfpVTt3oBWMd8gJeJk25TzPb
KslVDl+PMiYaRUScx9ah1i6r8w3XzfVYNAndFhrhmYexXQMZrLeFJUGE8C4/R5UifnKcvrY/
jRQMRHwiyCGdgwedEUBIMa8H2nMKS+dCyajDOQ/aGvQRPj+Rnz4+DM8e3sEKSdzu3PPB7ol9
7RUHoBRecpbXU6c0oD9Bo3Z9qJrdVW2/A9R9mPHJUAPGQ5nrFQS4EcH4xT8pEfJ7xcQoiCWs
HMnrgB45PFJOlE4GTya32OQ6CcCGjtr38bsUbStO2GQbnagLZ5U+X6xCP5mVGAAAAAAAAA==
--------------ms030307090005090600040805--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1CKEWaa030996 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Sat, 12 Feb 2005 12:14:33 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1CKEIKe018745 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sat, 12 Feb 2005 12:14:26 -0800
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 13:14:17 -0700
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] Re: What's wrong with more radical simplification?
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040405090603030004040305"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 20:14:35 -0000

This is a cryptographically signed message in MIME format.

--------------ms040405090603030004040305
Content-Type: multipart/mixed; boundary="------------070507000000090307060303"

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



Reinhold Kainhofer wrote:

> 
> You already need everything everyone needs for simple data exchange like 
> drag'n'drop!  And iCalendar was designed for exactly these kinds of thing (at 
> least that's how I understand the intro).

For drag'n'drop you do not need a calendar name.
You do not need access control, authentication, and
other things stuffed into the object. You do not
need to have information about how to create objects,
delete object, tracking of who got what revisions, ...
for drag'n'drop'.

Publishing or METHOD:PUBLISH does not need any of those
and other things.


-- 

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

               We Do Standards - You Need Standards


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

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


--------------070507000000090307060303--

--------------ms040405090603030004040305
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
9w0BCQUxDxcNMDUwMjEyMjAxNDE3WjAjBgkqhkiG9w0BCQQxFgQU8xZTva0dxm10UfrwOgi1
OthsxjkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAgm9/5dYftuezzMKxW0PX1u9g9Rl3Rk5IOoftJQymxjkem4H/Ut5ntnO+MFVfm7go
tgIZKDEesMw/HEbpWidHmL3ki6WoMq9P2yuIsT1z5BFqG4135w9ZDgAFDTLTsAoq87f+hyfz
OCCQ4IRQPCRaw1HT+yArMdeCGzbQ4fk1mvQielsqiZTS6sMYf8LkPguf4dJd6+otOj1rghAN
ril7c1sVgRepYsLpIS9yvClaUMJsDjUiFvnT0GOVZqg36/HpHi6JJxNKy2uJ7gesuTm7ieVS
oAtQdNaB9G1KpVcxuXSWsFE0kRmFQ3gXAlRV7Qu/C3kkrsv+FFqcqAU5HG7wUAAAAAAAAA==
--------------ms040405090603030004040305--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1CD3BaZ029801 for <[e-mail]>; Sat, 12 Feb 2005 05:03:11 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr13.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1CD3AHV057761 for <[e-mail]>; Sat, 12 Feb 2005 14:03:10 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 14:03:09 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 13:03:14 -0000

Tim Hare wrote:
> if:  The components and properties presented by a radically simple 
> implementation are a subset of iCalendar, so current implementations 
> _should_, if they are compliant, be able to accept these items.

I got a question about the simplification. Some of the simplifications 
are not compatible with the current spec. (like the way timezones are 
supposed to be moved to an extension. Even with the extension you still 
must store the start time in utc)
On the other side, there is talk about seeing what current clients can 
do, and remove the rest from the spec.
But if the spec will not be compatible, why look at current client? Why 
not start from the start, and see what you would need to do good 
calendaring, instead of looking at the bugs in current clients.

Michiel


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1C9dYaa017252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 12 Feb 2005 01:39:35 -0800
Received: from ip6-localhost ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1C9dViM025114 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Sat, 12 Feb 2005 10:39:33 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Sat, 12 Feb 2005 10:39:29 +0100
User-Agent: KMail/1.7.92
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1170573.1Y8MnYdoqU"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 09:39:48 -0000

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

Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare:
> Calsify / iCal-Basic is about finding that least common denominator point
> that everyone can agree to implement so that users do not have to worry
> about their publishing or scheduling of events being accepted. As an
> individual user, I want calendaring to be just as simple as e-mail is now=
 -

Hehe, you chose the wrong example here. Do you know how complex the=20
specification for email is (in particular the mime spec and all the various=
=20
encodings possible)? iCalendar is trivial compared to those specs...=20

Just because something appears simple to the user, doesn't mean that the=20
specification behind it is simple. Most times I think it's just the=20
opposite...=20
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

--nextPart1170573.1Y8MnYdoqU
Content-Type: application/pgp-signature

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

iD8DBQBCDc7STqjEwhXvPN0RAoqNAKDdstduOQCVGUn+FIcI7g4aN+hXbQCcCSue
cm2FFNicXZwutSGBr+Z3eCc=
=n5xG
-----END PGP SIGNATURE-----

--nextPart1170573.1Y8MnYdoqU--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1C9Ymaa017141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 12 Feb 2005 01:34:50 -0800
Received: from ip6-localhost ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1C9Yjrb024608 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Sat, 12 Feb 2005 10:34:47 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Sat, 12 Feb 2005 10:34:42 +0100
User-Agent: KMail/1.7.92
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3710403.xWqcledKGE"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 09:34:57 -0000

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

Am Samstag, 12. Februar 2005 00:23 schrieb Doug Royer:
> Michiel van Leeuwen wrote:
> > ... I'm thinking about the way sunbird handles
> > sharing a calendar here. You don't want to lose the recurrence
> > information the next time you open the file.
>
> People and applications use ICS files as their cal store,
> however iCalendar was not designed as a file store. Trying to
> make it do both is part of the problem. You end up with
> everything everyone needs.

You already need everything everyone needs for simple data exchange like=20
drag'n'drop!  And iCalendar was designed for exactly these kinds of thing (=
at=20
least that's how I understand the intro).

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

--nextPart3710403.xWqcledKGE
Content-Type: application/pgp-signature

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

iD8DBQBCDc20TqjEwhXvPN0RAscDAKDdiJ276p9eeQwjrXD7Ezqui9Y32wCg2Yem
mAAi4AGPHaVDUIhC/TAJIcE=
=rMeE
-----END PGP SIGNATURE-----

--nextPart3710403.xWqcledKGE--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1C1RwaZ017570 for <[e-mail]>; Fri, 11 Feb 2005 17:27:58 -0800
Received: from computer.comcast.net (pcp0011451694pcs.micske01.fl.comcast.net[69.244.223.118]) by comcast.net (rwcrmhc13) with SMTP id <2005021201275201500e0oepe>; Sat, 12 Feb 2005 01:27:53 +0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 11 Feb 2005 20:26:42 -0500
To: [e-mail]
From: Tim Hare <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
In-Reply-To: <OF6EFDEEB2.D8C1D211-ON85256FA5.00806B61-05256FA5.00809AFD@ egenconsulting.com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 01:27:58 -0000

Wow - I do seem to have a penchant for stirring up discussion!

I admit, here, that I probably went too far with the simplification idea. I 
still really want to see UTC as the common exchange time format, but I can 
see the point of retaining some RRULE idea.

Some of the ideas / discussion in response bring out an important (to me) 
point:

Calsify / iCal-Basic is about finding that least common denominator point 
that everyone can agree to implement so that users do not have to worry 
about their publishing or scheduling of events being accepted. As an 
individual user, I want calendaring to be just as simple as e-mail is now - 
there must be a set of functions that I can reasonably expect to be there 
in any calendaring tool I use. I don't want to stop and think about it, I 
just want to create the event/meeting/whatever and click 'OK'

Do we have any way to determine what this common set of functions is right 
now? Do the Interop reports from Calconnect give us enough information (yet)?


Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1C13xaa015702 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 17:04:00 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1C13tKe005847 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 17:03:58 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 18:03:55 -0700
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] Comments on radical simplification and bumping the	version
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------050004020803060707000402"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 01:04:02 -0000

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



> 
> Since sending two representations is kind of expensive (but as Nathaniel 
> pointed out, in this age of BitTorrent, who would notice?), a version n 
> identification would seem to be the better solution. I don't agree with 
> using VERSION: 3.0, however.  To me, it makes more sense for the 
> radically simple versions to be VERSION: 1.5  - i.e. more than vCalendar 
> and less than the current iCalendar.
> 

The iCal VERSION property takes a range. So we could do:

	VERSION:2.0,2.1

	VERSION:2.0.3.0

	....

That could mean that the sender supports a newer version
and understands the old.
-- 

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

               We Do Standards - You Need Standards


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

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


--------------050004020803060707000402--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1C0uuaZ013237 for <[e-mail]>; Fri, 11 Feb 2005 16:56:56 -0800
Received: from computer.comcast.net (pcp0011451694pcs.micske01.fl.comcast.net[69.244.223.118]) by comcast.net (rwcrmhc11) with SMTP id <2005021200564901300m9j85e>; Sat, 12 Feb 2005 00:56:49 +0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 11 Feb 2005 19:55:38 -0500
To: [e-mail]
From: Tim Hare <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Comments on radical simplification and bumping the version
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Sat, 12 Feb 2005 00:56:57 -0000

if:  The components and properties presented by a radically simple 
implementation are a subset of iCalendar, so current implementations 
_should_, if they are compliant, be able to accept these items.

and

if: Sending items to a radically simple implementation means that 
components and properties which are not part of the radically simplified 
set should not be sent, or should be sent only as an alterative representation

then: there needs to be a way for current implementations to know what 
they're exchanging items with so they can  send only the simple subset
or: they send two representations and recipients use what they can deal with

Since sending two representations is kind of expensive (but as Nathaniel 
pointed out, in this age of BitTorrent, who would notice?), a version n 
identification would seem to be the better solution. I don't agree with 
using VERSION: 3.0, however.  To me, it makes more sense for the radically 
simple versions to be VERSION: 1.5  - i.e. more than vCalendar and less 
than the current iCalendar.

Tim Hare
Interested Bystander, Non-Inc.

Tim Hare
Interested Bystander, Non-Inc. 




X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BNbTaZ032540; Fri, 11 Feb 2005 15:37:29 -0800
In-Reply-To: <[e-mail]>
To: Mark Swanson <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 11 Feb 2005 18:37:28 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/11/2005 06:37:29 PM, Serialize complete at 02/11/2005 06:37:29 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.89 () HTML_20_30,HTML_MESSAGE,NO_REAL_NAME,UPPERCASE_25_50
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail], [e-mail]
Subject: [Ietf-calsify] Re: EXRULE and multiple RRULEs - Frank Dawson store examples
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 23:37:32 -0000

Here's what Frank posted 8/18/1999 - wow that's a long time ago...... 8-)
=============================================

>This is Sam's bakery's opening times for the year 2000 and onward.
>
>Sam's bakery is open from 7 to 12 and 13 to 18, Monday through Thursday.
>(They close for lunch between 12 and 13)
>Sam's is open from 7 to 12 and 13 to 15.30  on Fridays
>Sam's is open from 9 to 13 on Saturdays
>Sam's is closed on Sundays
>Sam's does not open on Saturdays during the period of July 5 to August 5
>Sam shuts down on the following holidays;  Jan 1, Feb, 12 July 9, Oct 8, 
Dec
>24, 25 

FYI. I think you mean EXDATE, not EDATE in your original note. 
The easiest way to represent these store hours is to define separate 
VEVENTs and relate them using the RELATED-TO property. How about this 
using four events, one for the weekday morning store hours, a second for 
the weekday MO-TH afternoon store hours, a third for the weekday FR 
afternoon store hours and a fourth for the weekend store hours. 
Interesting, this is very much the same way that the store hours would be 
listed on the front door or on a website for the store! Actually, it is 
VERY important to keep the store hours as separate VEVENTS, as there will 
most probably be different store help for each. Your know the quirks of 
these unions ;-) In addition, if you copy the events on to the employee's 
work calendars you will want them as separate events. Bill won't want to 
see he is working the weekend when he has a hot date with Sally! There are 
probably other good reasons to have these as separate but linked/related 
events too. 
BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH 
BEGIN:VEVENT
DTSTAMP:19990101T100000Z
UID:123
DTSTART;TZID=US/Eastern:19990104T070000
DTEND;TZID=US/Eastern:19990104T120000
SUMMARY:Sam's Bakery Weekday Morning Hours
RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
EXDATE:19990101,19990212,19990709,19991008,19991224,19991225
RELATED-TO;RELTYPE=SIBLING:124
RELATED-TO;RELTYPE=SIBLING:125
RELATED-TO;RELTYPE=SIBLING:126
END:VEVENT 
BEGIN:VEVENT
DTSTAMP:19990101T100001Z
UID:124
DTSTART;TZID=US/Eastern:19990104T130000
DTEND;TZID=US/Eastern:19990104T180000
SUMMARY:Sam's Bakery MO-TH Afternoon Hours
RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH
EXDATE:19990101,19990212,19990709,19991008,19991224,19991225
RELATED-TO;RELTYPE=SIBLING:123
RELATED-TO;RELTYPE=SIBLING:125
RELATED-TO;RELTYPE=SIBLING:126
END:VEVENT 
BEGIN:VEVENT
DTSTAMP:19990101T100001Z
UID:125
DTSTART;TZID=US/Eastern:19990101T130000
DTEND;TZID=US/Eastern:19990101T183000
SUMMARY:Sam's Bakery FR Afternoon Hours
RRULE:FREQ=WEEKLY;BYDAY=FR
EXDATE:19990101,19990212,19990709,19991008,19991224,19991225
RELATED-TO;RELTYPE=SIBLING:123
RELATED-TO;RELTYPE=SIBLING:125
RELATED-TO;RELTYPE=SIBLING:126
END:VEVENT 
BEGIN:VEVENT
DTSTAMP:19990101T100001Z
UID:126
DTSTART;TZID=US/Eastern:19990102T090000
DTEND;TZID=US/Eastern:19990102T130000
SUMMARY:Sam's Bakery Weekend Hours
DESCRIPTION:NOTE: We are closed SUNDAYS.\n   We will also
 be closed on Saturdays, from July 5 through August 5.\n
We hope you enjoy your summer holidays also! -- Sam's
RRULE:FREQ=WEEKLY;BYDAY=SA
EXDATE:19990101,19990212,19990709,19991008,19991224,19991225
EXDATE:19990710,19990717,19990724,19990731
RELATED-TO;RELTYPE=SIBLING:123
RELATED-TO;RELTYPE=SIBLING:124
RELATED-TO;RELTYPE=SIBLING:125
END:VEVENT 
END:VCALENDAR 
One thing this exercise does point out is that it would have been very 
useful to have a ";START=" RECUR value, rule component. This would have 
been useful in the EXRULE definition for the Saturday close dates. For 
example, with this enhancement: 
EXRULE:FREQ=WEEKLY;BYDAY=SA;START=19990710;UNTIL=19990805 
Maybe Doug Royer could add this to his issues list? 
-- Frank  



Mark Swanson <[e-mail]> 
Sent by: [e-mail]
02/11/2005 02:55 PM

To
[e-mail]
cc

Subject
[Fwd: Re: [Ietf-calsify] EXRULE and multiple RRULEs]






Reinhold Kainhofer wrote:
> On Friday 11 February 2005 19:27, Doug Royer wrote:
> 
>>Currently 2445 allows for multiple RRULEs per component.
>>Can we agree that if RRULEs will remain, that they be limited to one?
> 
> 
> I don't think it's necessary to have multiple RRULES.
> Is there any application / library that supports multiple RRULES in one 
event 
> at all? libkcal (and thus all KDE applications that use iCalendar, like 

The ScheduleWorld iCalendar library does. If I remember right Frank
Dawson posted some examples of store hours specified with multiple
RRULEs (and more).

-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BNStaZ031559; Fri, 11 Feb 2005 15:28:56 -0800
In-Reply-To: <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] Example RRULEs
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 11 Feb 2005 18:28:56 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/11/2005 06:28:56 PM, Serialize complete at 02/11/2005 06:28:56 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.235 () HTML_30_40,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 23:28:58 -0000

Yes indeed, Cyrus, I think we can arrange for test examples to be on the 
Calconnect website.  Bravo!
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Cyrus Daboo <[e-mail]> 
Sent by: [e-mail]
02/11/2005 01:04 PM

To
[e-mail]
cc

Subject
[Ietf-calsify] Example RRULEs






To help with interop testing, I have made the following available:

1) 
<
http://www.mulberrymail.com/davroot/calendars/public/iCalendarTests/2445AllExamples.ics
>

This contains all the recurrence examples from 2445 Section 4.8.5.4 in one 

.ics file. The SUMMARY of each item indicates the example number in order 
from that section. The DESCRIPTION is the description from 2445 for each 
example. Note that some examples have a couple of variants and these are 
indicated by additional letters in the numbering (e.g. 05a 05b etc). Most 
of the examples use start dates in 1997, but there are some unbounded 
examples that will fill up the calendar display e.g. 'Every 20 minutes 
from 
9:00 AM to 4:40 PM every day'.

2) 
<
http://www.mulberrymail.com/davroot/calendars/public/iCalendarTests/PayDay.ics
>

This contains a single recurring event that uses a BYSETPOS. It 
corresponds 
to 'the last weekday in the month'.

Feel free to use these in whatever way you want.

If you have your own set of test events etc that you could share please 
let 
me know. Ultimately it would make sense to have all those on say the 
Calconnect website to help people do implementations. I am sure we can 
arrange that if there is interest...

-- 
Cyrus Daboo
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BNOiaZ031408; Fri, 11 Feb 2005 15:24:45 -0800
In-Reply-To: <[e-mail]>
To: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 11 Feb 2005 18:24:44 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/11/2005 06:24:45 PM, Serialize complete at 02/11/2005 06:24:45 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.683 () HTML_20_30,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 23:24:48 -0000

Helge, I think it's a pretty safe bet that the vendors you stated in your 
note do not 100% support the rrules  icalendar specs - I'd be surprised if 
they did 50%.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Helge Hess <[e-mail]> 
Sent by: [e-mail]
02/11/2005 12:04 PM

To
[e-mail]
cc

Subject
Re: [Ietf-calsify] Re: What's wrong with more radical simplification?






On Feb 11, 2005, at 17:33, Michiel van Leeuwen wrote:
> Helge Hess wrote:
>> If you have some standard you basically always loose information 
>> since you need to find a viable common denominator.
> I think that is the wrong approach.

Its not an approach at all, its just a statement/fact. Most 
clients/servers use iCalendar for interoperability, not for their 
implementation (and can therefore only expose iCal features, not their 
full functionality).

This is a bit different for most OpenSource clients, which also use 
iCalendar for storing the information.

> Fix the clients.
> Or come up with something completly new, that new clients can 
> implement correctly. But that will take even longer.

You have the assumption that fixing the clients is an easy and viable 
task. I had the impression that currently rrules can represent every 
recurrence model which was supported by the initial protocol creators. 
This in turn makes it very complex and forces everyone to implement all 
the rrules of the others (and in practice nobody does that which makes 
rrules not interoperable).

But people suggested that I might be wrong on how compliant current 
clients are. Do Outlook, Kontact, Evolution, Mozilla, iCal.app really 
support 100% of the currently specified iCalendar rrules? I would be 
surprised, but pleased to hear some actual investigation on that.

> imo extensions also are the wrong solution. If i want to publish my 
> calendar, i can't use the extensions, because i don't know what other 
> clients will read the file.

Thats a rather weird statement. Why can't you use the extensions? If 
the "other" client supports them, he will have additional information, 
if not, he will fall back to the base spec.

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

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BNNHaa031231 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 15:23:18 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1BNNDKe004460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 15:23:15 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 16:23:13 -0700
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] Re: What's wrong with more radical simplification?
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040702030305020306000201"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Fri, 11 Feb 2005 23:23:21 -0000

This is a cryptographically signed message in MIME format.

--------------ms040702030305020306000201
Content-Type: multipart/mixed; boundary="------------020807030700030606050205"

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



Michiel van Leeuwen wrote:
> ... I'm thinking about the way sunbird handles 
> sharing a calendar here. You don't want to lose the recurrence 
> information the next time you open the file.

People and applications use ICS files as their cal store,
however iCalendar was not designed as a file store. Trying to
make it do both is part of the problem. You end up with
everything everyone needs.

What you need in a cal store and what you need to schedule with
someone is not the same set of data.

-- 

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

               We Do Standards - You Need Standards


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

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


--------------020807030700030606050205--

--------------ms040702030305020306000201
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
9w0BCQUxDxcNMDUwMjExMjMyMzEzWjAjBgkqhkiG9w0BCQQxFgQUOvd4wU73xtWdl77NYfeH
979PSOAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAPHDme0Nmw2lybzJ/GIgfeLT7/oKRs16iRAI0zhsfSrGHDy8cnCdoz3mAcSIJzJw5
IV//K92UOkg0KO5IYew8zdF6eiOFODsJqPkScFLYZwy1sjiP9bZXSZsJsqvr0YdEG55WrBL8
xqMLHNX9mtttmQ+5GgocMUwVXo1OqUWcAypuh6/2AEkrTrXhQ1ssByVmnTYpTuuGWRRC+VED
8ry44bKQ8qXKF51Cp2fjS6RnJCh9fI7eYAULN/tkKuhiS8Z/SJMu18DlksVedotjGrSWFDkW
LG6qdubfG6NPqQgsCqK+XqNGOi28/vLVUBfFEyFezNQBs5iwq4DCTBA8hLrzPQAAAAAAAA==
--------------ms040702030305020306000201--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BN5paZ030169 for <[e-mail]>; Fri, 11 Feb 2005 15:05:52 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr15.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1BN5oYu010668 for <[e-mail]>; Sat, 12 Feb 2005 00:05:51 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 00:05:50 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: What's wrong with more radical simplification?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 23:05:53 -0000

Doug Royer wrote:
> Not with the ideas as proposed. The idea was to send out the data
> expanded (into multiple components or RDATEs - in UTC) and
> optionally also send the extension object unexpanded (w/ timezone info).
> 
Ok, i was more thinking about extensions in general. The two proposed 
extensions indeed have a fallback. Also, i was more thinking about the 
current usage of timezones in dtstart.

So for every extension there must be a fallback.

> Only when you want the recipient to understand the GUI user had clicked
> on weekly (or whatever) do you need to send out the recurrence rules.

Yeah, and that is important imho. First because of the infinite 
recurring events. (Yes, i know they will end one day, but you don't know 
that end date. i'm still not happy with forcing the user to come up with 
some value, or to add a magic number)
Second, for data exchange. I'm thinking about the way sunbird handles 
sharing a calendar here. You don't want to lose the recurrence 
information the next time you open the file.
Also, in real-life i'm thinking as an appointment as something 
recurring, not as a list of dates. removing that information requires 
the client to show a nice visual list to make it possible for the user 
to see the relation (every monday). If i know it is every monday at 10, 
I just need to check my weekly schedule to see if it fits for me. 
Without the information, i need to check every week. (this can be 
automated of course, but that depends on the user putting everything on 
his calendar. Again forcing the user to do something to make the spec a 
bit less complex)


Michiel


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BLeiaa017176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 13:40:45 -0800
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j1BLedwW006177; Fri, 11 Feb 2005 16:40:39 -0500 (EST) (envelope-from [e-mail])
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j1BLecBN006174; Fri, 11 Feb 2005 16:40:38 -0500 (EST) (envelope-from lennox)
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 16:40:38 -0500
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] Example RRULEs
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 21:40:48 -0000

On Friday, February 11 2005, "Cyrus Daboo" wrote to "[e-mail]" saying:

> If you have your own set of test events etc that you could share please let 
> me know. Ultimately it would make sense to have all those on say the 
> Calconnect website to help people do implementations. I am sure we can 
> arrange that if there is interest...

Would you be interested in a set of "pathological corner case RRULEs"?  We
discussed a bunch of these on the list back in 2001.  (Be aware that there
may not be consensus about what they mean...)

-- 
Jonathan Lennox
[e-mail]


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BL0Kaa004446 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 13:00:21 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1BL0DKe002578 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 13:00:16 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 14:00:13 -0700
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] Re: What's wrong with more radical simplification?
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------010503040802080400070001"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Fri, 11 Feb 2005 21:00:22 -0000

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



Michiel van Leeuwen wrote:
> Helge Hess wrote:
> 
>> Thats a rather weird statement. Why can't you use the extensions? If 
>> the "other" client supports them, he will have additional information, 
>> if not, he will fall back to the base spec.
> 
> 
> Let's assume that timezones move to an extension. The client i use 
> supports them. So, the start time of en event is defined with a 
> timezone. I publish the calendar. (upload the whole ics file). Someone 
> else reads it using a client that doesn't support timezones. How can he 
> fall back? he has to ignore the timezone information, because he doesn't 
> understand it. He can either use the time in the wrong timezone, or 
> ignore the time completely. Both is wrong.
> So, if i want my calendar to be readable by other clients, i can't use 
> timezones.
> The same story would hold for other extensions.


Not with the ideas as proposed. The idea was to send out the data
expanded (into multiple components or RDATEs - in UTC) and
optionally also send the extension object unexpanded (w/ timezone info).

For PUBLISH and most scheduling the expanded objects work just fine
as they have to work with RDATEs right now anyway.

Only when you want the recipient to understand the GUI user had clicked
on weekly (or whatever) do you need to send out the recurrence rules.

If you wish to synchronize entire objects including the ORGANIZERS
intent, then you do care about the recurrence rules. If you doing
scheduling with others - you just care if they can attend the
instance times.

In most cases, I do not visually check the recurrence rules in
the GUI or ICS file, I just look at when it places dates in
my calendar, or what any accompanying descriptive text sent
in an associated MIME object says about the meeting.

If a weekly meeting notice were sent out for one years
worth of time and it had 10 exception dates in it. How many
of you look at the GUI recurrence panel to see it? Many of
the GUI's out there can not display such objects even when
they can add them correctly to your calendar.

-- 

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

               We Do Standards - You Need Standards


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

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


--------------010503040802080400070001--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BKoIaa001515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 12:50:20 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1BKoAKe002413 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 12:50:13 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 13:50:09 -0700
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] Re: What's wrong with more radical simplification?
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030306020406080408080204"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Fri, 11 Feb 2005 20:50:23 -0000

This is a cryptographically signed message in MIME format.

--------------ms030306020406080408080204
Content-Type: multipart/mixed; boundary="------------050304010106090805010008"

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



Michiel van Leeuwen wrote:
> Helge Hess wrote:
> 
>> Thats a rather weird statement. Why can't you use the extensions? If 
>> the "other" client supports them, he will have additional information, 
>> if not, he will fall back to the base spec.
> 
> 
> Let's assume that timezones move to an extension. The client i use 
> supports them. So, the start time of en event is defined with a 
> timezone. I publish the calendar. (upload the whole ics file). Someone 
> else reads it using a client that doesn't support timezones. How can he 
> fall back? he has to ignore the timezone information, because he doesn't 
> understand it. He can either use the time in the wrong timezone, or 
> ignore the time completely. Both is wrong.
> So, if i want my calendar to be readable by other clients, i can't use 
> timezones.
> The same story would hold for other extensions.

Not with the ideas as proposed. The idea was to send out the data
expanded (into multiple components or RDATEs - in UTC) and
optionally also send the extension object unexpanded (w/ timezone info).

For PUBLISH and most scheduling the expanded objects work just fine
as they have to work with RDATEs right now anyway.

Only when you want the recipient to understand the GUI user had clicked
on weekly (or whatever) do you need to send out the recurrence rules.

If you wish to synchronize entire objects including the ORGANIZERS
intent, then you do care about the recurrence rules. If you doing
scheduling with others - you just care if they can attend the
instance times.

In most cases, I do not visually check the recurrence rules in
the GUI or ICS file, I just look at when it places dates in
my calendar, or what any accompanying descriptive text sent
in an associated MIME object says about the meeting.

If a weekly meeting notice were sent out for one years
worth of time and it had 10 exception dates in it. How many
of you look at the GUI recurrence panel to see it? Many of
the GUI's out there can not display such objects even when
they can add them correctly to your calendar.
-- 

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

               We Do Standards - You Need Standards


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

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


--------------050304010106090805010008--

--------------ms030306020406080408080204
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
9w0BCQUxDxcNMDUwMjExMjA1MDA5WjAjBgkqhkiG9w0BCQQxFgQUQlxgzailHIth9LB54mcO
ucQewJgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAkzgso5xG+vrJD6EOvOz1qKU1Gpm2LjEuN9mY8rv5Rg71LJ6stGzjZGM7Uu30+8n3
wCJX939zwmW5GImq2nVMgJTqHR2f7DujlMGSq4yupnHWr5v7mlqrTAQ4g3IQ5Pdey4RBoHkz
1sC6imygxVaWlWvLJJ2S46+kGH9qGimg8JmjokW2Y0FIcoXhIrELU2RD0Vt+zyJ+kAqmeWxe
3Mg/kIGGoPuPvIHbD1PnPwa3pT9J+3lIyp9ZJ2PPO5H43e6SWZcMlua1GgQHH05vD0iL1r7A
G5JZj9VBmPuMAv9UgkBL5z+zhpDNxnvNK8cYGVS/IRIYvbGSacxrpjr0DIZWvwAAAAAAAA==
--------------ms030306020406080408080204--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [69.44.62.208]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1BKa5aZ030400 for <[e-mail]>; Fri, 11 Feb 2005 12:36:05 -0800
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.2.1-RC1) with SMTP ID 454 for <[e-mail]>; Fri, 11 Feb 2005 14:36:04 -0600 (CST)
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 15:36:07 -0500
From: Mark Swanson <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 20:36:10 -0000

> On Feb 11, 2005, at 18:16, Mark Swanson wrote:
> 
>> Well, ScheduleWorld 100% implements RRULEs. The GUI doesn't reflect 
>> this because then folks could create RRULEs that wouldn't interoperate 
>> with a few other products.
> 
> 
> Isn't that a contradiction? What good is an rrule if you can't display 
> it? Of course I believe you that you can parse the iCalendar structure 
> of the rrule, but what good is the data if the user can't view/edit it?

I didn't say the user couldn't view it. If any other product uses all of
the RRULE capabilities it will render properly in ScheduleWorld. The
event will be on the right day in the day/week/month/etc.. view.

> Unless I'm missing something, not reflecting the rrule in the GUI is 
> exactly the same like not supporting it. And reflecting _all_ the 
> specified rrules in iCalendar should be quite difficult (if not 
> impossible if you still want to have good usability ;-).

Again, iCalendar views and editing VEVENTs are different. At least when
I overlay someone else's calendar with mine I will be able to see when
they are busy - I don't even have to edit their VEVENT.

>> My current impression is that RRULEs are fairly well supported - even 
>> by lesser known products like phpICalendar.
> 
> 
> My impression is that a lot of clients use a similiar subset of the 
> specified rrules and that this subset works pretty well. But it might be 
> wrong.

I think this group is on the right track by accepting RRULEs but perhaps
limiting the recurring event concept to the useful already implemented
subset by most vendors.

-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BKSuaZ029103 for <[e-mail]>; Fri, 11 Feb 2005 12:28:57 -0800
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id E0AA82D7E87 for <[e-mail]>; Fri, 11 Feb 2005 21:28:22 +0100 (CET)
Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 5044C2D2861 for <[e-mail]>; Fri, 11 Feb 2005 21:28:22 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 21:28:50 +0100
To: [e-mail]
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 20:29:02 -0000

On 11. Feb 2005, at 21:12 Uhr, Michiel van Leeuwen wrote:
> Let's assume that timezones move to an extension. The client i use 
> supports them. So, the start time of en event is defined with a 
> timezone.

No, the start time would still be defined in UTC, the timezone would be 
added as a hint (actually a required one for the rrules extension).

> I publish the calendar. (upload the whole ics file). Someone else 
> reads it using a client that doesn't support timezones. How can he 
> fall back?

See above, the times will always be in UTC, the timezone is additional 
information. So its a non-issue.

> he has to ignore the timezone information, because he doesn't 
> understand it.

Yes, and it won't hurt since the time value is always in UTC, there is 
no reason to do it otherwise. We only transport timezone information to
a) add information for editors/viewers
b) to allow for rrules

You seem to miss the reasons when and why timezones are required in the 
protocol/format? I'm somewhat surprised about that, since exactly this 
was discussed only some weeks ago including some details on how this 
could be done format-wise.

> He can either use the time in the wrong timezone, or ignore the time 
> completely. Both is wrong.

Yes, because your assumptions is wrong. To be up/downwards compatible 
timevalues would always be in UTC.

> So, if i want my calendar to be readable by other clients, i can't use 
> timezones.
> The same story would hold for other extensions.

Of course extensions must be properly done to be compatible, but so far 
both discussed items can be easily done as extensions while still 
providing downwards compatibility AND provide the same functionality 
like before.


BTW: we do not talk about timezone awareness in the client, this has to 
be available in any case. This is only about including timezone 
information in the protocol entity which is only required for 
recurrences and to one kind of allday appointments (as far as I can 
see).

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



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BKCSaZ024610 for <[e-mail]>; Fri, 11 Feb 2005 12:12:29 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr8.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1BKCR7i056118 for <[e-mail]>; Fri, 11 Feb 2005 21:12:27 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 21:12:26 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: What's wrong with more radical simplification?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 20:12:40 -0000

Helge Hess wrote:
> Thats a rather weird statement. Why can't you use the extensions? If the 
> "other" client supports them, he will have additional information, if 
> not, he will fall back to the base spec.

Let's assume that timezones move to an extension. The client i use 
supports them. So, the start time of en event is defined with a 
timezone. I publish the calendar. (upload the whole ics file). Someone 
else reads it using a client that doesn't support timezones. How can he 
fall back? he has to ignore the timezone information, because he doesn't 
understand it. He can either use the time in the wrong timezone, or 
ignore the time completely. Both is wrong.
So, if i want my calendar to be readable by other clients, i can't use 
timezones.
The same story would hold for other extensions.

Michiel



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [69.44.62.208]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1BJtZaZ022049 for <[e-mail]>; Fri, 11 Feb 2005 11:55:35 -0800
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.2.1-RC1) with SMTP ID 487 for <[e-mail]>; Fri, 11 Feb 2005 13:55:34 -0600 (CST)
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 14:55:37 -0500
From: Mark Swanson <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: Re: [Ietf-calsify] EXRULE and multiple RRULEs]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 19:55:41 -0000

Reinhold Kainhofer wrote:
> On Friday 11 February 2005 19:27, Doug Royer wrote:
> 
>>Currently 2445 allows for multiple RRULEs per component.
>>Can we agree that if RRULEs will remain, that they be limited to one?
> 
> 
> I don't think it's necessary to have multiple RRULES.
> Is there any application / library that supports multiple RRULES in one event 
> at all? libkcal (and thus all KDE applications that use iCalendar, like 

The ScheduleWorld iCalendar library does. If I remember right Frank
Dawson posted some examples of store hours specified with multiple
RRULEs (and more).

-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BJAsaa014323 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 11:10:55 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1BJAlKe001081 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 11:10:48 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 12:10:47 -0700
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
CC: [e-mail]
Subject: Re: [Ietf-calsify] EXRULE and multiple RRULEs
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------070002030901080408020006"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 1.441 (*) FORGED_RCVD_HELO,UNDISC_RECIPS
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Fri, 11 Feb 2005 19:11:05 -0000

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


[Some of my messages are having their content stripped out by the 
mailing list program - but only to some people - so this is a resend].


> However, are we talking about multiple RRULEs per component, or multiple 
> RRULEs per set of instances? If we limit it to per component, then what 
> is to stop someone from creating a new 'overridden' instance that 
> includes a second RRULE as a separate component (with the same UID etc)?
> 

Do you mean a METHOD:ADD with an new RRULE?

-- 

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

               We Do Standards - You Need Standards


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

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


--------------070002030901080408020006--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BJ9CaZ014083 for <[e-mail]>; Fri, 11 Feb 2005 11:09:12 -0800
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0F92E2D86A4 for <[e-mail]>; Fri, 11 Feb 2005 20:08:38 +0100 (CET)
Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id E4F552D867F for <[e-mail]>; Fri, 11 Feb 2005 20:08:37 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 20:09:06 +0100
To: [e-mail]
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 19:09:23 -0000

On 11. Feb 2005, at 19:57 Uhr, Reinhold Kainhofer wrote:
> Yes, but the problem is that the list of RDATEs is not only the result 
> from
> the RRULE, but it might also contain additional dates, which are 
> already in
> the "old" RDATE list according to rfc2445.
>
> E.g. if a file contains:
> DTSTART:20050109T070000Z
> RRULE:FREQ=WEEKLY;BYDAY=SU;COUNT=2
> RDATE;VALUE=DATE:20050109,20050116,20050216
>
> Then the recurrence rule is every sunday, but the rdate list also 
> contains an
> additional occurrence on Feb 16.

If this is a real world problem (say: more than one, non-MS 
implementation actively uses this construct), we obviously need some 
solution to this (eg a seperate field for one or the other).

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



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BJ6maa013677 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 11:06:49 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1BJ6hKe001022 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 11:06:45 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 12:06:43 -0700
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] EXRULE and multiple RRULEs
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050908050405020408010403"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Fri, 11 Feb 2005 19:06:58 -0000

This is a cryptographically signed message in MIME format.

--------------ms050908050405020408010403
Content-Type: multipart/mixed; boundary="------------050705090406060905030904"

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



Cyrus Daboo wrote:

> 
> However, are we talking about multiple RRULEs per component, or multiple 
> RRULEs per set of instances? If we limit it to per component, then what 
> is to stop someone from creating a new 'overridden' instance that 
> includes a second RRULE as a separate component (with the same UID etc)?
> 

You mean METHOD:ADD that contains a new RRULE?

-- 

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

               We Do Standards - You Need Standards


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

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


--------------050705090406060905030904--

--------------ms050908050405020408010403
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
9w0BCQUxDxcNMDUwMjExMTkwNjQzWjAjBgkqhkiG9w0BCQQxFgQUhDiPxUJkXgGAaRS8Q1OQ
us5I/EswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAQL9xhmTdMBy2ezehzp/edJu50vo4xcYFboYoUP6TJ3GgCH/eM2IrXpjCvLIQf3ig
6G1kIlBnStpI7wOO1gpFrPS5m6M1UOdB5T3dhOCAR/+T4xUfKCVHx9CPeU4XFZUP75k87v6p
SdVdcBKwFD4tFgdp8mpNpk2d36CkXiUfq/2ReZtaYve4VzWeD1NTMptAV2Q8tFavFPh6s+oZ
oYsrPT4/wiFEYqrIZ64yFjKIC2bGtfpYSuD/2hrezzzKHKEp4ZFPJvmEiCortXMrdTz4QC0x
BUGyO/J5TdE8Vcdp4jvR0w46Fj2muB+cVnH5M0NOLWrkM5SNDQSHuCuMwsP9WwAAAAAAAA==
--------------ms050908050405020408010403--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIxCaa012542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 10:59:13 -0800
Received: from [10.0.1.4] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1BIod6E013306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Feb 2005 13:50:39 -0500
Date: Fri, 11 Feb 2005 13:59:09 -0500
From: Cyrus Daboo <[e-mail]>
To: Reinhold Kainhofer <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] EXRULE and multiple RRULEs
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0a4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:59:18 -0000

Hi Reinhold,

--On February 11, 2005 7:46:16 PM +0100 Reinhold Kainhofer 
<[e-mail]> wrote:

>> Currently 2445 allows for multiple RRULEs per component.
>> Can we agree that if RRULEs will remain, that they be limited to one?
>
> I don't think it's necessary to have multiple RRULES.
> Is there any application / library that supports multiple RRULES in one
> event  at all? libkcal (and thus all KDE applications that use iCalendar,
> like  KOrganizer / Kontact, KArm, KAlarm, KPilot) at least doesn't
> support multiple  rrules.
>
>> Does anyone send EXRULE's ?
>
> Please don't use the word "send", as this suggests we're only about
> sending  invitations and PUBLISH. We're also talking about arbitrary data
> exchange.
>
> I'm not aware of any application that uses EXRULE's, but that doesn't
> mean  anything. At least libkcal doesn't support EXRULE at all, only
> EXDATE.

Lets make the distinction between 'accepting' a protocol element, 
'preserving' that protocol element and 'generating' it. My implementation 
will accept and preserve multiple RRULEs, EXRULEs, RDATEs and EXDATEs and 
produce the (hopefully) correct set of instances for display. However, it 
will only allow users to generate new recurrences with a single RRULE. 
RDATES/EXDATEs do get generated when instances get overridden. I suspect a 
lot of other implementations do the same.

Assuming everyone behaves in that way, then it is perfectly fine to 
deprecate EXRULEs and multiple RRULEs per component.

However, are we talking about multiple RRULEs per component, or multiple 
RRULEs per set of instances? If we limit it to per component, then what is 
to stop someone from creating a new 'overridden' instance that includes a 
second RRULE as a separate component (with the same UID etc)?

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIvEaa012311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 10:57:16 -0800
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1BIvDLO031068 for <[e-mail]>; Fri, 11 Feb 2005 19:57:14 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 19:57:10 +0100
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart11203786.mjsqKWJglJ"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:57:22 -0000

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

On Friday 11 February 2005 19:41, Helge Hess wrote:
> > And if the gui supports recurrence rules, you'd manually
> > need to check each of the dates in the RDATE if it is an additional
> > exception
> > to the RRULE...
>
> No. Why is the rrule still require if you have all individual instances
> anyway? Its required to support the editor panel in the calendering
> client. If it supports the rrule, it can show proper UI for changing
> the cycle.

Yes, but the problem is that the list of RDATEs is not only the result from=
=20
the RRULE, but it might also contain additional dates, which are already in=
=20
the "old" RDATE list according to rfc2445.=20

E.g. if a file contains:
DTSTART:20050109T070000Z
RRULE:FREQ=3DWEEKLY;BYDAY=3DSU;COUNT=3D2
RDATE;VALUE=3DDATE:20050109,20050116,20050216

Then the recurrence rule is every sunday, but the rdate list also contains =
an=20
additional occurrence on Feb 16. So one in the GUI one has to check each of=
=20
the dates in RDATE if it was generated by the RRULE, or if it is an=20
additional occurrence. Such additional occurrences would need to be edited=
=20
differently (like exception dates).

Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart11203786.mjsqKWJglJ
Content-Type: application/pgp-signature

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

iD8DBQBCDQAITqjEwhXvPN0RAnhDAKCpU5+QrnVSItHchYKmm5IWea9fTwCfdeO3
DEN1vDXzP8DEVU+pR8oNhxs=
=yzNB
-----END PGP SIGNATURE-----

--nextPart11203786.mjsqKWJglJ--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIt1aa011981 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 10:55:03 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1BIsrKe000725 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 10:54:55 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 11:54:53 -0700
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]
Content-Type: multipart/mixed; boundary="------------040709070408050009010308"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] EXRULE and multiple RRULEs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Fri, 11 Feb 2005 18:55:25 -0000

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

Currently 2445 allows for multiple RRULEs per component.

Can we agree that if RRULEs will remain, that they be limited to one?


Does anyone send EXRULE's ?



-- 

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

               We Do Standards - You Need Standards


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

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


--------------040709070408050009010308--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIoOaa011564 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 10:50:25 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1BIoHKe000658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 10:50:19 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 11:50:17 -0700
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]
Content-Type: multipart/mixed; boundary="------------040303070905040707010900"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: What's wrong with more radical simplification?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Fri, 11 Feb 2005 18:50:32 -0000

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

PUBLISH vs Scheduling vs Data Exchange.

    And the so called infinitely recurring appointment is an excuse
    we use when we really do not know the end date. No meeting
    lasts forever. At some point no one will care about our
    birthday.

For PUBLISH calendars:

    Most of the time you do not care. If it is a PUBLISH then there
    is no scheduling anyway. (And most implementations put their
    calendars on URL's without a METHOD property any way - so there
    really can not be scheduling).

    As for reverse engineering the RDATEs back into recurrence
    rules. For PUBLISH calendars I do not think that I do go to the
    recurrence tab and look at the recurrence rule. I just
    look at my screen and notice that it is every Tuesday at noon.
    And visually notice the exceptions.

    And a large percentage of implementations do not do scheduling,
    they just post or email non-iTIP calendars to some URL.

    If I post my personal calendar a year in advance, is that
    not sufficient as it really will be updated anyway? Two years?
    Why will RDATE's not be sufficient?

For Scheduled calendars:

    Again, is not one or two years sufficient? If not - why?

    Cameron is right, the first thing we do when scheduling
    is compare the instance times, not the recurrence rules.

    If I get a scheduling request that just happens to be
    every Tuesday at noon, I can simply look at the screen
    and notice the times. Later if an important customer
    wants to meet on a Tuesday at noon. Do I care about
    the recurrence rules? No, I look and my screen, notice
    that my standard Tuesday noon meeting is in the way
    and I say yes to the customer anyway. And I let
    the GUI sort it out.

For Data Exchange:

    This is when we need to be able to transfer the information
    about the intent of the ORGANIZER. This is when recurrence
    rules matter.


-- 

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

               We Do Standards - You Need Standards


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

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


--------------040303070905040707010900--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIkJaa011172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 10:46:21 -0800
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1BIkILm030419 for <[e-mail]>; Fri, 11 Feb 2005 19:46:19 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] EXRULE and multiple RRULEs
Date: Fri, 11 Feb 2005 19:46:16 +0100
User-Agent: KMail/1.7.1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3298641.tlRPbXO2lT"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:46:26 -0000

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

On Friday 11 February 2005 19:27, Doug Royer wrote:
> Currently 2445 allows for multiple RRULEs per component.
> Can we agree that if RRULEs will remain, that they be limited to one?

I don't think it's necessary to have multiple RRULES.
Is there any application / library that supports multiple RRULES in one eve=
nt=20
at all? libkcal (and thus all KDE applications that use iCalendar, like=20
KOrganizer / Kontact, KArm, KAlarm, KPilot) at least doesn't support multip=
le=20
rrules.

> Does anyone send EXRULE's ?

Please don't use the word "send", as this suggests we're only about sending=
=20
invitations and PUBLISH. We're also talking about arbitrary data exchange.

I'm not aware of any application that uses EXRULE's, but that doesn't mean=
=20
anything. At least libkcal doesn't support EXRULE at all, only EXDATE.

Reinhold
=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart3298641.tlRPbXO2lT
Content-Type: application/pgp-signature

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

iD8DBQBCDP15TqjEwhXvPN0RAhqKAKDM3Wz/TbplG2arZiVVXZDk3fA5CQCgkuhu
CeCuSmNlctFS8VSwo2EsG20=
=vLQN
-----END PGP SIGNATURE-----

--nextPart3298641.tlRPbXO2lT--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIfnaZ010554 for <[e-mail]>; Fri, 11 Feb 2005 10:41:49 -0800
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id BA7972D8665 for <[e-mail]>; Fri, 11 Feb 2005 19:41:14 +0100 (CET)
Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 6E5252D8632 for <[e-mail]>; Fri, 11 Feb 2005 19:41:14 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 19:41:43 +0100
To: [e-mail]
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:41:58 -0000

On 11. Feb 2005, at 19:14 Uhr, Reinhold Kainhofer wrote:
> If I understand you correctly, the RDATE list would now be the list of
> all recurrences.

All instances of a recurrence, yes.

> And if the gui supports recurrence rules, you'd manually
> need to check each of the dates in the RDATE if it is an additional 
> exception
> to the RRULE...

No. Why is the rrule still require if you have all individual instances 
anyway? Its required to support the editor panel in the calendering 
client. If it supports the rrule, it can show proper UI for changing 
the cycle.
Also if a server or client gets an event with the rrule and supports 
the rrule, it only needs to store one event (but would still need to 
transmit the full set when interacting).

>> The events are still connected, the idea was not to remove the
>> connection between the events but to remove the pretty complex rrule
>> language.
> Yes, but if you use an rrule, you would only have one vevent with the 
> rrule,
> not the whole chain of vevents.

Yes, it certainly has some advantages (eg it requires small 
transactions). But it also has major disadvantages which where already 
pointed out.

> BTW, I think it's an either or. Either we don't allow any recurrence 
> rules at
> all (which in my eyes would completely remove interoperability, since 
> almost
> all GUIs have settings for recurrence rule), or we need the whole 
> complex
> (but complete) RRULE language.

The choice to be made is whether rrules are supported in the basic 
draft or not. If you do, you also need to provide full timezone 
support, so the draft will get quite complex (not significant gain to 
what we have now).
Of course you could (and probably should) still restrict the rrule 
language if the choice goes for the latter.

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



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIVeaa008958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 10:31:42 -0800
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1BIVcnL029908 for <[e-mail]>; Fri, 11 Feb 2005 19:31:40 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 19:31:35 +0100
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4478703.8CgTpzCo2R"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:31:51 -0000

--nextPart4478703.8CgTpzCo2R
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 11 February 2005 18:35, Helge Hess wrote:
> On Feb 11, 2005, at 18:16, Mark Swanson wrote:
> > Well, ScheduleWorld 100% implements RRULEs. The GUI doesn't reflect
> > this because then folks could create RRULEs that wouldn't interoperate
> > with a few other products.
>
> Isn't that a contradiction? What good is an rrule if you can't display
> it? Of course I believe you that you can parse the iCalendar structure
> of the rrule, but what good is the data if the user can't view/edit it?

All instances of that event will be correctly displayed. Unless you edit th=
at=20
event, you don't loose any data.

Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart4478703.8CgTpzCo2R
Content-Type: application/pgp-signature

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

iD8DBQBCDPoJTqjEwhXvPN0RAlCGAJ9ty/8M2gBwJremW/rjA+8jo1ka6ACgpM1y
dIq8gdvIPXh6Jtl38wc3Dwo=
=JhDd
-----END PGP SIGNATURE-----

--nextPart4478703.8CgTpzCo2R--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BISDaZ008002 for <[e-mail]>; Fri, 11 Feb 2005 10:28:14 -0800
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0F6682D8601 for <[e-mail]>; Fri, 11 Feb 2005 19:27:39 +0100 (CET)
Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id E28032D85FF for <[e-mail]>; Fri, 11 Feb 2005 19:27:38 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 19:28:07 +0100
To: [e-mail]
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:28:24 -0000

On 11. Feb 2005, at 18:30 Uhr, Reinhold Kainhofer wrote:
> I think it basically boils down to the two views of standards:
> 1) A standard should describe what every application MUST implement. 
> If an
> application wants to do something more, it's on its own. ("lowest 
> common
> denominator")
> 2) A standard gives a suggestion how an application might implement 
> any (even
> very exotic) feature. No application will ever implement full support 
> for
> every little detail of such a standard, but if it implements one 
> feature, it
> can be sure that any other application that implements a similar 
> feature will
> be able to reuse the data.

I think this is painted rather black and white which is not how it 
needs to be. As mentioned there can be extensions and things like 
rrules and timezones certainly make a lot of sense.

But to have interoperability (aka a _standard_) you MUST agree on 
certain blocks of functionality. I can't see how a standard can work 
otherwise.

Your example of "if it implements one feature, it can be sure that any 
other application that implements a similar feature will be able to 
reuse the data" is obviously wrong, because this other application will 
not understand some other obscure feature you are using in the same 
iCalendar entity.

> it seems most people here think that a standard is just for those 
> parts that
> every application must implement (i.e. every detail of a standard 
> needs to be
> supported by an application).

Well, I would say thats the core definition of the word "standard" and 
not the "thinking" of the people here ;-)

> However, what I like so much about iCalendar is that it gives you a
> standardized way for lots of advanced features.

Si, iCalendar currently seems to be more like a framework to choose 
implementation suggestions from, less an actual standard (which someone 
is really compliant with). I thought the goal of calsify was to fix 
exactly this situation.

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



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIRAaa007733 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 10:27:13 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1BIR2Ke000309 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 10:27:05 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 11:27:01 -0700
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]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030904030908040200060402"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] EXRULE and multiple RRULEs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Fri, 11 Feb 2005 18:27:25 -0000

This is a cryptographically signed message in MIME format.

--------------ms030904030908040200060402
Content-Type: multipart/mixed; boundary="------------030903050702000805030801"

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


Currently 2445 allows for multiple RRULEs per component.

Can we agree that if RRULEs will remain, that they be limited to one?


Does anyone send EXRULE's ?


-- 

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

               We Do Standards - You Need Standards


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

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


--------------030903050702000805030801--

--------------ms030904030908040200060402
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
9w0BCQUxDxcNMDUwMjExMTgyNzAxWjAjBgkqhkiG9w0BCQQxFgQUZMnxNkJthJSg5J7ofcWA
a3+XLBUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAEDzgwsCMpLvX216rMrU3awGmCKX2FG+eeU0hXwqGnMeOLLaQwpnMURXxKa2oUXOr
PXbTKJEaENT3dmy9XBTZHTA3JPvdDgpV6h9d+qurRC783JG/bzEYKrgtv2nFIjXfewSm/Ylh
nIykGXhBZFQ4KG7D7mnInxQRf35LdDxOxcNjb75vYIXi8AzAWez+hUwBudJFh9N+WaH88g3c
D5KfBzG2ZN3vazExa6Nj0t+beQao8+Tk1q6pjtGuN40cdP3oat2PlnZuUZHBtjAJseaIurhe
Kn619eXzrczyUR7ubV0piVy+CP5F/wLvla9tSJngbGUca7lSVP0U/0t49C94EwAAAAAAAA==
--------------ms030904030908040200060402--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BILHaZ006968 for <[e-mail]>; Fri, 11 Feb 2005 10:21:17 -0800
Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.44) id 1CzfPf-0002L3-HN; Fri, 11 Feb 2005 18:21:11 +0000
Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 4.44) id 1CzfPd-0002VK-5e; Fri, 11 Feb 2005 18:21:05 +0000
Date: Fri, 11 Feb 2005 18:21:05 +0000 (GMT)
From: Libby Miller <[e-mail]>
X-X-Sender: [e-mail]
To: Reinhold Kainhofer <[e-mail]>
Subject: Re: [Ietf-calsify] Example RRULEs
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: Libby Miller <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Spam-Level: --
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:21:28 -0000

On Fri, 11 Feb 2005, Reinhold Kainhofer wrote:

> On Friday 11 February 2005 19:04, Cyrus Daboo wrote:
>> Ultimately it would make sense to have all those on say the
>> Calconnect website to help people do implementations. I am sure we can
>> arrange that if there is interest...
>
> Yes, I'd be very interested in such an archive of test cases.

that would be fantastic. I'm sure we can donate the few we have if 
useful.

Libby

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


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIHnaa006108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 10:17:51 -0800
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1BIHlP2027354 for <[e-mail]>; Fri, 11 Feb 2005 19:17:48 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Example RRULEs
Date: Fri, 11 Feb 2005 19:17:43 +0100
User-Agent: KMail/1.7.1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1709980.XNNNNoxR4W"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:18:01 -0000

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

On Friday 11 February 2005 19:04, Cyrus Daboo wrote:
> Ultimately it would make sense to have all those on say the
> Calconnect website to help people do implementations. I am sure we can
> arrange that if there is interest...

Yes, I'd be very interested in such an archive of test cases.

Cheers,
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart1709980.XNNNNoxR4W
Content-Type: application/pgp-signature

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

iD4DBQBCDPbKTqjEwhXvPN0RAkJjAJ99WiJQ6e0mmRtS5W6ru7ee8ElFTgCYtCSC
9pBvVvKnoyXrAN9yvyhqlw==
=ZIER
-----END PGP SIGNATURE-----

--nextPart1709980.XNNNNoxR4W--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIEqaa005796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 10:14:55 -0800
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1BIEmZi027253 for <[e-mail]>; Fri, 11 Feb 2005 19:14:49 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 19:14:46 +0100
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4407773.Gcf5D1DKSy"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:15:39 -0000

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

On Friday 11 February 2005 18:39, Helge Hess wrote:
> On Feb 11, 2005, at 18:28, Reinhold Kainhofer wrote:
> >> Thats a rather weird statement. Why can't you use the extensions? If
> >> the "other" client supports them, he will have additional information,
> >> if not, he will fall back to the base spec.
> >
> > Yes, exactly. And that is the problem here.
> > If you move recurrence information to the extension and you use a
> > recurrence,
> > any client which does not understand that recurrence extension will
> > just show
> > the very first occurrence but none of the other occurrences.
>
> Why is that? The client will show a sequence of connected events, it
> just doesn't know the algorithm the sequence was built with.

So the basic standard would require you to always send the whole list of=20
rdates, even if you then use a rrule with the extended standard?
What if you want to use an rrule plus an additional recurrence on a differe=
nt=20
date? Like a meeting each monday, but once it will happen on wednesday.

Things like=20
RRULE:FREQ=3DWEEKLY;BYDAY=3DMO;COUNT=3D120
RDATE;VALUE=3DDATE:20050101,20050120,20050216
would then become invalid iCalendar syntax...
Currently, the RRULE defines several dates, and the RDATE defines additiona=
l=20
dates. If I understand you correctly, the RDATE list would now be the list =
of=20
all recurrences. And if the gui supports recurrence rules, you'd manually=20
need to check each of the dates in the RDATE if it is an additional excepti=
on=20
to the RRULE...

> > So, to be sure that the receiving client really shows all occurrences
> > one
> > can't use the recurrence extension at all. Doesn't make too much
> > sense, does
> > it?
>
> No, but it isn't the way you describe it.
>
> The events are still connected, the idea was not to remove the
> connection between the events but to remove the pretty complex rrule
> language.=20

Yes, but if you use an rrule, you would only have one vevent with the rrule=
,=20
not the whole chain of vevents.

BTW, I think it's an either or. Either we don't allow any recurrence rules =
at=20
all (which in my eyes would completely remove interoperability, since almos=
t=20
all GUIs have settings for recurrence rule), or we need the whole complex=20
(but complete) RRULE language.

Reinhold

Reinhold
=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart4407773.Gcf5D1DKSy
Content-Type: application/pgp-signature

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

iD8DBQBCDPYXTqjEwhXvPN0RAjMFAKDCvYqXUp+AKs9DZWBf4FgmiUAIBwCfZ9EM
C9xNTnZVtDv1esy12AIdPWo=
=15Lr
-----END PGP SIGNATURE-----

--nextPart4407773.Gcf5D1DKSy--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BIE3aZ005719 for <[e-mail]>; Fri, 11 Feb 2005 10:14:03 -0800
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id CF8BD2D8632 for <[e-mail]>; Fri, 11 Feb 2005 19:13:28 +0100 (CET)
Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id A894B2D8598 for <[e-mail]>; Fri, 11 Feb 2005 19:13:28 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 19:13:57 +0100
To: "<[e-mail]> <[e-mail]>" <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:14:14 -0000

On 11. Feb 2005, at 18:59 Uhr, Cameron Stillion wrote:
> I'm in complete agreement with your statement below - and I think this
> is the sweet spot where calsify can make magic.  Let's declare that
> subset of RRULEs that seems to work and that people tend to implement 
> as
> "the standard" and THEN we can enjoy debating what to add to (or remove
> from) that specification.

Just let me restate why we initially thought that removing rrules might 
be a major simplification:
If we remove rrules this also should remove the necessity for 
timezones, so we could move to use UTC for all time based data which 
would be a HUGE gain (and reflect quite well what is done anyway by a 
lot of servers and clients).

For example Kontact support for rrules is actually broken due to 
timezones (really: no offense intended! :-) since it normalizes the 
iCal files to UTC in the storage. This in turn removes the information 
on the times the event creator planned the cycle (so its actually quite 
useless in a multi timezone setups).

IMHO its much worse to share incorrect information that to share a bit 
less information.

Before someone gets this wrong again ;-), I'm _not_ suggesting to 
remove rrules nor timezones. I'm suggesting to move them into 
(optional) extensions to the base draft. This should be quite possible 
while still providing upward and downward compatibility.

> (eg comparing interoperability between Sunbird and Kontact should be
> done, but isn't particulary interesting since both use some derivate of
> iCalendar. One would need to compare interoperability between eg 
> Outlook
> and Sunbird or Notes and Kontact).

BTW: this was supposed to mean: they all use some derivate "libical", 
not iCalendar.

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



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BI7uaa005112 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 10:07:57 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1BI7pKe032426 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 10:07:54 -0800
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 11:07:50 -0700
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] Re: What's wrong with more radical simplification?
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090106010100020007020206"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Fri, 11 Feb 2005 18:08:39 -0000

This is a cryptographically signed message in MIME format.

--------------ms090106010100020007020206
Content-Type: multipart/mixed; boundary="------------050103060901080402050103"

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


PUBLISH vs Scheduling vs Data Exchange.

   And the so called infinitely recurring appointment is an excuse
   we use when we really do not know the end date. No meeting
   lasts forever. At some point no one will care about our
   birthday.

For PUBLISH calendars:

   Most of the time you do not care. If it is a PUBLISH then there
   is no scheduling anyway. (And most implementations put their
   calendars on URL's without a METHOD property any way - so there
   really can not be scheduling).

   As for reverse engineering the RDATEs back into recurrence
   rules. For PUBLISH calendars I do not think that I do go to the
   recurrence tab and look at the recurrence rule. I just
   look at my screen and notice that it is every Tuesday at noon.
   And visually notice the exceptions.

   And a large percentage of implementations do not do scheduling,
   they just post or email non-iTIP calendars to some URL.

   If I post my personal calendar a year in advance, is that
   not sufficient as it really will be updated anyway? Two years?
   Why will RDATE's not be sufficient?

For Scheduled calendars:

   Again, is not one or two years sufficient? If not - why?

   Cameron is right, the first thing we do when scheduling
   is compare the instance times, not the recurrence rules.

   If I get a scheduling request that just happens to be
   every Tuesday at noon, I can simply look at the screen
   and notice the times. Later if an important customer
   wants to meet on a Tuesday at noon. Do I care about
   the recurrence rules? No, I look and my screen, notice
   that my standard Tuesday noon meeting is in the way
   and I say yes to the customer anyway. And I let
   the GUI sort it out.

For Data Exchange:

   This is when we need to be able to transfer the information
   about the intent of the ORGANIZER. This is when recurrence
   rules matter.

-- 

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

               We Do Standards - You Need Standards


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

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


--------------050103060901080402050103--

--------------ms090106010100020007020206
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
9w0BCQUxDxcNMDUwMjExMTgwNzUwWjAjBgkqhkiG9w0BCQQxFgQUGsXgF5ECVOrDHfLc64ak
JXQ198cwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAYffgOcOYAN9RdmJY3wiVqi64UbQFHUWjeDE7VbUtbU4TOnr9n2Z40aT6fbopulqf
AMHT0WSIyhh0ZxDhSWpav6Jcnrw9lopxKtN4LFNNC8xe/zVJA0l/SGWNHICfyfBFhuYp5AUt
zIU4INQbcgtzuj8uLflRhk6D1ZBl90O/28LRNeEO+/C8EmqDqcvUecrKO55cvSBfAcdIA6rq
0WMCk2XxkeTiT3vqSep01t0vEIg24s+0roc5kFHoGF6GfEx7ja8uHStve4tS+iPSwLATTbYN
6zsmTKLoV+g1SSzEb3DvHoLwZUfx5a8NbexgW50m7KYJ9fIvo4UbBSGDOpsxcAAAAAAAAA==
--------------ms090106010100020007020206--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BI46aa004683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 10:04:07 -0800
Received: from [10.0.1.4] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1BHtZ6E012300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 12:55:35 -0500
Date: Fri, 11 Feb 2005 13:04:04 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-calsify] Example RRULEs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:04:18 -0000

To help with interop testing, I have made the following available:

1) 
<http://www.mulberrymail.com/davroot/calendars/public/iCalendarTests/2445AllExamples.ics>

This contains all the recurrence examples from 2445 Section 4.8.5.4 in one 
.ics file. The SUMMARY of each item indicates the example number in order 
from that section. The DESCRIPTION is the description from 2445 for each 
example. Note that some examples have a couple of variants and these are 
indicated by additional letters in the numbering (e.g. 05a 05b etc). Most 
of the examples use start dates in 1997, but there are some unbounded 
examples that will fill up the calendar display e.g. 'Every 20 minutes from 
9:00 AM to 4:40 PM every day'.

2) 
<http://www.mulberrymail.com/davroot/calendars/public/iCalendarTests/PayDay.ics>

This contains a single recurring event that uses a BYSETPOS. It corresponds 
to 'the last weekday in the month'.

Feel free to use these in whatever way you want.

If you have your own set of test events etc that you could share please let 
me know. Ultimately it would make sense to have all those on say the 
Calconnect website to help people do implementations. I am sure we can 
arrange that if there is interest...

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BI2caZ004553 for <[e-mail]>; Fri, 11 Feb 2005 10:02:39 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr6.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1BI2c0d029928 for <[e-mail]>; Fri, 11 Feb 2005 19:02:38 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 19:02:37 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: What's wrong with more radical simplification?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 18:02:49 -0000

Cyrus Daboo wrote:
> Note that you almost always have to truncate an unbounded recurrence 
> when doing iTIP because you cannot do conflict resolution for an 
> unbounded recurrence.

Should a (sane) limitation in one application of ical restrict ical 
itself? There are other ways a ical can be published and/or shared. Not 
all of them need conflict resolution. If i just publish calendar 
somewhere, i'm not doing iTIP.

> I think this is reasonable because as a real world observation, I 
> believe that timed recurring events really are bounded in some fashion.
> 
In practice they do, but you don't always know the end when creating the 
event. Forcing the user to come up with an arbitrary enddate should be 
avoided imo.

Michiel


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BHxKaZ004210 for <[e-mail]>; Fri, 11 Feb 2005 09:59:21 -0800
Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211);  Fri, 11 Feb 2005 09:59:12 -0800
Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Fri, 11 Feb 2005 09:59:20 -0800
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Feb 2005 09:59:11 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 09:59:10 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Re: What's wrong with more radical simplification?
Thread-Index: AcUQYHdxZQvozmcJRRCLNxC3W5B7ZwAAm8eA
From: "Cameron Stillion" <[e-mail]>
To: "Helge Hess" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 Feb 2005 17:59:11.0822 (UTC) FILETIME=[642A2EE0:01C51063]
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1BHxKaZ004210
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:59:28 -0000

Helge,

I'm in complete agreement with your statement below - and I think this
is the sweet spot where calsify can make magic.  Let's declare that
subset of RRULEs that seems to work and that people tend to implement as
"the standard" and THEN we can enjoy debating what to add to (or remove
from) that specification.

cameron

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Helge Hess
Sent: Friday.11.February.2005 09.36
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical
simplification?

<snipped...>

My impression is that a lot of clients use a similiar subset of the
specified rrules and that this subset works pretty well. But it might be
wrong.

Also most of the newer clients are specifically build around iCalendar
which obviously improves on that too.
(eg comparing interoperability between Sunbird and Kontact should be
done, but isn't particulary interesting since both use some derivate of
iCalendar. One would need to compare interoperability between eg Outlook
and Sunbird or Notes and Kontact).

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

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BHdTaZ002609 for <[e-mail]>; Fri, 11 Feb 2005 09:39:30 -0800
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id D9D362D8547 for <[e-mail]>; Fri, 11 Feb 2005 18:38:54 +0100 (CET)
Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 968E92D853D for <[e-mail]>; Fri, 11 Feb 2005 18:38:54 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 18:39:24 +0100
To: [e-mail]
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:39:37 -0000

On Feb 11, 2005, at 18:28, Reinhold Kainhofer wrote:
>> Thats a rather weird statement. Why can't you use the extensions? If
>> the "other" client supports them, he will have additional information,
>> if not, he will fall back to the base spec.
>
> Yes, exactly. And that is the problem here.
> If you move recurrence information to the extension and you use a 
> recurrence,
> any client which does not understand that recurrence extension will 
> just show
> the very first occurrence but none of the other occurrences.

Why is that? The client will show a sequence of connected events, it 
just doesn't know the algorithm the sequence was built with.

> So, to be sure that the receiving client really shows all occurrences 
> one
> can't use the recurrence extension at all. Doesn't make too much 
> sense, does
> it?

No, but it isn't the way you describe it.

The events are still connected, the idea was not to remove the 
connection between the events but to remove the pretty complex rrule 
language. The latter would have the additional advantage that we could 
also drop timezones for the basic spec (another huge complication).
But all this was already discussed some month ago?

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



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BHa5aa002312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 09:36:06 -0800
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1BHa3xg026170 for <[e-mail]>; Fri, 11 Feb 2005 18:36:04 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 18:36:00 +0100
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1628097.7iaWAo05dh"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:36:17 -0000

--nextPart1628097.7iaWAo05dh
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 11 February 2005 17:53, Libby Miller wrote:
> which applications export data as rrules? and is it mostly timezone
> information? It looks from our smallish dataset[1] that evolution does
> export them.=20

KOrganizer and Kontact use rrule for recurring events and recurring to-dos.=
=20

Cheers,
Reinhold

--nextPart1628097.7iaWAo05dh
Content-Type: application/pgp-signature

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

iD8DBQBCDO0CTqjEwhXvPN0RAhQIAJ0cp6GFsO5mMseiiKJPbjetVy4EvACgvKn2
z5HX00ZzXhUWVP5uR09WYEQ=
=fmFc
-----END PGP SIGNATURE-----

--nextPart1628097.7iaWAo05dh--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BHZvaZ002301 for <[e-mail]>; Fri, 11 Feb 2005 09:35:58 -0800
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id ED94A2D8565 for <[e-mail]>; Fri, 11 Feb 2005 18:35:22 +0100 (CET)
Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 9414C2D8559 for <[e-mail]>; Fri, 11 Feb 2005 18:35:22 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 18:35:52 +0100
To: [e-mail]
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:36:08 -0000

On Feb 11, 2005, at 18:16, Mark Swanson wrote:
> Well, ScheduleWorld 100% implements RRULEs. The GUI doesn't reflect 
> this because then folks could create RRULEs that wouldn't interoperate 
> with a few other products.

Isn't that a contradiction? What good is an rrule if you can't display 
it? Of course I believe you that you can parse the iCalendar structure 
of the rrule, but what good is the data if the user can't view/edit it?

Unless I'm missing something, not reflecting the rrule in the GUI is 
exactly the same like not supporting it. And reflecting _all_ the 
specified rrules in iCalendar should be quite difficult (if not 
impossible if you still want to have good usability ;-).

> My current impression is that RRULEs are fairly well supported - even 
> by lesser known products like phpICalendar.

My impression is that a lot of clients use a similiar subset of the 
specified rrules and that this subset works pretty well. But it might 
be wrong.

Also most of the newer clients are specifically build around iCalendar 
which obviously improves on that too.
(eg comparing interoperability between Sunbird and Kontact should be 
done, but isn't particulary interesting since both use some derivate of 
iCalendar. One would need to compare interoperability between eg 
Outlook and Sunbird or Notes and Kontact).

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



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BHUTaa001844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 09:30:30 -0800
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1BHURSB026054 for <[e-mail]>; Fri, 11 Feb 2005 18:30:28 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 18:30:25 +0100
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1769327.rekaXgov53"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:30:41 -0000

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

On Friday 11 February 2005 18:04, Helge Hess wrote:
> On Feb 11, 2005, at 17:33, Michiel van Leeuwen wrote:
> > Helge Hess wrote:
> >> If you have some standard you basically always loose information
> >> since you need to find a viable common denominator.

I would argue to the contrary. What I like so much about iCalendar is that =
it=20
defines a way to do almost anything you might ever want to do. So when you=
=20
implement a new feature in your calendar application, most of the time,=20
iCalendar already gives you a format how to store this feature in an=20
iCalendar object (for drag'n'drop, invitations, even storing). So you don't=
=20
have to cook your own soup, but instead can use a standard which other=20
clients (that implement a similar feature) can also understand.

I think it basically boils down to the two views of standards:
1) A standard should describe what every application MUST implement. If an=
=20
application wants to do something more, it's on its own. ("lowest common=20
denominator")
2) A standard gives a suggestion how an application might implement any (ev=
en=20
very exotic) feature. No application will ever implement full support for=20
every little detail of such a standard, but if it implements one feature, i=
t=20
can be sure that any other application that implements a similar feature wi=
ll=20
be able to reuse the data.

it seems most people here think that a standard is just for those parts tha=
t=20
every application must implement (i.e. every detail of a standard needs to =
be=20
supported by an application).=20
However, what I like so much about iCalendar is that it gives you a=20
standardized way for lots of advanced features.=20


> You have the assumption that fixing the clients is an easy and viable
> task. I had the impression that currently rrules can represent every
> recurrence model which was supported by the initial protocol creators.

I think it was meant to be able to describe every possible combination one=
=20
might ever need. Anything else wouldn't make sense, because again it would=
=20
lead to fragmentation, since one would need to invent a new solution if an=
=20
application has needs that are not covered by a limited standard. And then=
=20
one can be sure that interoperaility between two applications that both=20
support such an advanced feature will never work.


> This in turn makes it very complex and forces everyone to implement all
> the rrules of the others (and in practice nobody does that which makes
> rrules not interoperable).
> But people suggested that I might be wrong on how compliant current
> clients are. Do Outlook, Kontact, Evolution, Mozilla, iCal.app really
> support 100% of the currently specified iCalendar rrules?=20

No, at least korganizer / kontact doesn't. AFAICR, BYSETPOS is not correctl=
y=20
handled. The GUI of korganizer or kontact might not suggest it, but our=20
libkcal library does in fact support almost the whole specification.

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart1769327.rekaXgov53
Content-Type: application/pgp-signature

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

iD8DBQBCDOuzTqjEwhXvPN0RAowVAJ0SkjWo8M3AZFLm54AsGzlw41cs5ACeLEI5
4ZmIecBq9eH4qBJba7FKgqk=
=a3Iq
-----END PGP SIGNATURE-----

--nextPart1769327.rekaXgov53--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BHS9aa001563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 09:28:10 -0800
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1BHS7On026050 for <[e-mail]>; Fri, 11 Feb 2005 18:28:08 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 18:28:05 +0100
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1872795.3LzHbjQjSx"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:28:21 -0000

--nextPart1872795.3LzHbjQjSx
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 11 February 2005 18:04, Helge Hess wrote:
> > imo extensions also are the wrong solution. If i want to publish my
> > calendar, i can't use the extensions, because i don't know what other
> > clients will read the file.
>
> Thats a rather weird statement. Why can't you use the extensions? If
> the "other" client supports them, he will have additional information,
> if not, he will fall back to the base spec.

Yes, exactly. And that is the problem here.
If you move recurrence information to the extension and you use a recurrenc=
e,=20
any client which does not understand that recurrence extension will just sh=
ow=20
the very first occurrence but none of the other occurrences.=20

So, to be sure that the receiving client really shows all occurrences one=20
can't use the recurrence extension at all. Doesn't make too much sense, doe=
s=20
it?

Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart1872795.3LzHbjQjSx
Content-Type: application/pgp-signature

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

iD8DBQBCDOsnTqjEwhXvPN0RArXWAKDea8mi3zs/CJON44GnytqDv1Yz1QCgnl7B
sElm3sUuCp2JpmH5r0+YgT8=
=HjBo
-----END PGP SIGNATURE-----

--nextPart1872795.3LzHbjQjSx--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BHQGaa001339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Feb 2005 09:26:18 -0800
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j1BHQDR2025998 for <[e-mail]>; Fri, 11 Feb 2005 18:26:15 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 18:26:09 +0100
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart8735903.1u7LG0RHgG"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Spam-Score: 0.629 () URIBL_SBL
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:26:31 -0000

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

On Thursday 10 February 2005 23:03, Michiel van Leeuwen wrote:
> Nathaniel Borenstein wrote:
> > I still believe that we can completely eliminate recurrence rules, and,
> > given that elimination, we can radically reduce the importance and
> > complexity of time zones as well.
>
> I think removing rrules would be a real bad idea. Sure, handing out a
> list of  occurrences will show up the same way on a calendar. But you
> lost information. The app won't know anymore that it is an event that
> happens every monday. It just has a list of dates. It can't show the UI
> anymore, so the user can't change it to every tuesday. The data is gone.

I can only second that. In particular, rfc 2445 is also meant as the format=
=20
e.g. for drag'n'dropping of events from one application to another. If you=
=20
expand the recurrence rule before dragging, the second application will not=
=20
get that information.
Currently, it's possible to take an event from KOrganizer / Kontact, drag i=
t=20
to evolution and the event will be exactly the same as it was in KOrganizer.

I think iCalendar should be a format that allows to exchange all available=
=20
information without any data loss.

Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart8735903.1u7LG0RHgG
Content-Type: application/pgp-signature

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

iD8DBQBCDOq1TqjEwhXvPN0RAgkTAJ9rcdkpXU5ROLyn4/duIwPNT5onZwCgkakC
XUVR40wlhonlzrg9WUGGjl8=
=746G
-----END PGP SIGNATURE-----

--nextPart8735903.1u7LG0RHgG--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [69.44.62.208]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1BHGvaZ000413 for <[e-mail]>; Fri, 11 Feb 2005 09:16:57 -0800
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.2.1-RC1) with SMTP ID 662; Fri, 11 Feb 2005 11:16:56 -0600 (CST)
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 12:16:58 -0500
From: Mark Swanson <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:17:06 -0000

Helge Hess wrote:
> 
> But people suggested that I might be wrong on how compliant current 
> clients are. Do Outlook, Kontact, Evolution, Mozilla, iCal.app really 
> support 100% of the currently specified iCalendar rrules? I would be 
> surprised, but pleased to hear some actual investigation on that.

Well, ScheduleWorld 100% implements RRULEs. The GUI doesn't reflect this 
because then folks could create RRULEs that wouldn't interoperate with a 
few other products. I have done a fair bit of RRULE interop testing over 
the years and some products have always been quite good and others have 
become good only recently. My current impression is that RRULEs are 
fairly well supported - even by lesser known products like phpICalendar.

Cheers.


-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [69.44.62.208]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1BH7paZ030667 for <[e-mail]>; Fri, 11 Feb 2005 09:07:52 -0800
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.2.1-RC1) with SMTP ID 437 for <[e-mail]>; Fri, 11 Feb 2005 11:07:51 -0600 (CST)
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 12:07:52 -0500
From: Mark Swanson <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:07:59 -0000

Libby Miller wrote:
> 
> which applications export data as rrules? and is it mostly timezone 
> information? It looks from our smallish dataset[1] that evolution does 
> export them. Does anyone have any bigger/better sets of example outputs?

I thought all applications exported data as RRULEs. Are there any 
existing applications that don't?

-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BH5waa030231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 11 Feb 2005 09:05:59 -0800
Received: from [10.0.1.4] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1BGvP6E009158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Feb 2005 11:57:25 -0500
Date: Fri, 11 Feb 2005 12:05:54 -0500
From: Cyrus Daboo <[e-mail]>
To: Michiel van Leeuwen <[e-mail]>, Tim Hare <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0a4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:06:05 -0000

Hi Michiel,

--On February 11, 2005 5:44:52 PM +0100 Michiel van Leeuwen <[e-mail]> 
wrote:

> There is some other problem i tought of: It isn't uncommon for users to
> create a recurring event without an end time, because it is not known at
> the time of creating. So for the time being, it will recur forever. What
> should the application do when exchanging that event as a list of rdates?
> It must come up with an arbitrary end date. The recipient might think of
> that as the real date. Not only did you loose the original information,
> you added wrong new information.
>

Note that you almost always have to truncate an unbounded recurrence when 
doing iTIP because you cannot do conflict resolution for an unbounded 
recurrence. Indeed iTIP specifies a request-status code that CUAs can use 
in a REPLY to indicate that a recurring event was scheduled, but only over 
a finite set of recurrences (i.e. unbounded set is truncated for scheduling 
purposes).

Its worth noting two different scenarios for unbounded recurrences:

1) Those that specify a date only - not time (i.e. all day events such as 
anniversaries, holidays etc). These are usually not a problem for iTIP 
because in general you are probably not worried about conflicts (e.g. it 
doesn't matter that my birthday falls on a national holiday or the day of 
the company outing etc).

2) Those that include a time. These are the ones that present real 
difficulties because of the need to do detailed conflict resolution.

One option we may want to consider is to only allow unbounded recurrences 
for date-only items. Recurring events with times then have to be bounded, 
using either UNTIL or COUNT in an RRULE or a set of RDATEs.

I think this is reasonable because as a real world observation, I believe 
that timed recurring events really are bounded in some fashion.

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BH46aZ030033 for <[e-mail]>; Fri, 11 Feb 2005 09:04:06 -0800
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 1AA372CC933 for <[e-mail]>; Fri, 11 Feb 2005 18:03:31 +0100 (CET)
Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id D2F3C2D841A for <[e-mail]>; Fri, 11 Feb 2005 18:03:30 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 18:04:00 +0100
To: [e-mail]
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 17:04:17 -0000

On Feb 11, 2005, at 17:33, Michiel van Leeuwen wrote:
> Helge Hess wrote:
>> If you have some standard you basically always loose information 
>> since you need to find a viable common denominator.
> I think that is the wrong approach.

Its not an approach at all, its just a statement/fact. Most 
clients/servers use iCalendar for interoperability, not for their 
implementation (and can therefore only expose iCal features, not their 
full functionality).

This is a bit different for most OpenSource clients, which also use 
iCalendar for storing the information.

> Fix the clients.
> Or come up with something completly new, that new clients can 
> implement correctly. But that will take even longer.

You have the assumption that fixing the clients is an easy and viable 
task. I had the impression that currently rrules can represent every 
recurrence model which was supported by the initial protocol creators. 
This in turn makes it very complex and forces everyone to implement all 
the rrules of the others (and in practice nobody does that which makes 
rrules not interoperable).

But people suggested that I might be wrong on how compliant current 
clients are. Do Outlook, Kontact, Evolution, Mozilla, iCal.app really 
support 100% of the currently specified iCalendar rrules? I would be 
surprised, but pleased to hear some actual investigation on that.

> imo extensions also are the wrong solution. If i want to publish my 
> calendar, i can't use the extensions, because i don't know what other 
> clients will read the file.

Thats a rather weird statement. Why can't you use the extensions? If 
the "other" client supports them, he will have additional information, 
if not, he will fall back to the base spec.

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



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BGrgaZ027014 for <[e-mail]>; Fri, 11 Feb 2005 08:53:43 -0800
Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.44) id 1Cze2v-00068j-RQ; Fri, 11 Feb 2005 16:53:36 +0000
Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 4.44) id 1Cze2t-0006sA-HG; Fri, 11 Feb 2005 16:53:32 +0000
Date: Fri, 11 Feb 2005 16:53:31 +0000 (GMT)
From: Libby Miller <[e-mail]>
X-X-Sender: [e-mail]
To: Michiel van Leeuwen <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: Libby Miller <[e-mail]>
X-Spam-Score: 0 () 
X-Spam-Level: --
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 16:53:55 -0000

On Fri, 11 Feb 2005, Michiel van Leeuwen wrote:

> Tim Hare wrote:
>> In a particular UI implementation, you _can_ use recurrence rules supported 
>> by that product - all we are proposing is that they be _exchanged_ as a 
>> list of RDATES, or even more simply as a set of VEVENTS.
>
> So the recipient of the exchange can't change (or even look at) the 
> recurrence information.
>
>> The calendar store(s) of the recipient(s) could, I suppose, use the UID on 
>> the VEVENTs to try to determine a recurrence rule according to its own 
>> methods
>
> That will give even more bugs. Trying to be smart based on a list of dates.
>
> There is some other problem i tought of: It isn't uncommon for users to 
> create a recurring event without an end time, because it is not known at the 
> time of creating. So for the time being, it will recur forever. What should 
> the application do when exchanging that event as a list of rdates? It must 
> come up with an arbitrary end date. The recipient might think of that as the 
> real date. Not only did you loose the original information, you added wrong 
> new information.

which applications export data as rrules? and is it mostly timezone 
information? It looks from our smallish dataset[1] that evolution does 
export them. Does anyone have any bigger/better sets of example outputs?

cheers,

Libby

[1] http://www.w3.org/2002/12/cal/test/
>
> Michiel
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BGiuaZ025215 for <[e-mail]>; Fri, 11 Feb 2005 08:44:57 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr15.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1BGirDL046100;  Fri, 11 Feb 2005 17:44:53 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 17:44:52 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: Tim Hare <[e-mail]>, [e-mail]
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-calsify] Re: What's wrong with more radical simplification?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 16:45:01 -0000

Tim Hare wrote:
> In a particular UI implementation, you _can_ use recurrence rules 
> supported by that product - all we are proposing is that they be 
> _exchanged_ as a list of RDATES, or even more simply as a set of 
> VEVENTS.

So the recipient of the exchange can't change (or even look at) the 
recurrence information.

> The calendar store(s) of the 
> recipient(s) could, I suppose, use the UID on the VEVENTs to try to 
> determine a recurrence rule according to its own methods

That will give even more bugs. Trying to be smart based on a list of dates.

There is some other problem i tought of: It isn't uncommon for users to 
create a recurring event without an end time, because it is not known at 
the time of creating. So for the time being, it will recur forever. What 
should the application do when exchanging that event as a list of 
rdates? It must come up with an arbitrary end date. The recipient might 
think of that as the real date. Not only did you loose the original 
information, you added wrong new information.

Michiel


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BGXtaZ023062 for <[e-mail]>; Fri, 11 Feb 2005 08:33:56 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr2.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1BGXjKO022813 for <[e-mail]>; Fri, 11 Feb 2005 17:33:51 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 17:33:44 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: What's wrong with more radical simplification?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 16:34:06 -0000

Helge Hess wrote:
> If you have some standard you basically always loose information since 
> you need to find a viable common denominator.
> 
I think that is the wrong approach. Looking at bugs/problems in current 
implementations, and removing that from the spec. You need to define 
what you want to approach with the spec, and make sure you can reach that.
Not having recurrence rules just because some clients have problems with 
them isn't the right way imo.

> So what is your _solution_ to this? Pointing out the flaws is 
> insufficient, its proven that rrules are not interoperable since 
> everyone does rrules in a different way and no one does support them 
> fully?!

Fix the clients.
Or come up with something completly new, that new clients can implement 
correctly. But that will take even longer.

> For the _basic_ draft, IMHO timezones and rrules should be removed to 
> have something which can be widely supported by everyone.
> Of course they should be supported in some extension.

imo extensions also are the wrong solution. If i want to publish my 
calendar, i can't use the extensions, because i don't know what other 
clients will read the file. So in reality, you can never use extensions. 
(can you imagine a client asking the user: what application is the 
recipient of this event using?)


Michiel



X-Envelope-From: [e-mail]
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1BFheaZ014860; Fri, 11 Feb 2005 07:43:40 -0800
In-Reply-To: <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
MIME-Version: 1.0
X-Mailer: IBM Lotus Notes Build V70_01312005NP January 31, 2005
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 11 Feb 2005 10:43:31 -0500
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V70_M4_12222004 Beta 3|December 22, 2004) at 02/11/2005 10:39:28 AM, Serialize complete at 02/11/2005 10:39:28 AM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.609 () DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 15:43:52 -0000

that is my take on rrule intop as well.



Cyrus Daboo <[e-mail]> 
Sent by: [e-mail]
02/10/2005 08:47 PM

To
Helge Hess <[e-mail]>, [e-mail]
cc

Subject
Re: [Ietf-calsify] Re: What's wrong with more radical simplification?






Hi Helge,

--On February 11, 2005 1:27:34 AM +0100 Helge Hess 
<[e-mail]> wrote:

> So what is your _solution_ to this? Pointing out the flaws is
> insufficient, its proven that rrules are not interoperable since 
everyone
> does rrules in a different way and no one does support them fully?!

OK - so what exactly is wrong with RRULEs in and of themselves? My reading 

of the current interoperability state is that most products handle RRULE 
generation/expansion correctly. The real problem is not the RRULEs per se, 

but rather then exceptions to recurrences and how to manage rescheduling 
of 
such exceptions via iTIP. Exceptions and rescheduling will be a problem 
whether we have RRULEs or just RDATEs. It looks like that ought to be 
easier with RDATEs only, but I'm not sure its all that much easier.

-- 
Cyrus Daboo
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1B9NqaZ009092 for <[e-mail]>; Fri, 11 Feb 2005 01:23:52 -0800
Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211);  Fri, 11 Feb 2005 01:23:42 -0800
Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Fri, 11 Feb 2005 01:23:32 -0800
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Feb 2005 01:23:35 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 01:23:42 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Re: What's wrong with more radical simplification?
Thread-Index: AcUP91aL+sKNeB2GR6eXhgv8OZUreAAIr6Tg
From: "Cameron Stillion" <[e-mail]>
To: "Tim Hare" <[e-mail]>, "Michiel van Leeuwen" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 Feb 2005 09:23:35.0636 (UTC) FILETIME=[5CC2D140:01C5101B]
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1B9NqaZ009092
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 09:24:00 -0000

What you are suggesting is that representing a simple example like "once
a week every Wednesday" would be a list of individual vevents (perhaps
with exceptions) and that the recipient somehow reverse engineer that
collection into the original rule? This is more than separating the data
from the UI, it's obscuring it completely.  This puts a very heavy
burden on clients who don't want to represent recurrences like a huge
list of events.  This would limit the UI vendor fairly severely, it
seems.

cameron

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Tim Hare
Sent: Thursday.10.February.2005 21.02
To: Michiel van Leeuwen; [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical
simplification?

In a particular UI implementation, you _can_ use recurrence rules
supported by that product - all we are proposing is that they be
_exchanged_ as a list of RDATES, or even more simply as a set of
VEVENTS. The calendar store of the originator of the recurring-event
item can store it in the compact manner with recurrence rules stored
according to what it supports.  The calendar store(s) of the
recipient(s) could, I suppose, use the UID on the VEVENTs to try to
determine a recurrence rule according to its own methods (the simplest
being to make it one item with a list of dates, probably).  But in
either case, the user hasn't lost the ability to simply put in recurring
items. The UI, in other words, is separate from the data.

Tim

At 05:03 PM 2/10/05, Michiel van Leeuwen wrote:
>Nathaniel Borenstein wrote:
>>I still believe that we can completely eliminate recurrence rules, 
>>and, given that elimination, we can radically reduce the importance 
>>and complexity of time zones as well.
>
>I think removing rrules would be a real bad idea. Sure, handing out a 
>list of  occurrences will show up the same way on a calendar. But you 
>lost information. The app won't know anymore that it is an event that 
>happens every monday. It just has a list of dates. It can't show the UI

>anymore, so the user can't change it to every tuesday. The data is
gone.
>
>
>Michiel
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1B53qaZ029402 for <[e-mail]>; Thu, 10 Feb 2005 21:03:52 -0800
Received: from computer.comcast.net (pcp0011451694pcs.micske01.fl.comcast.net[69.244.223.118]) by comcast.net (rwcrmhc11) with SMTP id <2005021105034401300md0l7e>; Fri, 11 Feb 2005 05:03:44 +0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 11 Feb 2005 00:02:05 -0500
To: Michiel van Leeuwen <[e-mail]>, [e-mail]
From: Tim Hare <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 05:03:57 -0000

In a particular UI implementation, you _can_ use recurrence rules supported 
by that product - all we are proposing is that they be _exchanged_ as a 
list of RDATES, or even more simply as a set of VEVENTS. The calendar store 
of the originator of the recurring-event item can store it in the compact 
manner with recurrence rules stored according to what it supports.  The 
calendar store(s) of the recipient(s) could, I suppose, use the UID on the 
VEVENTs to try to determine a recurrence rule according to its own methods 
(the simplest being to make it one item with a list of dates, 
probably).  But in either case, the user hasn't lost the ability to simply 
put in recurring items. The UI, in other words, is separate from the data.

Tim

At 05:03 PM 2/10/05, Michiel van Leeuwen wrote:
>Nathaniel Borenstein wrote:
>>I still believe that we can completely eliminate recurrence rules, and, 
>>given that elimination, we can radically reduce the importance and 
>>complexity of time zones as well.
>
>I think removing rrules would be a real bad idea. Sure, handing out a list 
>of  occurrences will show up the same way on a calendar. But you lost 
>information. The app won't know anymore that it is an event that happens 
>every monday. It just has a list of dates. It can't show the UI anymore, 
>so the user can't change it to every tuesday. The data is gone.
>
>
>Michiel
>_______________________________________________
>Ietf-calsify mailing list
>[e-mail]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify




X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1B1lsaa009355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 10 Feb 2005 17:47:56 -0800
Received: from [10.0.1.4] (pool-141-151-189-161.pitt.east.verizon.net [141.151.189.161]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1B1dP6E022112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Feb 2005 20:39:27 -0500
Date: Thu, 10 Feb 2005 20:47:49 -0500
From: Cyrus Daboo <[e-mail]>
To: Helge Hess <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0a4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 01:48:05 -0000

Hi Helge,

--On February 11, 2005 1:27:34 AM +0100 Helge Hess 
<[e-mail]> wrote:

> So what is your _solution_ to this? Pointing out the flaws is
> insufficient, its proven that rrules are not interoperable since everyone
> does rrules in a different way and no one does support them fully?!

OK - so what exactly is wrong with RRULEs in and of themselves? My reading 
of the current interoperability state is that most products handle RRULE 
generation/expansion correctly. The real problem is not the RRULEs per se, 
but rather then exceptions to recurrences and how to manage rescheduling of 
such exceptions via iTIP. Exceptions and rescheduling will be a problem 
whether we have RRULEs or just RDATEs. It looks like that ought to be 
easier with RDATEs only, but I'm not sure its all that much easier.

-- 
Cyrus Daboo


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1B0ReaZ003357 for <[e-mail]>; Thu, 10 Feb 2005 16:27:41 -0800
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id B09EE2D7EED for <[e-mail]>; Fri, 11 Feb 2005 01:27:00 +0100 (CET)
Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 9145C2D4450 for <[e-mail]>; Fri, 11 Feb 2005 01:27:00 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Helge Hess <[e-mail]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Fri, 11 Feb 2005 01:27:34 +0100
To: [e-mail]
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 11 Feb 2005 00:28:04 -0000

On 10. Feb 2005, at 23:03 Uhr, Michiel van Leeuwen wrote:
> Nathaniel Borenstein wrote:
>> I still believe that we can completely eliminate recurrence rules, 
>> and, given that elimination, we can radically reduce the importance 
>> and complexity of time zones as well.
> I think removing rrules would be a real bad idea. Sure, handing out a 
> list of  occurrences will show up the same way on a calendar. But you 
> lost information. The app won't know anymore that it is an event that 
> happens every monday. It just has a list of dates. It can't show the 
> UI anymore, so the user can't change it to every tuesday. The data is 
> gone.

If you have some standard you basically always loose information since 
you need to find a viable common denominator.

So what is your _solution_ to this? Pointing out the flaws is 
insufficient, its proven that rrules are not interoperable since 
everyone does rrules in a different way and no one does support them 
fully?!


For the _basic_ draft, IMHO timezones and rrules should be removed to 
have something which can be widely supported by everyone.
Of course they should be supported in some extension.

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



X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AN0YaZ029450; Thu, 10 Feb 2005 15:00:34 -0800
In-Reply-To: <[e-mail]>
To: Mark Swanson <[e-mail]>
Subject: Re: [Ietf-calsify] What's wrong with more radical simplification?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 10 Feb 2005 18:00:31 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/10/2005 06:00:35 PM, Serialize complete at 02/10/2005 06:00:35 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.265 () HTML_40_50,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 23:00:39 -0000

I responded before but want to make sure my count is in.   +2 for Cameron
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



Mark Swanson <[e-mail]> 
Sent by: [e-mail]
02/10/2005 03:02 PM

To
[e-mail]
cc

Subject
Re: [Ietf-calsify] What's wrong with more radical simplification?






+1 for Cameron's thoughts.

-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AMxXaZ029358; Thu, 10 Feb 2005 14:59:34 -0800
In-Reply-To: <[e-mail]>
To: "Cameron Stillion" <[e-mail]>
Subject: RE: [Ietf-calsify] What's wrong with more radical simplification?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 10 Feb 2005 17:59:30 -0500
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 02/10/2005 05:59:34 PM, Serialize complete at 02/10/2005 05:59:34 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.474 () HTML_10_20,HTML_MESSAGE,NO_REAL_NAME
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 22:59:42 -0000

Hi Cameron.  I agree as well.  However, one of the biggest problems we see 
are different implementations of the standards out there.  One product 
uses the very first implementation of vcalendar or icalendar and others 
use the later versions.  So, even within the standards that are out there, 
we have collisions. 

That's one of the reasons I am so excited about the Min-IOP Technical 
Steering committee work that's coming out of the Calconnect consortium. If 
we can identify what is the lowest common denominator where the majority 
of the calendaring applications work today - we have our ical-lite.  Then, 
we can carve away the pieces that dont' work (timezones and recurrence 
rules - although some things do indeed function - just not all) and make 
them either ical-extensions, or whatever, who cares.  But getting 
something we know will work with Outlook, Lotus Notes, Mozilla, Yahoo, 
Isamet, Oracle, whatever, makes me, a calendaring user from way back, 
pretty excited.  As it does my clients as well.  8-)
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



"Cameron Stillion" <[e-mail]> 
Sent by: [e-mail]
02/10/2005 12:43 PM

To
"Nathaniel Borenstein" <[e-mail]>, 
<[e-mail]>
cc

Subject
RE: [Ietf-calsify] What's wrong with more radical simplification?







While I agree with you philosophically, I believe there is also a
practical issue to consider:  Any standard which has meaning must have
some relevance to the working products that are in frequent or popular
usage.  If we were in a state where no product or vendor had yet
released significant support of iCal, I would agree with you completely.
However, there are products now shipping and becoming more commonplace
that we must also consider.  Apple's iCal (who came up with that
original name?) product and their .mac service that hosts published
calendars.  Mozilla's product that reads and writes iCal format, and
several others - some already out there, and some on the verge of
releasing... There are other web services (I use the term loosely, not
in the MS.NET sense) that have sprung up around iCal: icalx.com,
icalshare.com, and others...  A standard which these products and
services do not use is (imho) not all that meaningful.

To hit on some of your specific points: removing rrules would not affect
the apps and services that use them currently.  Frankly, I can't imagine
removing support for rrules in our current product, or generating icals
without them.  It would mean more "lossy" conversions, not less.  I
can't imagine other vendors doing it either.  Perhaps new systems could
opt for the "simpler" rrule-less standard, but then they would be
incompatible with the existing big dogs that use this technology.  In
some ways, we are dealing with the tyrrany of schema - you can't take it
back, once it is commonly used.  You can deprecate it, provide a better
replacement, but it is VERY difficult to stop supporting it.

I believe that to be successful, we must capture the state of the art
that is happening today, perhaps with some tweaks to the more difficult
aspects that thwart integration and interoperability.  Radical
simplification to the standard make it theoretically easier for entrance
to the game, but I think the sweet spot here is to capture what's
already being played, and then to move on from there.  A Diet-iCal may
very well be useful to embedded systems or small devices (maybe) in the
future, but I don't see it as our most pressing objective, or our most
promising one.

Thoughts?

cameron

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Nathaniel
Borenstein
Sent: Thursday.10.February.2005 08.29
To: [e-mail]
Subject: [Ietf-calsify] What's wrong with more radical simplification?

Tim Hare said something in October that was so on target that I think
it's worth reading again:

> Maybe it's serendipity, but I was pointed to an old post at 
> http://www.shirky.com/writings/evolve.html about evolvable systems as 
> it relates to the Web; and it kind of struck a chord about what we're 
> doing here.
>
> Let's get out an iCal-Basic that everyone can create easily from what 
> they've got now,  and everyone can read in with what they've got now.
> Even if it means we're passing back-and-forth larger sets of data to 
> describe repeating appointments, even if it means certain appointments

> that cross timezones or daylight-savings-time changes have problems.
> The thing is, if we can get out something that works, we can then 
> evolve it to work better.  We have got to find the simplest common 
> denominator that works, call that iCal-Basic, and release it. That's 
> the four-footed fish crawling up on the shore... we'll get to mammals 
> later.

I believe this post goes to the heart of everything that is most broken
about iCal, and that we must take it very seriously if we're to have any
hope of fixing this mess.  I will therefore reiterate yet again my past
observations about the potential for radical simplification, simply
because no one has yet convinced me that what I advocate would be an
*over* simplification.  I believe that we should grab for any
simplification that won't demonstrably make the standard inadequate for
its primary purposes, which I regard to be personal and interpersonal
event scheduling.

I still believe that we can completely eliminate recurrence rules, and,
given that elimination, we can radically reduce the importance and
complexity of time zones as well.

First of all, let's consider carefully what will happen if we choose to
go down the road, as many are proposing, of making RRULES an optional
part of the specification.  In that world, the composer of an email
invitation to a repeating meeting won't be able to know (for reasons
touched on in my companion post, "Receiver Capability Description
Considered Harmful") whether or not the recipient(s) will understand
RRULES.  Thus, such a composer will inevitably end up sending repeating
meeting invitations as multipart/alternatives, containing both a "set" 
and a "rule" description of the repeating meeting.  In that case, I
would argue that the RRULES can be dispensed with entirely as redundant.

Eliminating RRULES implies, in turn, that we can use UTC for nearly
everything, so that the only time zone translation that needs to be done
is at the user level and involves the relatively straightforward
translation between UTC and the user's own time zone.  Together, this
pair of changes would be an enormous simplification of a protocol that I
believe is choking under its own complexity.  Even the discussion on
this list about how to simplify RRULES is, I fear, too complex for many
potential implementors to understand, and thus will inevitably lead to
"misinterpretations."  (I put the word in quotes because I believe that
if there is any way to misinterpret a standard, it is the spec that is 
at fault, not the implementor.   Long experience has taught that if 
there is more than one way to interpret an RFC, it will be interpreted
in more than one way by software that claims to be conformant.)

If, as I am claiming, it is *possible* to do everything without RRULES,
and that RRULES are just a bandwith-and-space-saving-convenience for
repeat meetings that have LOTS of repeats (and, of course, a truly vital
feature for any imaginary meetings that continue infinitely, unlike
their attendees), then we should try to build a complete version without
RRULES first, and only try to add on the efficiency/convenience of
RRULES later, if at all.  Worrying about the cost/efficiency of
representing a recurring meeting, in a world full of BitTorrent and
webcams, strikes me as rather myopic.  If we can live with base64, we
can live with this.

I know that several of you are tired of hearing this argument from me. 
I encourage you to shut me up by convincing me that it is NOT possible
to define a completely adequate version of iCal that doesn't have any
recurrence rules.  But if it is possible, I think it is what we should
do. -- Nathaniel

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AM32aZ022992 for <[e-mail]>; Thu, 10 Feb 2005 14:03:03 -0800
Received: from [192.168.100.2] (lions.xs4all.nl [213.84.175.238]) by smtp-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1AM32tn068295 for <[e-mail]>; Thu, 10 Feb 2005 23:03:02 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2005 23:03:01 +0100
From: Michiel van Leeuwen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050129
X-Accept-Language: en-us, en, nl
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-Mailman-Approved-At: Thu, 10 Feb 2005 16:03:35 -0800
Subject: [Ietf-calsify] Re: What's wrong with more radical simplification?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 22:03:14 -0000

Nathaniel Borenstein wrote:
> I still believe that we can completely eliminate recurrence rules, and, 
> given that elimination, we can radically reduce the importance and 
> complexity of time zones as well.

I think removing rrules would be a real bad idea. Sure, handing out a 
list of  occurrences will show up the same way on a calendar. But you 
lost information. The app won't know anymore that it is an event that 
happens every monday. It just has a list of dates. It can't show the UI 
anymore, so the user can't change it to every tuesday. The data is gone.


Michiel


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [69.44.62.208]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1AK22aZ009241 for <[e-mail]>; Thu, 10 Feb 2005 12:02:02 -0800
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.2.1-RC1) with SMTP ID 671 for <[e-mail]>; Thu, 10 Feb 2005 14:02:00 -0600 (CST)
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2005 15:02:03 -0500
From: Mark Swanson <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] What's wrong with more radical simplification?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 20:02:25 -0000

+1 for Cameron's thoughts.

-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.technorati.com (mail.technorati.com [209.237.227.245]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AJO0aa004004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 10 Feb 2005 11:24:00 -0800
Received: from [192.168.1.121] (m206-184.dsl.tsoft.com [198.144.206.184]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.technorati.com (Postfix) with ESMTP id 3673921281A; Thu, 10 Feb 2005 11:32:33 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[e-mail]>
Subject: Re: [Ietf-calsify] What's wrong with more radical simplification?
Date: Thu, 10 Feb 2005 11:23:48 -0800
To: "Cameron Stillion" <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 19:24:27 -0000

+1 on what Cameron Stillion wrote.

If the choice is between defining iCal as:

  1. maximum interoperability profile of existing major/popular 
implementations
  2. minimum possible useful profile (radical simplification)

 From following all the discussions in this thread, and considering 
practical matters of current implementations and market forces (e.g. if 
current implementations interoperably output RRULES, then any new 
implementation will be forced by market forces and competitive pressure 
to accept and support RRULES), 1. seems like the only realistic choice.

Tantek



On Feb 10, 2005, at 9:43 AM, Cameron Stillion wrote:

>
> While I agree with you philosophically, I believe there is also a
> practical issue to consider:  Any standard which has meaning must have
> some relevance to the working products that are in frequent or popular
> usage.  If we were in a state where no product or vendor had yet
> released significant support of iCal, I would agree with you 
> completely.
> However, there are products now shipping and becoming more commonplace
> that we must also consider.  Apple's iCal (who came up with that
> original name?) product and their .mac service that hosts published
> calendars.  Mozilla's product that reads and writes iCal format, and
> several others - some already out there, and some on the verge of
> releasing... There are other web services (I use the term loosely, not
> in the MS.NET sense) that have sprung up around iCal: icalx.com,
> icalshare.com, and others...  A standard which these products and
> services do not use is (imho) not all that meaningful.
>
> To hit on some of your specific points: removing rrules would not 
> affect
> the apps and services that use them currently.  Frankly, I can't 
> imagine
> removing support for rrules in our current product, or generating icals
> without them.  It would mean more "lossy" conversions, not less.  I
> can't imagine other vendors doing it either.  Perhaps new systems could
> opt for the "simpler" rrule-less standard, but then they would be
> incompatible with the existing big dogs that use this technology.  In
> some ways, we are dealing with the tyrrany of schema - you can't take 
> it
> back, once it is commonly used.  You can deprecate it, provide a better
> replacement, but it is VERY difficult to stop supporting it.
>
> I believe that to be successful, we must capture the state of the art
> that is happening today, perhaps with some tweaks to the more difficult
> aspects that thwart integration and interoperability.  Radical
> simplification to the standard make it theoretically easier for 
> entrance
> to the game, but I think the sweet spot here is to capture what's
> already being played, and then to move on from there.  A Diet-iCal may
> very well be useful to embedded systems or small devices (maybe) in the
> future, but I don't see it as our most pressing objective, or our most
> promising one.
>
> Thoughts?
>
> cameron
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Nathaniel
> Borenstein
> Sent: Thursday.10.February.2005 08.29
> To: [e-mail]
> Subject: [Ietf-calsify] What's wrong with more radical simplification?
>
> Tim Hare said something in October that was so on target that I think
> it's worth reading again:
>
>> Maybe it's serendipity, but I was pointed to an old post at
>> http://www.shirky.com/writings/evolve.html about evolvable systems as
>> it relates to the Web; and it kind of struck a chord about what we're
>> doing here.
>>
>> Let's get out an iCal-Basic that everyone can create easily from what
>> they've got now,  and everyone can read in with what they've got now.
>> Even if it means we're passing back-and-forth larger sets of data to
>> describe repeating appointments, even if it means certain appointments
>
>> that cross timezones or daylight-savings-time changes have problems.
>> The thing is, if we can get out something that works, we can then
>> evolve it to work better.  We have got to find the simplest common
>> denominator that works, call that iCal-Basic, and release it. That's
>> the four-footed fish crawling up on the shore... we'll get to mammals
>> later.
>
> I believe this post goes to the heart of everything that is most broken
> about iCal, and that we must take it very seriously if we're to have 
> any
> hope of fixing this mess.  I will therefore reiterate yet again my past
> observations about the potential for radical simplification, simply
> because no one has yet convinced me that what I advocate would be an
> *over* simplification.  I believe that we should grab for any
> simplification that won't demonstrably make the standard inadequate for
> its primary purposes, which I regard to be personal and interpersonal
> event scheduling.
>
> I still believe that we can completely eliminate recurrence rules, and,
> given that elimination, we can radically reduce the importance and
> complexity of time zones as well.
>
> First of all, let's consider carefully what will happen if we choose to
> go down the road, as many are proposing, of making RRULES an optional
> part of the specification.  In that world, the composer of an email
> invitation to a repeating meeting won't be able to know (for reasons
> touched on in my companion post, "Receiver Capability Description
> Considered Harmful") whether or not the recipient(s) will understand
> RRULES.  Thus, such a composer will inevitably end up sending repeating
> meeting invitations as multipart/alternatives, containing both a "set"
> and a "rule" description of the repeating meeting.  In that case, I
> would argue that the RRULES can be dispensed with entirely as 
> redundant.
>
> Eliminating RRULES implies, in turn, that we can use UTC for nearly
> everything, so that the only time zone translation that needs to be 
> done
> is at the user level and involves the relatively straightforward
> translation between UTC and the user's own time zone.  Together, this
> pair of changes would be an enormous simplification of a protocol that 
> I
> believe is choking under its own complexity.  Even the discussion on
> this list about how to simplify RRULES is, I fear, too complex for many
> potential implementors to understand, and thus will inevitably lead to
> "misinterpretations."  (I put the word in quotes because I believe that
> if there is any way to misinterpret a standard, it is the spec that is
> at fault, not the implementor.   Long experience has taught that if
> there is more than one way to interpret an RFC, it will be interpreted
> in more than one way by software that claims to be conformant.)
>
> If, as I am claiming, it is *possible* to do everything without RRULES,
> and that RRULES are just a bandwith-and-space-saving-convenience for
> repeat meetings that have LOTS of repeats (and, of course, a truly 
> vital
> feature for any imaginary meetings that continue infinitely, unlike
> their attendees), then we should try to build a complete version 
> without
> RRULES first, and only try to add on the efficiency/convenience of
> RRULES later, if at all.  Worrying about the cost/efficiency of
> representing a recurring meeting, in a world full of BitTorrent and
> webcams, strikes me as rather myopic.  If we can live with base64, we
> can live with this.
>
> I know that several of you are tired of hearing this argument from me.
> I encourage you to shut me up by convincing me that it is NOT possible
> to define a completely adequate version of iCal that doesn't have any
> recurrence rules.  But if it is possible, I think it is what we should
> do. -- Nathaniel
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AJCaaZ002905 for <[e-mail]>; Thu, 10 Feb 2005 11:12:37 -0800
Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211);  Thu, 10 Feb 2005 11:12:28 -0800
Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Thu, 10 Feb 2005 11:11:32 -0800
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 11:08:02 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Thu, 10 Feb 2005 11:07:58 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Re: What's wrong with more radical simplification?
Thread-Index: AcUPmWa2CYoIZznnTlmrYXsDXvykIwACQomg
From: "Cameron Stillion" <[e-mail]>
To: "Peter Saint-Andre" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2005 19:08:02.0539 (UTC) FILETIME=[D7D9D3B0:01C50FA3]
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1AJCaaZ002905
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 19:12:37 -0000

Saint Peter,

With all due respect, I believe we can too.  But who will remove this
functionality from their parsers? Who will degrade their iCal generators
to begin unrolling recurrences?  I don't see it happening for this
generation.  

A new standard that includes less maybe - just like a new standard that
includes more (as some have suggested we pursue) - would be a viable
alternative to newcomers, assuming it provided 'enough' functionality
for their purpose.  

"For every problem, there is a solution that is simple, neat, and
wrong."
H. L. Mencken

/cds

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Peter
Saint-Andre
Sent: Thursday, February 10, 2005 9:37 AM
To: [e-mail]
Subject: [Ietf-calsify] Re: What's wrong with more radical
simplification?

In article <[e-mail]>,
 Nathaniel Borenstein <[e-mail]> wrote:

> I still believe that we can completely eliminate recurrence rules, 
> and, given that elimination, we can radically reduce the importance 
> and complexity of time zones as well.

+1

"Simplify, simplify, simplify." -- Henry David Thoreau

/psa

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AHr0aa025016 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 10 Feb 2005 09:53:02 -0800
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1CzIGh-0000zc-Be for [e-mail]; Thu, 10 Feb 2005 18:38:20 +0100
Received: from dialup-4.227.255.21.dial1.denver1.level3.net ([4.227.255.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 10 Feb 2005 18:38:19 +0100
Received: from stpeter by dialup-4.227.255.21.dial1.denver1.level3.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 10 Feb 2005 18:38:19 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Peter Saint-Andre <[e-mail]>
Date: Thu, 10 Feb 2005 10:37:02 -0700
Organization: Jabber Software Foundation
Lines: 12
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: dialup-4.227.255.21.dial1.denver1.level3.net
User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X)
Sender: news <[e-mail]>
X-Gmane-MailScanner: Found to be clean
X-Gmane-MailScanner: Found to be clean
X-Gmane-MailScanner-SpamScore: ss
X-MailScanner-From: [e-mail]
X-MailScanner-To: [e-mail]
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Re: What's wrong with more radical simplification?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 17:53:03 -0000

In article <[e-mail]>,
 Nathaniel Borenstein <[e-mail]> wrote:

> I still believe that we can completely eliminate recurrence rules, and, 
> given that elimination, we can radically reduce the importance and 
> complexity of time zones as well.

+1

"Simplify, simplify, simplify." -- Henry David Thoreau

/psa



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AHi4aZ023725 for <[e-mail]>; Thu, 10 Feb 2005 09:44:09 -0800
Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211);  Thu, 10 Feb 2005 09:43:56 -0800
Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Thu, 10 Feb 2005 09:43:54 -0800
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 09:43:50 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] What's wrong with more radical simplification?
Date: Thu, 10 Feb 2005 09:43:49 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] What's wrong with more radical simplification?
Thread-Index: AcUPjgg/KtfQiPnOSc2CJ7t2KBRawAAB1+tA
From: "Cameron Stillion" <[e-mail]>
To: "Nathaniel Borenstein" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2005 17:43:50.0527 (UTC) FILETIME=[149DF8F0:01C50F98]
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1AHi4aZ023725
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 17:44:12 -0000

While I agree with you philosophically, I believe there is also a
practical issue to consider:  Any standard which has meaning must have
some relevance to the working products that are in frequent or popular
usage.  If we were in a state where no product or vendor had yet
released significant support of iCal, I would agree with you completely.
However, there are products now shipping and becoming more commonplace
that we must also consider.  Apple's iCal (who came up with that
original name?) product and their .mac service that hosts published
calendars.  Mozilla's product that reads and writes iCal format, and
several others - some already out there, and some on the verge of
releasing... There are other web services (I use the term loosely, not
in the MS.NET sense) that have sprung up around iCal: icalx.com,
icalshare.com, and others...  A standard which these products and
services do not use is (imho) not all that meaningful.

To hit on some of your specific points: removing rrules would not affect
the apps and services that use them currently.  Frankly, I can't imagine
removing support for rrules in our current product, or generating icals
without them.  It would mean more "lossy" conversions, not less.  I
can't imagine other vendors doing it either.  Perhaps new systems could
opt for the "simpler" rrule-less standard, but then they would be
incompatible with the existing big dogs that use this technology.  In
some ways, we are dealing with the tyrrany of schema - you can't take it
back, once it is commonly used.  You can deprecate it, provide a better
replacement, but it is VERY difficult to stop supporting it.

I believe that to be successful, we must capture the state of the art
that is happening today, perhaps with some tweaks to the more difficult
aspects that thwart integration and interoperability.  Radical
simplification to the standard make it theoretically easier for entrance
to the game, but I think the sweet spot here is to capture what's
already being played, and then to move on from there.  A Diet-iCal may
very well be useful to embedded systems or small devices (maybe) in the
future, but I don't see it as our most pressing objective, or our most
promising one.

Thoughts?

cameron

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Nathaniel
Borenstein
Sent: Thursday.10.February.2005 08.29
To: [e-mail]
Subject: [Ietf-calsify] What's wrong with more radical simplification?

Tim Hare said something in October that was so on target that I think
it's worth reading again:

> Maybe it's serendipity, but I was pointed to an old post at 
> http://www.shirky.com/writings/evolve.html about evolvable systems as 
> it relates to the Web; and it kind of struck a chord about what we're 
> doing here.
>
> Let's get out an iCal-Basic that everyone can create easily from what 
> they've got now,  and everyone can read in with what they've got now.
> Even if it means we're passing back-and-forth larger sets of data to 
> describe repeating appointments, even if it means certain appointments

> that cross timezones or daylight-savings-time changes have problems.
> The thing is, if we can get out something that works, we can then 
> evolve it to work better.  We have got to find the simplest common 
> denominator that works, call that iCal-Basic, and release it. That's 
> the four-footed fish crawling up on the shore... we'll get to mammals 
> later.

I believe this post goes to the heart of everything that is most broken
about iCal, and that we must take it very seriously if we're to have any
hope of fixing this mess.  I will therefore reiterate yet again my past
observations about the potential for radical simplification, simply
because no one has yet convinced me that what I advocate would be an
*over* simplification.  I believe that we should grab for any
simplification that won't demonstrably make the standard inadequate for
its primary purposes, which I regard to be personal and interpersonal
event scheduling.

I still believe that we can completely eliminate recurrence rules, and,
given that elimination, we can radically reduce the importance and
complexity of time zones as well.

First of all, let's consider carefully what will happen if we choose to
go down the road, as many are proposing, of making RRULES an optional
part of the specification.  In that world, the composer of an email
invitation to a repeating meeting won't be able to know (for reasons
touched on in my companion post, "Receiver Capability Description
Considered Harmful") whether or not the recipient(s) will understand
RRULES.  Thus, such a composer will inevitably end up sending repeating
meeting invitations as multipart/alternatives, containing both a "set" 
and a "rule" description of the repeating meeting.  In that case, I
would argue that the RRULES can be dispensed with entirely as redundant.

Eliminating RRULES implies, in turn, that we can use UTC for nearly
everything, so that the only time zone translation that needs to be done
is at the user level and involves the relatively straightforward
translation between UTC and the user's own time zone.  Together, this
pair of changes would be an enormous simplification of a protocol that I
believe is choking under its own complexity.  Even the discussion on
this list about how to simplify RRULES is, I fear, too complex for many
potential implementors to understand, and thus will inevitably lead to
"misinterpretations."  (I put the word in quotes because I believe that
if there is any way to misinterpret a standard, it is the spec that is 
at fault, not the implementor.   Long experience has taught that if 
there is more than one way to interpret an RFC, it will be interpreted
in more than one way by software that claims to be conformant.)

If, as I am claiming, it is *possible* to do everything without RRULES,
and that RRULES are just a bandwith-and-space-saving-convenience for
repeat meetings that have LOTS of repeats (and, of course, a truly vital
feature for any imaginary meetings that continue infinitely, unlike
their attendees), then we should try to build a complete version without
RRULES first, and only try to add on the efficiency/convenience of
RRULES later, if at all.  Worrying about the cost/efficiency of
representing a recurring meeting, in a world full of BitTorrent and
webcams, strikes me as rather myopic.  If we can live with base64, we
can live with this.

I know that several of you are tired of hearing this argument from me.  
I encourage you to shut me up by convincing me that it is NOT possible
to define a completely adequate version of iCal that doesn't have any
recurrence rules.  But if it is possible, I think it is what we should
do. -- Nathaniel

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AHJWaZ019216 for <[e-mail]>; Thu, 10 Feb 2005 09:19:32 -0800
Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211);  Thu, 10 Feb 2005 09:19:24 -0800
Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Thu, 10 Feb 2005 09:19:24 -0800
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 09:19:24 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Ietf-calsify] Receiver Capability Description Considered Harmful
Date: Thu, 10 Feb 2005 09:19:23 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ietf-calsify] Receiver Capability Description Considered Harmful
Thread-Index: AcUPjd5isUBmWJ4URWWz+WAT4XaTgQABcigA
From: "Cameron Stillion" <[e-mail]>
To: "Nathaniel Borenstein" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2005 17:19:24.0018 (UTC) FILETIME=[AA827520:01C50F94]
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1AHJWaZ019216
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 17:19:33 -0000

I agree that this type of gleaning a remote participants capabilities is
typically handled via alternatives, rather than handshake.  Although, in
the crypto case, you explicitly don't know a recipients capabilities for
encryption until you receive a signed message containing their public
keys (or some other delivery/publishing of capabilities in PKIX).  This
precedent is for a very good reason, arguably - that security depends on
it.  In the crypto case, non-repudiation (for example) is not an
"alternative" but a requirement.

I understand Nathaniel's concern, but I also see (first hand in some
cases) how applications often use cues from their recipients messages to
respond to them.  The most basic form of this is replying to a message.
Whether the reply uses plain text or rich text (HTML) is based solely on
the sender's choice, and by implication, their capabilities.  There are
many other examples, but that is not to say that this is the best way to
distribute or guess capabilities.

camerost

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Nathaniel
Borenstein
Sent: Thursday.10.February.2005 08.29
To: [e-mail]
Subject: [Ietf-calsify] Receiver Capability Description Considered
Harmful

I'm somewhat concerned about any suggestion (below made by Doug, but
he's by no means alone) that encourages the composer of an iTIP message
to try to take into account the capabilities of the intended
receiver(s):

> 2) We add a property to all iTIP replies that indicate the supported 
> features of the
>     side that is replying. We name this new property EXTENSIONS. And 
> it will be
>     a muilti valued   property that lists the RFC numbers of 
> extensions supported by the
>     sender of the object.  This property will go at the same level as 
> VERSION.

I am skeptical that we can ever make this sort of capabilities
consideration work well in an email (imip) context.  There's no
precedent for requiring email composers to ascertain the recipient's
capabilities before deciding on the format of the message they're
sending, and I'd prefer not to make the calendaring work depend on such
a disruptive change to the email model.  Note that ESMTP is not a
counterexample, because the only capabilities exchange happens
synchronously at SMTP hops rather than when the message is being
composed for eventual delivery to a (possibly offline) recipient. --
Nathaniel

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AGTUaZ014150 for <[e-mail]>; Thu, 10 Feb 2005 08:29:30 -0800
Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A46CB0F30272; Thu, 10 Feb 2005 07:57:32 -0800
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: [e-mail]
From: Nathaniel Borenstein <[e-mail]>
Date: Thu, 10 Feb 2005 11:29:23 -0500
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] What's wrong with more radical simplification?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 16:29:31 -0000

Tim Hare said something in October that was so on target that I think 
it's worth reading again:

> Maybe it's serendipity, but I was pointed to an old post at 
> http://www.shirky.com/writings/evolve.html about evolvable systems as 
> it relates to the Web; and it kind of struck a chord about what we're 
> doing here.
>
> Let's get out an iCal-Basic that everyone can create easily from what 
> they've got now,  and everyone can read in with what they've got now. 
> Even if it means we're passing back-and-forth larger sets of data to 
> describe repeating appointments, even if it means certain appointments 
> that cross timezones or daylight-savings-time changes have problems.  
> The thing is, if we can get out something that works, we can then 
> evolve it to work better.  We have got to find the simplest common 
> denominator that works, call that iCal-Basic, and release it. That's 
> the four-footed fish crawling up on the shore... we'll get to mammals 
> later.

I believe this post goes to the heart of everything that is most broken 
about iCal, and that we must take it very seriously if we're to have 
any hope of fixing this mess.  I will therefore reiterate yet again my 
past observations about the potential for radical simplification, 
simply because no one has yet convinced me that what I advocate would 
be an *over* simplification.  I believe that we should grab for any 
simplification that won't demonstrably make the standard inadequate for 
its primary purposes, which I regard to be personal and interpersonal 
event scheduling.

I still believe that we can completely eliminate recurrence rules, and, 
given that elimination, we can radically reduce the importance and 
complexity of time zones as well.

First of all, let's consider carefully what will happen if we choose to 
go down the road, as many are proposing, of making RRULES an optional 
part of the specification.  In that world, the composer of an email 
invitation to a repeating meeting won't be able to know (for reasons 
touched on in my companion post, "Receiver Capability Description 
Considered Harmful") whether or not the recipient(s) will understand 
RRULES.  Thus, such a composer will inevitably end up sending repeating 
meeting invitations as multipart/alternatives, containing both a "set" 
and a "rule" description of the repeating meeting.  In that case, I 
would argue that the RRULES can be dispensed with entirely as 
redundant.

Eliminating RRULES implies, in turn, that we can use UTC for nearly 
everything, so that the only time zone translation that needs to be 
done is at the user level and involves the relatively straightforward 
translation between UTC and the user's own time zone.  Together, this 
pair of changes would be an enormous simplification of a protocol that 
I believe is choking under its own complexity.  Even the discussion on 
this list about how to simplify RRULES is, I fear, too complex for many 
potential implementors to understand, and thus will inevitably lead to 
"misinterpretations."  (I put the word in quotes because I believe that 
if there is any way to misinterpret a standard, it is the spec that is 
at fault, not the implementor.   Long experience has taught that if 
there is more than one way to interpret an RFC, it will be interpreted 
in more than one way by software that claims to be conformant.)

If, as I am claiming, it is *possible* to do everything without RRULES, 
and that RRULES are just a bandwith-and-space-saving-convenience for 
repeat meetings that have LOTS of repeats (and, of course, a truly 
vital feature for any imaginary meetings that continue infinitely, 
unlike their attendees), then we should try to build a complete version 
without RRULES first, and only try to add on the efficiency/convenience 
of RRULES later, if at all.  Worrying about the cost/efficiency of 
representing a recurring meeting, in a world full of BitTorrent and 
webcams, strikes me as rather myopic.  If we can live with base64, we 
can live with this.

I know that several of you are tired of hearing this argument from me.  
I encourage you to shut me up by convincing me that it is NOT possible 
to define a completely adequate version of iCal that doesn't have any 
recurrence rules.  But if it is possible, I think it is what we should 
do. -- Nathaniel



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AGTLaZ014120 for <[e-mail]>; Thu, 10 Feb 2005 08:29:21 -0800
Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A463B0F30272; Thu, 10 Feb 2005 07:57:23 -0800
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: [e-mail]
From: Nathaniel Borenstein <[e-mail]>
Date: Thu, 10 Feb 2005 11:29:14 -0500
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] The ical version number must be bumped
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 16:29:21 -0000

In October, Doug wrote:

> The difficult part is to ensure that we can distinguish old and new 
> objects
> and interoperate as much as possible.

which Tom Ramsdell simplified to:

> Default has to be current behavior to accomodate existing iCalendar 
> generators.

It seems to me that, given the number and nature of the problems with 
the old spec, we have no real choice but to bump the ical version 
number to 3.0.  Tom's concern about backwards compatibility is a real 
one, but my feeling is that, for as long as there are enough ical 2.0 
implementations out there to care abut, a 3.0-complaint implementation 
can *send* both 2.0 and 3.0 data, wrapped in a multipart/alternative.  
It's ugly, but it's the only hope I see for getting to a cleaner, 
simpler design in the long run.

With regard to how we'll actually specify version numbers, Tim Hare 
wrote:

> VERSION; LEVEL=STANDARD: 2.0    Complies with RFC 2445/6/7 as written 
> today
> VERSION: 2.0                            Same as above, under 2.0 
> default would be LEVEL=STANDARD to grandfather existing stuff
> VERSION: 3.0                            Same as the first one, under 
> 3.0 default would be LEVEL=BASIC
> VERSION; LEVEL=EXTENDED: 3.0    Standard plus extensions, look for the 
> EXTENSIONS property
> EXTENSIONS: RFC9901, RFC9902, RFC9903

I think that this and similar proposals to embed capability information 
with the version number are plausible but perilous, for reasons 
described in my other post, "Receiver Capability Description Considered 
Harmful".  That is, they're useful, but I think it would be a mistake 
to use version numbers received in the past to make choices about the 
format of a message to be sent.

Finally, a minor syntactic comment is that if we go down the path of 
extensions, I don't see why we need the syntactic change of "LEVEL=" -- 
it seems to me that syntactically you can do just as well with

	VERSION:  3.0; EXTENSIONS="EXT1, EXT2, etc."

I also claim that it's safer to give these things symbolic names (EXT1) 
rather than RFC numbers, so that it will be possible to produce a new 
RFC that clarifies but does not change the meaning of an extension.

Version numbers are very tricky.  I will be embarassed about our 
underspecification of "MIME-Version: 1.0" to my dying day.  Let's try 
to get this one right.  -- Nathaniel



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AGT9aZ014114 for <[e-mail]>; Thu, 10 Feb 2005 08:29:10 -0800
Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A457B0F30272; Thu, 10 Feb 2005 07:57:11 -0800
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: [e-mail]
From: Nathaniel Borenstein <[e-mail]>
Date: Thu, 10 Feb 2005 11:29:04 -0500
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Receiver Capability Description Considered Harmful
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 16:29:10 -0000

I'm somewhat concerned about any suggestion (below made by Doug, but 
he's by no means alone) that encourages the composer of an iTIP message 
to try to take into account the capabilities of the intended 
receiver(s):

> 2) We add a property to all iTIP replies that indicate the supported 
> features of the
>     side that is replying. We name this new property EXTENSIONS. And 
> it will be
>     a muilti valued   property that lists the RFC numbers of 
> extensions supported by the
>     sender of the object.  This property will go at the same level as 
> VERSION.

I am skeptical that we can ever make this sort of capabilities 
consideration work well in an email (imip) context.  There's no 
precedent for requiring email composers to ascertain the recipient's 
capabilities before deciding on the format of the message they're 
sending, and I'd prefer not to make the calendaring work depend on such 
a disruptive change to the email model.  Note that ESMTP is not a 
counterexample, because the only capabilities exchange happens 
synchronously at SMTP hops rather than when the message is being 
composed for eventual delivery to a (possibly offline) recipient. -- 
Nathaniel



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1AGSpaZ014097 for <[e-mail]>; Thu, 10 Feb 2005 08:28:51 -0800
Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A445B0F30272; Thu, 10 Feb 2005 07:56:53 -0800
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Nathaniel Borenstein <[e-mail]>
Date: Thu, 10 Feb 2005 11:28:44 -0500
To: [e-mail]
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Jumping back into the fray, with an apology
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 16:28:51 -0000

I must begin with an apology:  I had fallen way behind on the 
calendaring discussions due to a combination of new work 
responsibilities, family crises, and the usual email overload.  
However,  I have actually managed to catch up on the discussions, and 
have a few comments to throw in; I apologize for their tardiness.

My comments center around the notion of *simplifying* ical.  I am not 
yet convinced that we are being radical enough for this effort to 
succeed.  I have comments on 3 general topics that have come up in the 
last few months of discussion, which I am separating into 3 different 
messages, to make any subsequent discussion easier to follow.  My next 
three messages will discuss the following topics:

	-- Receiver Capability Description Considered Harmful
	-- The ical version number must be bumped
	-- What's wrong with more radical simplification?

Finally, after all of this belated and opinionated ranting, you will no 
doubt be happy to hear that I have no opinion whatsoever on the XML 
question.  I firmly believe that if we ever get the semantics right, 
either syntax will be fine.  -- Nathaniel



X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from smtp804.mail.sc5.yahoo.com (smtp804.mail.sc5.yahoo.com [66.163.168.183]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1A5VSaZ029736 for <[e-mail]>; Wed, 9 Feb 2005 21:31:28 -0800
Received: from unknown (HELO ?192.168.0.100?) ([e-mail]@69.107.151.197 with plain) by smtp804.mail.sc5.yahoo.com with SMTP; 10 Feb 2005 05:31:28 -0000
Message-ID: <[e-mail]>
Date: Wed, 09 Feb 2005 21:31:20 -0800
From: Dave Thewlis <[e-mail]>
Organization: The Calendaring and Scheduling Consortium
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Subject: [Ietf-calsify] Report on Calconnect Roundtable II; advance notice of Roundtable III - The Calendaring and Scheduling Consortium
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Thu, 10 Feb 2005 05:31:29 -0000

This note is going to the ietf-caldav and ietf-calsify mailing lists,
which means that many people will get it twice.  My apologies; there
seem to be enough people on one or the other but not both to require
separate sends.

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

The Calendaring and Scheduling Consortium, also known as CalConnect,
held its first formal  Roundtable event together with an Interop in
Seattle, Washington on 11-13 January, hosted by the University of
Washington.

A report on Roundtable II  has been posted to the Calconnect website at
www.calconnect.org:  choose "Roundtable II" from the sidebar or go to
www.calconnect.org/roundtable2.html.

The public report on the Interop event has been posted on the website
under Past Interops, where you can also locate information and results
from previous Calconnect Interops.

The next Consortium Roundtable and Interop will be 1-3 June, 2005,
hosted by Duke University in Durham, North Carolina.

Please visit our website at www.calconnect.org for further information
about the Consortium including events, technical committees, and
Interops.  Please contact me with any questions or for information about
joining the Consoritum.

Best Regards,

Dave Thewlis, Executive Director
The Calendaring and Scheduling Consortium
[phone] voice   [phone] cell









X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1219daa006017 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Tue, 1 Feb 2005 17:09:40 -0800
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1219W7J015699 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 1 Feb 2005 17:09:34 -0800
Message-ID: <[e-mail]>
Date: Tue, 01 Feb 2005 18:09:31 -0700
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] BOF at Minneapolis IETF meeting
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040804090807080501050104"
X-Royer.com-MailScanner-Information: Please contact [e-mail] for more information
X-Royer.com-MailScanner: Found to be clean
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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: Wed, 02 Feb 2005 01:09:41 -0000

This is a cryptographically signed message in MIME format.

--------------ms040804090807080501050104
Content-Type: multipart/mixed; boundary="------------030001040908070106000501"

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


> Input to this BOF will be a problem statement internet-draft 
> draft-daboo-calsify-issues-00.txt that pulls together existing document 
> errata, known problems with the specs and results from interoperability 
> tests.

I was getting ready to go back over the CALSCH archives and my notes
to get such a list. I am glad your going to do this, I'll wait.


  In addition, draft-royer-ical-basic-01.txt provides one possible
> direction for revisions.

It is now at -02. I put REPEAT and DURATION back in VALARM, they
should not have been deprecated. And other fixes to text.

  == and unrelated ==

And draft-royer-timezone-registry-01.txt is out
with suggestions from others including the 'TZ' guru mailing
list.

NOTE: Some on the TZ mailing list that say they do the real
work of keeping the database up to date requested that we
stop calling it the 'Olson' database and start calling it
the 'TZ' database. Mr. Olson had no objection.

So TZ-01 calls it the TZ database.

It adds optional POLYGON that descries the longitude / latitude of a 
polygon that outlines a TZ region per the request of some
cartographers. The  counter clockwise direction was a suggestion by
the TZ mailing list.

-- 

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

               We Do Standards - You Need Standards


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

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


--------------030001040908070106000501--

--------------ms040804090807080501050104
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
9w0BCQUxDxcNMDUwMjAyMDEwOTMxWjAjBgkqhkiG9w0BCQQxFgQU7ihdIqInhQrrb8k0BrOq
S9KZma8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAAn6ZCcIeK85ak5at6xfmkBJoV+FmZw6Jw0g5CySLY5bUrwGzY0tAxlaT4At6Ah9K
zTAo+nn5z65y1o2V1q2pyufEDi/kn99ozhXGB0YTipyPxOXuR5yOs2mk1mneOkJqaPJ0nhpR
ku/nsagXNas0C+Gm+sALLukHN5tg0nHp7Rf3pkhDcd/CZVP6N2SRjNmz6Nd6iU62QITuhAOk
u8ElM47OSVqk76XQPHKtOGnxDLYN1XLCHFwMaWDzgiaZ4d/SC5czZkjnzaiFDdevCVOPxGHZ
6DuoPHdTIKFBJVGmEr/9EGp/nK4HqTgsdhIVbr0H310brP/3VRN11TWsyJANGgAAAAAAAA==
--------------ms040804090807080501050104--


X-Envelope-From: [e-mail]
X-Envelope-To: <[e-mail]>
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j11Fb3aa007550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 1 Feb 2005 07:37:08 -0800
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j11FU36E019810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Feb 2005 10:30:04 -0500
Date: Tue, 01 Feb 2005 10:37:00 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-calsify] BOF at Minneapolis IETF meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
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, 01 Feb 2005 15:37:11 -0000

Hi folks,
We have requested a BOF slot for the IETF meeting in Minneapolis to help us 
jump start the Calsify effort. Below is the Agenda for the proposed BOF. 
Note that we can tweak this as needed before the actual meeting. The goal 
for the BOF (as mentioned below) is to come up with major charter points 
and milestones that can be used for an IETF working group charter to help 
carry out this work, assuming that that is what we actually want to do.

I am still working on the draft metione3d in the agenda. This will 
basically attempt to summarise current issues in the existing specs to help 
us formulate a possible solution. Right now I am planning on incorporating 
problem info from:

<http://www.softwarestudio.org/iCal/2445Issues.html>

<http://tipi.sourceforge.net/doc/recur/apa.html>

RFCEditor errata page

Interop reports.

I will also try and scan the mailing lists to extract issues from there, 
but the deadline for -00 drafts is next Monday and a thorough mailing list 
scan may take a while. If you know of any other sources of 2445 etc issues, 
please let me know. If you have your own list of issues, I would appreciate 
it if you could forward those to me too.


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

Calendaring and Scheduling Simplification BOF (Calsify)

Chairs: Cyrus Daboo <[e-mail]>
        RL 'Bob' Morgan <[e-mail]>

Description

Calendaring and Scheduling is currently defined in RFCs 2445, 2446 and 
2447. These documents have been available for several years now, and a 
number of implementations exist. However, a number of interoperability 
problems exist between these implementations, some due to bugs in the 
specifications, some due to lack of clarity in the specifications and some 
due to under specification of key behaviors. As a result, interoperable 
calendaring and scheduling has not been truly achieved.

The purpose of this BOF is to discuss revising RFCs 2445, 2446 and 2447 
with the primary goal of achieving interoperability over the range of 
calendaring and scheduling tasks needed in real world situations. The goal 
of the BOF is to come up with a clear direction on how those revisions 
should be done, including the scope of changes. The desired outcome is a 
set of major charter points and milestones for a proposed IETF calsify 
working group.

Input to this BOF will be a problem statement internet-draft 
draft-daboo-calsify-issues-00.txt that pulls together existing document 
errata, known problems with the specs and results from interoperability 
tests. In addition, draft-royer-ical-basic-01.txt provides one possible 
direction for revisions.

Proposed agenda follows:

Agenda

- Introduction (blue sheets, scribe etc)    (1 min)
- Agenda Bashing                            (3 mins)
- Introduction                              (6 mins)
- Problem statement document                (60 mins)
- Possible Solutions                        (40 mins)
- Next Steps/WG CHarter                     (10 mins)

Total                                       120 mins

-- 
Cyrus Daboo