X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from rgminet02.oracle.com (rgminet02.oracle.com [148.87.122.31]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3SEqjaa002858 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 28 Apr 2005 07:52:45 -0700 Received: from rgminet02.oracle.com (localhost [127.0.0.1]) by rgminet02.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j3SEqbc1026479 for ; Thu, 28 Apr 2005 08:52:37 -0600 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet02.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j3SEqa1i026446 for ; Thu, 28 Apr 2005 08:52:36 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j3SEqa1W005922 for ; Thu, 28 Apr 2005 08:52:36 -0600 Received: from [144.23.219.129] (dhcp-ca-montreal-144-23-219-129.ca.oracle.com [144.23.219.129]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j3SEqQv4005879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 28 Apr 2005 08:52:27 -0600 Message-ID: <4270F8A3.5030005@oracle.com> Date: Thu, 28 Apr 2005 10:52:19 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] 3.3 Timezones References: <426EE74B.90403@Royer.com> <426FD354.7070900@oracle.com> <426FEE80.70802@Royer.com> In-Reply-To: <426FEE80.70802@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 14:52:46 -0000 As can be read in "Comment.2" of the same section, this is still an open issue. 3.3 Timezones Calendar resources in CalDAV MUST be valid iCalendar objects. As such, an individual VTIMEZONE calendar component MUST be specified for each unique TZID parameter value specified in an iCalendar object. Unfortunately this mean that the same VTIMEZONE component will get sent or retrieved multiple times for each iCalendar object that uses the timezone. This is not efficient in terms of bandwidth usage. [[Comment.2: Not clear how big an issue that really is. CalDAV already allows clients to retrieve iCalendar objects without their VTIMEZONE component with the CALDAV:calendar-query REPORT. It is still not clear whether a client could rely only on the value of the TZID parameter, or should it always requests a VTIMEZONE component with at least the TZID and TZURL properties and rely on the TZURL as a unique identifier for a given time zone. CalDAV servers have no choice but to return complete VTIMEZONE components in iCalendar object retrieve with the GET method as their is no way to know if the client is a CalDAV client or a simple HTTP client. On a PUT request perhaps a CalDAV server could accept an iCalendar object with a VTIMEZONE object that has at least TZURL that points to a calendar resource that defines a time zone on the server. --desruisseaux]] "There is never any justification for compromising correctness for the sake of other concerns such as efficiency." -- Bertrand Meyer CalDAV MUST always return valid iCalendar objects retrieved with the GET method, that is, with complete VTIMEZONE components when necessary. With the CALDAV:calendar-query REPORT CalDAV clients are able to partially retrieve iCalendar objects, as such, clients may retrieve iCalendar objects without their VTIMEZONE component(s). The draft will need to specify what the CalDAV client may assume about the returned TZID if anything (e.g., they can rely on them if they are prefix with "/" or they can never rely on them). When a CalDAV client creates or update an iCalendar object with the PUT method it should provide the complete VTIMEZONE component. The draft will need to specify whether clients are allowed to submit iCalendar objects with TZID parameter value specified but no corresponding VTIMEZONE component(s) (e.g., yes if the TZID is prefixed by "/" or no otherwise) or whether clients should at least provide a VTIMEZONE component for each TZID parameter value specified in the iCalendar object, but allow them to only specify a TZURL property pointing to a VTIMEZONE component stored in the timezone collection set of the CalDAV server instead of providing the full definition. I personally don't think that all this added complexity is required. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald E. Knuth Cheers, Bernard Doug Royer wrote: > > Later in that same section it says: > > The timezone collection is a calendar collection that contains only > VTIMEZONE components as separate resources within that collection. > > So when I read it, it looks to me as if that does not sufficiently > solve the problem. > > I read it as saying that multiple VEVENTs can point to a single > TZID in a timezone collection? If yes, then without a smart compare > function it must not be used for externally created VEVENTS. > As you could not guarantee that Vendor-A TZID-X was the > same as TZID-X in the timezone collection. > > An later in the draft it says: > > > o any top-level component that references a timezone via a "TZID" > > property MUST include the VTIMEZONE component corresponding to > > that timezone id, as required by iCalendar, unless the timezone is > > one included in the server's timezone collection, as described in > > Section 3.3. > > > > For example, given the following iCalendar object: > > Followed by an example that does not have a TZID or VTIMEZONE. > > So, what is that saying? Is it saying that if a TZID is included > and no such VTIMEZONE is included, go fetch it? > > Or as the example shows, must you use UTC? > > Or is it saying something else ? > > > Bernard Desruisseaux wrote: > >> Doug Royer wrote: >> >>> >>> -05 says in part: >>> >>> > 3.3 Timezones >>> > >>> Its more complicated than that. It would need to be one VTIMEZONE >>> component per unique VTIMEZONE definition. >>> >>> Without standardized TZID's, there is no guarantee that TZID-X >>> is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE. >> >> >> >> The sentence « an individual "VTIMEZONE" calendar component MUST be >> specified for each unique "TZID" parameter value specified in the >> iCalendar object » was copied verbatim from section 4.2.19 Time Zone >> Identifier of RFC 2445. > > > Which does not have a separate VTIMEZONE container. So it can't have > a conflict. > >> While I understand what you are trying to say, this sentence is >> only making reference to "an iCalendar object". I can't believe >> a single iCalendar object would be making reference to multiple >> VTIMEZONE definitions with a single TZID. > > > > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3S0iZaa009654 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Wed, 27 Apr 2005 17:44:36 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3S0iQIm024661 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 27 Apr 2005 17:44:29 -0700 Message-ID: <427031EA.3030605@Royer.com> Date: Wed, 27 Apr 2005 18:44:26 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020504080502010002060701" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Have you seen this - WebDAV / CalDAVpatent issue ? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 00:44:39 -0000 This is a cryptographically signed message in MIME format. --------------ms020504080502010002060701 Content-Type: multipart/mixed; boundary="------------090007030706060703030908" This is a multi-part message in MIME format. --------------090007030706060703030908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable http://www.frntln.com/Patent.htm I have nothing to do with it! They do XML tools of some kind. April 2003 - Frontline Solutions is proud to announce our patent award: "Method and System for Allowing Multiple Users to Edit a Hierarchical=20 Data Structure" Patent No.: US 6,529,905 B1 Abstract: A method for locking elements of a hierarchical data structure to allow=20 multiple users at various distributed clients to simultaneously edit=20 unlocked portions of the data structure, and systems. The method=20 includes check for permission, setting and releasing various kind of=20 locks. The structured authoring systems of the invention may be=20 distributed and collaborative. The process of checking for permission=20 to set a lock is unique for each type of lock. Frontline Solutions strives for innovative and technically advanced=20 approaches in our software products. Our software program Procura=99 i= s=20 based on this patented technology. --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------090007030706060703030908 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------090007030706060703030908-- --------------ms020504080502010002060701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BCQUxDxcNMDUwNDI4MDA0NDI2WjAjBgkqhkiG9w0BCQQxFgQUWa3N9UWAQ44vIoQUpzJg vzSEdYowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAZFuH38v8qtxrgvNoKNjieDnPnbViyClR80SR2d6E7hey2xEcuXNi91cp04gGjg0Q AKjitrtOiQ/7CzHlPzd2/L8VV4RIw4MyXbrtUtqMstGolwihDzx6UJbkKVRKZ1yc0bxMawLw 7ATT8RsRbSgK6AGSt/bPuPITUE724VmaESajviIFiY344FbQ/SxWqmdCvW9i0p6kor/TWhhI 3/83XaHreW1e8UdnTzA47WT/Kqo6Y0M2uif5eQGBKWdWKBmsprHBG0qeGglQYtm4vYBhVo/a YtdyHDs75TglOsJy5Xkg/mzp+4o4zp3l3V5345cInGupYoLboDZyuOSvqzrrvQAAAAAAAA== --------------ms020504080502010002060701-- X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3RJuvaa029215 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Wed, 27 Apr 2005 12:56:59 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3RJunMf020030 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 27 Apr 2005 12:56:50 -0700 Message-ID: <426FEE80.70802@Royer.com> Date: Wed, 27 Apr 2005 13:56:48 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] 3.3 Timezones References: <426EE74B.90403@Royer.com> <426FD354.7070900@oracle.com> In-Reply-To: <426FD354.7070900@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000603070803090301000902" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: CalDAV DevList List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 19:57:03 -0000 This is a cryptographically signed message in MIME format. --------------ms000603070803090301000902 Content-Type: multipart/mixed; boundary="------------040006000307030107020407" This is a multi-part message in MIME format. --------------040006000307030107020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Later in that same section it says: The timezone collection is a calendar collection that contains only VTIMEZONE components as separate resources within that collection. So when I read it, it looks to me as if that does not sufficiently solve the problem. I read it as saying that multiple VEVENTs can point to a single TZID in a timezone collection? If yes, then without a smart compare function it must not be used for externally created VEVENTS. As you could not guarantee that Vendor-A TZID-X was the same as TZID-X in the timezone collection. An later in the draft it says: > o any top-level component that references a timezone via a "TZID" > property MUST include the VTIMEZONE component corresponding to > that timezone id, as required by iCalendar, unless the timezone is= > one included in the server's timezone collection, as described in > Section 3.3. > > For example, given the following iCalendar object: Followed by an example that does not have a TZID or VTIMEZONE. So, what is that saying? Is it saying that if a TZID is included and no such VTIMEZONE is included, go fetch it? Or as the example shows, must you use UTC? Or is it saying something else ? Bernard Desruisseaux wrote: > Doug Royer wrote: >=20 >> >> -05 says in part: >> >> > 3.3 Timezones >> > >> Its more complicated than that. It would need to be one VTIMEZONE >> component per unique VTIMEZONE definition. >> >> Without standardized TZID's, there is no guarantee that TZID-X >> is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE. >=20 >=20 > The sentence =AB an individual "VTIMEZONE" calendar component MUST be > specified for each unique "TZID" parameter value specified in the > iCalendar object =BB was copied verbatim from section 4.2.19 Time Zone > Identifier of RFC 2445. Which does not have a separate VTIMEZONE container. So it can't have a conflict. > While I understand what you are trying to say, this sentence is > only making reference to "an iCalendar object". I can't believe > a single iCalendar object would be making reference to multiple > VTIMEZONE definitions with a single TZID. --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040006000307030107020407 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------040006000307030107020407-- --------------ms000603070803090301000902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BCQUxDxcNMDUwNDI3MTk1NjQ4WjAjBgkqhkiG9w0BCQQxFgQUArrZ2dya1v4Hmr9PG8fi 2iT67/EwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAd8kYSfp5czXcUcBuoGMlBIBScGBPUCQx1612ejjeU5vY7NriffZKcfaTV8VlujsP g/EK9mC31WHaL3/6O5SetD1cNIGH6bBGxKBdusw4xQdXHS4ZgJQsxGLQ5vw9/UpINJxKr3I1 2GSlQFauSegD4loToZNBrt3E9BYdkRT4Hi6MQZmBggz3jQR98TVptM3wvPw0Lp7piJoVcDDl 5X8KvI+xjkswDy4J47uyFOzFJ1N+eOCfQiSjecLs3kM9F7m0AyQNXRytaqdk9vAipsME8hiK C+2ukb3q0DOekKde7HFBzPvEVSI+NbFBXvyRjNi6iO1DobJVsv5YX6uBJ/TeCAAAAAAAAA== --------------ms000603070803090301000902-- X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3RI1Caa031190 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 27 Apr 2005 11:01:13 -0700 Received: from agminet02.oracle.com (localhost [127.0.0.1]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j3RI16lX006375 for ; Wed, 27 Apr 2005 13:01:06 -0500 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j3RI15EU006361 for ; Wed, 27 Apr 2005 13:01:05 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j3RI15bl018752 for ; Wed, 27 Apr 2005 12:01:05 -0600 Received: from [144.23.219.129] (dhcp-ca-montreal-144-23-219-129.ca.oracle.com [144.23.219.129]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j3RI0w5G018710 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 27 Apr 2005 12:01:01 -0600 Message-ID: <426FD354.7070900@oracle.com> Date: Wed, 27 Apr 2005 14:00:52 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] 3.3 Timezones References: <426EE74B.90403@Royer.com> In-Reply-To: <426EE74B.90403@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 18:01:29 -0000 Doug Royer wrote: > > -05 says in part: > > > 3.3 Timezones > > > > Calendar resources in CalDAV MUST be valid iCalendar objects. As > > such, an individual VTIMEZONE calendar component MUST be specified > > for each unique TZID parameter value specified in an iCalendar > > object. Unfortunately this mean that the same VTIMEZONE component > > will get sent or retrieved multiple times for each iCalendar object > > Its more complicated than that. It would need to be one VTIMEZONE > component per unique VTIMEZONE definition. > > Without standardized TZID's, there is no guarantee that TZID-X > is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE. The sentence « an individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object » was copied verbatim from section 4.2.19 Time Zone Identifier of RFC 2445. While I understand what you are trying to say, this sentence is only making reference to "an iCalendar object". I can't believe a single iCalendar object would be making reference to multiple VTIMEZONE definitions with a single TZID. Cheers, Bernard X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3R1Draa004873 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Tue, 26 Apr 2005 18:13:54 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3R1DldP006337 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Apr 2005 18:13:48 -0700 Message-ID: <426EE74B.90403@Royer.com> Date: Tue, 26 Apr 2005 19:13:47 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070500000602020404050401" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] 3.3 Timezones X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: CalDAV DevList List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 01:13:58 -0000 This is a cryptographically signed message in MIME format. --------------ms070500000602020404050401 Content-Type: multipart/mixed; boundary="------------070500050704010507030209" This is a multi-part message in MIME format. --------------070500050704010507030209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -05 says in part: > 3.3 Timezones > > Calendar resources in CalDAV MUST be valid iCalendar objects. As > such, an individual VTIMEZONE calendar component MUST be specified > for each unique TZID parameter value specified in an iCalendar > object. Unfortunately this mean that the same VTIMEZONE component > will get sent or retrieved multiple times for each iCalendar object Its more complicated than that. It would need to be one VTIMEZONE component per unique VTIMEZONE definition. Without standardized TZID's, there is no guarantee that TZID-X is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------070500050704010507030209 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------070500050704010507030209-- --------------ms070500000602020404050401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BCQUxDxcNMDUwNDI3MDExMzQ3WjAjBgkqhkiG9w0BCQQxFgQUGYt/7b5+4lrlrDUsV/+q /7nfQnEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAhpieSM6IyV2PLMmrBeOcsVXrA5SCM/rIRx0lfyRScUZlUOdOu+BIHJSZFiax/hsU L9Xi27Us7Q9lQdajA3ZUZzEbp3VSwX5Vd1cwHJdSjKvSUG92JHrSjLqUrMJM0rTuS6ny5qyB J3CdX7OfzglBeMPc8c5NtarslWPRq8ZTjy2iqWBrJi/jKTXSQdLVM+o/ovWV2C6bLD25q9LS CNKB5ASWU8C6aVP1luk7GOiI3wycleXHUrjawqZfkgpkmS55GeTnOJtKeQBtb+rD7llOn98D QsDWmVWRW9pb5ca6lUtPTDKn2FBblD7HSQmH+fuSbwmdgd5G/LNlQV9h6aihrAAAAAAAAA== --------------ms070500000602020404050401-- X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from smtp819.mail.sc5.yahoo.com (smtp819.mail.sc5.yahoo.com [66.163.170.5]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j3PHOkaZ029220 for ; Mon, 25 Apr 2005 10:24:46 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.134.168 with plain) by smtp819.mail.sc5.yahoo.com with SMTP; 25 Apr 2005 17:24:46 -0000 Message-ID: <426D27D9.6040303@calconnect.org> Date: Mon, 25 Apr 2005 10:24:41 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.499 (*) HTML_10_20, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Further about the Calconnect Recurrence Questionnaire - status, thanks, and future developments X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2005 17:24:53 -0000 This message is going to all of the lists where I posted our original request for responses to the Consortium Recurrence Questionnaire, so many of you will see it more than once.  My apologies for the duplications.


Recently I posted a request on several of the calendaring discussion lists for organizations with calendaring products/implementations to please respond to our Recurrence Questionnaire.  We've had sixteen formal responses so far, and are delighted at both the number of responses and the thought and care put into them.

Our RECURR technical committee is beginning an analysis of the responses, and may be contacting responders if we have additional questions.  We hope to have our analysis done and a report issued in the next few weeks.  The report will be posted on the Calconnect web site and will be announced publicly to these discussion lists.  As noted in
my original posting, the report will maintain the confidentiality of the individual responses and will report results in an aggregate and narrative fashion.

We also wanted to let everyone know that there will be some more questionnaires in the future.  Several responders suggested a slightly different questionnaire tackling recurrence issues at a higher and more qualitative level, and we have begun work on that questionnare.  We hope to announce it within the next two-three weeks.  

Additionally, other Calconnect technical committes are considering questionnaires in other areas of the RFCs of particular interest to the Calsify effort as it develops, so there is a good chance we'll be announcing these as they become ready for public consumption.  We hope that you will be as supportive of these future questionnaires and help us with them as well.

Several responders have remarked that they found the exercise of filling out the questionnaire to be of help in understanding better their own  implementations, and we hope our future questionnaires, focusing on other parts of the RFCs, will be as useful to you as we hope they will be to us.

Best regards,

Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium

X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from smtp813.mail.sc5.yahoo.com (smtp813.mail.sc5.yahoo.com [66.163.170.83]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j3IGVsaZ018699 for ; Mon, 18 Apr 2005 09:31:55 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.154.104 with plain) by smtp813.mail.sc5.yahoo.com with SMTP; 18 Apr 2005 16:31:53 -0000 Message-ID: <4263E0F6.5090709@calconnect.org> Date: Mon, 18 Apr 2005 09:31:50 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.659 (**) HTML_40_50, HTML_FONT_FACE_CAPS, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, MIME_HTML_ONLY, SARE_HTML_TD_BR X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] General Notification -- June Interop Tests and Roundtable III -- Calconnect: The Calendaring and Scheduling Consortium X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 16:31:56 -0000
Please note that this announcement is being posted on multiple calendaring-related reflectors and to the Calconnect mailing lists to ensure as wide a distribution as possible.  Our apologies if you receive multiple copies.
 
 
CALL FOR PARTICIPATION -- THIRD INTEROP TESTING EVENT -  1-2 June 2005

