[Ietf-calsify] Example of the RRULE and TIMEZONE problem
Doug at Royer.com (Doug Royer) Fri, 29 October 2004 20:04 UTC
From: "Doug at Royer.com"
Date: Fri, 29 Oct 2004 20:04:40 +0000
Subject: [Ietf-calsify] Example of the RRULE and TIMEZONE problem
Message-ID: <418304BC.90905@Royer.com>
X-Date: Fri Oct 29 20:04:40 2004
This is an example of why the timezone problem is important.
Both of these companies have large resources and can not interoperate.
http://staff.washington.edu/oren/weblog/archives/000317.html
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041029/56596568/smime.bin
From TimHare at comcast.net Sun Oct 31 11:31:03 2004
From: TimHare at comcast.net (TimHare@comcast.net)
Date: Sun Oct 31 11:40:37 2004
Subject: [Ietf-calsify] food for thought
Message-ID: <6.1.1.1.0.20041031142118.02809c40@mail.comcast.net>
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.
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9VJeSM4003940 for <ietf-calsify@osafoundation.org>; Sun, 31 Oct 2004 11:40:31 -0800
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc13) with SMTP id <200410311940170150079vahe> (Authid: TimHare); Sun, 31 Oct 2004 19:40:17 +0000
Message-Id: <6.1.1.1.0.20041031142118.02809c40@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Sun, 31 Oct 2004 14:31:03 -0500
To: ietf-calsify@osafoundation.org
From: TimHare@comcast.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.42 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, NO_REAL_NAME
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] food for thought
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Oct 2004 19:40:34 -0000
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.
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9U34aM5017888 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 20:04:37 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9U34Svt030585 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 20:04:30 -0700
Message-ID: <418304BC.90905@Royer.com>
Date: Fri, 29 Oct 2004 21:04:28 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010103050707010204090405"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] Example of the RRULE and TIMEZONE problem
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Oct 2004 03:04:39 -0000
This is a cryptographically signed message in MIME format.
--------------ms010103050707010204090405
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
This is an example of why the timezone problem is important.
Both of these companies have large resources and can not interoperate.
http://staff.washington.edu/oren/weblog/archives/000317.html
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms010103050707010204090405
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
9w0BCQUxDxcNMDQxMDMwMDMwNDI4WjAjBgkqhkiG9w0BCQQxFgQUGT4MMPBsKK7D8xfgnLCU
ZJ1MDsMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAcWRgdBDmZoQEv1htleSd3YwAB70C3LU151T6uKFcySf1/ANeFPN8s7+ckyEc6hL9
495qQ+JY6plaThYBYRhDhMSGswrHhtNRiXHKigpUDN+BIEQC7t8PkKI0sj/fZrh1UZ38AqF1
ss59X5f6lyh1ZQ0je42WtEBPXpOUv2wyq04puxULOjy/h3Tfa0KY73SDxofkUPSLIwXLXoFR
r6ICr0mXyEJOUOPpGW/3eMkXYTQk6IcwBze88N8YnTff2vCiBdjH0jYz+G4NleW21SmFZHhR
v+vPruoI4a+uh4xuB4l4v0P0JsMyfoqCQVeRqg1CYGt1WqowqrdJt3NZqApH5gAAAAAAAA==
--------------ms010103050707010204090405--
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9U2QmM4016757 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 19:26:49 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc11) with SMTP id <200410300226420110031ku3e> (Authid: TimHare); Sat, 30 Oct 2004 02:26:42 +0000
Message-Id: <6.1.1.1.0.20041029220433.0286a810@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Fri, 29 Oct 2004 22:18:27 -0400
To: ietf-calsify@osafoundation.org
From: TimHare@comcast.net
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
In-Reply-To: <OFA70CD540.10EB521E-ON85256F3C.005F1C0D-85256F3C.005F3213@ notesdev.ibm.com>
References: <4181C499.80307@Royer.com> <OFA70CD540.10EB521E-ON85256F3C.005F1C0D-85256F3C.005F3213@notesdev.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.42 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, NO_REAL_NAME
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Oct 2004 02:26:51 -0000
At 01:20 PM 10/29/04, you wrote:
>Default has to be current behavior to accomidate existing iCalendar
>generators.
I disagree with this statement - current generators do not generate a
'basic' set of iCalendar items.
I also disagree with 'interoperate with most things Outlook can do'.
In my opion, existing generators could, without huge changes, transform a
more-complex set of items into a simpler, iCal-Basic set.
For example, it shouldn't be difficult to create a set of VEVENTs from a
recurrence rule, to send to an "outside" client whose capabilities are
unknow - a generator probably already has this expansion function to expand
incoming recurrence rules.
And, as Helge Hess said, there are other use cases which don't need the
complexity of RRULEs and timezones.
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: lisa@osafoundation.org
Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TNpwM5011902 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 29 Oct 2004 16:52:00 -0700
In-Reply-To: <200410291924.02630.mark@ScheduleWorld.com>
References: <200410281850.17020.mark@ScheduleWorld.com> <200410291822.39586.mark@ScheduleWorld.com> <2B1D3300-29FC-11D9-BF85-000D93C1A604@opengroupware.org> <200410291924.02630.mark@ScheduleWorld.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8067E244-2A05-11D9-BF80-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 16:51:50 -0700
To: Mark Swanson <mark@ScheduleWorld.com>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 23:52:01 -0000
There are also the use cases I've discussed with people who work on
Atom and XMPP
Atom:
- publish the timestamp of a blog post in a iCalendar-compatible way
- publish the location (ditto)
- use a blog post to advertise an event
XMPP:
- use XMPP as a transport for alarms (make your IM-enabled device make
a sound)
- send an invitation over XMPP to a calendar application
- negotiate a mutually free time by exchanging free-busy time
All of these cases, however, require an XML format compatible with the
fairly-standard ways Atom and XMPP use namespaces.
Lisa
On Oct 29, 2004, at 4:24 PM, Mark Swanson wrote:
> On October 29, 2004 6:45 pm, Helge Hess wrote:
>
>> As a simple example take Bugzilla. It currently doesn't implement
>> iCal.
>> It doesn't need recurrences nor does it require timezones in the
>> server. Nevertheless it would be great to be able to publish _and_
>> process tasks in an iCalendar format.
>> Currently it would need to implement the full iCal spec (aka a full
>> scheduling solution) which is out of question while implementing the
>> UTC based variant should be almost trivial.
>
> It would be great. All sorts of wonderful new things would happen from
> such
> interoperability.
>
>> PS: I have no religious issues with Outlook (we even provide an own
>> MAPI storage provider), but "other" solutions are equally, if not more
>> important in the broader scope of calendaring.
>
> As an iCalendar client/server provider, I didn't make my statement
> lightly:-)
>
> Perhaps I haven't understood what folks on this list were trying to
> accomplish
> with the lite version. I couldn't see how _I_ could use a lite
> version, and
> hadn't thought of the Bugzilla example until you just mentioned it.
> eBay
> might be another example. I can see why you previously mentioned
> RRULEs may
> not be needed, and why timezones would not be necessary for a number
> of apps.
> I think I assumed folks on this list were thinking of Outlook-like
> applications only.
>
> Cheers.
>
>
> --
> Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
> 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
> Ietf-calsify@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
X-Envelope-From: helge.hess@opengroupware.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TNb3M4011378 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 16:37:04 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id BBEAC299794 for <ietf-calsify@osafoundation.org>; Sat, 30 Oct 2004 01:36:40 +0200 (CEST)
Received: from [213.187.86.104] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 5934B299792 for <ietf-calsify@osafoundation.org>; Sat, 30 Oct 2004 01:36:40 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <200410291924.02630.mark@ScheduleWorld.com>
References: <200410281850.17020.mark@ScheduleWorld.com> <200410291822.39586.mark@ScheduleWorld.com> <2B1D3300-29FC-11D9-BF85-000D93C1A604@opengroupware.org> <200410291924.02630.mark@ScheduleWorld.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6DDD9DDF-2A03-11D9-BF85-000D93C1A604@opengroupware.org>
Content-Transfer-Encoding: 7bit
From: Helge Hess <helge.hess@opengroupware.org>
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Sat, 30 Oct 2004 01:37:00 +0200
To: ietf-calsify@osafoundation.org
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 23:37:05 -0000
On Oct 30, 2004, at 1:24, Mark Swanson wrote:
> Perhaps I haven't understood what folks on this list were trying to
> accomplish
> with the lite version.
Well, I'm not the list, this is just my opinion. We currently have no
events/tasks sharing mechanism which works on a lower level which leads
to no interoperability at all for a lot of solutions.
And even those which implement the full spec seem to have
interoperability issues.
> I couldn't see how _I_ could use a lite version, and
> hadn't thought of the Bugzilla example until you just mentioned it.
> eBay
> might be another example.
Yes, and loads of other stuff (viewing/editing blog entries in a
calendar is another one). A lot of things are bound to time and can be
represented as vevents or vtodos.
> I can see why you previously mentioned RRULEs may
> not be needed, and why timezones would not be necessary for a number
> of apps.
> I think I assumed folks on this list were thinking of Outlook-like
> applications only.
Even for Outlook like applications RRULE's are not strictly necessary,
recurrencies can be done in other ways, even "on top of the UTC-only
base spec". Most OpenSource groupware servers I know implement
recurring events as individual (but connected) events.
So the client is responsible for "evaluating" the RRULE and the
server/store only needs to know that they belong together (and maybe
keep some hint on how the construction was initially done).
regards,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TNO0M4010851 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 16:24:00 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 658 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 18:23:58 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 19:24:02 -0400
User-Agent: KMail/1.6.2
References: <200410281850.17020.mark@ScheduleWorld.com> <200410291822.39586.mark@ScheduleWorld.com> <2B1D3300-29FC-11D9-BF85-000D93C1A604@opengroupware.org>
In-Reply-To: <2B1D3300-29FC-11D9-BF85-000D93C1A604@opengroupware.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200410291924.02630.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 23:24:03 -0000
On October 29, 2004 6:45 pm, Helge Hess wrote:
> As a simple example take Bugzilla. It currently doesn't implement iCal.
> It doesn't need recurrences nor does it require timezones in the
> server. Nevertheless it would be great to be able to publish _and_
> process tasks in an iCalendar format.
> Currently it would need to implement the full iCal spec (aka a full
> scheduling solution) which is out of question while implementing the
> UTC based variant should be almost trivial.
It would be great. All sorts of wonderful new things would happen from such
interoperability.
> PS: I have no religious issues with Outlook (we even provide an own
> MAPI storage provider), but "other" solutions are equally, if not more
> important in the broader scope of calendaring.
As an iCalendar client/server provider, I didn't make my statement lightly:-)
Perhaps I haven't understood what folks on this list were trying to accomplish
with the lite version. I couldn't see how _I_ could use a lite version, and
hadn't thought of the Bugzilla example until you just mentioned it. eBay
might be another example. I can see why you previously mentioned RRULEs may
not be needed, and why timezones would not be necessary for a number of apps.
I think I assumed folks on this list were thinking of Outlook-like
applications only.
Cheers.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: helge.hess@opengroupware.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TMj5M4008148 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 15:45:06 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 35E442996C5 for <ietf-calsify@osafoundation.org>; Sat, 30 Oct 2004 00:44:42 +0200 (CEST)
Received: from [213.187.86.104] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id B3E0429965F for <ietf-calsify@osafoundation.org>; Sat, 30 Oct 2004 00:44:41 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <200410291822.39586.mark@ScheduleWorld.com>
References: <200410281850.17020.mark@ScheduleWorld.com> <200410291514.53392.mark@ScheduleWorld.com> <4182B89F.5000202@Royer.com> <200410291822.39586.mark@ScheduleWorld.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2B1D3300-29FC-11D9-BF85-000D93C1A604@opengroupware.org>
Content-Transfer-Encoding: 7bit
From: Helge Hess <helge.hess@opengroupware.org>
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Sat, 30 Oct 2004 00:45:01 +0200
To: ietf-calsify@osafoundation.org
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 22:45:08 -0000
On Oct 30, 2004, at 0:22, Mark Swanson wrote:
> OK. I still seem to be incorrectly getting my point across. It doesn't
> matter;
> it was just a brain fart about interoperability with the only "others"
> that
> matter: Outlook (probably Lotus Notes too).
That matter: _to you_ (or your customers, whatever).
While we are also interested in Outlook compatibility, it is equally
important for us to have compatibility with Mozilla Calendar, Kontact,
Evolution or Chandler. And to have interoperability with other
solutions which currently do not implement iCalendar because getting
started is quite hard (this covers a _huge_ number of existing
solutions).
Yes, we need a "non-basic" standard which includes the things which are
supported by Outlook, probably almost the complete current spec and a
lot of clients will implement that (eg Kontact and Evolution).
But besides that a basic spec, which only supports a certain set of
features (and eg restricts itself to UTC) allows us to significantly
lower the entry barrier to the standard. This would be IMO a very good
thing.
As a simple example take Bugzilla. It currently doesn't implement iCal.
It doesn't need recurrences nor does it require timezones in the
server. Nevertheless it would be great to be able to publish _and_
process tasks in an iCalendar format.
Currently it would need to implement the full iCal spec (aka a full
scheduling solution) which is out of question while implementing the
UTC based variant should be almost trivial.
best regards,
Helge
PS: I have no religious issues with Outlook (we even provide an own
MAPI storage provider), but "other" solutions are equally, if not more
important in the broader scope of calendaring.
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TMMbM4007148 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 15:22:37 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 213; Fri, 29 Oct 2004 17:22:36 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 18:22:39 -0400
User-Agent: KMail/1.6.2
References: <200410281850.17020.mark@ScheduleWorld.com> <200410291514.53392.mark@ScheduleWorld.com> <4182B89F.5000202@Royer.com>
In-Reply-To: <4182B89F.5000202@Royer.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200410291822.39586.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
Cc:
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 22:22:39 -0000
On October 29, 2004 5:39 pm, Doug Royer wrote:
> Mark Swanson wrote:
> >I see no point in having a lite/basic version of iCalendar unless the
> >lite/basic version includes the most common and useful parts of 2445 as
> >implemented by Outlook. Timezones, RRULEs (including dealing with specific
> >rrule instances), and others fall in this category.
>
> The point is (1) interopability with others. and (2) finding
> the correct subset.
OK. I still seem to be incorrectly getting my point across. It doesn't matter;
it was just a brain fart about interoperability with the only "others" that
matter: Outlook (probably Lotus Notes too).
Cheers.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TM9fM5006470 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 15:09:42 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9TM9Xvt027020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 15:09:35 -0700
Message-ID: <4182BF9D.20303@Royer.com>
Date: Fri, 29 Oct 2004 16:09:33 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
References: <OF86E32F70.0DC63299-ON85256F3C.007844AB-85256F3C.00784B89@notesdev.ibm.com>
In-Reply-To: <OF86E32F70.0DC63299-ON85256F3C.007844AB-85256F3C.00784B89@notesdev.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 22:09:44 -0000
Robert_Ransdell@notesdev.ibm.com wrote:
>I do believe all the vendors that attended the interop sessions agree on
>rules and timezone. (ie more than 2)
>
>
1) As that list and details are unpublished - this does not mean much to
anyone at this time.
2) Not all vendors on this list or CalDav participated. So if the
results are ever published
they will be valuable input, but it will not be the entire list of
issues.
The fact that several on this list are talking about interoperability
problems
with respect to recurring rules is the point of this discussion.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TLtXM4005206 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:55:33 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 254 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 16:55:32 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 17:55:34 -0400
User-Agent: KMail/1.6.2
References: <200410281850.17020.mark@ScheduleWorld.com> <200410291525.21395.mark@ScheduleWorld.com> <16770.45941.236732.925001@cnr.cs.columbia.edu>
In-Reply-To: <16770.45941.236732.925001@cnr.cs.columbia.edu>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200410291755.34778.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:55:36 -0000
On October 29, 2004 5:17 pm, Jonathan Lennox wrote:
> That only works because ET and PT have the same DST transition rule. You
> can't correctly share RRULEs with people in Europe, or Australia, say.
> (You probably even run into trouble with people in Arizona.)
Yep. Good catch Jonathan.
I'm shortly going to uncomment my forceUTC() code and let my TimeZone code
path be the standard codepath again so everything works perfectly. I've been
meaning to do this anyway because of a UTC-related issue with Outlook.
ScheduleWorld is free, and if anyone is interested simply use it to observe
the transition change scenario. I'm no longer interested in this direction as
I have fully working timezone code available. The current UTC-based codepath
will be in production for at least another week.
Cheers.
P.S. Even with a DST transition difference problem some folks still might find
it appealing.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: Robert_Ransdell@notesdev.ibm.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TLsfM4005008 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:54:41 -0700
In-Reply-To: <4182B96B.1000007@Royer.com>
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <OF86E32F70.0DC63299-ON85256F3C.007844AB-85256F3C.00784B89@notesdev.ibm.com>
From: Robert_Ransdell@notesdev.ibm.com
Date: Fri, 29 Oct 2004 17:54:28 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 10/29/2004 05:52:00 PM
Content-Type: multipart/mixed; boundary="=_mixed 00784B8185256F3C_="
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:54:44 -0000
This is a multi-part message in MIME format...
--=_mixed 00784B8185256F3C_=
Content-Type: multipart/alternative;
boundary="=_alternative 00784B8185256F3C_="
--=_alternative 00784B8185256F3C_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline
I do believe all the vendors that attended the interop sessions agree on
rules and timezone. (ie more than 2)
Doug Royer <Doug@royer.com>
Sent by: ietf-calsify-bounces@osafoundation.org
10/29/2004 05:43 PM
Please respond to
ietf-calsify@osafoundation.org
To
ietf-calsify@osafoundation.org
cc
Subject
[Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
Robert_Ransdell@notesdev.ibm.com wrote:
>Outlook and Notes ... 2 largest (by client count) vendors do timezone and
>rules the same
>
Yes - exactly, no three vendors have the same default behavious.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
--=_alternative 00784B8185256F3C_=--
--=_mixed 00784B8185256F3C_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQxMDI5MjE0MzA3WjAjBgkqhkiG9w0BCQQxFgQUTr9px6sT
tvxsI3ccQzKIUu1RHAYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAj4ap5kJWguvXwpEpni97SlxBBik1
OdHeDO3NGX95FNz/W3a/deLzOWL/T/A6OoCeJ5wVO6hdCIIcoYDnjEC8uZoQ
q4oTYM0WuF1Sazz/ShbYug9g0V9+y39a3fXA1Ugi2cG1FHtzDetWfjalsatc
XoqTgSdTAuv5DOuPkGhvS57o3/eHW9pg6f3pWyl3/5NgCN31oU7GxRvjb6i/
zsfpLLvYsMksrwzTHFi+qhczJpJkcDn5vT9KW54YQxJB+RGlJk5og4yBmBqy
+gC9QDanTceZbuUZsjCdXbUydQtsBSdizRrPHX/F7HqvtVKjuQ+zdAiVdppk
QUGPr6AAxyo5QAAAAAAAAA==
--=_mixed 00784B8185256F3C_=--
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TLhCM5004224 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:43:13 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9TLh7vt026493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:43:10 -0700
Message-ID: <4182B96B.1000007@Royer.com>
Date: Fri, 29 Oct 2004 15:43:07 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020604040006020303090107"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:43:14 -0000
This is a cryptographically signed message in MIME format.
--------------ms020604040006020303090107
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Robert_Ransdell@notesdev.ibm.com wrote:
>Outlook and Notes ... 2 largest (by client count) vendors do timezone and
>rules the same
>
Yes - exactly, no three vendors have the same default behavious.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms020604040006020303090107
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
9w0BCQUxDxcNMDQxMDI5MjE0MzA3WjAjBgkqhkiG9w0BCQQxFgQUTr9px6sTtvxsI3ccQzKI
Uu1RHAYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAj4ap5kJWguvXwpEpni97SlxBBik1OdHeDO3NGX95FNz/W3a/deLzOWL/T/A6OoCe
J5wVO6hdCIIcoYDnjEC8uZoQq4oTYM0WuF1Sazz/ShbYug9g0V9+y39a3fXA1Ugi2cG1FHtz
DetWfjalsatcXoqTgSdTAuv5DOuPkGhvS57o3/eHW9pg6f3pWyl3/5NgCN31oU7GxRvjb6i/
zsfpLLvYsMksrwzTHFi+qhczJpJkcDn5vT9KW54YQxJB+RGlJk5og4yBmBqy+gC9QDanTceZ
buUZsjCdXbUydQtsBSdizRrPHX/F7HqvtVKjuQ+zdAiVdppkQUGPr6AAxyo5QAAAAAAAAA==
--------------ms020604040006020303090107--
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TLdmM5004056 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:39:50 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9TLdhvt026362 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:39:47 -0700
Message-ID: <4182B89F.5000202@Royer.com>
Date: Fri, 29 Oct 2004 15:39:43 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
References: <200410281850.17020.mark@ScheduleWorld.com> <200410290917.17190.mark@ScheduleWorld.com> <4182872E.8030707@Royer.com> <200410291514.53392.mark@ScheduleWorld.com>
In-Reply-To: <200410291514.53392.mark@ScheduleWorld.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060104000801010607090007"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:39:51 -0000
This is a cryptographically signed message in MIME format.
--------------ms060104000801010607090007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Mark Swanson wrote:
>
>I see no point in having a lite/basic version of iCalendar unless the
>lite/basic version includes the most common and useful parts of 2445 as
>implemented by Outlook. Timezones, RRULEs (including dealing with specific
>rrule instances), and others fall in this category.
>
>
The point is (1) interopability with others. and (2) finding
the correct subset.
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms060104000801010607090007
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
9w0BCQUxDxcNMDQxMDI5MjEzOTQzWjAjBgkqhkiG9w0BCQQxFgQUErw5987O5ycyTb/xWivW
0+MqguYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAYNyZtRWY4DY1R9hDj88rlgNVHm1ig4SA0XV2BDD5cDiex8r7hzYMMxdBnNRUIhAC
GP3Nx6uTw1Ri6L6yc4UtCyGJzo+Vn2nPwIDUyla8sY/Gz2T1rbjRkjeXKQo/8iT8Fgi5V/3m
qJk9KKh/wjvWDgqGM9xuvHMiEz4aqTUbyDf7TqP2y4oNrKyxEZUruOs9IZe9HfN+AtDyiFvP
sHsCQmjGzi1Yj5ACjLazsF7CuyfJGaP8cfgEDPut11E83XWt3QpikpejHpSMmGsjC82OIliq
HM8YBHfdPBV7F27oYb7mOY0RU0S2xZdfmWmvVERTa1s7O4Jgoes+SoiFou0dbQAAAAAAAA==
--------------ms060104000801010607090007--
X-Envelope-From: jeffrey@skyhouseconsulting.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from mail.skyhouseconsulting.com (skyhouseconsulting.com [69.55.227.180]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TLbCM5003957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:37:12 -0700
Received: from [192.168.1.99] (unknown [216.146.255.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.skyhouseconsulting.com (Postfix) with ESMTP id A85334680D2 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 16:38:01 -0500 (CDT)
Message-ID: <4182B807.8050707@skyhouseconsulting.com>
Date: Fri, 29 Oct 2004 16:37:11 -0500
From: Jeffrey Harris <jeffrey@skyhouseconsulting.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
References: <200410281850.17020.mark@ScheduleWorld.com> <41828DB6.1020705@skyhouseconsulting.com> <200410291525.21395.mark@ScheduleWorld.com>
In-Reply-To: <200410291525.21395.mark@ScheduleWorld.com>
X-Enigmail-Version: 0.84.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:37:13 -0000
Hi Mark,
>>I'm sorry, I'm just not following how an RRULE like "1PM every Monday"
>>will work in UTC, when the user is in a timezone whose UTC offset
>>changes with DST. Seems like this will fail about this time of year
>>regardless of whether I'm interacting with people in different
>>timezones. Am I missing something?
>
> Well, I have this exact model working in production and someone in EST can
> schedule RRULEs with someone in PST just fine - even crossing EDT/EST
> boundaries. The caveat is that you can't cross the midnight boundary as
> previously described. Perhaps you could post the steps you took to test this?
OK, I hadn't done any research on how real live clients are dealing with
RRULE and timezones, so I spent a little time with an Outlook .ics file.
I guess it's not true that there's a problem if people in the same time
zone use UTC without a VTIMEZONE, Outlook at least just assumes any
vCalendar file without a timezone must have been created in your DST
regime and changes the offset for DST whether that was intended or not.
That works for people who don't deal with anyone in Indiana, but it
doesn't if someone in Chicago is collaborating with someone in
Indianapolis, most of Indiana doesn't observe DST.
If I export an RRULE in Outlook for someone in Indianapolis, then remove
the VTIMEZONE component, then import it in the Chicago timezone, Outlook
assumes I didn't REALLY mean that my RRULE didn't observe DST. RFC2445
does say any RRULE which crosses a DST shift must include a VTIMEZONE,
so I guess what I created isn't actually a valid iCalendar file...
I'm not seeing how RRULEs without timezones can get around this problem.
But I'd love to be proved wrong, it would make my life much easier!
Sincerely,
Jeffrey
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TLVcM5003562 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:31:39 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9TLVUvt025975 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:31:31 -0700
Message-ID: <4182B6B1.3080808@Royer.com>
Date: Fri, 29 Oct 2004 15:31:29 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
References: <200410281850.17020.mark@ScheduleWorld.com> <41828DB6.1020705@skyhouseconsulting.com>
In-Reply-To: <41828DB6.1020705@skyhouseconsulting.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020106020002000702070708"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:31:41 -0000
This is a cryptographically signed message in MIME format.
--------------ms020106020002000702070708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Jeffrey Harris wrote:
> Hi Folks,
>
> I'm sorry, I'm just not following how an RRULE like "1PM every Monday"
> will work in UTC, when the user is in a timezone whose UTC offset
> changes with DST. Seems like this will fail about this time of year
> regardless of whether I'm interacting with people in different
> timezones. Am I missing something?
A fact is that not all vendors support the same recurrence rule sets.
That's one issue.
By expanding the instances before sending them we can then transport objects
that can be used by everyone. Each expanded instance includes its start
time in UTC using the existing property RECURRENCE-ID which
already allows for its TZID to be different from the DTSTART TZID.
Assume the original 2445 vevent of :
BEGIN:VEVENT
UID:A-1
DTSTART;TZID=US/Pacific: ...29 cot 2004 at 1 pm... <--
Original in US/Pacific
RRULE: ... repeat daily for 100 days ...
...
END:VEVENT
Now the proposal is not to eliminate recurrence rules entirely. It is to
allow the
transfer of information in a way that can be used by any vendor. And iCAL
already has such a mechanism to describe each individual instance and
that is
the RECURRENCE-ID property. (Exactly what recurrence rules will be
supported to be defined separately)
So, now when the sender does not know if the recipient can process
recurrence
rules (Which are defined as optional in 2446), they instead send an
equivalent set
of objects that are also 2445 compliant.
Here I am including my proposed EXTENSION property and IS-SUB-SET
parameter, and the RECURRENCE-ID is UTC update to that proposal. In
addition, by setting the IS-SUB-SET parameter to TRUE, the recipient now
knows that they can do a REFRESH later and get the other 95 instances.
(lines wrapped for clarity). Note that these objects are 100% 2445/2446
valid while at the same time allowing vendors that do not support any
recurrence properties to completely interoperate.
So when the sender does not know if the recipient understands
recurrence rules, they send the same information in a 100%
2445 compatible way. Note that RECURRENCE-ID is in UTC
for each expanded instance sent.
BEGIN:VCALENDAR
VERSION:2.0
EXTENSIONS: ...the number for RFC-recurrences... ** sender says
they support this
BEGIN:VEVENT
UID:A-1
DTSTART;IS-SUB-SET=TRUE
** more unsent instances exist.
;TZID=US/Pacific: ...29 OCT 2004 at 1 pm ...
** Still in original US/Pacific
RRULE: ... repeat daily for 100 days ...
RECURRENCE-ID;TZID=UTC: ...29 OCT 2004 at 7 am... ** Time
in UTC
...
END:VEVENT
BEGIN:VEVENT
UID:A-1
DTSTART;IS-SUB-SET=TRUE
;TZID=US/Pacific: ...30 OCT 2004 at 1 pm ...
RRULE: ... repeat daily for 100 days ...
RECURRENCE-ID;TZID=UTC: ...30 OCT 2004 at 7 ** Time
in UTC
...
END:VEVENT
BEGIN:VEVENT
UID:A-1
DTSTART;IS-SUB-SET=TRU
;TZID=US/Pacific: ...29 OCT 2004 at 1 pm ...
RRULE: ... repeat daily for 100 days ...
RECURRENCE-ID;TZID=UTC: ...31 OCT 2004 at 7 **
Time in UTC
...
END:VEVENT
BEGIN:VEVENT
UID:A-1
DTSTART;IS-SUB-SET=TRUE
;TZID=US/Pacific: ...29 OCT 2004 at 1 pm ...
RRULE: ... repeat daily for 100 days ...
RECURRENCE-ID;TZID=UTC: ...01 NOV 2004 at 7 **
Time in UTC
...
END:VEVENT
BEGIN:VEVENT
UID:A-1
DTSTART;IS-SUB-SET=TRUE
;TZID=US/Pacific: ...29 OCT 2004 at 1 pm ...
RRULE: ... repeat daily for 100 days ...
RECURRENCE-ID;TZID=UTC: ...02 NOV 2004 at 7 **
Time in UTC
...
END:VEVENT
Summary: Valid 2445 objects were sent in a way that a non-recurrence
rule application can understand and the recipient was informed (1) that
the sender does support recurrence rules and (2) there are more instances
in this set that can be fetched with a REFRESH at a later time.
It solves the problem of how many instances to expand or if to
support infinite repeating objects.
And it transfered the effective start time of each instances sent
regardless of the recpients time zone.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms020106020002000702070708
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
9w0BCQUxDxcNMDQxMDI5MjEzMTI5WjAjBgkqhkiG9w0BCQQxFgQUkvCBqIrMB4MtKONKwVCd
dSihbaYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAj+SInBe1SeICGzPnW5LKYRDm2WuVNNdgpulf0eZ1vV8OeP2rmO3Dd0xKbl06GBwf
HlERakqrBqunBv7Y1PXdEXR8bhGoPQbJxGTNyBMPfHODwzI6vUHQ+cOQFDllc5iH8tSOCZ4Q
5dwC+LMGLA1wOQGs6Z3KXFhMU7MCPjm8pYJSKAYWNo7oeR+7KaC0tko0cRlodwOUgNkS2jp9
37ydbcH3zYvESrKL3y6ZYl+WYB27BVp4owfoBdvXqXd1L2nA7GSXleEplnuu+UK/6elufoQN
cT+DQizCJivU2oO8/a2NrvwPJJSBP7rQVCziL9Vlr6SonxjZ+Wo3+CKSZI9SGgAAAAAAAA==
--------------ms020106020002000702070708--
X-Envelope-From: lennox@cs.columbia.edu
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TLHkM5002472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:17:47 -0700
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9TLHfRX013618; Fri, 29 Oct 2004 17:17:42 -0400 (EDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9TLHfi7034421; Fri, 29 Oct 2004 17:17:41 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu)
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.12.10/8.12.10/Submit) id i9TLHfkh034418; Fri, 29 Oct 2004 17:17:41 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16770.45941.236732.925001@cnr.cs.columbia.edu>
Date: Fri, 29 Oct 2004 17:17:41 -0400
To: Mark Swanson <mark@ScheduleWorld.com>
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
In-Reply-To: <200410291525.21395.mark@ScheduleWorld.com>
References: <200410281850.17020.mark@ScheduleWorld.com> <41828DB6.1020705@skyhouseconsulting.com> <200410291525.21395.mark@ScheduleWorld.com>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.10.29.3
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Scanned-By: MIMEDefang 2.45
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:17:50 -0000
On Friday, October 29 2004, "Mark Swanson" wrote to "ietf-calsify@osafoundation.org" saying:
> On October 29, 2004 2:36 pm, Jeffrey Harris wrote:
> > Hi Folks,
> >
> > I'm sorry, I'm just not following how an RRULE like "1PM every Monday"
> > will work in UTC, when the user is in a timezone whose UTC offset
> > changes with DST. Seems like this will fail about this time of year
> > regardless of whether I'm interacting with people in different
> > timezones. Am I missing something?
>
> Well, I have this exact model working in production and someone in EST can
> schedule RRULEs with someone in PST just fine - even crossing EDT/EST
> boundaries. The caveat is that you can't cross the midnight boundary as
> previously described. Perhaps you could post the steps you took to test this?
That only works because ET and PT have the same DST transition rule. You
can't correctly share RRULEs with people in Europe, or Australia, say. (You
probably even run into trouble with people in Arizona.)
--
Jonathan Lennox
lennox@cs.columbia.edu
X-Envelope-From: daboo@isamet.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TL2VM5001600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:02:32 -0700
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 i9TJvU6E022902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Oct 2004 15:57:32 -0400
Date: Fri, 29 Oct 2004 17:02:28 -0400
From: Cyrus Daboo <daboo@isamet.com>
To: Mark Swanson <mark@scheduleworld.com>, ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Message-ID: <FFB06CCC9FBB8004D18597DA@ninevah.cyrusoft.com>
In-Reply-To: <200410291525.21395.mark@ScheduleWorld.com>
References: <200410281850.17020.mark@ScheduleWorld.com> <41828DB6.1020705@skyhouseconsulting.com> <200410291525.21395.mark@ScheduleWorld.com>
X-Mailer: Mulberry/4.0.0a1 (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-Scanned-By: MIMEDefang 2.45
Cc:
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:02:34 -0000
Hi Mark,
--On Friday, October 29, 2004 3:25:21 PM EDT -0400 Mark Swanson
<mark@scheduleworld.com> wrote:
>> I'm sorry, I'm just not following how an RRULE like "1PM every Monday"
>> will work in UTC, when the user is in a timezone whose UTC offset
>> changes with DST. Seems like this will fail about this time of year
>> regardless of whether I'm interacting with people in different
>> timezones. Am I missing something?
>
> Well, I have this exact model working in production and someone in EST
> can schedule RRULEs with someone in PST just fine - even crossing
> EDT/EST boundaries. The caveat is that you can't cross the midnight
> boundary as previously described. Perhaps you could post the steps you
> took to test this?
Perhaps you can post the VEVENT objects for that so we can see how it works
with UTC only. Personally I do not see how it can, but I'm prepared to be
persuaded otherwise...
--
Cyrus Daboo
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TJPJM4028179 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 12:25:19 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 940 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:25:18 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 15:25:21 -0400
User-Agent: KMail/1.6.2
References: <200410281850.17020.mark@ScheduleWorld.com> <41828DB6.1020705@skyhouseconsulting.com>
In-Reply-To: <41828DB6.1020705@skyhouseconsulting.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200410291525.21395.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 19:25:20 -0000
On October 29, 2004 2:36 pm, Jeffrey Harris wrote:
> Hi Folks,
>
> I'm sorry, I'm just not following how an RRULE like "1PM every Monday"
> will work in UTC, when the user is in a timezone whose UTC offset
> changes with DST. Seems like this will fail about this time of year
> regardless of whether I'm interacting with people in different
> timezones. Am I missing something?
Well, I have this exact model working in production and someone in EST can
schedule RRULEs with someone in PST just fine - even crossing EDT/EST
boundaries. The caveat is that you can't cross the midnight boundary as
previously described. Perhaps you could post the steps you took to test this?
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TJEpM4027540 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 12:14:52 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 274 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 14:14:51 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 15:14:53 -0400
User-Agent: KMail/1.6.2
References: <200410281850.17020.mark@ScheduleWorld.com> <200410290917.17190.mark@ScheduleWorld.com> <4182872E.8030707@Royer.com>
In-Reply-To: <4182872E.8030707@Royer.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200410291514.53392.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 19:14:53 -0000
On October 29, 2004 2:08 pm, Doug Royer wrote:
> Mark Swanson wrote:
> >Actually, the more I think about it I think having a basic/lite version of
> >iCalendar will fail unless the lite features are at lest the same as the
> > list of features supported by Outlook. Really, if you can't interoperate
> > with Outlook then I see no point.
> >
> >Cheers.
>
> Outlook can handle this subset of 2445. In fact this is how in many
> cases they
> store the appointments already.
I know Outlook can handle this subset of 2445... Perhaps I wasn't clear
enough. I'll try again:
I see no point in having a lite/basic version of iCalendar unless the
lite/basic version includes the most common and useful parts of 2445 as
implemented by Outlook. Timezones, RRULEs (including dealing with specific
rrule instances), and others fall in this category.
Cheers.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: jeffrey@skyhouseconsulting.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from mail.skyhouseconsulting.com (skyhouseconsulting.com [69.55.227.180]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TIadM5025446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 11:36:39 -0700
Received: from [192.168.1.99] (unknown [216.146.255.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.skyhouseconsulting.com (Postfix) with ESMTP id 00BD94681F0 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 13:37:28 -0500 (CDT)
Message-ID: <41828DB6.1020705@skyhouseconsulting.com>
Date: Fri, 29 Oct 2004 13:36:38 -0500
From: Jeffrey Harris <jeffrey@skyhouseconsulting.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
References: <200410281850.17020.mark@ScheduleWorld.com>
In-Reply-To: <200410281850.17020.mark@ScheduleWorld.com>
X-Enigmail-Version: 0.84.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 18:36:40 -0000
Hi Folks,
I'm sorry, I'm just not following how an RRULE like "1PM every Monday"
will work in UTC, when the user is in a timezone whose UTC offset
changes with DST. Seems like this will fail about this time of year
regardless of whether I'm interacting with people in different
timezones. Am I missing something?
Sincerely,
Jeffrey
> Here's a thought:
>
> The simple/basic version of ICalendar would not use timezones and everything
> is in UTC. Applications that implement the simple version would have a big
> warning sticker that described the limitation of two people/recur/cross
> midnight problem.
>
> The full version would use timezones and handle rrules properly. A small
> office that had everyone in the same building could use the 'lite' version
> and larger/distributed organizations (and/or people) could use software that
> implements the full (perhaps more expensive) version.
>
> I know there is some resistance to providing a spec that isn't perfect, but I
> think the case above is a real-world compromise.
>
> Thoughts?
X-Envelope-From: Robert_Ransdell@notesdev.ibm.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TIJNM4024417 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 11:19:24 -0700
In-Reply-To: <418286C6.1080906@Royer.com>
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <OF2A67D276.81903112-ON85256F3C.006486A2-85256F3C.00648CF2@notesdev.ibm.com>
From: Robert_Ransdell@notesdev.ibm.com
Date: Fri, 29 Oct 2004 14:18:46 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 10/29/2004 02:16:42 PM
Content-Type: multipart/mixed; boundary="=_mixed 00648CEC85256F3C_="
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 18:19:24 -0000
This is a multi-part message in MIME format...
--=_mixed 00648CEC85256F3C_=
Content-Type: multipart/alternative;
boundary="=_alternative 00648CEC85256F3C_="
--=_alternative 00648CEC85256F3C_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline
Outlook and Notes ... 2 largest (by client count) vendors do timezone and
rules the same
Doug Royer <Doug@royer.com>
Sent by: ietf-calsify-bounces@osafoundation.org
10/29/2004 02:07 PM
Please respond to
ietf-calsify@osafoundation.org
To
ietf-calsify@osafoundation.org
cc
Subject
Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
Robert_Ransdell@notesdev.ibm.com wrote:
>Default has to be current behavior to accomidate existing iCalendar
>generators.
>
>
>
So far no three vendors have the same default behaviour across the
board. That's the point
of making this a starndard.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
--=_alternative 00648CEC85256F3C_=--
--=_mixed 00648CEC85256F3C_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQxMDI5MTgwNzAyWjAjBgkqhkiG9w0BCQQxFgQUWWq4en92
zj2u2mVk6RrXoBM21C8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEAQ/oBncLmsbupdt9R3YjKf8HZxpmF
uhx2/p3bXanyecFvXcIaOPiwpecXj+rUFwHjOavT4u7g3OdKNQeAJyEVkg+M
cuxF8vxXEuCoo3sOGOQhfWWlGD5q3GSdeKmDFp2saBZCPcshnERh8vePb5C0
3JNKlEFdy2pvF5F5TYg4f8PcE3ItuEcDNRYB470kNl3w+2jYyrnShPqvR9rw
4OpOEaIkAavwucpsvQ9t0ZPu1Zi0olTOBLf/PhEJ55RRmPl72zC7ULohTW5z
70vtr3NX7CKTVst+9Vaga+XvKOITrTSNjoPtyphqIQLD9/ftjTIbyIdU5k7l
pux94jX6EQucZQAAAAAAAA==
--=_mixed 00648CEC85256F3C_=--
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TI8qM5023506 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 11:08:53 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9TI8kvt023700 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 11:08:48 -0700
Message-ID: <4182872E.8030707@Royer.com>
Date: Fri, 29 Oct 2004 12:08:46 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
References: <200410281850.17020.mark@ScheduleWorld.com> <4181C217.9080109@Royer.com> <200410290917.17190.mark@ScheduleWorld.com>
In-Reply-To: <200410290917.17190.mark@ScheduleWorld.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030406060206030706040602"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 18:08:54 -0000
This is a cryptographically signed message in MIME format.
--------------ms030406060206030706040602
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Mark Swanson wrote:
>Actually, the more I think about it I think having a basic/lite version of
>iCalendar will fail unless the lite features are at lest the same as the list
>of features supported by Outlook. Really, if you can't interoperate with
>Outlook then I see no point.
>
>Cheers.
>
>
Outlook can handle this subset of 2445. In fact this is how in many
cases they
store the appointments already.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms030406060206030706040602
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
9w0BCQUxDxcNMDQxMDI5MTgwODQ2WjAjBgkqhkiG9w0BCQQxFgQUO1k3xz/QcI5+ZZF5/3fj
GoZ3S38wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAOrytyuqizGmj1MOuLl/xDC32jvnB4dkRtxzNtPlgjs1gx1/YPaidSY6Et8fHlLt9
7h+1JnJSBjAsxMds3sib+V5bnQGYgIHCaK0FPYMq/0io7BEdHxbFhxUAqJfxdfAigh96UDn/
IskX4e1x7dN4SQri7GbwPai/JCx08iT0vj7ChD4nBL18fAKNK3zjff3+VZBTP7uImGBC0Rvo
iiGrj7Nfuo+pNbEL7eEEu+Lg7OU/CiI592dkYzITKLm5E6iyLm66C/6DV7faB7lmSi+hv/ES
2Sy225Oup+FO67bsD3NE+hSR6bDh4YZrINUb7iuMgCMmyN2aLpKgIOTJ6i+TRgAAAAAAAA==
--------------ms030406060206030706040602--
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9TI7CM5023367 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 11:07:13 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9TI72vt023678 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 11:07:05 -0700
Message-ID: <418286C6.1080906@Royer.com>
Date: Fri, 29 Oct 2004 12:07:02 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
References: <OFA70CD540.10EB521E-ON85256F3C.005F1C0D-85256F3C.005F3213@notesdev.ibm.com>
In-Reply-To: <OFA70CD540.10EB521E-ON85256F3C.005F1C0D-85256F3C.005F3213@notesdev.ibm.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020108000403080206010306"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 18:07:17 -0000
This is a cryptographically signed message in MIME format.
--------------ms020108000403080206010306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Robert_Ransdell@notesdev.ibm.com wrote:
>Default has to be current behavior to accomidate existing iCalendar
>generators.
>
>
>
So far no three vendors have the same default behaviour across the
board. That's the point
of making this a starndard.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms020108000403080206010306
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
9w0BCQUxDxcNMDQxMDI5MTgwNzAyWjAjBgkqhkiG9w0BCQQxFgQUWWq4en92zj2u2mVk6RrX
oBM21C8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAQ/oBncLmsbupdt9R3YjKf8HZxpmFuhx2/p3bXanyecFvXcIaOPiwpecXj+rUFwHj
OavT4u7g3OdKNQeAJyEVkg+McuxF8vxXEuCoo3sOGOQhfWWlGD5q3GSdeKmDFp2saBZCPcsh
nERh8vePb5C03JNKlEFdy2pvF5F5TYg4f8PcE3ItuEcDNRYB470kNl3w+2jYyrnShPqvR9rw
4OpOEaIkAavwucpsvQ9t0ZPu1Zi0olTOBLf/PhEJ55RRmPl72zC7ULohTW5z70vtr3NX7CKT
Vst+9Vaga+XvKOITrTSNjoPtyphqIQLD9/ftjTIbyIdU5k7lpux94jX6EQucZQAAAAAAAA==
--------------ms020108000403080206010306--
X-Envelope-From: Robert_Ransdell@notesdev.ibm.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9THKTqK016282 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 10:20:29 -0700
In-Reply-To: <4181C499.80307@Royer.com>
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <OFA70CD540.10EB521E-ON85256F3C.005F1C0D-85256F3C.005F3213@notesdev.ibm.com>
From: Robert_Ransdell@notesdev.ibm.com
Date: Fri, 29 Oct 2004 13:20:16 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 10/29/2004 01:17:48 PM
Content-Type: multipart/mixed; boundary="=_mixed 005F320785256F3C_="
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 17:20:32 -0000
This is a multi-part message in MIME format...
--=_mixed 005F320785256F3C_=
Content-Type: multipart/alternative;
boundary="=_alternative 005F320985256F3C_="
--=_alternative 005F320985256F3C_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline
Default has to be current behavior to accomidate existing iCalendar
generators.
Doug Royer <Doug@royer.com>
Sent by: ietf-calsify-bounces@osafoundation.org
10/29/2004 12:18 AM
Please respond to
ietf-calsify@osafoundation.org
To
ietf-calsify@osafoundation.org
cc
Subject
Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
TimHare@comcast.net wrote:
>
>> Both Doug and Mark's recent proposals have some merit. I see,
>> however, a need to identify iCal Basic, iCal SomethingElse, iCal
>> Complex, in a slightly different way than EXTENSIONS. Since iCal
>> Basic, or Level 0, or whatever we're calling it, will have LESS
>> capabilities than the current RFC 2445/2446, I think it might be
>> better to identify that level by something other than the lack of
>> extension properties. I think we either need a LEVEL property, or a
>> LEVEL parameter on the VERSION property, that identifies what level
>> we are dealing with, with the default being the lowest possible level
>> for that version. There's still room for EXTENSIONS with its RFC
>> identification scheme, under this proposal, I just want to see clear
>> identification, early in the data stream, of what we're dealing with.
>
The problem with a LEVEL property or parameter is that it is liner set of
inclusive revisions. For example LEVEL '3' implies '0', '1', and '2'
support. And
there would be no way to say that '2' is optional. Everyone would have
to support every included option lower than the number value provided.
Where the EXTENSION property is a random set of possibly non-inclusive
extensions.
Example EXTENSION '3' can mean you only support options '0' and '3'. And
that
you do not support '1' and '2' options.
>
> I would also suggest that the spec require that EXTENSIONS if coded
> immediately follow VERSION and that VERSION immediately follow
> VCALENDAR, to aid clients that are perhaps handling the data stream in
> a sequential fashion, but that's not a requirement that I'd have to
have.
I think we could make this a SHOULD and then that makes 2445 objects
complient.
>
>
> If you defined what the levels meant, you might eliminate the need for
> the IS-SUB-SET parameter. Define LEVEL=BASIC to be UTC-only and no
> RRULES, then follow Doug's suggestion and send only LEVEL=BASIC when
> you don't know the capabilities at the other end.
>
IS-SUB-SET means the sender has more instances they did not send.
Where LEVEL=BASIC only implies they might have more unsent instances
(or not).
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
--=_alternative 005F320985256F3C_=--
--=_mixed 005F320785256F3C_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
AQAAoIINcDCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZI
hvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4
MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rI
SsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+
MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG
+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY
UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5Jz
dC6JOzUTcudAMZrTssSr51a+i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBB
MPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQwHhcNMDQwOTAzMDAwMDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91
ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMWHYQKNX06SDOZPZvQOVD5lgC
2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4IaamL0bbVrINBtK
mW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo
0Y6uq+kkkPqYd+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQz
FWwe1UaHKYPb8d8xO6qGJNisRNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IH
nwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJBgNVHRMEAjAAMIGsBgNVHSAE
gaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM26zHybGdD0C7c
Q+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J3
8rgwggUBMIIEaqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEB
BAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAw
MFoXDTA1MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B
CQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAzFh2ECjV9OkgzmT2b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUE
k1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSpluabeSeXZhFTAZSp7mqR8kZM55
LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ+SIZOInZLPfU
iloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETS
N4vU/WT1Pv+IAvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IB
HDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT
aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcE
BhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp
4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPrGpYuUwn62iMbUSaGXYFlg0Am
2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOSzi6mbsF7ZSIc
2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wCQYF
Kw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDQxMDI5MDQxODM0WjAjBgkqhkiG9w0BCQQxFgQUclU9Ss+K
gOhZ4nigBkRp425o4ekwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90
IFZhbGlkYXRlZAIQV2Y2bnhVsEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsx
geSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg
U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wDQYJKoZIhvcNAQEBBQAEggEApUbxgdJu2pBwAI/k1+M2Pk01lzJS
e4W9B8rKxmWoteabaeGjwAzx2EZjAGm/Gc9wI7DO9kY4AQvrwVKEkNlyMwop
+354k3k319Igfe+kzos5VCJYp8P53miryRDPpOy33iX5v4S8QgvtAkHXW2l0
q9XCPLDiqbK3PKdJx3O6IewYJosE+Qtim2cmMpsQhfMUOlcjGiqlDcgpBNU2
oofaEt/kYttaXaE3LjG7p2sGeMg8IcjIeaSwVpyLwxAW8AUL0NT6CDBMGo40
XArh1bseSxSWuimleZ7G7dz9qcMRi/aTNWDq6YNMUo1xz1sierlXRP/d9fPc
cwvRzDAWyTmWewAAAAAAAA==
--=_mixed 005F320785256F3C_=--
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9TDHHqK005409 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 06:17:18 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 501 for <ietf-calsify@osafoundation.org>; Fri, 29 Oct 2004 08:17:16 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 09:17:17 -0400
User-Agent: KMail/1.6.2
References: <200410281850.17020.mark@ScheduleWorld.com> <4181C217.9080109@Royer.com>
In-Reply-To: <4181C217.9080109@Royer.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200410290917.17190.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 13:17:20 -0000
On October 29, 2004 12:07 am, Doug Royer wrote:
> Mark Swanson wrote:
> >Here's a thought:
> >
> >The simple/basic version of ICalendar would not use timezones and
> > everything is in UTC. Applications that implement the simple version
> > would have a big warning sticker that described the limitation of two
> > people/recur/cross midnight problem.
> >
> >The full version would use timezones and handle rrules properly. A small
> >office that had everyone in the same building could use the 'lite' version
> >and larger/distributed organizations (and/or people) could use software
> > that implements the full (perhaps more expensive) version.
>
> The problem is not the size of your office. The problem can be the location
> of your customers and vendors.
I covered that case (distributed organizations and/or people).
> If we disallow recurrence rules in 'basic' then the time zone boundry
> problem
> goes away as each instance of the same entry has a RECURRENCE-ID
> that can be specified in UTC, even when the DTSTART propertyt is not.
Actually, the more I think about it I think having a basic/lite version of
iCalendar will fail unless the lite features are at lest the same as the list
of features supported by Outlook. Really, if you can't interoperate with
Outlook then I see no point.
Cheers.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9T4IlqL020285 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 28 Oct 2004 21:18:52 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9T4IYvt010668 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Thu, 28 Oct 2004 21:18:37 -0700
Message-ID: <4181C499.80307@Royer.com>
Date: Thu, 28 Oct 2004 22:18:33 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
References: <200410281850.17020.mark@ScheduleWorld.com> <6.1.1.1.0.20041028232857.02f16e60@mail.comcast.net>
In-Reply-To: <6.1.1.1.0.20041028232857.02f16e60@mail.comcast.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080404060008060600010501"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 04:18:55 -0000
This is a cryptographically signed message in MIME format.
--------------ms080404060008060600010501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
TimHare@comcast.net wrote:
>
>> Both Doug and Mark's recent proposals have some merit. I see,
>> however, a need to identify iCal Basic, iCal SomethingElse, iCal
>> Complex, in a slightly different way than EXTENSIONS. Since iCal
>> Basic, or Level 0, or whatever we're calling it, will have LESS
>> capabilities than the current RFC 2445/2446, I think it might be
>> better to identify that level by something other than the lack of
>> extension properties. I think we either need a LEVEL property, or a
>> LEVEL parameter on the VERSION property, that identifies what level
>> we are dealing with, with the default being the lowest possible level
>> for that version. There's still room for EXTENSIONS with its RFC
>> identification scheme, under this proposal, I just want to see clear
>> identification, early in the data stream, of what we're dealing with.
>
The problem with a LEVEL property or parameter is that it is liner set of
inclusive revisions. For example LEVEL '3' implies '0', '1', and '2'
support. And
there would be no way to say that '2' is optional. Everyone would have
to support every included option lower than the number value provided.
Where the EXTENSION property is a random set of possibly non-inclusive
extensions.
Example EXTENSION '3' can mean you only support options '0' and '3'. And
that
you do not support '1' and '2' options.
>
> I would also suggest that the spec require that EXTENSIONS if coded
> immediately follow VERSION and that VERSION immediately follow
> VCALENDAR, to aid clients that are perhaps handling the data stream in
> a sequential fashion, but that's not a requirement that I'd have to have.
I think we could make this a SHOULD and then that makes 2445 objects
complient.
>
>
> If you defined what the levels meant, you might eliminate the need for
> the IS-SUB-SET parameter. Define LEVEL=BASIC to be UTC-only and no
> RRULES, then follow Doug's suggestion and send only LEVEL=BASIC when
> you don't know the capabilities at the other end.
>
IS-SUB-SET means the sender has more instances they did not send.
Where LEVEL=BASIC only implies they might have more unsent instances
(or not).
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms080404060008060600010501
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
9w0BCQUxDxcNMDQxMDI5MDQxODM0WjAjBgkqhkiG9w0BCQQxFgQUclU9Ss+KgOhZ4nigBkRp
425o4ekwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEApUbxgdJu2pBwAI/k1+M2Pk01lzJSe4W9B8rKxmWoteabaeGjwAzx2EZjAGm/Gc9w
I7DO9kY4AQvrwVKEkNlyMwop+354k3k319Igfe+kzos5VCJYp8P53miryRDPpOy33iX5v4S8
QgvtAkHXW2l0q9XCPLDiqbK3PKdJx3O6IewYJosE+Qtim2cmMpsQhfMUOlcjGiqlDcgpBNU2
oofaEt/kYttaXaE3LjG7p2sGeMg8IcjIeaSwVpyLwxAW8AUL0NT6CDBMGo40XArh1bseSxSW
uimleZ7G7dz9qcMRi/aTNWDq6YNMUo1xz1sierlXRP/d9fPccwvRzDAWyTmWewAAAAAAAA==
--------------ms080404060008060600010501--
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9T47uqL019927 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 28 Oct 2004 21:07:57 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9T47pvt010559 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Thu, 28 Oct 2004 21:07:53 -0700
Message-ID: <4181C217.9080109@Royer.com>
Date: Thu, 28 Oct 2004 22:07:51 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
References: <200410281850.17020.mark@ScheduleWorld.com>
In-Reply-To: <200410281850.17020.mark@ScheduleWorld.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060007040702050106020203"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 04:07:59 -0000
This is a cryptographically signed message in MIME format.
--------------ms060007040702050106020203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mark Swanson wrote:
>Here's a thought:
>
>The simple/basic version of ICalendar would not use timezones and everything
>is in UTC. Applications that implement the simple version would have a big
>warning sticker that described the limitation of two people/recur/cross
>midnight problem.
>
>The full version would use timezones and handle rrules properly. A small
>office that had everyone in the same building could use the 'lite' version
>and larger/distributed organizations (and/or people) could use software that
>implements the full (perhaps more expensive) version.
>
>
The problem is not the size of your office. The problem can be the location
of your customers and vendors.
If we disallow recurrence rules in 'basic' then the time zone boundry
problem
goes away as each instance of the same entry has a RECURRENCE-ID
that can be specified in UTC, even when the DTSTART propertyt is not.
So, along with the proposal I send earlier today, we could add that
in 'Basic' the time zone for single instance objects be in UTC.
And that the RECURRENCE-ID value for expanded instances be in UTC
even when the DTSTART property is not.
This would allow implementations that know TZ processing to continue
to work with 'Basic' and 2445 objects.
>I know there is some resistance to providing a spec that isn't perfect, but I
>think the case above is a real-world compromise.
>
>Thoughts?
>
>
>
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms060007040702050106020203
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
9w0BCQUxDxcNMDQxMDI5MDQwNzUxWjAjBgkqhkiG9w0BCQQxFgQUxTWiw4jic4463J8/CQw+
MQd/nxswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAJQWtQJBgtlWvreuUZshxsKPJXy6yDvV4kGmXLpeEmkYg7amb6AVPFhTJ9z21iLjx
w8aifEcA9ZxYpsbjFHv92tY1Tr675UtI87xFVo3yGVMDxM+X9SOAVUsVl7g6dCUQ7x7kMM3G
avLHWvF2kdyR5kEuZSsz8s9v7nKP3FsosIPZAW42hvpvIXZYk+j9YEFvYTsDOtOnnHHR/VAB
pOfmn6j6XCuC0JW6ctso0SM4mIhuVpALqJ+tOWqwreQprBQOz91VKS3BQKvDZ7Y88A75+y21
zIjU5PtT+hb5b2QeRXFHzuJlyCwh382pHRHOA20v73X2hV8HdCRAYJH0y/58VgAAAAAAAA==
--------------ms060007040702050106020203--
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9T3uEqK019551 for <ietf-calsify@osafoundation.org>; Thu, 28 Oct 2004 20:56:14 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc12) with SMTP id <20041029035608012009l6hue> (Authid: TimHare); Fri, 29 Oct 2004 03:56:08 +0000
Message-Id: <6.1.1.1.0.20041028232857.02f16e60@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 28 Oct 2004 23:48:02 -0400
To: ietf-calsify@osafoundation.org
From: TimHare@comcast.net
In-Reply-To: <200410281850.17020.mark@ScheduleWorld.com>
References: <200410281850.17020.mark@ScheduleWorld.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.42 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, NO_REAL_NAME
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 03:56:15 -0000
>Both Doug and Mark's recent proposals have some merit. I see, however, a
>need to identify iCal Basic, iCal SomethingElse, iCal Complex, in a
>slightly different way than EXTENSIONS. Since iCal Basic, or Level 0, or
>whatever we're calling it, will have LESS capabilities than the current
>RFC 2445/2446, I think it might be better to identify that level by
>something other than the lack of extension properties. I think we either
>need a LEVEL property, or a LEVEL parameter on the VERSION property, that
>identifies what level we are dealing with, with the default being the
>lowest possible level for that version. There's still room for EXTENSIONS
>with its RFC identification scheme, under this proposal, I just want to
>see clear identification, early in the data stream, of what we're dealing with.
Examples:
VERSION; LEVEL=BASIC: 3.0 Identifies compliance with only the
most basic iCal RFCs (Mark's "lite" version) after
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 would also suggest that the spec require that EXTENSIONS if coded
immediately follow VERSION and that VERSION immediately follow VCALENDAR,
to aid clients that are perhaps handling the data stream in a sequential
fashion, but that's not a requirement that I'd have to have.
If you defined what the levels meant, you might eliminate the need for the
IS-SUB-SET parameter. Define LEVEL=BASIC to be UTC-only and no RRULES, then
follow Doug's suggestion and send only LEVEL=BASIC when you don't know the
capabilities at the other end.
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9SMoFqK016683 for <ietf-calsify@osafoundation.org>; Thu, 28 Oct 2004 15:50:17 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 522 for <ietf-calsify@osafoundation.org>; Thu, 28 Oct 2004 17:50:14 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Date: Thu, 28 Oct 2004 18:50:16 -0400
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200410281850.17020.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] timezone/rrule standard/basic proposal
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2004 22:50:20 -0000
Here's a thought:
The simple/basic version of ICalendar would not use timezones and everything
is in UTC. Applications that implement the simple version would have a big
warning sticker that described the limitation of two people/recur/cross
midnight problem.
The full version would use timezones and handle rrules properly. A small
office that had everyone in the same building could use the 'lite' version
and larger/distributed organizations (and/or people) could use software that
implements the full (perhaps more expensive) version.
I know there is some resistance to providing a spec that isn't perfect, but I
think the case above is a real-world compromise.
Thoughts?
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9SHq9qL016764 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 28 Oct 2004 10:52:11 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9SHq4vt001079 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Thu, 28 Oct 2004 10:52:06 -0700
Message-ID: <418131C4.9080200@Royer.com>
Date: Thu, 28 Oct 2004 11:52:04 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
References: <0649D32A5A62294BBF93B77A6EC985AD158970@trebe051.ntc.nokia.com>
In-Reply-To: <0649D32A5A62294BBF93B77A6EC985AD158970@trebe051.ntc.nokia.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070804020008070101040507"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] iCal Basic and RRULE proposal.
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2004 17:52:15 -0000
This is a cryptographically signed message in MIME format.
--------------ms070804020008070101040507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
The difficult part is to ensure that we can distinguish old and new objects
and interoperate as much as possible. I think this will work with the vast
majority of products. The goal is interoperability between vendors.
After re-reading many of these posts and the larger number in calsch I
would like
to make this proposal. One new property and one new parameter. These
will uniquely identify the supported formats of the senders. Includes
are some scenarios.
1) We standardize on never sending any recurrence rule to a
user/UPN/calendar
until the sending side has confirmation that the recipient can
handle recurrence rules.
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.
3) We add a new parameter to the DTSTART property that indicates that
this is part of a recurring set, even when no recurrence rule is
provided.
The name of this parameter is 'IS-SUB-SET' and is a boolean. And that
it is a mandatory parameter for all iCal-Basic objects.
Scenarios:
When the sender sends an object without the EXTENSION property and
one of the following:
a) No 'IS-SUB-SET' parameter in the DTSTART, then the recipient knows
this is an RFC-2445 object. And the recipient knows that the sender
is unaware
of the newer iCal specifications.
b) Has a DTSTART with the IS-SUB-SET (true or false) then the recipient
knows that the sender does not support recurrence rules, and
that the sender supports iCal-Basic.
c) Has a DTSTART with the IS-SUB-SET parameter set to TRUE, then
the recipient knows that the sender does not support recurrence rules,
and that the recipient only has a sub-set of the object times. And that
the recipient may at a later time wish to do a REFRESH to get the
latest version (new SEQUENCE) of the UID. Which may contain
new objects with new DTSTART values.
d) Has a DTSTART with the IS-SUB-SET property set to FALSE.
Then the recipient knows that the sender does not support recurrence
rules and that the objects instances are complete as of the time they
were sent.
If the sender sends out an object with an EXTENSIONS property
that contains the RFC number of the new-recurrence-rfc, then
the recipient knows that the sender supports recurrence rules.
Then:
e) If the sender is unaware if the recipient understands recurrence
rules.
then the sender must expand the recurring instances, add the IS-SUBSET
parameter to all objects that have been expanded. And add its unique
RECURRENCE-ID to those objects.
f) If the sender is aware that the recipient does NOT understand
recurrence rules, then send the object exactly as in (e).
g) If the sender is aware that the recipient CAN handle recurrence
rules, then the sender can still send the object as in (e), or send
the the object with IS-SUB-SET false and include any recurrence
rules as specified in the RFC described in the EXTENSIONS property
values.
When replying back the replying application would never send
back the original EXTENSION property value. It only sends
its known extensions - if any. As the replying application would have
already received the initial object from the sender. The replying
application would
be aware if the sender was RFC-2445, iCal-Basic, and EXTENSIONS aware.
The replying application would not add IS-SUB-SET as it would not know.
For a COUNTER object.
The sending application would add any EXTENSIONS property
and values, and the IS-SUB-SET parameters to any new
DTSTART properties that were part of the COUNTER.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-4638
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms070804020008070101040507
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
9w0BCQUxDxcNMDQxMDI4MTc1MjA0WjAjBgkqhkiG9w0BCQQxFgQUDUk8WCBAB7PZES/ab+Tr
wf5MDD8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAlHhMpWsMzNq+GFvm+kAynXwplMIuGgUQujtBEKFSryXksVstRcWLtn7XVo9u9j49
O6gxMIp8rca/CX5Ekmr5cf7aXWpppxwiF7M3/yG8phwAUC5T92x/Nb7OqBoNcAnEwJ6TBO9x
8bB8iPZI710//IS8i/8WaNzb7a7TkfZG2hXqSqDTngSyYHlq+wUF8uFzHBpv9AFr2xDxOksW
iLvvHSDl/rk9s7CQ9GXHcJarfRvcw0A/LtIaLHkk08ObISOMi5WyZ0a0hBFiAzadWBj+RG8R
+iOPC3pXC0J88I75T1Bu+kv1+lZ6ofUMn/Py9J3JuEs9hpU1EZcBapoWOd9P/QAAAAAAAA==
--------------ms070804020008070101040507--
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9S00SqK001358 for <ietf-calsify@osafoundation.org>; Wed, 27 Oct 2004 17:00:33 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc12) with SMTP id <2004102800001801200r8edpe> (Authid: TimHare); Thu, 28 Oct 2004 00:00:18 +0000
Message-Id: <6.1.1.1.0.20041027195135.02868dd0@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 27 Oct 2004 19:52:34 -0400
To: ietf-calsify@osafoundation.org
From: TimHare@comcast.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.42 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, NO_REAL_NAME
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] re: Roundtable
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2004 00:00:36 -0000
Dave Thewlis of calconnect.org wrote to me on the subject and gave me
permission to share what he wrote:
"Tim,
What's available right now is largely on the calconnect website - take a
look at the home page www.calconnect.org (which has "current" information)
and the publicity release after the roundtable. Also look at the
"committees" page for a list of the technical committees agreed by the
roundtable, their purposes (VERY brief) and time schedules. I have not
produced a "formal" meeting report (nobody has asked for one, although I
certainly could) -- it would largely say the same things as are in the
publicity statement and the committees.
There are some internal notes but they haven't been reviewed and made
comprehensible unless one was at the roundtable.
"
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9Q2QLqK006716 for <ietf-calsify@osafoundation.org>; Mon, 25 Oct 2004 19:26:29 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc12) with SMTP id <2004102602261301200g72v3e> (Authid: TimHare); Tue, 26 Oct 2004 02:26:13 +0000
Message-Id: <6.1.1.1.0.20041025221649.02864b80@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Mon, 25 Oct 2004 22:18:19 -0400
To: ietf-calsify@osafoundation.org
From: TimHare@comcast.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.42 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, NO_REAL_NAME
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] report from the roundtable?
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Oct 2004 02:26:32 -0000
I just learned of a September roundtable about the future of calendaring
sponsored by calconnect.org. Does anyone know of a transcription of the
meeting (minutes, meeting report, or anything)?
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: Veikko.Punkka@nokia.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9E7gcaA023265 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 14 Oct 2004 00:42:41 -0700
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9E7gZw10546; Thu, 14 Oct 2004 10:42:35 +0300 (EET DST)
X-Scanned: Thu, 14 Oct 2004 10:42:18 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9E7gIR6006712; Thu, 14 Oct 2004 10:42:18 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 006uYb0H; Thu, 14 Oct 2004 10:42:15 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9E7gFS22787; Thu, 14 Oct 2004 10:42:15 +0300 (EET DST)
Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 14 Oct 2004 10:41:44 +0300
Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 14 Oct 2004 10:41:44 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Ietf-calsify] RRULEs, TimeZones
Date: Thu, 14 Oct 2004 10:41:42 +0300
Message-ID: <0649D32A5A62294BBF93B77A6EC985AD158970@trebe051.ntc.nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ietf-calsify] RRULEs, TimeZones
Thread-Index: AcSxqFxTclGAX6znTmCBO6x0vhmM/wAE+CJA
From: <Veikko.Punkka@nokia.com>
To: <TimHare@comcast.net>, <ietf-calsify@osafoundation.org>
X-OriginalArrivalTime: 14 Oct 2004 07:41:44.0590 (UTC) FILETIME=[40B932E0:01C4B1C1]
X-Scanned-By: MIMEDefang 2.45
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i9E7gcaA023265
Cc:
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2004 07:42:43 -0000
We could try another alternative approach. We could try to find the RRULE features that
do not have interoperability issues, and have those in the base spec.
My hunch is that all we are going to get is daily repeats, possibly repeats every n days.
Coincidentially, I think these are the only ones that can be expressed without a reference
to a local time zone, using the current spec.
Untimed repeating events (ones that do only specify a date, not time) would also be possible to
represent without a reference to a local time zone. For example I hold my anniversaries on
a specific date, even though it means a different period of time in every time zone.
Unfortunately, the current spec does not provide a very good way to represent these.
At least partly because of this they also have interoperability problems.
Timed repeating events that have the same fixed time in every time zone (say 6:30 in the
morning, regardless of the time zone) would also be possible to represent without
a reference to a local time zone. Unfortunately, the current spec does not provide a very
good way to represent these. At least partly because of this they also have interoperability
problems.
Veikko Punkka
> -----Original Message-----
> From: ietf-calsify-bounces@osafoundation.org
> [mailto:ietf-calsify-bounces@osafoundation.org]On Behalf Of ext
> TimHare@comcast.net
> Sent: 14 October, 2004 07:34
> To: ietf-calsify@osafoundation.org
> Subject: Re: [Ietf-calsify] RRULEs, TimeZones
>
>
> There's a good point here, we can't afford to work on this forever...
>
> Has anyone from previous Interops or other sources got a
> listing of RRULE
> issues that exist between implementations? If we can list all
> of the places
> where RRULE interoperabiltiy is broken, will vendors /
> implementors commit
> on this list to work out the differences and solve the
> problems? If they
> will, and not get into finger-pointing sessions, then RRULEs
> should be in a
> base spec. If not, then RRULEs need to be in an extension spec and
> implementations that don't support RRULEs or don't support them in an
> interoperable way will have to calculate the individual
> VEVENTs (obviously
> within a finite timeframe) and exchange those.
>
> As for timezones: it's the political timezone system that is
> broken on
> this issue, not necessarily our RFCs. If we have to have
> them (for the use
> cases others have cited?), then can we simplify how we
> exchange them? How
> about the spec referencing some repository for political timezone
> definitions, and the spec only referencing TZs by a standard
> name? There
> are standards for names of political entities (like states in
> the US which
> have two-letter postal codes, and also federal state ID
> numbers), standards
> for names of languages (EN, FR, etc.), so why couldn't one of these
> standards bodies "hold" the timezones also?
>
>
> At 09:49 PM 10/13/04, Mark Swanson wrote:
>
> >I'm a little surprised to hear this. Based on the seemingly infinite
> >amount of
> >time wasted waffling over 2445 (all good smart folks
> involved) I couldn't
> >fathom trying to make _two_ specifications work.
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
>
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9E4fEa9012045 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 21:41:14 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc12) with SMTP id <20041014044108014004pauge> (Authid: TimHare); Thu, 14 Oct 2004 04:41:08 +0000
Message-Id: <6.1.1.1.0.20041014002410.0286a350@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 14 Oct 2004 00:34:19 -0400
To: ietf-calsify@osafoundation.org
From: TimHare@comcast.net
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
In-Reply-To: <200410132149.14894.mark@ScheduleWorld.com>
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131944.23546.mark@ScheduleWorld.com> <966DD28E-1D74-11D9-88E6-000D93C1A604@opengroupware.org> <200410132149.14894.mark@ScheduleWorld.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.42 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, NO_REAL_NAME
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2004 04:41:16 -0000
There's a good point here, we can't afford to work on this forever...
Has anyone from previous Interops or other sources got a listing of RRULE
issues that exist between implementations? If we can list all of the places
where RRULE interoperabiltiy is broken, will vendors / implementors commit
on this list to work out the differences and solve the problems? If they
will, and not get into finger-pointing sessions, then RRULEs should be in a
base spec. If not, then RRULEs need to be in an extension spec and
implementations that don't support RRULEs or don't support them in an
interoperable way will have to calculate the individual VEVENTs (obviously
within a finite timeframe) and exchange those.
As for timezones: it's the political timezone system that is broken on
this issue, not necessarily our RFCs. If we have to have them (for the use
cases others have cited?), then can we simplify how we exchange them? How
about the spec referencing some repository for political timezone
definitions, and the spec only referencing TZs by a standard name? There
are standards for names of political entities (like states in the US which
have two-letter postal codes, and also federal state ID numbers), standards
for names of languages (EN, FR, etc.), so why couldn't one of these
standards bodies "hold" the timezones also?
At 09:49 PM 10/13/04, Mark Swanson wrote:
>I'm a little surprised to hear this. Based on the seemingly infinite
>amount of
>time wasted waffling over 2445 (all good smart folks involved) I couldn't
>fathom trying to make _two_ specifications work.
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9E1nEa9002575 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 18:49:14 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 875 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 20:49:13 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 21:49:14 -0400
User-Agent: KMail/1.6.2
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131944.23546.mark@ScheduleWorld.com> <966DD28E-1D74-11D9-88E6-000D93C1A604@opengroupware.org>
In-Reply-To: <966DD28E-1D74-11D9-88E6-000D93C1A604@opengroupware.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200410132149.14894.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2004 01:49:16 -0000
On October 13, 2004 8:04 pm, Helge Hess wrote:
> spec, its a huge gain for implementors. If its only in the base spec
> because of another - questionable! - feature, rrule's, its even more
> viable.
10 recurring swimming lessons in a row, x skating lessons in a row, and a
number of other recurring events. Let's not forget birthdays, anniversaries,
10:00 am weekly meetings during a crunch.
Perhaps you meant RRULEs are questionable in their current form?
> > We must not remove timezones.
>
> Me says, remove rrule's and timezones from the base spec, but ensure
> that they are still available in an extension spec from the beginning
> on.
I'm a little surprised to hear this. Based on the seemingly infinite amount of
time wasted waffling over 2445 (all good smart folks involved) I couldn't
fathom trying to make _two_ specifications work.
Cheers.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: helge.hess@opengroupware.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9E04Na9028895 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 17:04:24 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 5540E295F2B for <ietf-calsify@osafoundation.org>; Thu, 14 Oct 2004 02:03:32 +0200 (CEST)
Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 997072928AE for <ietf-calsify@osafoundation.org>; Thu, 14 Oct 2004 02:03:30 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <200410131944.23546.mark@ScheduleWorld.com>
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131814.37611.reinhold@kainhofer.com> <200410132243.09298.reinhold@kainhofer.com> <200410131944.23546.mark@ScheduleWorld.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <966DD28E-1D74-11D9-88E6-000D93C1A604@opengroupware.org>
Content-Transfer-Encoding: 7bit
From: Helge Hess <helge.hess@opengroupware.org>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Thu, 14 Oct 2004 02:04:16 +0200
To: ietf-calsify@osafoundation.org
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2004 00:04:26 -0000
On Oct 14, 2004, at 1:44, Mark Swanson wrote:
> Well... duh. :-) My head was stuck where the <recurring>
> timezone/event would
> not conflict across the 12 midnight boundary. When it does you're
> hosed.
> Thanks to Reinhold, Helge, and Cyrus for taking the time to set me
> straight.
Well, this is just another example why avoiding a requirement for
timezones in the base spec will pay off.
(Political) Timezones are an incredibly complex issue (and I attribute
my first grey hair to it ;-) If we can remove that issue from the base
spec, its a huge gain for implementors. If its only in the base spec
because of another - questionable! - feature, rrule's, its even more
viable.
> I also agree localtime is not possible either.
> There is no way to calculate when the midnight boundary condition will
> happen
> - without a timezone...
>
> We must not remove timezones.
Me says, remove rrule's and timezones from the base spec, but ensure
that they are still available in an extension spec from the beginning
on.
There are proper implementations and it would be a real waste to render
them useless due to incompatible changes in the standard.
Greets,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DNiNa9026874 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 16:44:24 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 656 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 18:44:22 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 19:44:23 -0400
User-Agent: KMail/1.6.2
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131814.37611.reinhold@kainhofer.com> <200410132243.09298.reinhold@kainhofer.com>
In-Reply-To: <200410132243.09298.reinhold@kainhofer.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200410131944.23546.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 23:44:26 -0000
On October 13, 2004 4:43 pm, Reinhold Kainhofer wrote:
>
> Yes, he'll see the event on monday. However, the event really occurs on
> Monday 01:30 CEST, which is about *Sunday afternoon* in the US. Oops.
> I really said the event is on monday - for a person in CEST. But monday in
> CEST (UTC+0200) is not necessarily monday for a person in the US!
Well... duh. :-) My head was stuck where the <recurring> timezone/event would
not conflict across the 12 midnight boundary. When it does you're hosed.
Thanks to Reinhold, Helge, and Cyrus for taking the time to set me straight.
I also agree localtime is not possible either.
There is no way to calculate when the midnight boundary condition will happen
- without a timezone...
We must not remove timezones.
Cheers.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: reinhold@kainhofer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DKhCa9005323 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 13:43:12 -0700
Received: from [] (curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id i9DKhAQ03445 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 22:43:10 +0200
From: Reinhold Kainhofer <reinhold@kainhofer.com>
Organization: FAM, Vienna University of Technology
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 22:43:06 +0200
User-Agent: KMail/1.7.50
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131201.20121.mark@ScheduleWorld.com> <200410131814.37611.reinhold@kainhofer.com>
In-Reply-To: <200410131814.37611.reinhold@kainhofer.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1517890.xD8ELjkDY0"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200410132243.09298.reinhold@kainhofer.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 20:43:14 -0000
--nextPart1517890.xD8ELjkDY0
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Mark Swanson wrote:
> On October 13, 2004 12:14 pm, Reinhold Kainhofer wrote:
> > Ahm, for two persons in two different time zones this will not work.
>=20
> It does. We'll get to it in a couple of emails I'm sure.
To be honest, I'd really love to see this work. Because then all our proble=
ms=20
would have vanished... But so far, I haven't seen=20
> > Again use the example of my last mail: every monday at 01:30 in Timezone
> > Europe/Vienna. If the start date is in summer time, the event is on sun=
day
> > 23:30 UTC. No imagine somebody in the US views this event. The event st=
art
> > day will be on a sunday, so for the US person the event will only be
>=20
> If your RRULE specifies weekly every Monday, the US person will see the
> Monday 1 second after his DTSTART, so he will see the correct Monday.
Yes, that's what he'll see, which is wrong. See below.
> I'd like to pick a different example because I read this as: you say the
> event is on Monday, then you say the US person viewing the event on a=20
> Monday is the wrong day?
Yes, he'll see the event on monday. However, the event really occurs on Mon=
day=20
01:30 CEST, which is about *Sunday afternoon* in the US. Oops.=20
I really said the event is on monday - for a person in CEST. But monday in=
=20
CEST (UTC+0200) is not necessarily monday for a person in the US!
RRULEs are highly dependent on the local time zone. If you specify a=20
recurrence on monday, this will no longer be true in general for a differen=
t=20
time zone.
And translating RRULES from local time to UTC is not possible either. E.g.=
=20
00:30 localtime on the first monday each month will be either 23:30 UTC of=
=20
the first sunday, or of the last sunday of the previous month. I don't see=
=20
any way to represent this as a RRULE in UTC.
So, to be correct, all recurrence calculation need to be done in the origin=
al=20
time zone of the event, and only then can the results be translated to the=
=20
time zone of the presentation layer.
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold@kainhofer.com, 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
--nextPart1517890.xD8ELjkDY0
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBBbZNdTqjEwhXvPN0RAoZtAJ92ftG2865rvsDTO2ptHY+QY4Cr+ACfdybq
m51QG2yqEsxn/6rG2OfF0wM=
=aVnv
-----END PGP SIGNATURE-----
--nextPart1517890.xD8ELjkDY0--
X-Envelope-From: helge.hess@opengroupware.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DJb4a9029289 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 12:37:04 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 07C6529338C for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 21:36:21 +0200 (CEST)
Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 55CEA2931C7 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 21:36:20 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <200410131848.15930.reinhold@kainhofer.com>
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131201.20121.mark@ScheduleWorld.com> <200410131814.37611.reinhold@kainhofer.com> <200410131848.15930.reinhold@kainhofer.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3EC587F6-1D4F-11D9-88E6-000D93C1A604@opengroupware.org>
Content-Transfer-Encoding: 7bit
From: Helge Hess <helge.hess@opengroupware.org>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 21:36:57 +0200
To: ietf-calsify@osafoundation.org
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 19:37:06 -0000
On Oct 13, 2004, at 18:48, Reinhold Kainhofer wrote:
> On Wednesday 13 October 2004 18:14, Reinhold Kainhofer wrote:
>> I don't think RRULES can work without some information about the time
>> zone.
> ... which gives me an idea: How about moving the TZID parameter from
> the
> DTSTART to the RRULE (and RDATEs)?
This is something I suggested before. The only, but significant,
problem is that this will break compatibility with existing solutions.
I fear the latter might be a very valid reason to keep it like it is.
Greets,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
X-Envelope-From: daboo@isamet.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DJ7SaA023971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 12:07:29 -0700
Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i9DIgqo3025907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2004 14:42:52 -0400
Date: Wed, 13 Oct 2004 15:11:27 -0400
From: Cyrus Daboo <daboo@isamet.com>
To: Mark Swanson <mark@scheduleworld.com>, ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Message-ID: <D40E82667AF79666ADDC9BBE@plato.cyrusoft.com>
In-Reply-To: <200410131447.47065.mark@ScheduleWorld.com>
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131201.20121.mark@ScheduleWorld.com> <287891D2-1D34-11D9-88E6-000D93C1A604@opengroupware.org> <200410131447.47065.mark@ScheduleWorld.com>
X-Mailer: Mulberry/4.0.0d1 (Win32)
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-Scanned-By: MIMEDefang 2.45
Cc:
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 19:07:30 -0000
Hi Mark,
--On Wednesday, October 13, 2004 2:47 PM -0400 Mark Swanson
<mark@scheduleworld.com> wrote:
>> Of course, but the presentation layer needs to know that the event was
>> created in (and is intended for) "Candian/Eastern" time.
>
> Perhaps "(and is intended for)" is also a key factor. F.E. I assume that
> someone flying to Vancouver for a meeting would ask his presentation
> layer to display his events for that day in the Pacific timezone. I
> believe this to be logical.
The timezone needed for 'presentation' may well be different than the
timezone needed when editing an event. Consider: I am in EST timezone but
want to schedule an event for a meeting next week on the west coast in PST
- so I create the event and set the start to 12:00 pm PST - note that I
edit it in PST not my current 'presentation' timezone of EST. If at some
later point I want to edit it, the edit dialog should show the time in PST
- not the current 'presentation' timezone, whatever that may be.
Thus timezone information does need to be included with event data -
however that info only needs to be a 'hint' - the actual time can be stored
in UTC.
Hence my earlier suggestion of having a 'TZHINT' parameter on times
specified in UTC. That 'hint' is only needed is special circumstances, e.g.
editing, rrule expansion - all other operations can be done with the UTC
time without reference to it.
--
Cyrus Daboo
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DIvBa9022431 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 11:57:11 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 400 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 13:57:10 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 14:57:10 -0400
User-Agent: KMail/1.6.2
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131201.20121.mark@ScheduleWorld.com> <200410131814.37611.reinhold@kainhofer.com>
In-Reply-To: <200410131814.37611.reinhold@kainhofer.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200410131457.10813.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 18:57:12 -0000
On October 13, 2004 12:14 pm, Reinhold Kainhofer wrote:
> Again use the example of my last mail: every monday at 01:30 in Timezone
> Europe/Vienna. If the start date is in summer time, the event is on sunday
> 23:30 UTC. No imagine somebody in the US views this event. The event start
> day will be on a sunday, so for the US person the event will only be
If your RRULE specifies weekly every Monday, the US person will see the Monday
1 second after his DTSTART, so he will see the correct Monday.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DIlma9021267 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 11:47:48 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 719 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 13:47:47 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 14:47:47 -0400
User-Agent: KMail/1.6.2
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131201.20121.mark@ScheduleWorld.com> <287891D2-1D34-11D9-88E6-000D93C1A604@opengroupware.org>
In-Reply-To: <287891D2-1D34-11D9-88E6-000D93C1A604@opengroupware.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200410131447.47065.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 18:47:50 -0000
On October 13, 2004 12:23 pm, Helge Hess wrote:
> On Oct 13, 2004, at 18:01, Mark Swanson wrote:
> >> How do you store a recurrence rule for "every monday 11:00 PST" in
> >> UTC?
> >> Due to DST shifts, 11:00 PST translates to different UTC values
> >> depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC
> >> (UTC-6) in summer).
> >
> > The key is in DTSTART. Since you have a UTC value at an instance of
> > time you
> > can compensate for the changing timezone offsets at any set instance
> > in the
> > future.
>
> Yes, if you know the timezone the event was created in. Or in other
> words, you can save the time values in any timezone, including UTC, but
> you need to specify the timezone required for DST and historic
> calculations.
It involves some work, but there is a way to do it without having to know what
timezone the event is created in.
> > The key is the fact that the presentation layer can convert 11:00am
> > April 22,
> > 2004 Canadian/Eastern into a UTC value and back again.
>
> Of course, but the presentation layer needs to know that the event was
> created in (and is intended for) "Candian/Eastern" time.
Perhaps "(and is intended for)" is also a key factor. F.E. I assume that
someone flying to Vancouver for a meeting would ask his presentation layer to
display his events for that day in the Pacific timezone. I believe this to be
logical.
> An "each Monday at 11:00 MST" is different to "each Monday at 23:00
> CET" even though the UTC starttime might match (DST rules are
> different, so a German flying to Arizona for a meeting at 11:00 MST
> will arrive at the incorrect time).
Still a presentation issue. Perhaps this will help:
1. TZ=PST, recurring monday meeting: 11:00AM created by Joe
2. TZ=EST, Bob's calendar shows a 2:00PM recurring monday meeting.
3. Bob flies to the PST timezone, and sets his presentation timezone to PST,
which shows his meeting at 11:00AM.
If that isn't the issue Helge/Reinhold, perhaps it's a deeper issue of how
some folks are creating instances of the recurrence set from the
DTSTART/RRULE definition.
Cheers.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DIOMa9019240 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 11:24:22 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 902 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 13:24:21 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 14:24:21 -0400
User-Agent: KMail/1.6.2
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131201.20121.mark@ScheduleWorld.com> <200410131814.37611.reinhold@kainhofer.com>
In-Reply-To: <200410131814.37611.reinhold@kainhofer.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200410131424.21541.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 18:24:24 -0000
On October 13, 2004 12:14 pm, Reinhold Kainhofer wrote:
> On Wednesday 13 October 2004 18:01, Mark Swanson wrote:
> > The key is in DTSTART. Since you have a UTC value at an instance of time
> > you can compensate for the changing timezone offsets at any set instance
> > in the future.
> > The key is the fact that the presentation layer can convert 11:00am April
> > 22, 2004 Canadian/Eastern into a UTC value and back again.
>
> Ahm, for two persons in two different time zones this will not work.
It does. We'll get to it in a couple of emails I'm sure.
> Again use the example of my last mail: every monday at 01:30 in Timezone
> Europe/Vienna. If the start date is in summer time, the event is on sunday
> 23:30 UTC. No imagine somebody in the US views this event. The event start
> day will be on a sunday, so for the US person the event will only be
> displayed on the following monday, which is one day after it was actually
> supposed to happen...
I'd like to pick a different example because I read this as: you say the event
is on Monday, then you say the US person viewing the event on a Monday is the
wrong day? (or did you mean in 8 days as the following Monday?)
Next emai...
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: Robert_Ransdell@notesdev.ibm.com
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 i9DGvpa9007620; Wed, 13 Oct 2004 09:57:51 -0700
In-Reply-To: <200410131848.15930.reinhold@kainhofer.com>
To: Reinhold Kainhofer <reinhold@kainhofer.com>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_08182004NP August 18, 2004
Message-ID: <OFA5EDB3D4.C7C5BA03-ON85256F2C.005D1C73-85256F2C.005D2950@notesdev.ibm.com>
From: Robert_Ransdell@notesdev.ibm.com
Date: Wed, 13 Oct 2004 12:57:39 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 10/13/2004 12:55:05 PM
Content-Type: multipart/mixed; boundary="=_mixed 005D294285256F2C_="
X-Scanned-By: MIMEDefang 2.45
Cc: ietf-calsify@osafoundation.org, ietf-calsify-bounces@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 16:57:54 -0000
This is a multi-part message in MIME format...
--=_mixed 005D294285256F2C_=
Content-Type: multipart/alternative;
boundary="=_alternative 005D294685256F2C_="
--=_alternative 005D294685256F2C_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline
You have to read the DTSTART to correctly process the RRULE so leave TZID
where it is.
Reinhold Kainhofer <reinhold@kainhofer.com>
Sent by: ietf-calsify-bounces@osafoundation.org
10/13/2004 12:48 PM
To
ietf-calsify@osafoundation.org
cc
Subject
Re: [Ietf-calsify] RRULEs, TimeZones
On Wednesday 13 October 2004 18:14, Reinhold Kainhofer wrote:
> I don't think RRULES can work without some information about the time
zone.
... which gives me an idea: How about moving the TZID parameter from the
DTSTART to the RRULE (and RDATEs)?
I'm not aware of any other places in rfc2445, that depend on the timezone
information, so this might put the timezone problem with recurrence rules
to
the place it actually belongs to: To the recurrence rules.
It will be nasty to implement in GUIs, but that nastiness is already
there...
Basically, the user would have to specify the rrule in some timezone, and
if
somebody else uses a different timezone, he'll have to change the rrule in
the original timezone, so although the event might appear at 11:30 on
Sunday
in his calendar, the recurrence rule might still be set to recur on 01:30
on
Monday (but in CEST)...
>From a usability standpoint this is not the ideal solution, but we have
the
same problem at the moment, too. Actually, KOrganizer doesn't handle this
situation well at the moment. How do other CUAs behave in that respect?
Reinhold
--
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold@kainhofer.com, 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
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
--=_alternative 005D294685256F2C_=--
--=_mixed 005D294285256F2C_=
Content-Type: application/octet-stream; name="attxokfw.dat"
Content-Disposition: attachment; filename="attxokfw.dat"
Content-Transfer-Encoding: base64
LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBH
IHYxLjIuNSAoR05VL0xpbnV4KQ0KDQppRDhEQlFCQmJWeFBUcWpFd2hYdlBO
MFJBa2h6QUtEWDBMY294QStKeStrSHRQY2pScEZ0TFBTTDZnQ2FBemFvDQo4
Zk8zYytlYktWZ0NmTEQ5ck5jaWhFZz0NCj04Z3NCDQotLS0tLUVORCBQR1Ag
U0lHTkFUVVJFLS0tLS0NCg==
--=_mixed 005D294285256F2C_=--
X-Envelope-From: reinhold@kainhofer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DGmHa9006507 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 09:48:17 -0700
Received: from curie.fam.tuwien.ac.at (curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id i9DGmGQ22932 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 18:48:16 +0200
From: Reinhold Kainhofer <reinhold@kainhofer.com>
Organization: FAM, Vienna University of Technology
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 18:48:13 +0200
User-Agent: KMail/1.7
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131201.20121.mark@ScheduleWorld.com> <200410131814.37611.reinhold@kainhofer.com>
In-Reply-To: <200410131814.37611.reinhold@kainhofer.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1446937.6jAROLxlbu"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200410131848.15930.reinhold@kainhofer.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 16:48:19 -0000
--nextPart1446937.6jAROLxlbu
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 13 October 2004 18:14, Reinhold Kainhofer wrote:
> I don't think RRULES can work without some information about the time zon=
e.
=2E.. which gives me an idea: How about moving the TZID parameter from the=
=20
DTSTART to the RRULE (and RDATEs)?
I'm not aware of any other places in rfc2445, that depend on the timezone=20
information, so this might put the timezone problem with recurrence rules t=
o=20
the place it actually belongs to: To the recurrence rules.
It will be nasty to implement in GUIs, but that nastiness is already there.=
=2E.=20
Basically, the user would have to specify the rrule in some timezone, and i=
f=20
somebody else uses a different timezone, he'll have to change the rrule in=
=20
the original timezone, so although the event might appear at 11:30 on Sunda=
y=20
in his calendar, the recurrence rule might still be set to recur on 01:30 o=
n=20
Monday (but in CEST)...=20
=46rom a usability standpoint this is not the ideal solution, but we have t=
he=20
same problem at the moment, too. Actually, KOrganizer doesn't handle this=20
situation well at the moment. How do other CUAs behave in that respect?
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold@kainhofer.com, 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
--nextPart1446937.6jAROLxlbu
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBBbVxPTqjEwhXvPN0RAkhzAKDX0LcoxA+Jy+kHtPcjRpFtLPSL6gCaAzao
8fO3c+ebKVgCfLD9rNcihEg=
=8gsB
-----END PGP SIGNATURE-----
--nextPart1446937.6jAROLxlbu--
X-Envelope-From: helge.hess@opengroupware.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DGN8a9002553 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 09:23:09 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 948AF295D21 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 18:22:24 +0200 (CEST)
Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 763D3295BE9 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 18:22:24 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <200410131201.20121.mark@ScheduleWorld.com>
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131021.34988.mark@ScheduleWorld.com> <8CF3B6F2-1D26-11D9-88E6-000D93C1A604@opengroupware.org> <200410131201.20121.mark@ScheduleWorld.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <287891D2-1D34-11D9-88E6-000D93C1A604@opengroupware.org>
Content-Transfer-Encoding: 7bit
From: Helge Hess <helge.hess@opengroupware.org>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 18:23:03 +0200
To: ietf-calsify@osafoundation.org
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 16:23:12 -0000
On Oct 13, 2004, at 18:01, Mark Swanson wrote:
>> How do you store a recurrence rule for "every monday 11:00 PST" in
>> UTC?
>> Due to DST shifts, 11:00 PST translates to different UTC values
>> depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC
>> (UTC-6) in summer).
>
> The key is in DTSTART. Since you have a UTC value at an instance of
> time you
> can compensate for the changing timezone offsets at any set instance
> in the
> future.
Yes, if you know the timezone the event was created in. Or in other
words, you can save the time values in any timezone, including UTC, but
you need to specify the timezone required for DST and historic
calculations.
> The key is the fact that the presentation layer can convert 11:00am
> April 22,
> 2004 Canadian/Eastern into a UTC value and back again.
Of course, but the presentation layer needs to know that the event was
created in (and is intended for) "Candian/Eastern" time.
An "each Monday at 11:00 MST" is different to "each Monday at 23:00
CET" even though the UTC starttime might match (DST rules are
different, so a German flying to Arizona for a meeting at 11:00 MST
will arrive at the incorrect time).
Greets,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
X-Envelope-From: reinhold@kainhofer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DGEda9001084 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 09:14:40 -0700
Received: from curie.fam.tuwien.ac.at (curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id i9DGEcQ19432 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 18:14:38 +0200
From: Reinhold Kainhofer <reinhold@kainhofer.com>
Organization: FAM, Vienna University of Technology
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 18:14:35 +0200
User-Agent: KMail/1.7
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <8CF3B6F2-1D26-11D9-88E6-000D93C1A604@opengroupware.org> <200410131201.20121.mark@ScheduleWorld.com>
In-Reply-To: <200410131201.20121.mark@ScheduleWorld.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3480088.jZzOb4mufg"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200410131814.37611.reinhold@kainhofer.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 16:14:43 -0000
--nextPart3480088.jZzOb4mufg
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 13 October 2004 18:01, Mark Swanson wrote:
> The key is in DTSTART. Since you have a UTC value at an instance of time
> you can compensate for the changing timezone offsets at any set instance =
in
> the future.
> The key is the fact that the presentation layer can convert 11:00am April
> 22, 2004 Canadian/Eastern into a UTC value and back again.
Ahm, for two persons in two different time zones this will not work.
Again use the example of my last mail: every monday at 01:30 in Timezone=20
Europe/Vienna. If the start date is in summer time, the event is on sunday=
=20
23:30 UTC. No imagine somebody in the US views this event. The event start=
=20
day will be on a sunday, so for the US person the event will only be=20
displayed on the following monday, which is one day after it was actually=20
supposed to happen...=20
I don't think RRULES can work without some information about the time zone.
Reinhold
PS: Yes, his is a borderline-case, but a spec, which doesn't get the=20
borderline cases correct, is next to useless.
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold@kainhofer.com, 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
--nextPart3480088.jZzOb4mufg
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBBbVRtTqjEwhXvPN0RAqMwAKCV1co0xxcme5OG9L9/BTMQmdQ1eACgm9XA
BjvTkRH7csuJzN+DjLTxDO8=
=nNX8
-----END PGP SIGNATURE-----
--nextPart3480088.jZzOb4mufg--
X-Envelope-From: reinhold@kainhofer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DG1La9031946 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 09:01:22 -0700
Received: from curie.fam.tuwien.ac.at (curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id i9DG1KQ18891 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 18:01:20 +0200
From: Reinhold Kainhofer <reinhold@kainhofer.com>
Organization: FAM, Vienna University of Technology
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 18:01:17 +0200
User-Agent: KMail/1.7
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131021.34988.mark@ScheduleWorld.com>
In-Reply-To: <200410131021.34988.mark@ScheduleWorld.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1991365.nDJtpEQdJK"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200410131801.20504.reinhold@kainhofer.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 16:01:23 -0000
--nextPart1991365.nDJtpEQdJK
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 13 October 2004 16:21, Mark Swanson wrote:
> RRULEs already work fine when you strictly use UTC. TimeZone support is
> purely a presentation issue and does not belong in RFC 2445.
Ahm, it's not that easy. Assume you want a recurring event each monday at=20
01:30. During summer time this is (I'm in Austria, so central European Summ=
er=20
time, UTC+02:00) 23:30 on the previous sunday, in winter time this is 00:30=
=20
on the monday. The recurrence rule will have to state that it's 01:30 local=
=20
time each monday. You just cannot express this as a RRULE in UTC...
Reinhold
--nextPart1991365.nDJtpEQdJK
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBBbVFQTqjEwhXvPN0RAkKiAJ98HOtbqHjDjT59Uful6dOE7OYYHwCgwvMQ
bx9QycnvnREiSj+WecElbAU=
=jzWd
-----END PGP SIGNATURE-----
--nextPart1991365.nDJtpEQdJK--
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DG1Ja9031939 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 09:01:20 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 666 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 11:01:18 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 12:01:20 -0400
User-Agent: KMail/1.6.2
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131021.34988.mark@ScheduleWorld.com> <8CF3B6F2-1D26-11D9-88E6-000D93C1A604@opengroupware.org>
In-Reply-To: <8CF3B6F2-1D26-11D9-88E6-000D93C1A604@opengroupware.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200410131201.20121.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 16:01:21 -0000
On October 13, 2004 10:45 am, Helge Hess wrote:
> On Oct 13, 2004, at 16:21, Mark Swanson wrote:
> > RRULEs already work fine when you strictly use UTC. TimeZone support
> > is purely
> > a presentation issue and does not belong in RFC 2445.
>
> How do you store a recurrence rule for "every monday 11:00 PST" in UTC?
> Due to DST shifts, 11:00 PST translates to different UTC values
> depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC
> (UTC-6) in summer).
The key is in DTSTART. Since you have a UTC value at an instance of time you
can compensate for the changing timezone offsets at any set instance in the
future.
The key is the fact that the presentation layer can convert 11:00am April 22,
2004 Canadian/Eastern into a UTC value and back again.
Cheers.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: helge.hess@opengroupware.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DEjia9021633 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 07:45:45 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0BBDC295AE7 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 16:45:00 +0200 (CEST)
Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id A7899295A12 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 16:44:59 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <200410131021.34988.mark@ScheduleWorld.com>
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <200410131021.34988.mark@ScheduleWorld.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8CF3B6F2-1D26-11D9-88E6-000D93C1A604@opengroupware.org>
Content-Transfer-Encoding: 7bit
From: Helge Hess <helge.hess@opengroupware.org>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 16:45:39 +0200
To: ietf-calsify@osafoundation.org
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 14:45:45 -0000
On Oct 13, 2004, at 16:21, Mark Swanson wrote:
> RRULEs already work fine when you strictly use UTC. TimeZone support
> is purely
> a presentation issue and does not belong in RFC 2445.
How do you store a recurrence rule for "every monday 11:00 PST" in UTC?
Due to DST shifts, 11:00 PST translates to different UTC values
depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC
(UTC-6) in summer).
Greets,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
X-Envelope-From: helge.hess@opengroupware.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DEVFa9019449 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 07:31:15 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 31965295BC5 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 16:30:30 +0200 (CEST)
Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id DFDE9295AE8 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 16:30:29 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <200410131556.58853.reinhold@kainhofer.com>
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <C1826FB4-1D15-11D9-88E6-000D93C1A604@opengroupware.org> <200410131556.58853.reinhold@kainhofer.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8650BB79-1D24-11D9-88E6-000D93C1A604@opengroupware.org>
Content-Transfer-Encoding: 7bit
From: Helge Hess <helge.hess@opengroupware.org>
Subject: Re: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 16:31:09 +0200
To: ietf-calsify@osafoundation.org
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 14:31:17 -0000
On Oct 13, 2004, at 15:56, Reinhold Kainhofer wrote:
> Why is it so clear that RRULE needs to be removed?
There was a long discussion on that (UTC+RRULE) issue some weeks back
and I had the impression that everyone agreed.
> Sure, moving to UTC would be great, but recurrence rules are such a
> core feature to (almost) all calendar GUIs, that I don't think
> sacrificing rrules for UTC is really
> warranted.
Recurring appointments can be done in various ways and there are
several servers (actually almost all OpenSource servers are in that
category!) which store recurring events as a finite set of individual
(but connected) events for good reasons.
So, removing RRULE's improves interoperability because it matches
non-iCal-like-RRULE servers and clients, avoids differences in RRULE
support, and it removes a huge complexity because timezones can be
dropped.
> For pure invitation handling, RRULEs might not be absolutely
> necessary, but
> remember that many applications use iCalendar as their native storage
> format
> (for example, KOrganizer, Evolution, KPilot's calendar conduits, etc.).
As mentioned before I definitely agree that RRULE's should not be
dropped, just moved out of the core specification.
So you can still use iCalendar+RRULE-ext as the native storage format
(nothing will change for you!).
Greets,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
X-Envelope-From: mark@ScheduleWorld.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DELZa9018359 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 07:21:36 -0700
Received: from 10.0.2.4 ([10.0.2.4]) by ns1.webservicesolutions.com (JAMES SMTP Server 2.1.3) with SMTP ID 559 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 09:21:34 -0500 (CDT)
From: Mark Swanson <mark@ScheduleWorld.com>
Organization: Web Service Solutions, Inc.
To: ietf-calsify@osafoundation.org
Date: Wed, 13 Oct 2004 10:21:34 -0400
User-Agent: KMail/1.6.2
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com>
In-Reply-To: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200410131021.34988.mark@ScheduleWorld.com>
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] RRULEs, TimeZones
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 14:21:37 -0000
On October 13, 2004 8:33 am, Veikko.Punkka@nokia.com wrote:
> I agree, it would be _really_ useful to have a (maintained) chart
> which outlines what RRULE features are supported by what
> implementation. Based on that chart it would be possible to make a rational
> choice of which RRULE features belong to the core specification and
> which ones not.
>
> Any ideas of how we could practically start creating this kind of a chart?
ScheduleWorld supports the entire RRULE definition.
ScheduleWorld also uses UTC for everything internally. This has greatly eased
interoperability with limited devices and simplified the J2ME client.
RRULEs already work fine when you strictly use UTC. TimeZone support is purely
a presentation issue and does not belong in RFC 2445.
Cheers.
--
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
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: reinhold@kainhofer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DDv1a9016579 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 06:57:01 -0700
Received: from curie.fam.tuwien.ac.at (curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id i9DDuxQ07089 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 15:56:59 +0200
From: Reinhold Kainhofer <reinhold@kainhofer.com>
Organization: FAM, Vienna University of Technology
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 15:56:56 +0200
User-Agent: KMail/1.7
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com> <C1826FB4-1D15-11D9-88E6-000D93C1A604@opengroupware.org>
In-Reply-To: <C1826FB4-1D15-11D9-88E6-000D93C1A604@opengroupware.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1270986.pGm1uimyFn"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200410131556.58853.reinhold@kainhofer.com>
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 13:57:04 -0000
--nextPart1270986.pGm1uimyFn
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 13 October 2004 14:45, Helge Hess wrote:
> On Oct 13, 2004, at 14:33, <Veikko.Punkka@nokia.com> wrote:
> > I agree, it would be _really_ useful to have a (maintained) chart
> > which outlines what RRULE features are supported by what
> > implementation.=20
Yes, I'd like to have such a table too. Here's the current support of KDE=20
(libkcal as the base library, which supports more than KOrganizer as the=20
corresponding GUI. libkcal is also used by other applications like KPilot's=
=20
calendar conduits, the time tracking application KArm, and KNotes). I'll ha=
ve=20
to distinguish betwen KOrganizer (which provides less gui options) and=20
libkcal (which supports almost all BY* rule, although you cannot create the=
m=20
in korganizer):
libkcal does understand and can handle the following BY* rules (not all=20
combinations are understood, though. The ones neede by korganizer below are=
=20
of course best supported):
BYSECOND: somewhat
BYMINUTE: YES
BYHOUR: YES
BYDAY: YES
BYMONTHDAY: YES
BYYEARDAY: YES
BYWEEKNO: NO
BYMONTH: YES
BYSETPOS: No (but is planned, needed for first/last weekday of a month)
In KOrganizer's GUI we support the following recurrence options:
Daily: FREQ=3DDAILY
Weekly: FREQ=3DWEEKLY;BYDAY=3D...
Monthly: FREQ=3DMONTHLY
-) on the n-th (mon|tues|..)day: BYDAY=3D...=20
-) on the n-th day: BYMONTHDAY=3D...
Yearly: FREQ=3DYEARLY
-) On the n-th day of month Y: BYMONTHDAY=3D11;BYMONTH=3D10
-) On the n-th (mon|tues|..)day of Month Y:BYDAY=3D2MO;BYMONTH=3D10
-) On the n-th day of the year: BYYEARDAY=3D285
All other recurrence rules understood by libkcal are shown in KOrganizer (i=
f=20
the FREQ>=3DDAILY), but cannot be edited.
> > Based on that chart it would be possible to make a=20
> > rational
> > choice of which RRULE features belong to the core specification and
> > which ones not.
>
> I think its already more or less clear that RRULE needs to be removed
> completely from the core spec so that we can move to UTC for the base
> spec.
Why is it so clear that RRULE needs to be removed? Sure, moving to UTC woul=
d=20
be great, but recurrence rules are such a core feature to (almost) all=20
calendar GUIs, that I don't think sacrificing rrules for UTC is really=20
warranted.=20
=46or pure invitation handling, RRULEs might not be absolutely necessary, b=
ut=20
remember that many applications use iCalendar as their native storage forma=
t=20
(for example, KOrganizer, Evolution, KPilot's calendar conduits, etc.).=20
I think it really depends on whether iCalendar is supposed to be a format=20
purely intended for invitation handling, or also as a storage format.=20
Currently, I think it's the latter, and there removing all recurrence rules=
=20
in the core spec is like removing all paragraph format settings in a word=20
processing format spec.
Reinhold
--nextPart1270986.pGm1uimyFn
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBBbTQqTqjEwhXvPN0RAoDGAKCtCIIAepIJn1V+iapXcvHA0PGdyACcCSVl
JB2jK46YH0EQawMnsXCbq9w=
=QiqA
-----END PGP SIGNATURE-----
--nextPart1270986.pGm1uimyFn--
X-Envelope-From: helge.hess@opengroupware.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DCjga9010564 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 05:45:43 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 5610C295C3E for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 14:44:48 +0200 (CEST)
Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id C53FC295BD7 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 14:44:45 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com>
References: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C1826FB4-1D15-11D9-88E6-000D93C1A604@opengroupware.org>
Content-Transfer-Encoding: 7bit
From: Helge Hess <helge.hess@opengroupware.org>
Subject: Re: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 14:45:26 +0200
To: "<ietf-calsify@osafoundation.org> <ietf-calsify@osafoundation.org>" <ietf-calsify@osafoundation.org>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 12:45:43 -0000
On Oct 13, 2004, at 14:33, <Veikko.Punkka@nokia.com> wrote:
> I agree, it would be _really_ useful to have a (maintained) chart
> which outlines what RRULE features are supported by what
> implementation. Based on that chart it would be possible to make a
> rational
> choice of which RRULE features belong to the core specification and
> which ones not.
I think its already more or less clear that RRULE needs to be removed
completely from the core spec so that we can move to UTC for the base
spec.
An interesting question is whether the RRULE extension needs to have
additional "levels" for basic / complex RRULE support.
Greets,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
X-Envelope-From: Veikko.Punkka@nokia.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9DCXgaA009656 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 05:33:49 -0700
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DCXeF28259; Wed, 13 Oct 2004 15:33:40 +0300 (EET DST)
X-Scanned: Wed, 13 Oct 2004 15:33:29 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9DCXTdC022506; Wed, 13 Oct 2004 15:33:29 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00HTks7w; Wed, 13 Oct 2004 15:33:29 EEST
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DCXNS15604; Wed, 13 Oct 2004 15:33:23 +0300 (EET DST)
Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 15:33:05 +0300
Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 15:33:12 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 15:33:11 +0300
Message-ID: <0649D32A5A62294BBF93B77A6EC985AD15896C@trebe051.ntc.nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ietf-calsify] (no subject)
Thread-Index: AcSxFo7W01HxH6syRLWWO5mt71NkEgABcnjg
From: <Veikko.Punkka@nokia.com>
To: <helge.hess@opengroupware.org>, <ietf-calsify@osafoundation.org>
X-OriginalArrivalTime: 13 Oct 2004 12:33:12.0403 (UTC) FILETIME=[CDDBF230:01C4B120]
X-Scanned-By: MIMEDefang 2.45
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i9DCXgaA009656
Cc:
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 12:33:51 -0000
I agree, it would be _really_ useful to have a (maintained) chart
which outlines what RRULE features are supported by what
implementation. Based on that chart it would be possible to make a rational
choice of which RRULE features belong to the core specification and
which ones not.
Any ideas of how we could practically start creating this kind of a chart?
Best Regards,
Veikko
> -----Original Message-----
> From: ietf-calsify-bounces@osafoundation.org
> [mailto:ietf-calsify-bounces@osafoundation.org]On Behalf Of ext Helge
> Hess
> Sent: 13 October, 2004 14:15
> To: <ietf-calsify@osafoundation.org> <ietf-calsify@osafoundation.org>
> Subject: Re: [Ietf-calsify] (no subject)
>
>
> On Oct 13, 2004, at 8:12, <Veikko.Punkka@nokia.com> wrote:
> > If you now start sending each occurence as a single VEVENT
> > with some other thing to keep them related (not necessarily
> supported
> > by current clients), how do you think that will make you reach
> > interoperability
> > sooner?
>
> The huge majority of available systems are not interoperable at all.
> Reducing complexity will make it much easier for those systems to
> implement iCal and to ensure interoperability at a certain
> level. This
> level might not be sufficient for you, but it will improve the
> situation for a lot of other users of scheduling software.
>
> On the other side we should not break existing applications (you are
> certainly correct that some implementations probably support 100% of
> RRULE's). IMHO if we remove RRULE's from the core spec, we should _at
> the same time_ have an extension spec available which implements
> 'traditional' RRULE's.
>
> Besides that it would be _really_ useful to have a (maintained) chart
> which outlines what RRULE features are supported by what
> implementation. So far I have only seen pretty broad
> statements like "4
> of 5 implements X".
>
> best regards,
> Helge
> --
> http://docs.opengroupware.org/Members/helge/
> OpenGroupware.org
>
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
X-Envelope-From: helge.hess@opengroupware.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i9DBFLa9006635 for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 04:15:22 -0700
Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 64B47295B1A for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 13:14:35 +0200 (CEST)
Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id DE9A929296A for <ietf-calsify@osafoundation.org>; Wed, 13 Oct 2004 13:14:32 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <0649D32A5A62294BBF93B77A6EC985AD158969@trebe051.ntc.nokia.com>
References: <0649D32A5A62294BBF93B77A6EC985AD158969@trebe051.ntc.nokia.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <272CCD38-1D09-11D9-88E6-000D93C1A604@opengroupware.org>
Content-Transfer-Encoding: 7bit
From: Helge Hess <helge.hess@opengroupware.org>
Subject: Re: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 13:15:13 +0200
To: "<ietf-calsify@osafoundation.org> <ietf-calsify@osafoundation.org>" <ietf-calsify@osafoundation.org>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 11:15:25 -0000
On Oct 13, 2004, at 8:12, <Veikko.Punkka@nokia.com> wrote:
> If you now start sending each occurence as a single VEVENT
> with some other thing to keep them related (not necessarily supported
> by current clients), how do you think that will make you reach
> interoperability
> sooner?
The huge majority of available systems are not interoperable at all.
Reducing complexity will make it much easier for those systems to
implement iCal and to ensure interoperability at a certain level. This
level might not be sufficient for you, but it will improve the
situation for a lot of other users of scheduling software.
On the other side we should not break existing applications (you are
certainly correct that some implementations probably support 100% of
RRULE's). IMHO if we remove RRULE's from the core spec, we should _at
the same time_ have an extension spec available which implements
'traditional' RRULE's.
Besides that it would be _really_ useful to have a (maintained) chart
which outlines what RRULE features are supported by what
implementation. So far I have only seen pretty broad statements like "4
of 5 implements X".
best regards,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
X-Envelope-From: Veikko.Punkka@nokia.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9D6bXaA024932 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 23:37:36 -0700
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D6bUW23882; Wed, 13 Oct 2004 09:37:30 +0300 (EET DST)
X-Scanned: Wed, 13 Oct 2004 09:37:18 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9D6bId3025508; Wed, 13 Oct 2004 09:37:18 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 002cL1cn; Wed, 13 Oct 2004 09:37:17 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D6Cka02836; Wed, 13 Oct 2004 09:12:46 +0300 (EET DST)
Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 09:12:42 +0300
Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 09:12:43 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 09:12:42 +0300
Message-ID: <0649D32A5A62294BBF93B77A6EC985AD158969@trebe051.ntc.nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ietf-calsify] (no subject)
Thread-Index: AcSwxR9UgDp77YEcSueg60dU7AMHQQAIwQpA
From: <Veikko.Punkka@nokia.com>
To: <TimHare@comcast.net>, <ietf-calsify@osafoundation.org>
X-OriginalArrivalTime: 13 Oct 2004 06:12:43.0049 (UTC) FILETIME=[A680F990:01C4B0EB]
X-Scanned-By: MIMEDefang 2.45
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i9D6bXaA024932
Cc:
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 06:37:38 -0000
It sounds like you would be sacrificing a lot of other things at the
same time. Let me explain my own situation. I have my calendar data
on multiple devices (a PC, a bigger mobile phone I carry around at work,
a smaller mobile phone I carry around at leisure). I synchronise the
devices periodically so that they keep in sync to each other and I use
all the devices to enter and view events in the calendar. In my calendar I
have several things that repeat: anniversaries, weekly meetings, etc.
Sometimes they do not have a specific end date, while other times they do
(say for example the projected duration of a project). Occasionally I need
to modify these repeating things. The time of the weekly meeting may change,
or it may be changed to a biweekly meeting or the end date of the project has
slipped and so the end date of the repeat changes. I want to do these changes from
any one of my devices without having to go through every occurence of that
repeating thing. For that I need a reliable synchronisation method that keeps
those repeating things related. Most of current implementations I use do
this by sending the repeating things as a single VEVENT with a RRULE
that is used to calculate the occurences of the thing in each of the
devices. If you now start sending each occurence as a single VEVENT
with some other thing to keep them related (not necessarily supported
by current clients), how do you think that will make you reach interoperability
sooner?
Veikko Punkka
> -----Original Message-----
> From: ietf-calsify-bounces@osafoundation.org
> [mailto:ietf-calsify-bounces@osafoundation.org]On Behalf Of ext
> TimHare@comcast.net
> Sent: 13 October, 2004 04:28
> To: ietf-calsify@osafoundation.org
> Subject: Re: [Ietf-calsify] (no subject)
>
>
> Sorry - I was unclear. What I meant to say was, for
> iCal-Basic or whatever
> we're calling it, that a set of VEVENTs instead of using
> RRULEs would work
> for me, if it means that interoperability comes sooner. It
> sacrifices the
> "every week forever" kind of event, but if my client and/or
> server can
> compute and send "every week until my projected retirement
> date" that's
> sufficient :-)
>
> At 09:21 AM 10/12/04, Doug Royer wrote:
>
>
> >What do you mean by "single VEVENT"?
> >Do you mean that we need to start with VEVENTs?
> >
> >--
> >
> >Doug Royer | http://INET-Consulting.com
> >-------------------------------|-----------------------------
> >Doug@Royer.com | Office: (208)520-4044
> >http://Royer.com/People/Doug | Fax: (866)594-8574
> > | Cell: (208)520-4044
> >
> > We Do Standards - You Need Standards
> >
> >
> >
> >
> >
> >_______________________________________________
> >Ietf-calsify mailing list
> >Ietf-calsify@osafoundation.org
> >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
>
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9D1Yja9022548 for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 18:34:46 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc12) with SMTP id <200410130134390120035mu6e> (Authid: TimHare); Wed, 13 Oct 2004 01:34:39 +0000
Message-Id: <6.1.1.1.0.20041012212357.02864030@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 12 Oct 2004 21:27:37 -0400
To: ietf-calsify@osafoundation.org
From: TimHare@comcast.net
Subject: Re: [Ietf-calsify] (no subject)
In-Reply-To: <416BDA4F.4090703@Royer.com>
References: <6.1.1.1.0.20041012075513.028611a0@mail.comcast.net> <416BDA4F.4090703@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.42 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, NO_REAL_NAME
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2004 01:34:48 -0000
Sorry - I was unclear. What I meant to say was, for iCal-Basic or whatever
we're calling it, that a set of VEVENTs instead of using RRULEs would work
for me, if it means that interoperability comes sooner. It sacrifices the
"every week forever" kind of event, but if my client and/or server can
compute and send "every week until my projected retirement date" that's
sufficient :-)
At 09:21 AM 10/12/04, Doug Royer wrote:
>What do you mean by "single VEVENT"?
>Do you mean that we need to start with VEVENTs?
>
>--
>
>Doug Royer | http://INET-Consulting.com
>-------------------------------|-----------------------------
>Doug@Royer.com | Office: (208)520-4044
>http://Royer.com/People/Doug | Fax: (866)594-8574
> | Cell: (208)520-4044
>
> We Do Standards - You Need Standards
>
>
>
>
>
>_______________________________________________
>Ietf-calsify mailing list
>Ietf-calsify@osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9CDlZaA003618 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 06:47:36 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9CDlTx3031841 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 06:47:31 -0700
Message-ID: <416BE071.3000805@Royer.com>
Date: Tue, 12 Oct 2004 07:47:29 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] RRULE options - VEVENT
References: <6.1.1.1.0.20041012075513.028611a0@mail.comcast.net>
In-Reply-To: <6.1.1.1.0.20041012075513.028611a0@mail.comcast.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090502050901090008030103"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2004 13:47:37 -0000
This is a cryptographically signed message in MIME format.
--------------ms090502050901090008030103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
What does everyone think?
A) Disallow all RRULEs in a VEVENT?
B) Allow only a simplified RRULE in a VEVENT?
C) Allow only one RRULE (simple or not) per VEVENT?
D) Allow EXRULE ?
E) Allow EXDATE?
F) Allow RDATE?
Notes from my searching calendaring tools:
1) All implementations can do simple non-repeating VEVENTs.
This also includes non iCAL calendaring tools.
2) All iCAL implementations that I can find can do:
Daily, Weekly, Monthly
3) Many allow:
Yearly
4) Many allow:
Nth day of month.
5) Of the ones that allow recurring rules, all that I can find allow
one or more of the recurring instances to be removed.
6) Of (5) only one does it without EXDATE. And that implementation
can not export its entries in way that almost all other
implementations
can import. It uses a list of objects that have to be recreated
in order.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)520-4044
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms090502050901090008030103
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
9w0BCQUxDxcNMDQxMDEyMTM0NzI5WjAjBgkqhkiG9w0BCQQxFgQUIRa93I5qbx8OfzTujig2
YJv/zgYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAX0OHct+/3x/dQE9Idf5dZp4iYExuy3pm5vqmzWF+ogsQciUaNooClqh6Ki6JU3q9
XSECo0DPHde2OIis0tHyGnadi2qpAa+g/XhCt01hT1WmtzaHrhATHKLKom4vNs0EncOgkm7z
j+ajoeM1D7k0TCI4SqrgYiGhw23xU0n38HcngxNTrmOHUjULPAZsUI9TUgRHrfgk/6sZBSc+
LN8+Jgadp82CsEvlytD90dGtiiYTEbw/x51SyKwq19N1BDs8Jcv+4Zl/udc7Lh0IIxoMNl3G
pMFpKvlmN3HDSfCklbMKPOulSN3799wP5QfXRaBiStI3trNDZl8ju2wCZvqXsgAAAAAAAA==
--------------ms090502050901090008030103--
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9CDLPaA032066 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 06:21:27 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i9CDLJx3031547 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 06:21:21 -0700
Message-ID: <416BDA4F.4090703@Royer.com>
Date: Tue, 12 Oct 2004 07:21:19 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] (no subject)
References: <6.1.1.1.0.20041012075513.028611a0@mail.comcast.net>
In-Reply-To: <6.1.1.1.0.20041012075513.028611a0@mail.comcast.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040903040503020705060509"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2004 13:21:28 -0000
This is a cryptographically signed message in MIME format.
--------------ms040903040503020705060509
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
TimHare@comcast.net wrote:
>
> I heartily agree with this - and in thinking about it, I think my
> discussions on retaining simple recurrence rules might also need to
> fall by the wayside. Exchanging only single VEVENTs would definitely
> bring about interoperability between diverse implementations, which is
> one thing that is desperately needed, and has been for at least a
> decade - I remember discussing this stuff at SHARE
> (http://www.share.org) in the early 1990's.
What do you mean by "single VEVENT"?
Do you mean that we need to start with VEVENTs?
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)520-4044
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms040903040503020705060509
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
9w0BCQUxDxcNMDQxMDEyMTMyMTE5WjAjBgkqhkiG9w0BCQQxFgQUQsHU0pCXb5b2CMvjfc34
Am74g/MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAEILbg0XnlwmbOxy59KkWcHHGXLG3YcRbwh9a7Tb/R8SOKJNwwYlxBYYdTo4+jIhJ
oZSC/KxlePKFrUsUcB0mPick6lNZpmYoTpy3W7kNRRq0nSueFcTKFPdFDVjeiNaEDRJhVCo3
Y4apcixZyJ65tlU/MV6dNeTHLbGSm0R3MkmpAnVpr93CGL9EaMJANLNPb57m5IKXNzcsYbdQ
FeN8fDFxNSCOMLEruxe0QPzdJcOFpo00CggCnxL3V9sk2HE2VchG0uwQjaXpDOGaP2zCT2OU
qP+s0/pczZSTQ2cOiFZqTKnBvXaX/bwGtIfJY3bud2EovpCQn7Sv4zBRNiXS/wAAAAAAAA==
--------------ms040903040503020705060509--
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9CCAKa9021892 for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 05:10:20 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc13) with SMTP id <2004101212101201600c6btbe> (Authid: TimHare); Tue, 12 Oct 2004 12:10:12 +0000
Message-Id: <6.1.1.1.0.20041012075513.028611a0@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 12 Oct 2004 08:03:45 -0400
To: ietf-calsify@osafoundation.org
From: TimHare@comcast.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] (no subject)
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2004 12:10:21 -0000
Cameron Stillion wrote, in part:
"... This is not to say we should paint ourselves into a corner in the most
fundamental ways, but it does mean we need to start small, get something
basic that we all can agree to, grow some real interoperability, and
THEN we can start tinkering with how to extend the standard to the
zillion other applications and possibilities. "
I heartily agree with this - and in thinking about it, I think my
discussions on retaining simple recurrence rules might also need to fall by
the wayside. Exchanging only single VEVENTs would definitely bring about
interoperability between diverse implementations, which is one thing that
is desperately needed, and has been for at least a decade - I remember
discussing this stuff at SHARE (http://www.share.org) in the early 1990's.
I think our focus needs to narrow to: simplify to the point that
individuals and organizations can begin to schedule with each other, no
matter what platform they're using. While it may seem counter-intuitive,
I believe that this will benefit those who are vendors - I know what a boon
it would be if my employer could schedule meetings with the many
contractors and consultants we use. We have limited capability in that area
now - if they have Outlook/Exchange and we have Notes, for example, there's
some interoperability - but if a small contractor uses something like Yahoo
for his calendaring, we may be out of luck (I say "may be" because I
haven't researched it).
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9CC0na9020718 for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 05:00:49 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc12) with SMTP id <2004101212004301400rgjdje> (Authid: TimHare); Tue, 12 Oct 2004 12:00:43 +0000
Message-Id: <6.1.1.1.0.20041012074747.02863eb0@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 12 Oct 2004 07:54:08 -0400
To: ietf-calsify@osafoundation.org
From: TimHare@comcast.net
Subject: Re: [Ietf-calsify] Re: XML format?
Cc: ietf-calsify@osafoundation.org
In-Reply-To: <90BA8DCE-1BDE-11D9-AA84-000A95B2BB72@osafoundation.org>
References: <stpeter-331D11.19382706102004@sea.gmane.org> <6.1.1.1.0.20041006222713.0285b490@mail.comcast.net> <stpeter-557827.17145211102004@sea.gmane.org> <90BA8DCE-1BDE-11D9-AA84-000A95B2BB72@osafoundation.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2004 12:00:49 -0000
I believe XML has a lot of benefit for calendaring, also (one of the
reasons for
http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt). I am NO
expert in XML but I am a believer in the benefits of markup from a long
time ago.
I think, however, that if we're going to discuss it, we need another
mailing list. I wouldn't want to muddle "iCalendar simplification" with
"redoing the calendaring idea". The RDFiCalendar folks should be invited
as well since they've already got an XML implementation, and they tried to
build "round-tripping" tools between that and iCalendar. My only issue with
their implementation so far is that "I'm just a simple caveman..." and the
theoretical aspects of why they choose to do things in certain ways, have
escaped me so far.
At 07:37 PM 10/11/04, Lisa Dusseault wrote:
>Peter's mail reminded me that whenever I talk about calendaring standards
>outside the group of calendaring implementors, people always ask about an
>XML format for calendar data. For example, Paul Hoffman explained to me
>last week why Atom (blog feed format) would only use XML but that if
>iCalendar had some XML data format standards they would be happy to be
>compliant with that for dates, durations, attendee lists or what have you.
>
>Doing a non-backward-compatible switch from iCalendar 1.0 to something
>XML-based would certainly have a big switchover cost in calendaring
>software. But moving to XML would certainly have long-term synergy with
>other standards groups, benefits in terms of fewer format parsers, greater
>flexibility and greater interoperability. I don't even know how we can
>estimate when the benefits outweigh the costs, or at what rate the costs
>would be amortized, but it does seem clear to me that the switchover cost
>is more temporary while the benefits are longer lasting.
>
>Lisa
>
>On Oct 11, 2004, at 4:14 PM, Peter Saint-Andre wrote:
>
>>In article <6.1.1.1.0.20041006222713.0285b490@mail.comcast.net>,
>> TimHare@comcast.net wrote:
>>
>>>Please look at:
>>>http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt
>>>
>>>Suggestions and opinions are appreciated.
>>
>>In Section 8, you recommend using the HTTP URIs of the RFCs as XML
>>namespace names. This is potentially problematic (what happens when ther
>>are superseded?). I'd suggest XML namespace URIs in the
>>urn:ietf:params:xml:ns tree (RFC 3920 is a recent spec that uses these).
>>
>>In Section 9, your media types are off -- "application/calendar+xml" is
>>more correct. http://www.xmpp.org/specs/rfc3923.html#iana has an example
>>of a recent content-type registration of this kind. When the time comes,
>>don't forget to run your definition by the friendly folks on the
>>ietf-types list: http://www.alvestrand.no/mailman/listinfo/ietf-types
>>
>>In Section 11.1 you define a DTD. That's so old-fashioned -- all the
>>cool kids are using XML schema these days. ;-)
>>
>>That's about as far as I got. It'll be great to have an XML format for
>>calendar objects!
>>
>>Peter
>>
>>P.S. Given some of the layout oddities, it seems that perhaps you did
>>not use the XML RFC format; http://xml.resource.org/ tells you how and
>>it is highly recommended!
>>
>>_______________________________________________
>>Ietf-calsify mailing list
>>Ietf-calsify@osafoundation.org
>>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>_______________________________________________
>Ietf-calsify mailing list
>Ietf-calsify@osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: gettes@duke.edu
Received: from wilson.acpub.duke.edu (wilson.acpub.duke.edu [152.3.233.69]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9BNsbaA029566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2004 16:54:38 -0700
Received: from [192.168.0.6] (rdu26-59-053.nc.rr.com [66.26.59.53]) by wilson.acpub.duke.edu (8.12.10/8.12.10/Duke-5.0.0) with ESMTP id i9BNsNPH010306; Mon, 11 Oct 2004 19:54:24 -0400 (EDT)
In-Reply-To: <1198328AFDBF5841B27E40C40C331537012AE609@df-chewy-msg.exchange.corp.microsoft.com>
References: <1198328AFDBF5841B27E40C40C331537012AE609@df-chewy-msg.exchange.corp.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E0B7D273-1BE0-11D9-AD67-000A95B34C0E@duke.edu>
Content-Transfer-Encoding: 7bit
From: Michael R Gettes <gettes@duke.edu>
Subject: Re: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
Date: Mon, 11 Oct 2004 19:54:24 -0400
To: "Cameron Stillion" <camerost@exchange.microsoft.com>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
Cc: ietf-calsify@osafoundation.org, ietf-caldav@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2004 23:54:39 -0000
Is it reasonable to suggest community based ical or task
oriented ical? People oriented systems might be able to
limit one set of abilities within the spec whereas others,
such as computing clusters and other areas, could use
forms of ical that allow them to their jobs as well.
Creating namespaces for ical specifications would seem
to be a logical thing to do. Well known namespaces have
well defined specs and uses -- this allows for local
namespaces to implement other aspects of ical.
Just a thought...
/mrg
On Oct 11, 2004, at 19:30, Cameron Stillion wrote:
>
> I respectfully disagree. Leaving a standard "as open as possible" can
> easily lead to such difficulties in interoperability as we have all
> witnessed over the past several years. The idea for calsify, I
> believe,
> is to actually curb the open-ended nature of iCal in favor of the more
> practical bottom line: something that works for a subset that we really
> really care about.
>
> This is not uncommon in software development, it's just that iCal is
> long due for such a refocus and simplification. It's not so much a
> matter of Social Restrictions - it's just that the kinds of systems we
> are creating have a general purpose to them, and it is centered around
> creating calendars, sharing calendars, scheduling meetings, and other
> simple day-to-day things. Aligning stellar cartography hardware and
> synchronizing atomic clocks are most definitely on the ragged outer
> edge
> of our target.
>
> This is not to say we should paint ourselves into a corner in the most
> fundamental ways, but it does mean we need to start small, get
> something
> basic that we all can agree to, grow some real interoperability, and
> THEN we can start tinkering with how to extend the standard to the
> zillion other applications and possibilities.
>
> As for your specific example -- "granularity", I can easily see a
> property emerge in a future version of iCal that specified
> sub-15-minute
> granularity. This would not break clients who didn't care (most of
> them, IMHO) and would be easily read and interpreted by those who did.
>
> Let's avoid getting wrapped around the axle of creating "the perfect
> calendaring standard" - I'm just hoping we can get something simple
> that
> kind of works without too much pain and suffering.
>
>
> Cameron
>
>
> -----Original Message-----
> From: ietf-calsify-bounces@osafoundation.org
> [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Lyndon
> Nerenberg
> Sent: Saturday, October 09, 2004 9:57 PM
> To: TimHare@comcast.net; ietf-caldav@osafoundation.org;
> ietf-calsify@osafoundation.org
> Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
>
> --On 2004-10-6 10:25 PM -0400 TimHare@comcast.net wrote:
>
>> my view is that we ought to establish a standard for the granularity
>> of a free/busy time map (15 minutes would be my choice)
>
> I disagree with this. Calendaring is much more than just scheduling
> meetings (with people). I can see using iCal and friends to schedule
> runtime on computing clusters, or access to radio astronomy telescopes,
> or many other resources where fine-grained access times are
> appropriate.
> We should not be placing any form of social restrictions on the
> protocols like this. They must be left as open ended as possible so as
> to preclude us having to revisit the specifications in the near term
> because we didn't anticipate a use for them.
>
> --lyndon
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-caldav mailing list
> Ietf-caldav@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
X-Envelope-From: lisa@osafoundation.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9BNc1aA028374 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 11 Oct 2004 16:38:02 -0700
In-Reply-To: <stpeter-557827.17145211102004@sea.gmane.org>
References: <stpeter-331D11.19382706102004@sea.gmane.org> <6.1.1.1.0.20041006222713.0285b490@mail.comcast.net> <stpeter-557827.17145211102004@sea.gmane.org>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <90BA8DCE-1BDE-11D9-AA84-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: [Ietf-calsify] Re: XML format?
Date: Mon, 11 Oct 2004 16:37:50 -0700
To: Peter Saint-Andre <stpeter@jabber.org>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2004 23:38:02 -0000
Peter's mail reminded me that whenever I talk about calendaring
standards outside the group of calendaring implementors, people always
ask about an XML format for calendar data. For example, Paul Hoffman
explained to me last week why Atom (blog feed format) would only use
XML but that if iCalendar had some XML data format standards they would
be happy to be compliant with that for dates, durations, attendee lists
or what have you.
Doing a non-backward-compatible switch from iCalendar 1.0 to something
XML-based would certainly have a big switchover cost in calendaring
software. But moving to XML would certainly have long-term synergy
with other standards groups, benefits in terms of fewer format parsers,
greater flexibility and greater interoperability. I don't even know
how we can estimate when the benefits outweigh the costs, or at what
rate the costs would be amortized, but it does seem clear to me that
the switchover cost is more temporary while the benefits are longer
lasting.
Lisa
On Oct 11, 2004, at 4:14 PM, Peter Saint-Andre wrote:
> In article <6.1.1.1.0.20041006222713.0285b490@mail.comcast.net>,
> TimHare@comcast.net wrote:
>
>> Please look at:
>> http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt
>>
>> Suggestions and opinions are appreciated.
>
> In Section 8, you recommend using the HTTP URIs of the RFCs as XML
> namespace names. This is potentially problematic (what happens when
> ther
> are superseded?). I'd suggest XML namespace URIs in the
> urn:ietf:params:xml:ns tree (RFC 3920 is a recent spec that uses
> these).
>
> In Section 9, your media types are off -- "application/calendar+xml" is
> more correct. http://www.xmpp.org/specs/rfc3923.html#iana has an
> example
> of a recent content-type registration of this kind. When the time
> comes,
> don't forget to run your definition by the friendly folks on the
> ietf-types list: http://www.alvestrand.no/mailman/listinfo/ietf-types
>
> In Section 11.1 you define a DTD. That's so old-fashioned -- all the
> cool kids are using XML schema these days. ;-)
>
> That's about as far as I got. It'll be great to have an XML format for
> calendar objects!
>
> Peter
>
> P.S. Given some of the layout oddities, it seems that perhaps you did
> not use the XML RFC format; http://xml.resource.org/ tells you how and
> it is highly recommended!
>
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
X-Envelope-From: camerost@exchange.microsoft.com
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.76.149] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9BNUIa9027843; Mon, 11 Oct 2004 16:30:25 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Oct 2004 16:30:04 -0700
Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 16:30:14 -0700
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: [Ietf-caldav] comments on -02
Date: Mon, 11 Oct 2004 16:30:10 -0700
Message-ID: <1198328AFDBF5841B27E40C40C331537012AE609@df-chewy-msg.exchange.corp.microsoft.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
Thread-Index: AcSuhcHlVIm4b/zwQ7uWek12p1xQxgBYy+qw
From: "Cameron Stillion" <camerost@exchange.microsoft.com>
To: "Lyndon Nerenberg" <lyndon@orthanc.ca>, <TimHare@comcast.net>, <ietf-caldav@osafoundation.org>, <ietf-calsify@osafoundation.org>
X-OriginalArrivalTime: 11 Oct 2004 23:30:14.0437 (UTC) FILETIME=[42657550:01C4AFEA]
X-Scanned-By: MIMEDefang 2.45
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i9BNUIa9027843
X-Mailman-Approved-At: Mon, 11 Oct 2004 16:36:43 -0700
Cc:
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2004 23:30:26 -0000
I respectfully disagree. Leaving a standard "as open as possible" can
easily lead to such difficulties in interoperability as we have all
witnessed over the past several years. The idea for calsify, I believe,
is to actually curb the open-ended nature of iCal in favor of the more
practical bottom line: something that works for a subset that we really
really care about.
This is not uncommon in software development, it's just that iCal is
long due for such a refocus and simplification. It's not so much a
matter of Social Restrictions - it's just that the kinds of systems we
are creating have a general purpose to them, and it is centered around
creating calendars, sharing calendars, scheduling meetings, and other
simple day-to-day things. Aligning stellar cartography hardware and
synchronizing atomic clocks are most definitely on the ragged outer edge
of our target.
This is not to say we should paint ourselves into a corner in the most
fundamental ways, but it does mean we need to start small, get something
basic that we all can agree to, grow some real interoperability, and
THEN we can start tinkering with how to extend the standard to the
zillion other applications and possibilities.
As for your specific example -- "granularity", I can easily see a
property emerge in a future version of iCal that specified sub-15-minute
granularity. This would not break clients who didn't care (most of
them, IMHO) and would be easily read and interpreted by those who did.
Let's avoid getting wrapped around the axle of creating "the perfect
calendaring standard" - I'm just hoping we can get something simple that
kind of works without too much pain and suffering.
Cameron
-----Original Message-----
From: ietf-calsify-bounces@osafoundation.org
[mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Lyndon
Nerenberg
Sent: Saturday, October 09, 2004 9:57 PM
To: TimHare@comcast.net; ietf-caldav@osafoundation.org;
ietf-calsify@osafoundation.org
Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
--On 2004-10-6 10:25 PM -0400 TimHare@comcast.net wrote:
> my view is that we ought to establish a standard for the granularity
> of a free/busy time map (15 minutes would be my choice)
I disagree with this. Calendaring is much more than just scheduling
meetings (with people). I can see using iCal and friends to schedule
runtime on computing clusters, or access to radio astronomy telescopes,
or many other resources where fine-grained access times are appropriate.
We should not be placing any form of social restrictions on the
protocols like this. They must be left as open ended as possible so as
to preclude us having to revisit the specifications in the near term
because we didn't anticipate a use for them.
--lyndon
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
X-Envelope-From: gic-ietf-calsify@gmane.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9BNF3a9027242 for <ietf-calsify@osafoundation.org>; Mon, 11 Oct 2004 16:15:04 -0700
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CH9Nd-00063l-00 for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 01:15:01 +0200
Received: from corp-fw-main.jabber.com ([207.182.164.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 01:15:01 +0200
Received: from stpeter by corp-fw-main.jabber.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Tue, 12 Oct 2004 01:15:01 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calsify@osafoundation.org
From: Peter Saint-Andre <stpeter@jabber.org>
Date: Mon, 11 Oct 2004 17:14:52 -0600
Organization: Jabber Software Foundation
Lines: 30
Message-ID: <stpeter-557827.17145211102004@sea.gmane.org>
References: <stpeter-331D11.19382706102004@sea.gmane.org> <6.1.1.1.0.20041006222713.0285b490@mail.comcast.net>
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: corp-fw-main.jabber.com
User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X)
Sender: news <news@sea.gmane.org>
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] Re: XML format?
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2004 23:15:07 -0000
In article <6.1.1.1.0.20041006222713.0285b490@mail.comcast.net>,
TimHare@comcast.net wrote:
> Please look at:
> http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt
>
> Suggestions and opinions are appreciated.
In Section 8, you recommend using the HTTP URIs of the RFCs as XML
namespace names. This is potentially problematic (what happens when ther
are superseded?). I'd suggest XML namespace URIs in the
urn:ietf:params:xml:ns tree (RFC 3920 is a recent spec that uses these).
In Section 9, your media types are off -- "application/calendar+xml" is
more correct. http://www.xmpp.org/specs/rfc3923.html#iana has an example
of a recent content-type registration of this kind. When the time comes,
don't forget to run your definition by the friendly folks on the
ietf-types list: http://www.alvestrand.no/mailman/listinfo/ietf-types
In Section 11.1 you define a DTD. That's so old-fashioned -- all the
cool kids are using XML schema these days. ;-)
That's about as far as I got. It'll be great to have an XML format for
calendar objects!
Peter
P.S. Given some of the layout oddities, it seems that perhaps you did
not use the XML RFC format; http://xml.resource.org/ tells you how and
it is highly recommended!
X-Envelope-From: TimHare@comcast.net
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9ACv2a9007317; Sun, 10 Oct 2004 05:57:02 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc11) with SMTP id <2004101012565201100jtmqee> (Authid: TimHare); Sun, 10 Oct 2004 12:56:52 +0000
Message-Id: <6.1.1.1.0.20041010084709.028597b0@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Sun, 10 Oct 2004 08:50:55 -0400
To: Lyndon Nerenberg <lyndon@orthanc.ca>, ietf-caldav@osafoundation.org, ietf-calsify@osafoundation.org
From: TimHare@comcast.net
In-Reply-To: <B8CA5B4508B930F4CAA10314@d216-232-212-223.bchsia.telus.net >
References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchan ge.corp.microsoft.com> <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net> <B8CA5B4508B930F4CAA10314@d216-232-212-223.bchsia.telus.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.45
Cc:
Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Oct 2004 12:57:03 -0000
After several comments, I can see that exchanging a "bit map" of free/busy
time has definite downsides, so let's drop that idea.
Also, rather than continuing to cross-post I will put further discussion of
how to simplify free/busy work on the calsify list rather than caldav.
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: lyndon@orthanc.ca
Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9A4vIaA031952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2004 21:57:18 -0700
Received: from d216-232-212-223.bchsia.telus.net (d216-232-212-223.bchsia.telus.net [216.232.212.223]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i9A4v3uf087760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2004 22:57:09 -0600 (MDT)
Date: Sat, 09 Oct 2004 21:57:02 -0700
From: Lyndon Nerenberg <lyndon@orthanc.ca>
To: TimHare@comcast.net, ietf-caldav@osafoundation.org, ietf-calsify@osafoundation.org
Message-ID: <B8CA5B4508B930F4CAA10314@d216-232-212-223.bchsia.telus.net>
In-Reply-To: <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net>
References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchan ge.corp.microsoft.com> <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net>
X-Mailer: Mulberry/3.1.6 (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=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca
X-Scanned-By: MIMEDefang 2.45
Cc:
Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Oct 2004 04:57:19 -0000
--On 2004-10-6 10:25 PM -0400 TimHare@comcast.net wrote:
> my view is that we ought to establish a standard for the granularity
> of a free/busy time map (15 minutes would be my choice)
I disagree with this. Calendaring is much more than just scheduling
meetings (with people). I can see using iCal and friends to schedule
runtime on computing clusters, or access to radio astronomy telescopes,
or many other resources where fine-grained access times are
appropriate. We should not be placing any form of social restrictions
on the protocols like this. They must be left as open ended as possible
so as to preclude us having to revisit the specifications in the near
term because we didn't anticipate a use for them.
--lyndon
X-Envelope-From: Doug@Royer.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i984Go0f008907 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 7 Oct 2004 21:16:54 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i984Gix3028579 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Thu, 7 Oct 2004 21:16:46 -0700
Message-ID: <416614AC.6040400@Royer.com>
Date: Thu, 07 Oct 2004 22:16:44 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000306060902040204020406"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] Proposed TOC for new iCal-Basic draft
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Oct 2004 04:16:56 -0000
This is a cryptographically signed message in MIME format.
--------------ms000306060902040204020406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I took the TOC from 2445 and tweaked it.
I propose that we take 2445 and only change what we agree
needs to be changed and split out several of the objects as
noted below (This list does not include typo changes)
First collum key:
+----> 'R' = Remove - this section gets removed or tagged as deprecated.
|
|----> 'M' = Modify - Modify text for clarity.
|
|----> 'N' = New item - new section to be added.
|
|----> 'D' = Document in separate RFC.
|
| Proposed Table of Contents for iCal-Basic
|
V
1 Introduction
2 Basic Grammar and Conventions
2.1 Formatting Conventions
2.2 Related Memos
2.3 International Considerations
3 Registration Information
3.1 Content Type
3.2 Parameters
3.3 Content Header Fields
3.4 Encoding Considerations
3.5 Security Considerations
3.6 Interoperability Considerations
3.7 Applications Which Use This Media Type
3.8 Additional Information
3.9 Magic Numbers
3.10 File Extensions
3.11 Contact for Further Information:
3.12 Intended Usage
3.13 Authors/Change Controllers
4 iCalendar Object Specification
4.1 Content Lines
4.1.1 List and Field Separators
4.1.2 Multiple Values
4.1.3 Binary Content
4.1.4 Character Set
4.2 Property Parameters
4.2.1 Alternate Text Representation
4.2.2 Common Name
4.2.3 Calendar User Type
4.2.4 Delegators
4.2.5 Delegatees
4.2.6 Directory Entry Reference
4.2.7 Inline Encoding
4.2.8 Format Type
4.2.9 Free/Busy Time Type
4.2.10 Language
4.2.11 Group or List Membership
4.2.12 Participation Status
4.2.13 Recurrence Identifier Range
D 4.2.14 Alarm Trigger Relationship
(Document in VALARM RFC)
4.2.15 Relationship Type
4.2.16 Participation Role
4.2.17 RSVP Expectation
4.2.18 Sent By
4.2.19 Time Zone Identifier
4.2.20 Value Data Types
4.3 Property Value Data Types
4.3.1 Binary
4.3.2 Boolean
4.3.3 Calendar User Address
4.3.4 Date
4.3.5 Date-Time
4.3.6 Duration
4.3.7 Float
4.3.8 Integer
4.3.9 Period of Time
4.3.10 Recurrence Rule
4.3.11 Text
4.3.12 Time
4.3.13 URI
4.3.14 UTC Offset
4.4 iCalendar Object
4.5 Property
4.6 Calendar Components
4.6.1 Event Component
D 4.6.2 To-do Component
(Document in VTODO RFC)
D 4.6.3 Journal Component
(Document in VJOURNAL RFC)
4.6.4 Free/Busy Component
4.6.5 Time Zone Component
D 4.6.6 Alarm Component
(Document in VALARM RFC)
4.7 Calendar Properties
4.7.1 Calendar Scale
4.7.2 Method
4.7.3 Product Identifier
4.7.4 Version
4.8 Component Properties
4.8.1 Descriptive Component Properties
4.8.1.1 Attachment
4.8.1.2 Categories
4.8.1.3 Classification
4.8.1.4 Comment
4.8.1.5 Description
R 4.8.1.6 Geographic Position
(Delete this property - tag it as deprecated in iCal-Basic)
4.8.1.7 Location
4.8.1.8 Percent Complete
4.8.1.9 Priority
4.8.1.10 Resources
4.8.1.11 Status
4.8.1.12 Summary
4.8.2 Date and Time Component Properties
4.8.2.1 Date/Time Completed
4.8.2.2 Date/Time End
4.8.2.3 Date/Time Due
4.8.2.4 Date/Time Start
4.8.2.5 Duration
4.8.2.6 Free/Busy Time
4.8.2.7 Time Transparency
4.8.3 Time Zone Component Properties
4.8.3.1 Time Zone Identifier
4.8.3.2 Time Zone Name
4.8.3.3 Time Zone Offset From
4.8.3.4 Time Zone Offset To
4.8.3.5 Time Zone URL
4.8.4 Relationship Component Properties
4.8.4.1 Attendee
4.8.4.2 Contact
4.8.4.3 Organizer
4.8.4.4 Recurrence ID
R 4.8.4.5 Related To
(Delete this property - tag it as deprecated - in
iCal-Basic)
4.8.4.6 Uniform Resource Locator
4.8.4.7 Unique Identifier
4.8.5 Recurrence Component Properties
4.8.5.1 Exception Date/Times
4.8.5.2 Exception Rule
4.8.5.3 Recurrence Date/Times
4.8.5.4 Recurrence Rule
D 4.8.6 Alarm Component Properties
D 4.8.6.1 Action
D 4.8.6.2 Repeat Count
D 4.8.6.3 Trigger
(Document the above in VALARM RFC)
4.8.7 Change Management Component Properties
4.8.7.1 Date/Time Created
4.8.7.2 Date/Time Stamp
4.8.7.3 Last Modified
4.8.7.4 Sequence Number
4.8.8 Miscellaneous Component Properties
4.8.8.1 Non-standard Properties
4.8.8.2 Request Status
5 iCalendar Object Examples
6 Recommended Practices
7 Registration of Content Type Elements
7.1 Registration of New and Modified iCalendar Object
Methods ..141
7.2 Registration of New Properties
7.2.1 Define the property
7.2.2 Post the Property definition
7.2.3 Allow a comment period
7.2.4 Submit the property for approval
7.3 Property Change Control
N x.x.x.x EXTENSIONS property
(Document in iCal-Basic RFC)
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)520-4044
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms000306060902040204020406
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
9w0BCQUxDxcNMDQxMDA4MDQxNjQ0WjAjBgkqhkiG9w0BCQQxFgQURBYQg6HkuceJ+dUgSZ8K
ErkkR1MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAM0CV7zxFH0EXaslJarfHRLFvH0vfdMX2bk+GC6wIdKb75i6CthCsVzrgvsB5vFec
hgt6B+uSfG9uzp6wzGxaeZXJDaZWZppKkvH5DdDLtPl35j7qh79BWF37nRbDjGoyyyJr1R2u
sCosE4IEz+HsSiVbwnVf1ikm0i5JLIglI1oWVSJ3Pl4f6BypKWIk0eJcLL7Y3e2D79oKi/63
H81aIA/o+y1C4/xCc6odZRPVyRuB5beI1oZRPfe8U+r3jLBLSU/oBnWPNUImcowl63MvKPiK
0AUyHIgEsA49jDCZLVpnXIH1udZujkkovVWmK8u3giVF8/KaPE1kFlIdlcWx2AAAAAAAAA==
--------------ms000306060902040204020406--
X-Envelope-From: Doug@Royer.com
Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i97HaF0f018432 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 7 Oct 2004 10:36:16 -0700
Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i97HaBx3015166 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 7 Oct 2004 10:36:12 -0700
Message-ID: <41657E8A.7030505@Royer.com>
Date: Thu, 07 Oct 2004 11:36:10 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify@osafoundation.org, ietf-caldav@osafoundation.org
References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchange.corp.microsoft.com> <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net> <2AC2E790-1813-11D9-9014-000A95B2BB72@osafoundation.org>
In-Reply-To: <2AC2E790-1813-11D9-9014-000A95B2BB72@osafoundation.org>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070409010101090702000600"
X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Cc:
Subject: [Ietf-calsify] Re: [Ietf-caldav] comments on -02
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ietf-calsify@osafoundation.org
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2004 17:36:17 -0000
This is a cryptographically signed message in MIME format.
--------------ms070409010101090702000600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lisa Dusseault wrote:
> I don't see why a bit map has any advantages over a free busy summary
> with begin/end times for each busy blocks. And the begin/end
> timestamps have some advantages: they're human-readable (or at least
> developer/debugger readable), and don't require us to choose an
> arbitrary maximum granularity (why fifteen minutes? why not five?
> one? Can I negotiate granularity?).
I agree. VFREEBUSY is already in effect a bit map represented in ASCII.
>
> ...
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)520-4044
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--------------ms070409010101090702000600
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
9w0BCQUxDxcNMDQxMDA3MTczNjEwWjAjBgkqhkiG9w0BCQQxFgQUChGRjx7FJktRKPkrufe+
YZKlr4gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAbE42ROKZXxC7oRjBZBSNc3plr+xmNU8A25O8I2aPdJg5W8VXCIQKlLyVY2OgUoAT
c32pjxL0ubJHSFwmpAl7v0yydxvhpIf3mVsxqjy3dMeA6w7PLQkSqwoMF2cok5lYDgsl/ykX
HqyoTxcvyRQGdyGDBT8zTM0VLP0sTdGFwJHNoqD8zXHVL4YeVhbUTX2NRETAgjAyYSeLHxzz
VNYj5Uo59cFj5BqBdUKVvqSfZwHg6UULkP8+fa4Iqpv7hfVBSbiwJB8DS7dXS9Quo6dfCgl1
GrSwqbkOWZNE6lkV/2GQp5pFxGGnF490z5NdQ45nRhlvnI05xp1B5x5b39PeswAAAAAAAA==
--------------ms070409010101090702000600--
X-Envelope-From: lisa@osafoundation.org
Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i973iR0f008870 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 6 Oct 2004 20:44:30 -0700
In-Reply-To: <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net>
References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchange.corp.microsoft.com> <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2AC2E790-1813-11D9-9014-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 6 Oct 2004 20:44:18 -0700
To: TimHare@comcast.net
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.45
Cc: ietf-calsify@osafoundation.org, ietf-caldav@osafoundation.org
Subject: [Ietf-calsify] Re: [Ietf-caldav] comments on -02
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2004 03:44:32 -0000
I don't see why a bit map has any advantages over a free busy summary
with begin/end times for each busy blocks. And the begin/end
timestamps have some advantages: they're human-readable (or at least
developer/debugger readable), and don't require us to choose an
arbitrary maximum granularity (why fifteen minutes? why not five? one?
Can I negotiate granularity?).
The calendar agent can always translate begin/end times into a bitmap
for summarization -- that's implementation-dependent.
I have a prejudice against binary formats, too :)
Lisa
On Oct 6, 2004, at 7:25 PM, TimHare@comcast.net wrote:
> Free/Busy is a property of the user/owner of the calendar more than
> anything else; in essence I really want a logical AND of all of my
> free/busy time so that none of my events, personal or business, get
> overbooked. In iCalendar, however, we have to represent those at the
> VCALENDAR level. I am cross-posting this to the calsify list, because
> it really belongs there - my view is that we ought to establish a
> standard for the granularity of a free/busy time map (15 minutes would
> be my choice), and then just exchange a "bit map" of the time between
> two dates that are requested as the endpoints - call it a VBUSYMAP
> deliverable as other binary objects are, in Base64. Then, scheduling
> a meeting might go something like this:
>
> Organizer to each attendee: Show me your free/busy map between date X
> and date Y.
> Each attendee: here is the VBUSYMAP of my time
> Organizer then finds (hopefully) a time when all are free, and sends
> out meeting requests for that time;or, finding no acceptable time,
> picks two different dates and tries again.
>
> This, to me, simplifies and shortens the scheduling process. Your code
> doesn't have to parse all of the VFREEBUSY items. In fact, an
> implementation can choose to maintain the map in whatever backing
> store it uses, and keep it updated as VEVENTS are added or removed.
>
> At 08:36 PM 10/6/04, Cameron Stillion wrote:
>> But if you don't want to be scheduled, that means you want the time to
>> appear as if you are "scheduled" already... Right? You can do this
>> now
>> by putting an appointment on your calendar marked as "OOF" - and the
>> free/busy view of this event will clearly mark this as already taken.
>>
>> Having someone schedule you on Saturday or Sunday is really a social
>> problem though. If it is your wife, it makes sense. If it's your
>> co-worker, then there are social checks and balances that say this
>> won't
>> happen if it isn't appropriate. The protocol is not meant to solve
>> the
>> social aspect. Clearly good software would keep this in mind and help
>> you do the right thing, but it can't know all the human
>> implications...
>>
>> I still stand by the fact that free/busy is merely a translation of
>> events, and that anything else is unnecessarily complex with really no
>> benefit - to the standard most especially, but even more to
>> applications
>> and systems.
>>
>>
>> cameron
>>
>>
>> -----Original Message-----
>> From: ietf-caldav-bounces@osafoundation.org
>> [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of G. Barnes
>> Sent: Wednesday, October 06, 2004 10:26 AM
>> To: ietf-caldav@osafoundation.org
>> Subject: Re: [Ietf-caldav] comments on -02
>>
>> On Wed, 6 Oct 2004, Lisa Dusseault wrote:
>>
>> > I could go either way on allowing users to store standalone
>> VFREEBUSY
>> > components. Keeping it is a small feature/flexibility; removing it
>> is
>>
>> > a small simplification. Who else has use cases or problems with
>> > keeping or removing that feature?
>>
>> I have a problem with removing it. I want to be able to say, 'no one
>> can schedule me on Saturday or Sunday' (among other times). Othewise,
>> some jerk is going to schedule a mandatory meeting at 7am Saturday.
>> Creating a VEVENT would presumably mean something shows up in my
>> calendar.
>> But I don't necessarily have an event scheduled; I just want to be
>> left
>> alone. The most obvious way to do this is to create a standalone
>> VFREEBUSY.
>>
>> Greg Barnes
>> Computing and Communications, University of
>> Washington
>> gsbarnes@washington.edu
>> (206) 685-3295
>> _______________________________________________
>> Ietf-caldav mailing list
>> Ietf-caldav@osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>>
>> _______________________________________________
>> Ietf-caldav mailing list
>> Ietf-caldav@osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> _______________________________________________
> Ietf-caldav mailing list
> Ietf-caldav@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
X-Envelope-From: gic-ietf-calsify@gmane.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i972ov0e004966 for <ietf-calsify@osafoundation.org>; Wed, 6 Oct 2004 19:50:57 -0700
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CFOMq-0000HI-00 for <ietf-calsify@osafoundation.org>; Thu, 07 Oct 2004 04:50:56 +0200
Received: from 64.221.254.66.ptr.us.xo.net ([64.221.254.66]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Thu, 07 Oct 2004 04:50:56 +0200
Received: from stpeter by 64.221.254.66.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Thu, 07 Oct 2004 04:50:56 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calsify@osafoundation.org
From: Peter Saint-Andre <stpeter@jabber.org>
Date: Wed, 06 Oct 2004 20:45:55 -0600
Organization: Jabber Software Foundation
Lines: 9
Message-ID: <stpeter-FCA11A.20455506102004@sea.gmane.org>
References: <stpeter-331D11.19382706102004@sea.gmane.org> <6.1.1.1.0.20041006222713.0285b490@mail.comcast.net>
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 64.221.254.66.ptr.us.xo.net
User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X)
Sender: news <news@sea.gmane.org>
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] Re: XML format?
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2004 02:50:58 -0000
In article <6.1.1.1.0.20041006222713.0285b490@mail.comcast.net>,
TimHare@comcast.net wrote:
> Please look at:
> http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt
Thanks, I'll have a look at that.
/psa
X-Envelope-From: TimHare@comcast.net
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i972X40e003259 for <ietf-calsify@osafoundation.org>; Wed, 6 Oct 2004 19:33:04 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <2004100702325801300c4a5te> (Authid: TimHare); Thu, 7 Oct 2004 02:32:58 +0000
Message-Id: <6.1.1.1.0.20041006222713.0285b490@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 06 Oct 2004 22:27:37 -0400
To: Peter Saint-Andre <stpeter@jabber.org>, ietf-calsify@osafoundation.org
From: TimHare@comcast.net
Subject: Re: [Ietf-calsify] XML format?
In-Reply-To: <stpeter-331D11.19382706102004@sea.gmane.org>
References: <stpeter-331D11.19382706102004@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.45
Cc:
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2004 02:33:05 -0000
Please look at: http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt
Suggestions and opinions are appreciated.
At 09:38 PM 10/6/04, Peter Saint-Andre wrote:
>Is anyone thinking about doing an XML format for calendaring and
>scheduling data?
>
>Peter
>
>_______________________________________________
>Ietf-calsify mailing list
>Ietf-calsify@osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: TimHare@comcast.net
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 i972Ua0e003061; Wed, 6 Oct 2004 19:30:36 -0700
Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc13) with SMTP id <200410070230290150037l8he> (Authid: TimHare); Thu, 7 Oct 2004 02:30:30 +0000
Message-Id: <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 06 Oct 2004 22:25:15 -0400
To: <ietf-caldav@osafoundation.org>, ietf-calsify@osafoundation.org
From: TimHare@comcast.net
In-Reply-To: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exch ange.corp.microsoft.com>
References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchange.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.45
Cc:
Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2004 02:30:36 -0000
Free/Busy is a property of the user/owner of the calendar more than
anything else; in essence I really want a logical AND of all of my
free/busy time so that none of my events, personal or business, get
overbooked. In iCalendar, however, we have to represent those at the
VCALENDAR level. I am cross-posting this to the calsify list, because it
really belongs there - my view is that we ought to establish a standard for
the granularity of a free/busy time map (15 minutes would be my choice),
and then just exchange a "bit map" of the time between two dates that are
requested as the endpoints - call it a VBUSYMAP deliverable as other binary
objects are, in Base64. Then, scheduling a meeting might go something like
this:
Organizer to each attendee: Show me your free/busy map between date X and
date Y.
Each attendee: here is the VBUSYMAP of my time
Organizer then finds (hopefully) a time when all are free, and sends out
meeting requests for that time;or, finding no acceptable time, picks two
different dates and tries again.
This, to me, simplifies and shortens the scheduling process. Your code
doesn't have to parse all of the VFREEBUSY items. In fact, an
implementation can choose to maintain the map in whatever backing store it
uses, and keep it updated as VEVENTS are added or removed.
At 08:36 PM 10/6/04, Cameron Stillion wrote:
>But if you don't want to be scheduled, that means you want the time to
>appear as if you are "scheduled" already... Right? You can do this now
>by putting an appointment on your calendar marked as "OOF" - and the
>free/busy view of this event will clearly mark this as already taken.
>
>Having someone schedule you on Saturday or Sunday is really a social
>problem though. If it is your wife, it makes sense. If it's your
>co-worker, then there are social checks and balances that say this won't
>happen if it isn't appropriate. The protocol is not meant to solve the
>social aspect. Clearly good software would keep this in mind and help
>you do the right thing, but it can't know all the human implications...
>
>I still stand by the fact that free/busy is merely a translation of
>events, and that anything else is unnecessarily complex with really no
>benefit - to the standard most especially, but even more to applications
>and systems.
>
>
>cameron
>
>
>-----Original Message-----
>From: ietf-caldav-bounces@osafoundation.org
>[mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of G. Barnes
>Sent: Wednesday, October 06, 2004 10:26 AM
>To: ietf-caldav@osafoundation.org
>Subject: Re: [Ietf-caldav] comments on -02
>
>On Wed, 6 Oct 2004, Lisa Dusseault wrote:
>
> > I could go either way on allowing users to store standalone VFREEBUSY
> > components. Keeping it is a small feature/flexibility; removing it is
>
> > a small simplification. Who else has use cases or problems with
> > keeping or removing that feature?
>
>I have a problem with removing it. I want to be able to say, 'no one
>can schedule me on Saturday or Sunday' (among other times). Othewise,
>some jerk is going to schedule a mandatory meeting at 7am Saturday.
>Creating a VEVENT would presumably mean something shows up in my
>calendar.
>But I don't necessarily have an event scheduled; I just want to be left
>alone. The most obvious way to do this is to create a standalone
>VFREEBUSY.
>
> Greg Barnes
> Computing and Communications, University of
>Washington
> gsbarnes@washington.edu
> (206) 685-3295
>_______________________________________________
>Ietf-caldav mailing list
>Ietf-caldav@osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
>_______________________________________________
>Ietf-caldav mailing list
>Ietf-caldav@osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Tim Hare
Interested Bystander, Non-Inc.
X-Envelope-From: gic-ietf-calsify@gmane.org
X-Envelope-To: <ietf-calsify@osafoundation.org>
Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i971ov0e001405 for <ietf-calsify@osafoundation.org>; Wed, 6 Oct 2004 18:50:58 -0700
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CFNQm-0007Ux-00 for <ietf-calsify@osafoundation.org>; Thu, 07 Oct 2004 03:50:56 +0200
Received: from 64.221.254.66.ptr.us.xo.net ([64.221.254.66]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Thu, 07 Oct 2004 03:50:56 +0200
Received: from stpeter by 64.221.254.66.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Thu, 07 Oct 2004 03:50:56 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calsify@osafoundation.org
From: Peter Saint-Andre <stpeter@jabber.org>
Date: Wed, 06 Oct 2004 19:38:27 -0600
Organization: Jabber Software Foundation
Lines: 4
Message-ID: <stpeter-331D11.19382706102004@sea.gmane.org>
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 64.221.254.66.ptr.us.xo.net
User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X)
Sender: news <news@sea.gmane.org>
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] XML format?
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2004 01:50:59 -0000
Is anyone thinking about doing an XML format for calendaring and
scheduling data?
Peter
X-Envelope-From: nsb@guppylake.com
X-Envelope-To: <ietf-calsify@osafoundation.org>
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 i92GV0Bl022473 for <ietf-calsify@osafoundation.org>; Sat, 2 Oct 2004 09:31:00 -0700
Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A159128201B2; Sat, 02 Oct 2004 09:03:37 -0700
In-Reply-To: <6.1.1.1.0.20040930232831.02800b10@mail.comcast.net>
References: <6.1.1.1.0.20040915234911.0285ceb0@mail.comcast.net> <79C6C498B45768C10B17CB96@ninevah.local> <6.1.1.1.0.20040916215859.028555a0@mail.comcast.net> <0F420E4F-0A4C-11D9-A373-000D93C1A604@opengroupware.org> <81119E9C-1304-11D9-BA5F-000A9571873E@guppylake.com> <51EF9288-1306-11D9-8ED1-000D93C1A604@opengroupware.org> <415C542E.1020809@Royer.com> <6.1.1.1.0.20040930232831.02800b10@mail.comcast.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6D135A7B-1490-11D9-BA5F-000A9571873E@guppylake.com>
Content-Transfer-Encoding: 7bit
From: Nathaniel Borenstein <nsb@guppylake.com>
Subject: Re: [Ietf-calsify] UTC
Date: Sat, 2 Oct 2004 12:30:52 -0400
To: TimHare@comcast.net
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.39
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
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:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Oct 2004 16:31:01 -0000
Tim -- I'm actually not at all inclined to give up on recurrence
altogether. I just think we've been doing it almost altogether wrong.
I apologize for not expressing myself as clearly as I might have liked,
but my thoughts have been crystalizing quite slowly -- probably my age.
Let me try to summarize my current (and tentative) thinking:
1. "Recurrence" is an infinitely complex concept. Any language that
could express all desirable recurrences would be too complex to
implement, let alone standardize.
2. Although there are some kinds of recurrence we can all agree are
highly valuable (e.g. weekly meetings), there is no simple strategy by
which to encapsulate a single set of things that some or most of us
would find useful. In other words, there is a potential for unbounded
frustration and argument in defining the "edge cases" of a set of
"universally important" recurrence rules.
3. We should therefore give up on the concept of a single, special,
"privileged" language for repeat events, such as the current RRULE.
4. Instead, we need a framework for an extensible set of recurrence
rule languages (RRL's). I predict most RRL's will actually be quite
simple, targeting very specific purposes. (The UNIX "cron" format
comes to mind as a very useful "level-zero" RRL.) I'm not sure if it
will be possible, but it would be really nice if some RRL's could be
timezone-smart without requiring the basic protocol to be
timezone-smart. (<Rathole-provocation> Would it really hurt if an
event that was scheduled for "every Tuesday at 9" was
timezone-agnostic? Isn't it the case that for a virtual meeting across
time zones, people are going to either doublecheck or assume the
timezone in which the meeting is based, which is often "out of band"
knowledge from a protocol perspective?</rathole-provocation>)
5. The hardest part, if we do this, will be handling communication
between heterogeneous calendaring agents with disjoint RRL sets that
they support. I can see two main ways to approach this problem:
-- Always send dual representation with a lowest-common-denominator
lingua franca. This is the essence of the "always send a set,
optionally send a rule" proposal that I have floated in the past. It
is also the fundamental motivation for "multipart/alternative" in MIME
-- avoid format negotiations by always sending a dumbed-down form of
the data. The primary downsides are less efficient data
representations (which certainly doesn't seem to have hurt email), and
no universal representation of (the philosophically dubious but
emotionally comforting concept of) infinitely recurring events.
-- Allow servers to translate RRL's that clients don't understand.
This would be relatively easy for CAP/CALDAV -- it could be done like
ESMTP negotiation, and it would be the server's responsibility to
provide something that the client says it can understand. It's more
challenging for mail/IMIP, but I could imagine extending the
functionality of the SMTP/iMIP receiver to notice unrecognized rule
languages and locate a rule translation server. The latter could be
any CAP/CALDAV server that understood the right rule languages.
I don't know how much of this we have the appetite to bite off,
particularly at first, but I sure do like the idea of separating
recurrence from the rest of the spec. I think that our primary goal
should be to facilitate evolution: make the simple things work, with an
extension mechanism for gradually tackling more and more of the hard
cases. An extensible set of RRL's would be one way to accomplish that.
There may be others. -- Nathaniel
On Sep 30, 2004, at 11:50 PM, TimHare@comcast.net wrote:
> I'd hate to give up the idea of some form of recurrence too easily.
> For the most common use cases - like weekly and monthly events -
> recurrence is a convenient and efficient shorthand. Perhaps we can
> adopt the following simplifications:
>
> 1. All components exchanged or published use UTC for date/time
> properties.
> 2. A new component is defined, VRECUR (or a better name) is defined
> for use only locally, which has simple properties for recurring
> events.
> 3. VRECUR does not allow infinite repetition
> 4. Components have a recurrence ID (RID - something I think was
> proposed before?) which can be null.
> 4. VRECUR dates and times use floating time to eliminate daylight
> savings time problems.
> 5. When exchanging VRECUR components, send the VRECUR with RID and
> beginning time converted to UTC, then convert to VEVENT/VTODO/etc. and
> UTC and send those, with the same RID.
> 6. Recipients can accept and store the VRECUR if capable, and ignore
> the events with that RID, or ignore the VRECUR and accept the events.
> 7. "Exchanging" also applies to publishing to a file.
>
> This is a minor amount of overhead compared to just exchanging the
> individual events, yet allows both ends to use the more compact way of
> storing the recurring events if desired. It leaves conversion from
> UTC to local time as a presentation problem. We would still have to
> define the "simple properties" for VRECUR. I think we would need to
> concentrate on the few use cases which are used by the majority of
> people. There's probably an 80/20 rule there somewhere. Does anyone
> have a way to gather statistics on recurrence definitions? For
> example, where I work we use Notes and I'd bet 80% of recurrence is
> "weekly".
>
> If this seems like it's not solving the problem or introducing new
> ones, then I'd agree to "just UTC with no RRULEs in the base spec",
> and putting RRULEs elsewhere.
>
>
> At 02:45 PM 9/30/04, Doug Royer wrote:
>
>
>> Helge Hess wrote:
>>
>>>
>>> As mentioned before this issue might be resolved by putting rrules
>>> into an extension to a core spec, so that we have a base spec which
>>> only requires UTC which of course would be a huge simplification.
>>
>> I agree. For protocols like CAP and CalDAV, that works. For iMIP
>> there may be
>> no way in advance to know if the recipient will ignore or understand
>> any extensions.
>>
>> So I think that the base set needs to be 100% compatible at the iMIP
>> level.
>>
>> Perhaps we need to add an optional property that can be added to iCAL
>> objects
>> that indicate the extensions supported by the sender. Then the
>> recipient
>> will know how it can reply. And then the recipient also includes this
>> extension property so then the originator may then track which
>> recipient
>> supports which features. Such as:
>>
>> EXTENSIONS: XXXX,YYYY,ZZZZ
>>
>> where XXXX, YYYY, and ZZZZ are RFC numbers that describe extensions.
>> This would be placed in the VCALENDAR objects. Then the recipient
>> of the object would know that the sender supports RFC-XXXX, RFC-YYYY,
>> and RFC-ZZZZ extensions.
>>
>> Vendor specific extensions could be handled with a vendor specific
>> property such as X-EXTENSIONS that could follow the vendor
>> specifications.
>>
>> If the EXTENSIONS property is absent, then the sender only supports
>> RFC-'calsify-basic' which I think needs to be compatible with iCAL
>> and would not include the rrule properties.
>>
>> --
>>
>> Doug Royer | http://INET-Consulting.com
>> -------------------------------|-----------------------------
>> Doug@Royer.com | Office: (208)520-4044
>> http://Royer.com/People/Doug | Fax: (866)594-8574
>> | Cell: (208)520-4044
>>
>> We Do Standards - You Need Standards
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> Ietf-calsify@osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>