CONSORTIUM ROUNDTABLE III MEMBER MEETINGS 1-3 June 2005
 
The third Interop of The Calendaring and Scheduling Consortium (CALCONNECT.ORG) will take place Wednesday and Thursday, June 1-2, 2005.  It will be hosted by Duke University in Durham, North Carolina.
 
This event will feature multiple Interop testing scenarios.  Participating organizations are welcome to test against multiple scenarios.  These scenarios will be going on simultaneously so you will probably need a person for each scenario you participate in.
 
A Consortium Roundtable will be colocated from 1-3 June 2005 featuring Technical Committee sessions and a full Plenary of the Consortium.

Space will be limited to 40 paticipants in both the Roundtable and Interop so early notification and registration is advised.
 
INTEROP SCENARIOS


The exact scenarios are still being worked on and can certainly change to meet participants' needs.  Current plans include:
  • Extended CalDAV tests between CalDAV servers and any clients supporting CalDAV
  • iMIP testing
  • iCalendar - General tests; clients importing/exporting each other's data with formal scripts
  • Testing to support CalsifySIFY work
    • Handling of Timezones
    • Recurrence exceptions and Recurrence Rules
    • Other specific areas as identified prior to June
  • Min-IOP (Minimum Interoperable Subset) validation
  • Other interop scenarios can be added if there is a specific need, for example iCalendar<-->RDF
 
WHO MAY PARTICIPATE IN THE INTEROPS
 
Any vendors or organizations wishing to test a calendaring and scheduling implementation are welcome to attend whether or not they are Consortium members.  Consortium members receive a substantial discount on their Interop participation fee (see below).
 
 
CONSORTIUM ROUNDTABLE III
 
Technical committee meetings of the Calendaring and Scheduling Consortium are planned for 1-2 June at the same location, followed by an all-hands Consortium Roundtable on Friday 3 June.  Interop participants who are not Consortium members may not particpate in the other Consortium activities unless their organization indicates that it wishes to do so as an observer for this Roundtable (a non-member can participate in a single Roundtable as an observer to determine its interest in joining the Consortium).  A non-member Interop Participant can also join the Consortium at the event and become a member immediately and be able to participate in the technical committee and roundtable meetings.

Please note that it will probably be impossible for a single individual to both participate in the Interop and still be able to participate at all in the TC meetings of hte Roundtable simply due to the simultaneous nature of the events.
 
 
REGISTRATION FEE
 
Interop: $1500 for Consortium members and $2500 for non-members.  The registration fee covers two individuals; additional individuals are $275 each for members or non-members.  (If you are planning to participate in more than one Interop scenario, or participate in all the TC meetings, you will need more than one person and possibley more than two.)
 
The Interop Registration Fee also covers participation in the Consortium Roundtable for members or declared observers.
 
Roundtable:  $275 per individual until 15 May and $325 thereafter.  Registration for the Roundtable does not include Interop participation.
 
 
HOW TO REGISTER AND FURTHER INFORMATION
 
Logistics, registration and other information may be found on the Consortium Website:  see http://www.calconnect.org and go to the Coming Events area; see "Roundtable III" and "Jun 2005 Interop".
 
For questions or more information, or to inform us of your plan to participate in the Interop, please contact me at the Consortium.  Plan to register as soon as possible to ensure we will have room.

 
Best Regards,
 
Dave Thewlis
Executive Director
The Calendaring and Scheduling Consortium
1550 Dena Drive
McKinleyville CA 95519-4146
+1 707 840 9391 (voice)
+1 415 946 3454 (fax)
+1 707 498 2238 (mobile)
. 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 j3FIxWaa006011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 15 Apr 2005 11:59:38 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FIxKpc012087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 15 Apr 2005 11:59:22 -0700 Message-ID: <42600F08.3090603@Royer.com> Date: Fri, 15 Apr 2005 12:59:20 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , Calsify , CalDAV DevList Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050803010100090309050007" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-caldav] Document Action: 'Calendar Access Protocol (CAP)' to Experimental RFC X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: "ietf-calendar@imc.org" List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 18:59:40 -0000 This is a cryptographically signed message in MIME format. --------------ms050803010100090309050007 Content-Type: multipart/mixed; boundary="------------090107000606060801060006" This is a multi-part message in MIME format. --------------090107000606060801060006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It has taken forever - it is on it way!! From: The IESG To: IETF-Announce Date: Fri, 15 Apr 2005 13:15:42 -0400 Subject: Document Action: 'Calendar Access Protocol (CAP)' to Experimental RFC The IESG has approved the following document: - 'Calendar Access Protocol (CAP) ' as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ted Hardie. IANA Note: This draft includes registrations under RFC 2445, section 7.1; these are the first registrations of that type, and a registry will be needed for them. The author of this specification, as well as the original authors of RFC 2445 should be consulted as to its form. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------090107000606060801060006 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------090107000606060801060006-- --------------ms050803010100090309050007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BCQUxDxcNMDUwNDE1MTg1OTIwWjAjBgkqhkiG9w0BCQQxFgQU9sGhz3WE9M3eMlqIsCLG MKgtj6wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAL1d1aAhHOPMeQhT50+E45knuJgWaf7iQa/bkVzsTTQ7wNi1xAljKYHrGg9wwpXSd UTb6aNM2XwdlEakACddicL6iUE0HS3dYc2iQGW9gANj1qd8s8o6RVRmpuJoIkiOgJl4t2ReB eoVSW6BwYpG3Az0yWNYjM5cbP4+8yRGenJO7QOh//4tqAlDTVSStfWG6IjYLXh7Jwk8w4AMq yp7oJFD6/BayslM3/qcP5kcc/RWvIokgvgGz3ACemNjmWuRR1DYcfLMyt0pStTJg0vuCEJmp FoSBCkpDmV5TXVBzcXCREVHiZt3GU1kE9veJcXHdHKz4CCPiSirZXSg65Wf7twAAAAAAAA== --------------ms050803010100090309050007-- X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: 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 j37KqfaZ001330 for ; Thu, 7 Apr 2005 13:52:41 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 51F0B2EF32B for ; Thu, 7 Apr 2005 22:50:58 +0200 (CEST) Received: from [192.168.1.126] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 3122F2EF3C7 for ; Thu, 7 Apr 2005 22:50:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <5EDFE55E90291868FC347A92@ninevah.cyrusoft.com> References: <4e1d365f70d1335f08253a0f48e4f1fd@opengroupware.org> <5EDFE55E90291868FC347A92@ninevah.cyrusoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] attendee;cutype Date: Thu, 7 Apr 2005 22:52:35 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2005 20:52:43 -0000 On Apr 7, 2005, at 22:28, Cyrus Daboo wrote: > It seems to me that you would probably want to extend the CALADRURI > defined in RFC2739 to accept a CUTYPE= parameter to add that > information into the vCard. Sounds reasonable, thanks. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: daboo@isamet.com X-Envelope-To: 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 j37KS6aa029387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Apr 2005 13:28:08 -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 j37KBC6g031079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2005 16:11:13 -0400 Date: Thu, 07 Apr 2005 16:28:04 -0400 From: Cyrus Daboo To: Helge Hess , CalDAV DevList Subject: Re: [Ietf-caldav] attendee;cutype Message-ID: <5EDFE55E90291868FC347A92@ninevah.cyrusoft.com> In-Reply-To: <4e1d365f70d1335f08253a0f48e4f1fd@opengroupware.org> References: <4e1d365f70d1335f08253a0f48e4f1fd@opengroupware.org> X-Mailer: Mulberry/4.0.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2005 20:28:13 -0000 Hi Helge, --On April 7, 2005 10:06:32 PM +0200 Helge Hess wrote: > we are currently discussing on how to allow booking of resources in > conjunction with iCalendar and I suppose it matters for CalDAV as well. > > iCalendar already supports resources with various approaches, eg > "attendee;cutype=room" for booking a scheduled room. > Our assumption is that the attendee fields in CUA are mostly derived from > either a local vCard or an LDAP directory. > > So the question is: How can I derive the 'cutype' from a vCard or an LDAP > contact record? > It seems to me that you would probably want to extend the CALADRURI defined in RFC2739 to accept a CUTYPE= parameter to add that information into the vCard. I'm not sure what the right approach is for the LDAP attributes defined in that document. -- Cyrus Daboo X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: 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 j37K6daZ024203 for ; Thu, 7 Apr 2005 13:06:39 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 3B1262EE29A for ; Thu, 7 Apr 2005 22:04:55 +0200 (CEST) Received: from [192.168.1.126] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 0BAF82EECCF for ; Thu, 7 Apr 2005 22:04:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <4e1d365f70d1335f08253a0f48e4f1fd@opengroupware.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: CalDAV DevList From: Helge Hess Date: Thu, 7 Apr 2005 22:06:32 +0200 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] attendee;cutype X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2005 20:06:41 -0000 Hi, we are currently discussing on how to allow booking of resources in conjunction with iCalendar and I suppose it matters for CalDAV as well. iCalendar already supports resources with various approaches, eg "attendee;cutype=room" for booking a scheduled room. Our assumption is that the attendee fields in CUA are mostly derived from either a local vCard or an LDAP directory. So the question is: How can I derive the 'cutype' from a vCard or an LDAP contact record? best regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from smtp801.mail.sc5.yahoo.com (smtp801.mail.sc5.yahoo.com [66.163.168.180]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j36GYJaZ015307 for ; Wed, 6 Apr 2005 09:34:19 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.236.43.183 with plain) by smtp801.mail.sc5.yahoo.com with SMTP; 6 Apr 2005 16:34:19 -0000 Message-ID: <42540F81.6070904@calconnect.org> Date: Wed, 06 Apr 2005 09:34:09 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.245 (*) HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Calconnect Questionnaire on Recurrence - request responses by 11 April X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2005 16:34:21 -0000 I would like to thank those who have already responded to our request last week to complete our Recurrence Questionnaire, and to ask for more responses.  If you haven't responded, please do so -- the more implementations we have information about, the more valuable the results will be to everyone.

We really need your responses by Monday evening, 11 April, as we want to start looking at the results later next week. 

You can find the questionnaire at

http://www.calconnect.org/recurrencequestionnaire.html

Please contact me with any questions.

Dave Thewlis
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391
Dave.Thewlis@calconnect.org
www.calconnnect.org
X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.101] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j340h4aa006479 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 3 Apr 2005 17:43:06 -0700 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <519335652e553b4908959bee8a131e29@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: CalDAV DevList From: Lisa Dusseault Date: Sun, 3 Apr 2005 17:42:57 -0700 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Timezone collections X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2005 00:43:07 -0000 Putting together the whole picture on timezones (for myself as much as for anyone): - Only components with an RRULE (not regular events, and not exception components) require timezone information. This isn't that much data (my work calendar has only 20 recurring events out of about 400 events). Bandwidth limits aren't likely to be a problem even if every one of those recurring events has the whole VTIMEZONE in it. - The advantage to including the whole VTIMEZONE is that the event is self-contained. With the URL to that recurring event, the client can download in a single GET request the entire recurring event, the RRULE, the timezone in which the RRULE must be evaluated, and all the exceptions and their properties. This seems like a good thing for data consistency and for interoperability -- it's easier than requiring clients to be aware that they might have to download the timezone information from somewhere else. An existing browser with no special CalDAV logic can use that URL, hand the resulting ICS file off to a calendar application, and voila, the calendar application has the whole event. - OTOH, there might also be advantages to having a shared timezone collection managed by the server. For example, if new timezones are defined they would only have to be added on the server, rather than having users upgrade their clients. - Having a shared timezone collection means that the client MUST synchronize that collection periodically in case any timezone information on the server changes. So far our only mechanism to do that would be to download all the ETags and compare them to the last cached set of timezone ETags. Not a huge problem, but it is another thing to get wrong. - Having a shared timezone collection adds specification complexity (OPTIONS, properties, etc). I don't think we've quite nailed this yet -- for example, do we define a way for a user to browse the set of server-defined timezones so that the user can select an appropriate one -- AND have this browsing support i18n? (Or is that needed)? I guess now that I've learned and thought more about this, I'm leaning towards removing the timezone collection. However, I may well have overlooked advantages (or disadvantages, for that matter). Has anybody implemented this yet? Has anybody found any issues or benefits? Lisa 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 j33LHFaa026606 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Sun, 3 Apr 2005 14:17:16 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j33LH5FJ028281 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 3 Apr 2005 14:17:08 -0700 Message-ID: <42505D51.7070404@Royer.com> Date: Sun, 03 Apr 2005 15:17:05 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Roberts Subject: Re: [Ietf-caldav] dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> In-Reply-To: <20050403022715.GB7536@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010102060608050004010305" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org, CalDAV DevList , "ietf-calendar@imc.org" X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2005 21:17:18 -0000 This is a cryptographically signed message in MIME format. --------------ms010102060608050004010305 Content-Type: multipart/mixed; boundary="------------040500020902040002060007" This is a multi-part message in MIME format. --------------040500020902040002060007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This discussion belongs in CALSIFY - not CALDAV. Sam Roberts wrote: > Quoting Doug@royer.com, on Sun, Jan 16, 2005 at 02:11:43PM -0700: > >>I send -01 of iCal-Basis to the IETF. It fixed some problems and >>typos that were sent to me and the lists. It also deprecates DTEND and >>replaced the examples and ABNF with DURATION. > > > dtstart/dtend and dtstart/duration are equivalent ONLY for single > non-recurring events. > A yearly event on that starts at april second 3PM, and goes until > april 3 6PM will have different durations. This year it falls on > DST. The duration will be different next year. > > Anything starting on the 25th and going to the "-1th"/last day of the > month will have a different duration every month. Etc. > > It's also trivial to support doing the calculation of duration/dtend for > a specific event. > > Do you ever intend to support recurring events again? > > I just hours ago wrote a little server that publishes all the birthdays > in my address book as text/calendar over http, which is handy because my > calendar program now subscribes to it. Those birthdays recur! > > Sam > > > >>Copy at: >> >> http://inet-consulting.com/draft-royer-ical-basic-01.txt >> >>And HTML version at: >> >> http://inet-consulting.com/draft-royer-ical-basic-01.html >> >>-- >> >>Doug Royer | http://INET-Consulting.com >>-------------------------------|----------------------------- >>Doug@Royer.com | Office: (208)612-4638 >>http://Royer.com | Fax: (866)594-8574 >> | Cell: (208)520-4044 >> >> We Do Standards - You Need Standards >> > > > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040500020902040002060007 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------040500020902040002060007-- --------------ms010102060608050004010305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BCQUxDxcNMDUwNDAzMjExNzA1WjAjBgkqhkiG9w0BCQQxFgQUEgyEfHfu1gQIt83fzcNi eAQgwigwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAx3T9sssPdmnr5ob9mvMWWVCLAjtuHfnJ1Jmxaamor/OyEGJ0F3ncaXH7OcRhdgEW BHOP/iIt8IxAJDPEFJxV8uvogzQQ1QUSWT9FAz/dSrFFz65x8Op+ozrfV8nXIL/7jiJPYY7G dieFa4cUrzZj9hJ1ufkZW9/JjZDBj0bzQiqIwwDCRuEmqEZa/loVpWjbZhWt+Ovb+aONi7Xh c9q2gZWGPPljLKVYkRdl7Ci2gIp4Z3F8ObNWT0GOOxHzWP5gsKl5TIlGZ+QiSqpyljME1wp4 R/tsx19wFoGdlEjF491rv7ViITn1DV/5/JOQ7k8Yb0LSDIzBxXBTWOQAvmUoygAAAAAAAA== --------------ms010102060608050004010305-- X-Envelope-From: sroberts@uniserve.com Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j332RkaZ006430; Sat, 2 Apr 2005 18:27:46 -0800 Received: from ensemble.local ([64.229.170.33]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403022745.VBOS26102.tomts10-srv.bellnexxia.net@ensemble.local>; Sat, 2 Apr 2005 21:27:45 -0500 Received: by ensemble.local (Postfix, from userid 501) id 369AD42D2B0; Sat, 2 Apr 2005 21:27:16 -0500 (EST) Date: Sat, 2 Apr 2005 21:27:15 -0500 From: Sam Roberts To: Doug Royer Message-ID: <20050403022715.GB7536@ensemble.local> References: <41EAD88F.1030601@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41EAD88F.1030601@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Sun, 03 Apr 2005 14:05:37 -0700 Cc: ietf-calsify@osafoundation.org, CalDAV DevList , "ietf-calendar@imc.org" Subject: [Ietf-caldav] dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2005 02:27:48 -0000 Quoting Doug@royer.com, on Sun, Jan 16, 2005 at 02:11:43PM -0700: > I send -01 of iCal-Basis to the IETF. It fixed some problems and > typos that were sent to me and the lists. It also deprecates DTEND and > replaced the examples and ABNF with DURATION. dtstart/dtend and dtstart/duration are equivalent ONLY for single non-recurring events. A yearly event on that starts at april second 3PM, and goes until april 3 6PM will have different durations. This year it falls on DST. The duration will be different next year. Anything starting on the 25th and going to the "-1th"/last day of the month will have a different duration every month. Etc. It's also trivial to support doing the calculation of duration/dtend for a specific event. Do you ever intend to support recurring events again? I just hours ago wrote a little server that publishes all the birthdays in my address book as text/calendar over http, which is handy because my calendar program now subscribes to it. Those birthdays recur! Sam > Copy at: > > http://inet-consulting.com/draft-royer-ical-basic-01.txt > > And HTML version at: > > http://inet-consulting.com/draft-royer-ical-basic-01.html > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-4638 > http://Royer.com | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: 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 j32Au6aa004742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 2 Apr 2005 02:56:08 -0800 Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j32AtsTW005708; Sat, 2 Apr 2005 12:55:56 +0200 From: Reinhold Kainhofer Organization: Vienna University of Technology To: Dave.Thewlis@calconnect.org, dthewlis@dcta.com, Ietf-caldav@osafoundation.org Date: Sat, 2 Apr 2005 12:55:50 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1376318.2Dl4rzUC5u"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504021255.53491.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Sat, 02 Apr 2005 07:06:38 -0800 Cc: Subject: [Ietf-caldav] Re: Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2005 10:56:09 -0000 --nextPart1376318.2Dl4rzUC5u Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline David C. Thewlis wrote: > The Recurrence Technical Committee of Calconnect - The Calendaring and > Scheduling Consortium - needs your help.=A0 The Committee is collecting > specific informationon how C&S implementations have, or have not, > implemented the Recurrence Rules of RFCs 2445 and 2446, iCalendar and > iTIP Are you talking about creating the iCalendar data or interpreting them? E.g= =2E=20 4.3.10.b: If an implementation always creates RRULEs with the FREQ part tha= t=20 would be "Yes" for creating, but if it tries to understand RRULEs without a= =20 =46REQ part, it would mean that the implementation disregards the MUST whe= n=20 reading the data and it would be "No" for reading. So from which view do you want us to fill out the form? Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, Austria email: 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 --nextPart1376318.2Dl4rzUC5u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCTno5TqjEwhXvPN0RAjf0AJ4tlEkN3/owSJU8tIFToHe8FSCx8QCfS3UC +90aC0irud3NnqotPKk1WoM= =8meH -----END PGP SIGNATURE----- --nextPart1376318.2Dl4rzUC5u-- X-Envelope-From: dthewlis@dcta.com X-Envelope-To: Received: from smtp816.mail.sc5.yahoo.com (smtp816.mail.sc5.yahoo.com [66.163.170.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j31GhTaZ015631 for ; Fri, 1 Apr 2005 08:43:29 -0800 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.236.43.127 with plain) by smtp816.mail.sc5.yahoo.com with SMTP; 1 Apr 2005 16:43:27 -0000 Message-ID: <424D7A2C.1010005@dcta.com> Date: Fri, 01 Apr 2005 08:43:24 -0800 From: "David C. Thewlis" Organization: DCTA Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.663 (*) HTML_20_30,HTML_MESSAGE,MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org, dthewlis@dcta.com List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 16:43:31 -0000 Dear IETF-Caldav:

This e-mail is going to IETF-Caldav, IETF-Calsify, IETF-Calendar and www-rdf-calendar.  My apologies if you get it more than once (which I'm afraid most people probably will).

The Recurrence Technical Committee of Calconnect - The Calendaring and Scheduling Consortium - needs your help.  The Committee is collecting specific informationon how C&S implementations have, or have not,
implemented the Recurrence Rules of RFCs 2445 and 2446, iCalendar and iTIP, as part of its work to compile actual usage informaton and interoperability issues.

The information collected will be analyzed and the results, with specific product identifications eliminated, will be transmitted to the incipient CALSIFY Working Group of the IETF as soon as possible.  The results will also be made generally available on the Consortium website, and will be input to Technical Committee recommendations to be formulated once the results are available.

If you are willing to help, please fill out the questionnaire linked below.  This is absolutely NOT limited to Consortium members; we need responses for as many products and implementations as possible for the
results to be of maximum value.  The questionnaire may be found at:

 http://www.calconnect.org/recurrencequestionnaire.html

Thank you for participating; I'll post again as soon as results are available.

Dave Thewlis, Executive Director
CalConnect - The Calendaring and Scheduling Consortium