From owner-ietf-calendar@mail.imc.org Thu Jan 2 20:22:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18937 for ; Thu, 2 Jan 2003 20:22:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h031G5k10317 for ietf-calendar-bks; Thu, 2 Jan 2003 17:16:05 -0800 (PST) Received: from office2.jigzaw.com (adsl-68-20-84-161.dsl.chcgil.ameritech.net [68.20.84.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h031G3o10309 for ; Thu, 2 Jan 2003 17:16:04 -0800 (PST) Received: from colatz ([10.0.0.10]) by office2.jigzaw.com (8.9.3/8.9.3) with SMTP id TAA21796 for ; Thu, 2 Jan 2003 19:05:43 -0600 Reply-To: From: "Shannon J. Clark" To: Subject: Site using ical? Date: Thu, 2 Jan 2003 19:15:49 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thought the list might interested in the following site: http://icalshare.com/ It is part of Apple's ventures, seems designed for the publishing and sharing of calendars. I bring it to the list's attention to raise a couple of items for discussion. 1 - is there anything this site is doing that might be suggestive to the overall CAP efforts that are underway? (and/or the RDF/XML efforts that people have discussed) 2 - is there some simple way that the underlying standards can be referenced and referred to - and if so, is there a best way to approach companies (such as Apple) that are using the standards in some way to "get the word out" as it were? Shannon Shannon J. Clark President - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Thu Jan 2 20:37:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19246 for ; Thu, 2 Jan 2003 20:37:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h031W7I12723 for ietf-calendar-bks; Thu, 2 Jan 2003 17:32:07 -0800 (PST) Received: from office2.jigzaw.com (adsl-68-20-84-161.dsl.chcgil.ameritech.net [68.20.84.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h031W6o12718 for ; Thu, 2 Jan 2003 17:32:06 -0800 (PST) Received: from colatz ([10.0.0.10]) by office2.jigzaw.com (8.9.3/8.9.3) with SMTP id TAA21811 for ; Thu, 2 Jan 2003 19:22:24 -0600 Reply-To: From: "Shannon J. Clark" To: Subject: RE: Site using ical? Date: Thu, 2 Jan 2003 19:32:29 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit One correction - a friend pointed out to me that this is "home grown" not a formal part of Apple. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Shannon J. Clark Sent: Thursday, January 02, 2003 7:16 PM To: ietf-calendar@imc.org Subject: Site using ical? Thought the list might interested in the following site: http://icalshare.com/ It is part of Apple's ventures, seems designed for the publishing and sharing of calendars. I bring it to the list's attention to raise a couple of items for discussion. 1 - is there anything this site is doing that might be suggestive to the overall CAP efforts that are underway? (and/or the RDF/XML efforts that people have discussed) 2 - is there some simple way that the underlying standards can be referenced and referred to - and if so, is there a best way to approach companies (such as Apple) that are using the standards in some way to "get the word out" as it were? Shannon Shannon J. Clark President - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Fri Jan 3 12:44:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14268 for ; Fri, 3 Jan 2003 12:44:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03HZmA27888 for ietf-calendar-bks; Fri, 3 Jan 2003 09:35:48 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03HZko27875 for ; Fri, 3 Jan 2003 09:35:47 -0800 (PST) To: Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Site using ical? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 3 Jan 2003 12:35:46 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 01/03/2003 12:35:49 PM, Serialize complete at 01/03/2003 12:35:49 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hey Shannon. Happy new year. We are aware of the Apple work. Someone else brought it to the list a while ago. I think there should be a simply way to get the standards referenced. What I have done in the past is contact groups myself. That's how we got the Novel people involved. I called and asked if anyone in their development group was looking at calendar standards - and the next thing I knew I was talking directly to the right guy. It happened pretty quickly. As for a formal way to contact them - there is none. But I think we might be able to put together a small group of volunteers that can periodically call organizations and companies and 'suggest' they look at our site and using standards. We can't really force them to use them - so it's a balancing act. Anyone interested in being part of this small group - speak up. I'm happy to put up a small discussion group where we can chat about this work if we don't want it on the list. "Shannon J. Clark" Sent by: owner-ietf-calendar@mail.imc.org 01/02/2003 20:15 Please respond to shannon To: cc: Subject: Site using ical? Thought the list might interested in the following site: http://icalshare.com/ It is part of Apple's ventures, seems designed for the publishing and sharing of calendars. I bring it to the list's attention to raise a couple of items for discussion. 1 - is there anything this site is doing that might be suggestive to the overall CAP efforts that are underway? (and/or the RDF/XML efforts that people have discussed) 2 - is there some simple way that the underlying standards can be referenced and referred to - and if so, is there a best way to approach companies (such as Apple) that are using the standards in some way to "get the word out" as it were? Shannon Shannon J. Clark President - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Fri Jan 3 13:19:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15237 for ; Fri, 3 Jan 2003 13:19:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03IDPv00662 for ietf-calendar-bks; Fri, 3 Jan 2003 10:13:25 -0800 (PST) Received: from amsfep14-int.chello.nl (amsfep14-int.chello.nl [213.46.243.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03IDNo00655 for ; Fri, 3 Jan 2003 10:13:23 -0800 (PST) Received: from erebor.copa.nl ([212.83.72.215]) by amsfep14-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP id <20030103181317.WWA3670.amsfep14-int.chello.nl@erebor.copa.nl> for ; Fri, 3 Jan 2003 19:13:17 +0100 Received: from martijn by erebor.copa.nl with local (Exim 3.36 #1 (Debian)) id 18UWJj-0007tk-00 for ; Fri, 03 Jan 2003 19:13:11 +0100 Date: Fri, 3 Jan 2003 19:13:11 +0100 From: Martijn van Beers To: ietf-calendar@imc.org Subject: Re: Site using ical? Message-ID: <20030103181311.GA27498@erebor.copa.nl> Mail-Followup-To: Martijn van Beers , ietf-calendar@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jan 02, 2003 at 07:15:49PM -0600, Shannon J. Clark wrote: > > Thought the list might interested in the following site: > > http://icalshare.com/ also, http://myical.com/ and http://icalx.com/ Martijn From owner-ietf-calendar@mail.imc.org Sat Jan 4 15:49:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15736 for ; Sat, 4 Jan 2003 15:49:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04KiU904468 for ietf-calendar-bks; Sat, 4 Jan 2003 12:44:30 -0800 (PST) Received: from sud.globenet.org (globenet-gw.gitoyen.net [80.67.168.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04KiSo04459 for ; Sat, 4 Jan 2003 12:44:29 -0800 (PST) Received: from sud.globenet.org (sud [127.0.0.1]) by sud.globenet.org (Postfix) with SMTP id 5B84E17F14 for ; Sat, 4 Jan 2003 21:31:28 +0100 (CET) Received: from hse-toronto-ppp3484595.sympatico.ca ([65.92.96.226]) (SquirrelMail authenticated user benjamin_pops.globenet.org) by secure.globenet.org with HTTP; Sat, 4 Jan 2003 21:31:28 +0100 (CET) Message-ID: <39371.65.92.96.226.1041712288.squirrel@secure.globenet.org> Date: Sat, 4 Jan 2003 21:31:28 +0100 (CET) Subject: small typos From: "Benjamin Sonntag" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, just some typos in latest cap : 11.8 CALID Property Parameter : Conformance: This property can be specified in the "VCAP" --> "VCAR" 6.2.4.2 in the delete restriction : . VAGENDA Only if VAGENDAS were deleted the 0+ is missing -- Regards Benjamin Sonntag From owner-ietf-calendar@mail.imc.org Thu Jan 9 12:00:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17756 for ; Thu, 9 Jan 2003 12:00:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09Gq4b26995 for ietf-calendar-bks; Thu, 9 Jan 2003 08:52:04 -0800 (PST) Received: from sud.globenet.org (globenet-gw.gitoyen.net [80.67.168.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09Gq2o26990 for ; Thu, 9 Jan 2003 08:52:03 -0800 (PST) Received: from sud.globenet.org (sud [127.0.0.1]) by sud.globenet.org (Postfix) with SMTP id 8E73E18170 for ; Thu, 9 Jan 2003 17:38:00 +0100 (CET) Received: from toronto-hse-ppp3700487.sympatico.ca ([65.95.109.252]) (SquirrelMail authenticated user benjamin_pops.globenet.org) by secure.globenet.org with HTTP; Thu, 9 Jan 2003 17:38:00 +0100 (CET) Message-ID: <40027.65.95.109.252.1042130280.squirrel@secure.globenet.org> Date: Thu, 9 Jan 2003 17:38:00 +0100 (CET) Subject: DTD on the draft From: "Benjamin Sonntag" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi all, I found some problems/remarks in the latest CAP draft. Can you please check/confirm/modify ? --------------------------------------------------- 1. the CAP DTD seems to be incorrect (or just outdated...) : should be replaced by : - the 'add' element is not defined at all (this is a sub-element of modify) ! And there is no example of this element in 6.2.4.3 (modify command). - the max-result and max-size elements (used by the search CAP command) are not defined in the search command paragraph (6.2.4.5). We don't know how it works, and there is no example. - in 6.1.1 (generateuid command), there is the following example : C: MSG 1 5 . 2837 60 C: Content-Type: application/beep+xml C: C: C: END XML attributes MUST be enclosed with ' or " : (as specified in XML Specifications) C: MSG 1 5 . 2837 60 C: Content-Type: application/beep+xml C: C: C: END (note : this error appears in other places in the draft) - in 6.2.4.1 (create command), the example is : (...) C: --boundary-foo321 C: Content-Type: application/beep+xml C: Content-ID: 1@cal.example.com C: C: (...) C: --boundary-foo321 C: Content-Type: text/calendar C: Content-ID: 2@cal.example.com C: C: BEGIN:VCALENDAR (...) RFC822 says that Content-ID MUST be enclosed in < > so the correct example MUST be : (...) C: --boundary-foo321 C: Content-Type: application/beep+xml C: Content-ID: <1@cal.example.com> C: C: (...) C: --boundary-foo321 C: Content-Type: text/calendar C: Content-ID: <2@cal.example.com> C: C: BEGIN:VCALENDAR (...) (note : ALL the content-id in CAP are incorrect...) - in 6.2.4.3 (modify command), the example is incorrect : C: C: > (...) > C: > C: > C: > C: > > on line 1 : the / is irrelevant ... > (I don't check the other examples) > > > --------------------------------------------------- > 2. I think that the DTD is not very clear (when a human read it) : > - Elements that corresponds to CAP commands may be separated from > sub-elements. (create,modify,delete visually separated from max-result, > target,data...) - 'CAP request' element can be separated from 'CAP answer' elements. > (create,delete,modify separated from request-status, error...) > Today, all the elements are in a random order in the DTD. I can send you a > 'human compliant' version if you want. This will allow a more clean > reading of this document. It is not very important, but this kind of > document should be easy to read (I am developping a CAP server, that's why > I found this DTD hard to read.). > > > -- > Regards, > > Benjamin Sonntag > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000201010806010600070301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMDkxNzE4MjlaMCMGCSqGSIb3DQEJBDEWBBQa guBQ2MQi3jcusQ6DtinDxs0kITBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYN8Pbp8TCPWp thegMJ/bgFeJv4rnFNso71WMRL/P4QYWthm1qdCvDXM+Z6EEvToY4dg9boCzsp1ER3ZsgU80 U0Ro6aL6Fz4CTnuYKb2h8nVRvezeeVf0VE7sLAgJRFN5u2yx0xvjj8ND/Uy8vJszl8+cmF/e iRWoUlJBuO4ojgVVo+wmSO1LOkqgJ/XAcaFvJtNA646fM1SEZWelMxHAs75lpQHy2z3n4Kq4 UfcdOaIsbxt/E2s0FdUNl6atFA0E4l2vkK9Bmr8fsq1XUFCzf4Ee4b27oH10PCWsWacqR2bj /+IQeAyVdxNGesKWjm75ymXEGU8ldUAmUsfXqltqhAAAAAAAAA== --------------ms000201010806010600070301-- From owner-ietf-calendar@mail.imc.org Thu Jan 9 12:26:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18386 for ; Thu, 9 Jan 2003 12:26:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09HLjU27731 for ietf-calendar-bks; Thu, 9 Jan 2003 09:21:45 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09HLho27726 for ; Thu, 9 Jan 2003 09:21:44 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h09HLlto003413; Thu, 9 Jan 2003 09:21:47 -0800 Message-ID: <3E1DAFA6.1070300@Royer.com> Date: Thu, 09 Jan 2003 10:21:42 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: small typos References: <39371.65.92.96.226.1041712288.squirrel@secure.globenet.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040307050108020801010100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040307050108020801010100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This text is not in -09 of CAP. Where did you get this text? Benjamin Sonntag wrote: > Hello, > > just some typos in latest cap : > > > 11.8 CALID Property Parameter : > > Conformance: This property can be specified in the "VCAP" > --> "VCAR" > > > 6.2.4.2 in the delete restriction : > . VAGENDA Only if VAGENDAS were > deleted > the 0+ is missing > > > > -- > Regards > > Benjamin Sonntag > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040307050108020801010100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMDkxNzIxNDJaMCMGCSqGSIb3DQEJBDEWBBSH cyNzQ1XT0/uiNL3jiE8ZfCtjuzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAFWA8sRtU6hDG 3SOBfBIfxRe0bmxvTYd0aIkzp00dRYaV/c+8yJBf1wrTZ2JopC1NVwxAXYQtWKALHGc9KZDz GaG6cG2kh85B2zYDSIWPhvCgjH8nIiRt7rvcJ5mG2Q4YMx5Uwd2kMivzhaGqJ5dOrQVSUEs3 SlKbsUTmav7fd92db9AOa/+uoktcWEHo2w4nmRs3rIrGqQ3cHmZ9aSA4fXjstbHzdkGQPxqw VGCevOt1jEFo61gNPeMhOUK63tbhGhODtNSLcYpJ4yqH5nXp6FCTGq5AMsC5BM5FGB5PNbFe XaSX2AxJSSTJq18XJcdCxPPq/uZcYXO7yaG1exOhkwAAAAAAAA== --------------ms040307050108020801010100-- From owner-ietf-calendar@mail.imc.org Thu Jan 9 12:50:14 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18882 for ; Thu, 9 Jan 2003 12:50:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09HcPi28188 for ietf-calendar-bks; Thu, 9 Jan 2003 09:38:25 -0800 (PST) Received: from localhost.localdomain (24-240-234-245.charter.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09HcOo28183 for ; Thu, 9 Jan 2003 09:38:24 -0800 (PST) Received: from jsoft.com (eeyore.jsoft.com [192.168.0.46]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h09HfRcV022505 for ; Thu, 9 Jan 2003 11:41:28 -0600 Message-ID: <3E1DB24C.2030803@jsoft.com> Date: Thu, 09 Jan 2003 11:33:00 -0600 From: Gary Frederick User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20021205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: [Fwd: next calendar IRC meeting: Wednesday 15th Jan, 6pm GMT] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Some good conversation last chat. Check out the logs and join in if you are interested. Gary -------- Original Message -------- Subject: next calendar IRC meeting: Wednesday 15th Jan, 6pm GMT Resent-Date: Thu, 9 Jan 2003 09:31:45 -0500 (EST) Resent-From: www-rdf-calendar@w3.org Date: Thu, 9 Jan 2003 14:30:19 +0000 (GMT) From: Libby Miller To: www-rdf-calendar@w3.org hi all The next IRC calendar meeting is Wednesday 15th Jan, 6pm GMT: http://www.timeanddate.com/worldclock/fixedtime.html?day=15&month=1&year=2003&hour=18&min=0&sec=0&p1=0 in iCalendar (not sure if this will work - it's an invite to attend from Damian to me with an alarm): http://www.w3.org/2002/12/cal/test/20030115mtg.ics We had an interesting IRC chat yesterday. The logs start here: http://ilrt.org/discovery/chatlogs/rdfig/2003-01-08.html#T18-01-33 As well as the usual suspects we had Gary Frederick from Open Office/Mozilla calendar and Olivier Gutknecht from the Apple iCal development team come along. We have a few things people volunteered to do for next time (see below). Other suggestions for a slightly more formal agenda are welcome. [[ 19:08:10 For next time, I'll report on efforts to get iCal out of my new iPaq/outlook setup and into Moz, Apple and RDF tools. [snip] 19:09:04 I'm going to have some info on what the calsch group is doing and if nobody else does - a bit of info on Moz cal 19:09:12 I want to try getting out data from iCal and Moz cal: feel very slack not having done it already ]] cheers Libby From owner-ietf-calendar@mail.imc.org Thu Jan 9 12:54:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18988 for ; Thu, 9 Jan 2003 12:54:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09Hm1v28462 for ietf-calendar-bks; Thu, 9 Jan 2003 09:48:01 -0800 (PST) Received: from sud.globenet.org (globenet-gw.gitoyen.net [80.67.168.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09Hm0o28458 for ; Thu, 9 Jan 2003 09:48:00 -0800 (PST) Received: from sud.globenet.org (sud [127.0.0.1]) by sud.globenet.org (Postfix) with SMTP id 84B5118140 for ; Thu, 9 Jan 2003 18:34:02 +0100 (CET) Received: from toronto-hse-ppp3700487.sympatico.ca ([65.95.109.252]) (SquirrelMail authenticated user benjamin_pops.globenet.org) by secure.globenet.org with HTTP; Thu, 9 Jan 2003 18:34:02 +0100 (CET) Message-ID: <41668.65.95.109.252.1042133642.squirrel@secure.globenet.org> Date: Thu, 9 Jan 2003 18:34:02 +0100 (CET) Subject: Re: DTD on the draft From: "Benjamin Sonntag" To: In-Reply-To: <3E1DAEE5.4000709@Royer.com> References: <40027.65.95.109.252.1042130280.squirrel@secure.globenet.org> <3E1DAEE5.4000709@Royer.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > Where did you get this DTD? It is not in the CAP draft or the xCal > draft? > http://calsch.org/ietf/cap.html#cap_dtd -- Cordialement, Benjamin Sonntag From owner-ietf-calendar@mail.imc.org Thu Jan 9 12:56:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19070 for ; Thu, 9 Jan 2003 12:56:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09Ho5b28524 for ietf-calendar-bks; Thu, 9 Jan 2003 09:50:05 -0800 (PST) Received: from sud.globenet.org (globenet-gw.gitoyen.net [80.67.168.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09Ho4o28520 for ; Thu, 9 Jan 2003 09:50:05 -0800 (PST) Received: from sud.globenet.org (sud [127.0.0.1]) by sud.globenet.org (Postfix) with SMTP id 2791D18146 for ; Thu, 9 Jan 2003 18:36:07 +0100 (CET) Received: from toronto-hse-ppp3700487.sympatico.ca ([65.95.109.252]) (SquirrelMail authenticated user benjamin_pops.globenet.org) by secure.globenet.org with HTTP; Thu, 9 Jan 2003 18:36:07 +0100 (CET) Message-ID: <41714.65.95.109.252.1042133767.squirrel@secure.globenet.org> Date: Thu, 9 Jan 2003 18:36:07 +0100 (CET) Subject: Re: small typos From: "Benjamin Sonntag" To: In-Reply-To: <3E1DAFA6.1070300@Royer.com> References: <39371.65.92.96.226.1041712288.squirrel@secure.globenet.org> <3E1DAFA6.1070300@Royer.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Doug said : > This text is not in -09 of CAP. Where did you get this text? http://calsch.org/ietf/cap.html#anchor62 >> 11.8 CALID Property Parameter : >> >> Conformance: This property can be specified in the "VCAP" >> --> "VCAR" and http://calsch.org/ietf/cap.html#delete >> 6.2.4.2 in the delete restriction : >> . VAGENDA Only if VAGENDAS were >> deleted >> the 0+ is missing -- Cordialement, Benjamin Sonntag From owner-ietf-calendar@mail.imc.org Thu Jan 9 13:35:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20308 for ; Thu, 9 Jan 2003 13:35:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09IUon29671 for ietf-calendar-bks; Thu, 9 Jan 2003 10:30:50 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09IUmo29667 for ; Thu, 9 Jan 2003 10:30:48 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h09IUpto003966; Thu, 9 Jan 2003 10:30:51 -0800 Message-ID: <3E1DBFD6.30305@Royer.com> Date: Thu, 09 Jan 2003 11:30:46 -0700 From: Doug Royer Reply-To: xCal Mailing List User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xCal Mailing List CC: "ietf-calendar@imc.org" Subject: Re: DTD on the draft References: <40027.65.95.109.252.1042130280.squirrel@secure.globenet.org> <3E1DAEE5.4000709@Royer.com> <41668.65.95.109.252.1042133642.squirrel@secure.globenet.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070802050608020803010400" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070802050608020803010400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The latest released is (not that it is better or not): http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt I have set the REPLY-TO to the xCal mailing list. Benjamin Sonntag wrote: > >>Where did you get this DTD? It is not in the CAP draft or the xCal >>draft? >> > > > http://calsch.org/ietf/cap.html#cap_dtd > > -- > Cordialement, > > Benjamin Sonntag > > > -- http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070802050608020803010400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMDkxODMwNDZaMCMGCSqGSIb3DQEJBDEWBBRn SThGcFP2UP+QXUkXyUh7BgcWRTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAY3djuzdrox6d 7dW2FfLP4DfztcaZHn1ICcYBqnuUON/koaNgh3S4KqVJjSe9nptIzuf78Nq398TmW1emEGq7 MmxCvlpmlMdgHhFi65qEC0uR9V2LuZftRlNmZejAOej/+5no0NTkEvpAnPTHGT23A4A/ZYX3 csqeYH1qhbyAs+YCXkqaHaAeGjR/srivVrWYBWOAcWMp5WQD6DVQ9JRsLrp8BzLK1fuGyyuU dbyUyHh6mY31buay6LlUroy1UPwgf1MdV/2MSZAh0Wk3rcZU7eT9vP6RCIOT859RGfiQX4wT EDMf2oVsp/DeGYW3v0Dwv7g1EnM2dWXkOpfZOEa5nAAAAAAAAA== --------------ms070802050608020803010400-- From owner-ietf-calendar@mail.imc.org Thu Jan 9 13:37:32 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20344 for ; Thu, 9 Jan 2003 13:37:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09IWJc29737 for ietf-calendar-bks; Thu, 9 Jan 2003 10:32:19 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09IWIo29733 for ; Thu, 9 Jan 2003 10:32:18 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h09IWMto003977; Thu, 9 Jan 2003 10:32:22 -0800 Message-ID: <3E1DC030.70001@Royer.com> Date: Thu, 09 Jan 2003 11:32:16 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: small typos References: <39371.65.92.96.226.1041712288.squirrel@secure.globenet.org> <3E1DAFA6.1070300@Royer.com> <41714.65.95.109.252.1042133767.squirrel@secure.globenet.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050103060407080104030301" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050103060407080104030301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The latest released is at: http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-09.txt Benjamin Sonntag wrote: > Doug said : > >>This text is not in -09 of CAP. Where did you get this text? > > > > http://calsch.org/ietf/cap.html#anchor62 > > >>>11.8 CALID Property Parameter : >>> >>> Conformance: This property can be specified in the "VCAP" >>> --> "VCAR" >> > > and > > http://calsch.org/ietf/cap.html#delete > > >>>6.2.4.2 in the delete restriction : >>> . VAGENDA Only if VAGENDAS were >>> deleted >>> the 0+ is missing >> > > -- > Cordialement, > > Benjamin Sonntag > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050103060407080104030301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMDkxODMyMTdaMCMGCSqGSIb3DQEJBDEWBBQf ivSSzAO8HNJ5Com70O/Hbb5PGDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEADKkYWjHjEsez 4S0GwjPe+q8j/3EhnzvDUljn17CKMSS0FS2Ki+/p8eeGpdQ5HESeOqWRbTUtwhQENTIPUjJB y5Nu59e/d3IFUGCchTEqFIcpOO2qeQ0tO5jaIKxtVLxTuIJCPOigCgjNpleO1oO7PahwyEDv KU85Qw+9+xShucrf5gM1CrqHmFYLZkXni72zu23TpHgzRLlyU6RffiR0H9k54DbGbS4rwh3r cglSsDQIAiB5jPyS5fUj6CXiE4M6nRW+DgdVPstqFFf/vGDCGlDul/WQtmAjF+WQFHSngWUw QSu5PRCi2zxH+3XBIfxrk0PuT2TDmT4LfNKPFy2BdgAAAAAAAA== --------------ms050103060407080104030301-- From owner-ietf-calendar@mail.imc.org Thu Jan 9 18:55:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00762 for ; Thu, 9 Jan 2003 18:55:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09NkwW09831 for ietf-calendar-bks; Thu, 9 Jan 2003 15:46:58 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09Nkso09819 for ; Thu, 9 Jan 2003 15:46:54 -0800 (PST) To: Gary Frederick Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: [Fwd: next calendar IRC meeting: Wednesday 15th Jan, 6pm GMT] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 9 Jan 2003 18:46:58 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 01/09/2003 06:47:01 PM, Serialize complete at 01/09/2003 06:47:01 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Gary, thanks for the notes about this group. It's good we have someone on that group keeping an eye out for us! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Gary Frederick Sent by: owner-ietf-calendar@mail.imc.org 01/09/2003 12:33 To: ietf-calendar@imc.org cc: Subject: [Fwd: next calendar IRC meeting: Wednesday 15th Jan, 6pm GMT] Some good conversation last chat. Check out the logs and join in if you are interested. Gary -------- Original Message -------- Subject: next calendar IRC meeting: Wednesday 15th Jan, 6pm GMT Resent-Date: Thu, 9 Jan 2003 09:31:45 -0500 (EST) Resent-From: www-rdf-calendar@w3.org Date: Thu, 9 Jan 2003 14:30:19 +0000 (GMT) From: Libby Miller To: www-rdf-calendar@w3.org hi all The next IRC calendar meeting is Wednesday 15th Jan, 6pm GMT: http://www.timeanddate.com/worldclock/fixedtime.html?day=15&month=1&year=2003&hour=18&min=0&sec=0&p1=0 in iCalendar (not sure if this will work - it's an invite to attend from Damian to me with an alarm): http://www.w3.org/2002/12/cal/test/20030115mtg.ics We had an interesting IRC chat yesterday. The logs start here: http://ilrt.org/discovery/chatlogs/rdfig/2003-01-08.html#T18-01-33 As well as the usual suspects we had Gary Frederick from Open Office/Mozilla calendar and Olivier Gutknecht from the Apple iCal development team come along. We have a few things people volunteered to do for next time (see below). Other suggestions for a slightly more formal agenda are welcome. [[ 19:08:10 For next time, I'll report on efforts to get iCal out of my new iPaq/outlook setup and into Moz, Apple and RDF tools. [snip] 19:09:04 I'm going to have some info on what the calsch group is doing and if nobody else does - a bit of info on Moz cal 19:09:12 I want to try getting out data from iCal and Moz cal: feel very slack not having done it already ]] cheers Libby From owner-ietf-calendar@mail.imc.org Fri Jan 10 09:34:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29047 for ; Fri, 10 Jan 2003 09:34:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AERWt06649 for ietf-calendar-bks; Fri, 10 Jan 2003 06:27:32 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0AERUo06645 for ; Fri, 10 Jan 2003 06:27:30 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003011009273216787 ; Fri, 10 Jan 2003 09:27:32 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 10 Jan 2003 09:25:22 -0500 Message-ID: <3E1ED7D2.2000707@centive.com> Date: Fri, 10 Jan 2003 09:25:22 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benjamin Sonntag CC: ietf-calendar@imc.org Subject: Re: DTD on the draft References: <40027.65.95.109.252.1042130280.squirrel@secure.globenet.org> <3E1DAEE5.4000709@Royer.com> <41668.65.95.109.252.1042133642.squirrel@secure.globenet.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2003 14:25:22.0607 (UTC) FILETIME=[1C2C13F0:01C2B8B4] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Benjamin Sonntag wrote: >>Where did you get this DTD? It is not in the CAP draft or the xCal >>draft? >> >> >http://calsch.org/ietf/cap.html#cap_dtd > > Ah--I think that's from when we had a misunderstanding about BEEP; someone revised the draft on the assumption that using BEEP meant we had to encode CAP in XML. We're no longer doing that; we're back to using text/calendar. -- /==============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |==============================================================| |Never mind the GUIs--Unix won't be for the masses until we fix| |backspace & delete. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri Jan 10 18:13:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19486 for ; Fri, 10 Jan 2003 18:13:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AN6HQ23753 for ietf-calendar-bks; Fri, 10 Jan 2003 15:06:17 -0800 (PST) Received: from sud.globenet.org (globenet-gw.gitoyen.net [80.67.168.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0AN6Go23748 for ; Fri, 10 Jan 2003 15:06:16 -0800 (PST) Received: from sud.globenet.org (sud [127.0.0.1]) by sud.globenet.org (Postfix) with SMTP id D1B29181CC for ; Fri, 10 Jan 2003 23:51:50 +0100 (CET) Received: from toronto-hse-ppp3700487.sympatico.ca ([65.95.109.252]) (SquirrelMail authenticated user benjamin_pops.globenet.org) by secure.globenet.org with HTTP; Fri, 10 Jan 2003 23:51:50 +0100 (CET) Message-ID: <44366.65.95.109.252.1042239110.squirrel@secure.globenet.org> Date: Fri, 10 Jan 2003 23:51:50 +0100 (CET) Subject: Re: DTD on the draft From: "Benjamin Sonntag" To: In-Reply-To: <3E1ED7D2.2000707@centive.com> References: <40027.65.95.109.252.1042130280.squirrel@secure.globenet.org> <3E1DAEE5.4000709@Royer.com> <41668.65.95.109.252.1042133642.squirrel@secure.globenet.org> <3E1ED7D2.2000707@centive.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, DAMNED !!! Why the calsch.org web site is so outdated ??? Is it an OFFICIAL page about CAP or not ? If it is not, is there an official website ? I'm quite angry ... >>>Where did you get this DTD? It is not in the CAP draft or the xCal >>>draft? >>http://calsch.org/ietf/cap.html#cap_dtd > Ah--I think that's from when we had a misunderstanding about BEEP; > someone revised the draft on the assumption that using BEEP meant we > had to encode CAP in XML. We're no longer doing that; we're back to > using text/calendar. I did not heard about it in the list, nor in the latest cap draft in calsch.org (I thought the latest was here...) -- Regards, Benjamin Sonntag From owner-ietf-calendar@mail.imc.org Fri Jan 10 18:44:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20121 for ; Fri, 10 Jan 2003 18:44:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ANggr24230 for ietf-calendar-bks; Fri, 10 Jan 2003 15:42:42 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ANgeo24220 for ; Fri, 10 Jan 2003 15:42:41 -0800 (PST) To: "Benjamin Sonntag" Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: DTD on the draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 10 Jan 2003 18:42:42 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 01/10/2003 06:42:44 PM, Serialize complete at 01/10/2003 06:42:44 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Benjamin, we are sorry you are so angry. The "official" site of all IETF drafts is always on the IETF pages. (www.ietf.org). WE keep a copy on our site as a "courtesy." Because of that, sometimes, we get behind. We all have other jobs - so we do the updates when we can. This draft had been out on the calsch site - however, it went under some major revisions because of the changes added to support BEEP. I'm not sure where the most current copies went. However, the most current copies are FOR SURE out on the IETF site. If you are interested in reading an IETF draft, you should use that site as your starting point. Hope that helps. Also, it is preferable that we keep our lists "nice." By that, I mean keep the bad language at home and not on this list. Screaming on the list is ok - cursing kind of is not... 8-) ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "Benjamin Sonntag" Sent by: owner-ietf-calendar@mail.imc.org 01/10/2003 17:51 To: cc: Subject: Re: DTD on the draft Hi, DAMNED !!! Why the calsch.org web site is so outdated ??? Is it an OFFICIAL page about CAP or not ? If it is not, is there an official website ? I'm quite angry ... >>>Where did you get this DTD? It is not in the CAP draft or the xCal >>>draft? >>http://calsch.org/ietf/cap.html#cap_dtd > Ah--I think that's from when we had a misunderstanding about BEEP; > someone revised the draft on the assumption that using BEEP meant we > had to encode CAP in XML. We're no longer doing that; we're back to > using text/calendar. I did not heard about it in the list, nor in the latest cap draft in calsch.org (I thought the latest was here...) -- Regards, Benjamin Sonntag From owner-ietf-calendar@mail.imc.org Sun Jan 12 15:38:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14435 for ; Sun, 12 Jan 2003 15:38:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0CKOx109846 for ietf-calendar-bks; Sun, 12 Jan 2003 12:24:59 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0CKOwo09842 for ; Sun, 12 Jan 2003 12:24:58 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0CKOxto023891 for ; Sun, 12 Jan 2003 12:24:59 -0800 Message-ID: <3E21CF15.40001@Royer.com> Date: Sun, 12 Jan 2003 13:24:53 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: No partial success when it comes to deletion? Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050404050708080500030806" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050404050708080500030806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I would like to add this text to the DELETE command in CAP: There is no partial success for a "DELETE" command. Ether everything succeeds or nothing is done. So if the VREPLY contains X number of successful replies and at least one (1) failure then no objects were deleted or marked for deletion. This is because a malformed "QUERY" property value could have devastating effects and unintended deletion of some objects could make a calendar unusable. The CUA could inform the CU that their request must be modified in order to succeed. Comments? - Site note: I am about 80% done with removing the duplicate descriptions from CAP - I will be posting the proposed update (which includes the above text which I can delete if there are objections) in a few days. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050404050708080500030806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMTIyMDI0NTNaMCMGCSqGSIb3DQEJBDEWBBRY QansGTjAzAugQuOBhKVYsaEsAzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAW+My/tQ7xDvC g005iC/NvXjR8YW0RjffUa0GgoD2FfPoOdr/g8116pM0zZPdEdR7gvmvRYj26aRnPZAdA7ez zP/Zd/+XKt9nFScoKdRF0pA5KMh5I87Jli9/oeMPzVPJwFbVny+hr1KA+8RX2dFjl3gQUedn OQc8eAZwqV67bdP+ExWFZZEL1Er+v1qdLOqqSGhJC5dPEtZIcDTXT+U8gOvCwh8P8bOfp7OL r/PiO/TxrmT7Sw4LYKpWRQ53su4wvUZV3lBK36EtSs+Jb7oMgqy1usCUJeHj6pcNnui+3AKG +eARgzTXEGp5Wj79HWov94E/2Qjd0jPTvfbBORPzuAAAAAAAAA== --------------ms050404050708080500030806-- From owner-ietf-calendar@mail.imc.org Sun Jan 12 17:08:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15719 for ; Sun, 12 Jan 2003 17:08:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0CM0A511209 for ietf-calendar-bks; Sun, 12 Jan 2003 14:00:10 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0CM09o11204 for ; Sun, 12 Jan 2003 14:00:09 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0CM0Bto024557 for ; Sun, 12 Jan 2003 14:00:11 -0800 Message-ID: <3E21E565.9040501@Royer.com> Date: Sun, 12 Jan 2003 15:00:05 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP work in progress Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020100070305020205010407" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020100070305020205010407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I put the current snapshot of 'cap-12-JAN-2003' on INET-Consulting.com : http://INET-Consulting.com/cap-12-JAN-2003.html http://INET-Consulting.com/cap-12-JAN-2003.txt http://INET-Consulting.com/cap-12-JAN-2003.diffs http://INET-Consulting.com/cap-12-JAN-2003.xml The '.diffs' file is a context diff between the -09 submitted version and todays snapshot. I am still checking for duplicate text and incorporating duplicate comments from the list. As soon as this is done I'll move back to technical issues. I have also updated some of the ABNF as I found errors. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020100070305020205010407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMTIyMjAwMDVaMCMGCSqGSIb3DQEJBDEWBBRC IHMDDSetc8qlWhlf2u/iuDiGLzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAml/gMpGdHm7W UXMpMUNgwqHptneG7t0Fld74Yb5b8LGw8Bnkwj5JTXghJ5mPwJ9sKq+YAcHOEnpyNQf6mHML +E7svjUXm3jX0JErmSUme5WV498FR2P6HJzFMv7ERGd4rNCBJJzSOsoqYk89HbfkZTQ4bQtb UvTOGhgR5+QDel82QfW/+O2F8pqRSxZ1ZO4rvsltM5KHEbcuLsyhpCbQMqr6o5iOYjLgEvSd L3M5Cfn48LlTKaATazTIBYkNtdjrQ4Lgx38gwCTVfHFppvEcbm9EbgipjQcjEI2VlGnqLzHf Umxd8wKR9HeS4HfUsP25DvHtg6JIatPpowSgHsPy6QAAAAAAAA== --------------ms020100070305020205010407-- From owner-ietf-calendar@mail.imc.org Mon Jan 13 04:46:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05974 for ; Mon, 13 Jan 2003 04:46:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0D9b3A18945 for ietf-calendar-bks; Mon, 13 Jan 2003 01:37:03 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0D9b1o18940 for ; Mon, 13 Jan 2003 01:37:01 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 41C6B15507; Mon, 13 Jan 2003 10:36:56 +0100 (CET) Date: Mon, 13 Jan 2003 10:36:56 +0100 From: Andrea Campi To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? Message-ID: <20030113093656.GB44480@inet.it> References: <3E21CF15.40001@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E21CF15.40001@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, Jan 12, 2003 at 01:24:53PM -0700, Doug Royer wrote: > > I would like to add this text to the DELETE command in CAP: > > There is no partial success for a "DELETE" command. Ether > everything succeeds or nothing is done. So if the VREPLY > contains X number of successful replies and at least > one (1) failure then no objects were deleted or marked > for deletion. This is because a malformed "QUERY" property > value could have devastating effects and unintended > deletion of some objects could make a calendar unusable. > The CUA could inform the CU that their request must > be modified in order to succeed. > > Comments? I still think (as briefly mentioned before) that we should clearly define failure modes for all commands. The text you are proposing implies that all other commands can partly fail, but this is not clearly stated anywhere (that I recall - I might be wrong). I think that MODIFY and maybe MOVE need the same as what you are proposing. CREATE is a judgement call - on one side, it isn't as dangerous; on the other side, it would be if all commands that modify data behaved the same. Personally, I'd prefer this to be discussed in a common paragraph before the commands, not in each command description. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Jan 13 10:07:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12625 for ; Mon, 13 Jan 2003 10:07:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DEvPa09664 for ietf-calendar-bks; Mon, 13 Jan 2003 06:57:25 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0DEvNo09660 for ; Mon, 13 Jan 2003 06:57:23 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003011309581931055 for ; Mon, 13 Jan 2003 09:58:19 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 09:55:10 -0500 Message-ID: <3E22D34E.6090309@centive.com> Date: Mon, 13 Jan 2003 09:55:10 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? References: <3E21CF15.40001@Royer.com> <20030113093656.GB44480@inet.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2003 14:55:10.0559 (UTC) FILETIME=[C51D26F0:01C2BB13] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: >I think that MODIFY and maybe MOVE need the same as what you are >proposing. CREATE is a judgement call - on one side, it isn't >as dangerous; on the other side, it would be if all commands that >modify data behaved the same. > > One note: an implementor that makes DELETE and CREATE atomic will have a much easier time making MODIFY and MOVE atomic, too, since you could do it as "CREATE modified/moved components, DELETE originals, commit". So, if the spec says DELETE and CREATE are atomic, then probably MODIFY and MOVE should be, too. Let's see...MODIFY can modify two properties at a time, can't it? If so, then I'd say it should definitely be atomic, at least within each component; the opportunities for confusion are just too great, when you're changing properties that affect each other. Consider what happens if you're rescheduling an event, and changing the TZID at the same time; someone could wind up seeing the old TZID but the new DTSTART. Atomicity across components--being assured that none of them will change until they all do--is probably less important. Atomicity does complicate the implementations; but it's possible to provide it relatively simply. A low-end CS that doesn't need to perform wonderfully could simplify its atomicity requirements by serializing its writes--instead of doing full-fledged rollback logs, it could lock down the store while doing a write, and only have one outstanding write at a time. And, of course, any CS built on an RDBMS can just piggyback on the DB's own rollback. -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |Excuse me. I've been dead lately, and my brain isn't working too| |well. --Miles Vorkosigan | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Jan 13 10:49:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14298 for ; Mon, 13 Jan 2003 10:49:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DFies11055 for ietf-calendar-bks; Mon, 13 Jan 2003 07:44:40 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DFido11049 for ; Mon, 13 Jan 2003 07:44:39 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 49C9A15533; Mon, 13 Jan 2003 16:44:36 +0100 (CET) Date: Mon, 13 Jan 2003 16:44:36 +0100 From: Andrea Campi To: John Stracke Cc: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? Message-ID: <20030113154436.GF44480@inet.it> References: <3E21CF15.40001@Royer.com> <20030113093656.GB44480@inet.it> <3E22D34E.6090309@centive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E22D34E.6090309@centive.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jan 13, 2003 at 09:55:10AM -0500, John Stracke wrote: > Let's see...MODIFY can modify two properties at a time, can't it? If so, > then I'd say it should definitely be atomic, at least within each > component; the opportunities for confusion are just too great, when > you're changing properties that affect each other. Consider what Exactly. > happens if you're rescheduling an event, and changing the TZID at the > same time; someone could wind up seeing the old TZID but the new > DTSTART. Atomicity across components--being assured that none of them > will change until they all do--is probably less important. Possibly, but as a minimum we must define if we guarantee atomicity or not. > Atomicity does complicate the implementations; but it's possible to > provide it relatively simply. A low-end CS that doesn't need to perform I agree with your considerations but they are not all that is involved. For instance, my CS does things in this order: - look at all queries (we may have more than one in the same command), if any of them is invalid fail entire command - look at all targets, if any of them is invalid fail entire command - perform command in order Oh and by the way: there is confusion in the draft regarding whether an error should stop command processing and rollback immediately, or processing goes on to the end in order to report all errors. This needs to be clarified as well. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Jan 13 12:28:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17438 for ; Mon, 13 Jan 2003 12:28:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DHKaF15860 for ietf-calendar-bks; Mon, 13 Jan 2003 09:20:36 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DHKZo15856 for ; Mon, 13 Jan 2003 09:20:35 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0DHKato001860 for ; Mon, 13 Jan 2003 09:20:36 -0800 Message-ID: <3E22F55F.2020901@Royer.com> Date: Mon, 13 Jan 2003 10:20:31 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? References: <3E21CF15.40001@Royer.com> <20030113093656.GB44480@inet.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: > On Sun, Jan 12, 2003 at 01:24:53PM -0700, Doug Royer wrote: > >>I would like to add this text to the DELETE command in CAP: >> ... >>Comments? > > > I still think (as briefly mentioned before) that we should clearly > define failure modes for all commands. The text you are proposing > implies that all other commands can partly fail, but this is not > clearly stated anywhere (that I recall - I might be wrong). Yes. > I think that MODIFY and maybe MOVE need the same as what you are > proposing. CREATE is a judgement call - on one side, it isn't > as dangerous; on the other side, it would be if all commands that > modify data behaved the same. MODIFY already has that restriction: If any error occurred: No component will be changed at all. That is, it will appear just as it was prior to the modify and the CAP server SHOULD return a ... I think that CREATE does not need that restriction. I would be happy ether way. > Personally, I'd prefer this to be discussed in a common paragraph > before the commands, not in each command description. Of the commands I would say: CMD My thoughts --- ------------ ABORT Does not apply as there is no partial failure. CONTINUE Does not apply as there is no partial failure. CREATE Maybe an issue - YES DELETE YES GENERATE-UID Does not apply as there is no partial failure. GET-CAPABILITY Does not apply as there is no partial failure. IDENTIFY Does not apply as there is no partial failure. MODIFY YES MOVE YES REPLY Does not apply as there is no partial failure of REPLY SEARCH Does not apply as partial failures cause no harm. SET-LOCALE Does not apply as there is no partial failure. TIMEOUT Does not apply as there is no partial failure. It it would only apply to 3 commands not all of them. Correct? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Mon Jan 13 12:37:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17640 for ; Mon, 13 Jan 2003 12:37:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DHSst16457 for ietf-calendar-bks; Mon, 13 Jan 2003 09:28:54 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DHSro16451 for ; Mon, 13 Jan 2003 09:28:53 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0DHSsto001904 for ; Mon, 13 Jan 2003 09:28:54 -0800 Message-ID: <3E22F750.3080108@Royer.com> Date: Mon, 13 Jan 2003 10:28:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? References: <3E21CF15.40001@Royer.com> <20030113093656.GB44480@inet.it> <3E22D34E.6090309@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040600000309040700080901" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040600000309040700080901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > One note: an implementor that makes DELETE and CREATE atomic will have a > much easier time making MODIFY and MOVE atomic, too, since you could do > it as "CREATE modified/moved components, DELETE originals, commit". So, > if the spec says DELETE and CREATE are atomic, then probably MODIFY and > MOVE should be, too. I agree. > Let's see...MODIFY can modify two properties at a time, can't it? If so, > then I'd say it should definitely be atomic, at least within each > component; the opportunities for confusion are just too great, when > you're changing properties that affect each other. Consider what > happens if you're rescheduling an event, and changing the TZID at the > same time; someone could wind up seeing the old TZID but the new > DTSTART. Atomicity across components--being assured that none of them > will change until they all do--is probably less important. I agree - it is too dangerous to not make them atomic and there are simpler ways to do it than rollback. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040600000309040700080901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMTMxNzI4NDhaMCMGCSqGSIb3DQEJBDEWBBRg FrB7U0T24/zXfzXTzsupNKjbDjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAQ57e7nqPA4cR kjOc8TOL2YAM+x2qc0vVHTYKckFjijGN15YdSq1V34EfCA4hsoNC8b9Pi80Pc4WOiGgvAD1h fdXLDSuZaVdFvhWEONqKjtJzeu1Xah1jHgw/T1YjJM+1s0F9HiQrZGABni5O0ZuwNgRv7COp VpCaLagmqpEs3UmfUS4wADoHamhG+r6VG4etG/BfdBik01iO+bpP0Vvv26WI9Anz1dyzFDuY BXNJ1K/iWt1Y0hXZiBWs/LAL4CiqB53hf+BTpRmtrkmdBFS8L3SzT5cWWnYIxzdkMuYCAKvq YhvETUhEr7z9Ha9+TAOxSPJRqapLSvIKmS30SNxW7QAAAAAAAA== --------------ms040600000309040700080901-- From owner-ietf-calendar@mail.imc.org Mon Jan 13 12:51:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17915 for ; Mon, 13 Jan 2003 12:51:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DHioR16996 for ietf-calendar-bks; Mon, 13 Jan 2003 09:44:50 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0DHimo16992 for ; Mon, 13 Jan 2003 09:44:49 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003011312455412433 for ; Mon, 13 Jan 2003 12:45:54 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 12:42:44 -0500 Message-ID: <3E22FA94.3070800@centive.com> Date: Mon, 13 Jan 2003 12:42:44 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? References: <3E21CF15.40001@Royer.com> <20030113093656.GB44480@inet.it> <3E22F55F.2020901@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2003 17:42:44.0506 (UTC) FILETIME=[2DBBB7A0:01C2BB2B] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > I think that CREATE does not need that restriction. I would > be happy ether way. Let's see. A partial failure can certainly occur--say, if the system has enough disk space for the main VEVENT, but not for the VTIMEZONE in contains. In that case, the VEVENT would be invalid--and we probably do want to make sure that we don't put invalid iCalendar components into a CS, don't we? -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |"And bring the search warrant." "You mean the sledgehammer, sir?"| |"Yes." | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Jan 13 14:07:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20248 for ; Mon, 13 Jan 2003 14:07:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DJ0fe19138 for ietf-calendar-bks; Mon, 13 Jan 2003 11:00:41 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DJ0eo19134 for ; Mon, 13 Jan 2003 11:00:40 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0DJ0fto002567 for ; Mon, 13 Jan 2003 11:00:41 -0800 Message-ID: <3E230CD4.8090007@Royer.com> Date: Mon, 13 Jan 2003 12:00:36 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? References: <3E21CF15.40001@Royer.com> <20030113093656.GB44480@inet.it> <3E22F55F.2020901@Royer.com> <3E22FA94.3070800@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070505050204090903030006" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070505050204090903030006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > >> I think that CREATE does not need that restriction. I would >> be happy ether way. > > > Let's see. A partial failure can certainly occur--say, if the system > has enough disk space for the main VEVENT, but not for the VTIMEZONE in > contains. In that case, the VEVENT would be invalid--and we probably do > want to make sure that we don't put invalid iCalendar components into a > CS, don't we? > If there are no objections I'll add that restriction to CREATE DELETE MODIFY MOVE I'll add a general note at the top level describing the issue. I'll add a specific note to each of the 4 commands saying it applies to 'this' command. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070505050204090903030006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMTMxOTAwMzZaMCMGCSqGSIb3DQEJBDEWBBR2 2SFBtyIEPLL7upQ2DgHVY0mF4TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAMuLyXNjqbIwD Gh7FNAihlMBXLrfvV9cgxNB9jrmRcPYtmwrQEK9Xcs3c4S1OJAt1n1hZhEcgTWsRrbGAvBE8 U4Ax6wd8PdrBagMViK4+sxx+00kN9pm7r4UCVmw6AMd9lALJN/4eTkFGomYTPWFrrMD4FFVt Mzfm0KFhbGusVFeNMAssVkEgrBmg1s8bMoCG6Tx+T1VTkPCip+5KGB6dHjViATJ/xDbODr8w pj3cE3FbX3HRBZSH81FyU0885SlL9NgIT3Avt/k/wGjz8bgxvHwfejxUXTc5I8lBmOD7clGJ 93Y0jiGt+i/C2QH9fWzOueP0+rAtt7FXkhBJDY4RZwAAAAAAAA== --------------ms070505050204090903030006-- From owner-ietf-calendar@mail.imc.org Wed Jan 15 18:54:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15154 for ; Wed, 15 Jan 2003 18:54:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0FNp5s28048 for ietf-calendar-bks; Wed, 15 Jan 2003 15:51:05 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0FNp3o28044 for ; Wed, 15 Jan 2003 15:51:04 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 85D6B15533; Thu, 16 Jan 2003 00:51:01 +0100 (CET) Date: Thu, 16 Jan 2003 00:51:01 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Missing description of parameters Message-ID: <20030115235101.GA56931@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Doug and all, I might be looking at the wrong version of the draft, but I think we miss descriptions of some new parameters. In 2.1.1 and 7 we discuss LOCAL and ENABLE - shouldn't ACTION, ID, LATENCY, LOCALIZE and OPTIONS have the same? Besides, you mentioned before that some people get upset when a property and a parameter have the same name - ACTION is one such instance. You don't think we could rename ACTION to something else - TIMEOUT or ONTIMEOUT maybe? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Jan 15 19:28:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15828 for ; Wed, 15 Jan 2003 19:28:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0G0LUt29188 for ietf-calendar-bks; Wed, 15 Jan 2003 16:21:30 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0G0LTo29184 for ; Wed, 15 Jan 2003 16:21:29 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 9DD2E15533; Thu, 16 Jan 2003 01:21:31 +0100 (CET) Date: Thu, 16 Jan 2003 01:21:31 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: STORES-EXPANDED Message-ID: <20030116002131.GB56931@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, maybe I'm just being dense, but I still don't get the meaning and the intended use of STORES-EXPANDED and RECUR-EXPAND: STORES-EXPANDED 1 If TRUE then it expands multiple instances separately when they are stored (RRULEs converted to RDATEs) and when sent. If FALSE then it expands instances dynamically during sending. Default is FALSE. From the description, it seems as either way, "it" (the CS probably) must expand multiple "instances" - either when storing them or when sending them. But what if "it" is the CUA? Or, what if the CS doesn't want to expand? Also, queryprop lacks expand. I think we need to clarify the whole concept. Is this table right? if EXPAND=FALSE then the CS sends recurrences as-is - but if the CS has STORES-EXPANDED=TRUE - the server sends expanded recurrences, since it already expanded them if EXPAND=TRUE: if the CS has RECUR-EXPAND=TRUE - what? give an error? if the CS has STORES-EXPANDED=TRUE - the server sends expanded recurrences, it already expanded them if the CS has STORES-EXPANDED=FALSE - the server expands recurrences and sends them Somehow this all sounds complicated and not terribly useful... Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Jan 15 19:33:32 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16000 for ; Wed, 15 Jan 2003 19:33:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0G0Rsk29345 for ietf-calendar-bks; Wed, 15 Jan 2003 16:27:54 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0G0Rro29341 for ; Wed, 15 Jan 2003 16:27:53 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 0E67415533; Thu, 16 Jan 2003 01:27:56 +0100 (CET) Date: Thu, 16 Jan 2003 01:27:56 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: typo in 8.17 MULTIPART Property Message-ID: <20030116002756.GD56931@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As per subject: Description: This property is used in the in the "GET-CAPABILITY" comamnd reply to indicated the MIME multipart types supported. A CS and CUS SHOULD support all registered MIME multipart types. CUS should be CUA -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Jan 15 19:44:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16270 for ; Wed, 15 Jan 2003 19:44:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0G0eHY29618 for ietf-calendar-bks; Wed, 15 Jan 2003 16:40:17 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0G0eGo29614 for ; Wed, 15 Jan 2003 16:40:16 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0G0eHto031918 for ; Wed, 15 Jan 2003 16:40:18 -0800 Message-ID: <3E25FF6C.2070007@Royer.com> Date: Wed, 15 Jan 2003 17:40:12 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Missing description of parameters References: <20030115235101.GA56931@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060802080005040606090900" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060802080005040606090900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > Hi Doug and all, > > I might be looking at the wrong version of the draft, but I think > we miss descriptions of some new parameters. In 2.1.1 and 7 we > discuss LOCAL and ENABLE - shouldn't ACTION, ID, LATENCY, LOCALIZE > and OPTIONS have the same? Yes - the version of the draft is on the cover page as part of the file name. > Besides, you mentioned before that some people get upset when > a property and a parameter have the same name - ACTION is one such > instance. You don't think we could rename ACTION to something else - > TIMEOUT or ONTIMEOUT maybe? Good point. If I we here from anyone else in a week or so - I add this to my edit list. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060802080005040606090900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFqjCC AtEwggI6oAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgbsxCzAJBgNVBAYTAlVTMQ4wDAYDVQQI EwVJZGFobzEUMBIGA1UEBxMLSWRhaG8gRmFsbHMxIzAhBgNVBAoTGmh0dHA6Ly9JTkVULUNv bnN1bHRpbmcuY29tMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u MRIwEAYDVQQDEwlyb3llci5jb20xIzAhBgkqhkiG9w0BCQEWFGhvc3RtYXN0ZXJAcm95ZXIu Y29tMB4XDTAyMDMwNTAzMjYxNloXDTAzMDMwNTAzMjYxNlowNDETMBEGA1UEAxMKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYORG91Z0BSb3llci5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAM3PIShuwkPiVQksnNCKNJp5vQkAb8XuAzEdRosWrZB5zn5lb8EEgOtA2EbL 1DG9Y0RR0KaJzWKUI6s+H0POB/trmc2f4lIgtRnOrUOVjUSUYQcp6q949b7bHrhgA72kLeNC a+Q/R/cJQnq82C8MjConCKIvgHd+/nFP1lKFRioNAgMBAAGjazBpMBkGA1UdEQQSMBCBDkRv dWdAUm95ZXIuY29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU5BxDMi6+s0s1G32/6RRw nn7N67UwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GB AJGTJRemVJkpnlhYXtIs0Y89ln+Q1FvVIL035haRVJ0K1T9Lm2q7CjzK9TcCxeXy31BlfWl0 X+3FHNDzU/eqThdacZudpZB85AugMjscnSpz8SDmVDaLAa2IjHaYdOYqxBOhZCgUOVqwX5RR kqkNTgHLoU2mJ/pqtCcyDGHC0GDqMIIC0TCCAjqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCB uzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBUlkYWhvMRQwEgYDVQQHEwtJZGFobyBGYWxsczEj MCEGA1UEChMaaHR0cDovL0lORVQtQ29uc3VsdGluZy5jb20xKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xEjAQBgNVBAMTCXJveWVyLmNvbTEjMCEGCSqGSIb3 DQEJARYUaG9zdG1hc3RlckByb3llci5jb20wHhcNMDIwMzA1MDMyNjE2WhcNMDMwMzA1MDMy NjE2WjA0MRMwEQYDVQQDEwpEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5Eb3VnQFJveWVy LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzc8hKG7CQ+JVCSyc0Io0mnm9CQBv xe4DMR1GixatkHnOfmVvwQSA60DYRsvUMb1jRFHQponNYpQjqz4fQ84H+2uZzZ/iUiC1Gc6t Q5WNRJRhBynqr3j1vtseuGADvaQt40Jr5D9H9wlCerzYLwyMKicIoi+Ad37+cU/WUoVGKg0C AwEAAaNrMGkwGQYDVR0RBBIwEIEORG91Z0BSb3llci5jb20wDAYDVR0TAQH/BAIwADAfBgNV HSMEGDAWgBTkHEMyLr6zSzUbfb/pFHCefs3rtTAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAkZMlF6ZUmSmeWFhe0izRjz2Wf5DUW9UgvTfmFpFU nQrVP0ubarsKPMr1NwLF5fLfUGV9aXRf7cUc0PNT96pOF1pxm52lkHzkC6AyOxydKnPxIOZU NosBrYiMdph05irEE6FkKBQ5WrBflFGSqQ1OAcuhTaYn+mq0JzIMYcLQYOoxggL0MIIC8AIB ATCBwTCBuzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBUlkYWhvMRQwEgYDVQQHEwtJZGFobyBG YWxsczEjMCEGA1UEChMaaHR0cDovL0lORVQtQ29uc3VsdGluZy5jb20xKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xEjAQBgNVBAMTCXJveWVyLmNvbTEjMCEG CSqGSIb3DQEJARYUaG9zdG1hc3RlckByb3llci5jb20CAQEwCQYFKw4DAhoFAKCCAYgwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwMTE2MDA0MDEyWjAj BgkqhkiG9w0BCQQxFgQUSUWKBienDYhCGMivPAWVB9Hh0T4wUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgdQGCyqGSIb3DQEJEAILMYHEoIHBMIG7MQswCQYDVQQGEwJVUzEOMAwG A1UECBMFSWRhaG8xFDASBgNVBAcTC0lkYWhvIEZhbGxzMSMwIQYDVQQKExpodHRwOi8vSU5F VC1Db25zdWx0aW5nLmNvbTEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjESMBAGA1UEAxMJcm95ZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRob3N0bWFzdGVyQHJv eWVyLmNvbQIBATANBgkqhkiG9w0BAQEFAASBgAna34uOMRb8UQAb176hDtDlm0rqpmRLc+zr URufPDt+AXA+l5DD0PW0SOit8MAnqQSBbdeypTTSB3KzhqxXvIezotOKmoMqBkKGNn7wOiSh GpVUhLyTgFl9IB5vTYZgdJDjvmIqY9jkrlPh4NUBdKNpdo0qbQhp422rxlmi6WDKAAAAAAAA --------------ms060802080005040606090900-- From owner-ietf-calendar@mail.imc.org Wed Jan 15 20:26:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15829 for ; Wed, 15 Jan 2003 19:28:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0G0Opv29266 for ietf-calendar-bks; Wed, 15 Jan 2003 16:24:51 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0G0Ooo29262 for ; Wed, 15 Jan 2003 16:24:50 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 354E715533; Thu, 16 Jan 2003 01:24:53 +0100 (CET) Date: Thu, 16 Jan 2003 01:24:53 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: RECUR-ACCEPTED duplicated in 10.3 Message-ID: <20030116002453.GC56931@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Subject says all - it's there twice -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 16 11:56:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16038 for ; Thu, 16 Jan 2003 11:56:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GGqFP03534 for ietf-calendar-bks; Thu, 16 Jan 2003 08:52:15 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0GGqEo03530 for ; Thu, 16 Jan 2003 08:52:14 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0GGqFto006503 for ; Thu, 16 Jan 2003 08:52:15 -0800 Message-ID: <3E26E33A.6020302@Royer.com> Date: Thu, 16 Jan 2003 09:52:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: STORES-EXPANDED References: <20030116002131.GB56931@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040802080200070202040103" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040802080200070202040103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > Hi all, > > maybe I'm just being dense, but I still don't get the meaning and the intended > use of STORES-EXPANDED and RECUR-EXPAND: > > Also, queryprop lacks expand. Not all of the vendors had the same model. Rather then decide on who would have to change (and they said they would not), we ignored the differences and decided to appease everyone by documenting the differences. One major vendor stores the object AFTER expanding the instances. If you give them an RRULE with 10 instances, they store 10 objects. EACH with the RRULE removed and replaced with an RDATE. And they also silently truncated the number of instances to an unspecified number. So we added the RECUR-LIMIT so the CUA would know if they had a limit. Similar with the CUA's. The reality is that not all CUA's are going to be able to expand instances and not all CS's are going to expand instances. Not all CUAs can handle recurrence rules (I do not know of any CS's that can not). The capability properties are so that each endpoint can tell what the other end can and can not do. > Also, queryprop lacks expand. Added -thanks. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040802080200070202040103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFqjCC AtEwggI6oAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgbsxCzAJBgNVBAYTAlVTMQ4wDAYDVQQI EwVJZGFobzEUMBIGA1UEBxMLSWRhaG8gRmFsbHMxIzAhBgNVBAoTGmh0dHA6Ly9JTkVULUNv bnN1bHRpbmcuY29tMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u MRIwEAYDVQQDEwlyb3llci5jb20xIzAhBgkqhkiG9w0BCQEWFGhvc3RtYXN0ZXJAcm95ZXIu Y29tMB4XDTAyMDMwNTAzMjYxNloXDTAzMDMwNTAzMjYxNlowNDETMBEGA1UEAxMKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYORG91Z0BSb3llci5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAM3PIShuwkPiVQksnNCKNJp5vQkAb8XuAzEdRosWrZB5zn5lb8EEgOtA2EbL 1DG9Y0RR0KaJzWKUI6s+H0POB/trmc2f4lIgtRnOrUOVjUSUYQcp6q949b7bHrhgA72kLeNC a+Q/R/cJQnq82C8MjConCKIvgHd+/nFP1lKFRioNAgMBAAGjazBpMBkGA1UdEQQSMBCBDkRv dWdAUm95ZXIuY29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU5BxDMi6+s0s1G32/6RRw nn7N67UwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GB AJGTJRemVJkpnlhYXtIs0Y89ln+Q1FvVIL035haRVJ0K1T9Lm2q7CjzK9TcCxeXy31BlfWl0 X+3FHNDzU/eqThdacZudpZB85AugMjscnSpz8SDmVDaLAa2IjHaYdOYqxBOhZCgUOVqwX5RR kqkNTgHLoU2mJ/pqtCcyDGHC0GDqMIIC0TCCAjqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCB uzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBUlkYWhvMRQwEgYDVQQHEwtJZGFobyBGYWxsczEj MCEGA1UEChMaaHR0cDovL0lORVQtQ29uc3VsdGluZy5jb20xKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xEjAQBgNVBAMTCXJveWVyLmNvbTEjMCEGCSqGSIb3 DQEJARYUaG9zdG1hc3RlckByb3llci5jb20wHhcNMDIwMzA1MDMyNjE2WhcNMDMwMzA1MDMy NjE2WjA0MRMwEQYDVQQDEwpEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5Eb3VnQFJveWVy LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzc8hKG7CQ+JVCSyc0Io0mnm9CQBv xe4DMR1GixatkHnOfmVvwQSA60DYRsvUMb1jRFHQponNYpQjqz4fQ84H+2uZzZ/iUiC1Gc6t Q5WNRJRhBynqr3j1vtseuGADvaQt40Jr5D9H9wlCerzYLwyMKicIoi+Ad37+cU/WUoVGKg0C AwEAAaNrMGkwGQYDVR0RBBIwEIEORG91Z0BSb3llci5jb20wDAYDVR0TAQH/BAIwADAfBgNV HSMEGDAWgBTkHEMyLr6zSzUbfb/pFHCefs3rtTAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAkZMlF6ZUmSmeWFhe0izRjz2Wf5DUW9UgvTfmFpFU nQrVP0ubarsKPMr1NwLF5fLfUGV9aXRf7cUc0PNT96pOF1pxm52lkHzkC6AyOxydKnPxIOZU NosBrYiMdph05irEE6FkKBQ5WrBflFGSqQ1OAcuhTaYn+mq0JzIMYcLQYOoxggL0MIIC8AIB ATCBwTCBuzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBUlkYWhvMRQwEgYDVQQHEwtJZGFobyBG YWxsczEjMCEGA1UEChMaaHR0cDovL0lORVQtQ29uc3VsdGluZy5jb20xKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xEjAQBgNVBAMTCXJveWVyLmNvbTEjMCEG CSqGSIb3DQEJARYUaG9zdG1hc3RlckByb3llci5jb20CAQEwCQYFKw4DAhoFAKCCAYgwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwMTE2MTY1MjEwWjAj BgkqhkiG9w0BCQQxFgQUQGZOnDVkiBnasJ2COolPH/uxiscwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgdQGCyqGSIb3DQEJEAILMYHEoIHBMIG7MQswCQYDVQQGEwJVUzEOMAwG A1UECBMFSWRhaG8xFDASBgNVBAcTC0lkYWhvIEZhbGxzMSMwIQYDVQQKExpodHRwOi8vSU5F VC1Db25zdWx0aW5nLmNvbTEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjESMBAGA1UEAxMJcm95ZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRob3N0bWFzdGVyQHJv eWVyLmNvbQIBATANBgkqhkiG9w0BAQEFAASBgDEX6jCeen9Fwqsz+NdgmNFhsdg+9aKdD2+X 0+aSwg7QpLq9Kkoj6PPAaV5bJre2dYn1Jy5cpXqSv/UkBLvy12VGQ/Xa9/Q+dCyI98/uqs3O buW1GBXcomB6MPuD9dgfSFhluCXogFB5m7MuSS6q+Cs+J/K2FLRCdLr2Gj+ZhBQoAAAAAAAA --------------ms040802080200070202040103-- From owner-ietf-calendar@mail.imc.org Thu Jan 16 12:02:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16204 for ; Thu, 16 Jan 2003 12:02:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GGsHw03613 for ietf-calendar-bks; Thu, 16 Jan 2003 08:54:17 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0GGsGo03603 for ; Thu, 16 Jan 2003 08:54:16 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0GGsHto006511 for ; Thu, 16 Jan 2003 08:54:17 -0800 Message-ID: <3E26E3B4.9090602@Royer.com> Date: Thu, 16 Jan 2003 09:54:12 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECUR-ACCEPTED duplicated in 10.3 References: <20030116002453.GC56931@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020607050700040105050509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020607050700040105050509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks! Andrea Campi wrote: > Subject says all - it's there twice > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020607050700040105050509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFqjCC AtEwggI6oAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgbsxCzAJBgNVBAYTAlVTMQ4wDAYDVQQI EwVJZGFobzEUMBIGA1UEBxMLSWRhaG8gRmFsbHMxIzAhBgNVBAoTGmh0dHA6Ly9JTkVULUNv bnN1bHRpbmcuY29tMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u MRIwEAYDVQQDEwlyb3llci5jb20xIzAhBgkqhkiG9w0BCQEWFGhvc3RtYXN0ZXJAcm95ZXIu Y29tMB4XDTAyMDMwNTAzMjYxNloXDTAzMDMwNTAzMjYxNlowNDETMBEGA1UEAxMKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYORG91Z0BSb3llci5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAM3PIShuwkPiVQksnNCKNJp5vQkAb8XuAzEdRosWrZB5zn5lb8EEgOtA2EbL 1DG9Y0RR0KaJzWKUI6s+H0POB/trmc2f4lIgtRnOrUOVjUSUYQcp6q949b7bHrhgA72kLeNC a+Q/R/cJQnq82C8MjConCKIvgHd+/nFP1lKFRioNAgMBAAGjazBpMBkGA1UdEQQSMBCBDkRv dWdAUm95ZXIuY29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU5BxDMi6+s0s1G32/6RRw nn7N67UwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GB AJGTJRemVJkpnlhYXtIs0Y89ln+Q1FvVIL035haRVJ0K1T9Lm2q7CjzK9TcCxeXy31BlfWl0 X+3FHNDzU/eqThdacZudpZB85AugMjscnSpz8SDmVDaLAa2IjHaYdOYqxBOhZCgUOVqwX5RR kqkNTgHLoU2mJ/pqtCcyDGHC0GDqMIIC0TCCAjqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCB uzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBUlkYWhvMRQwEgYDVQQHEwtJZGFobyBGYWxsczEj MCEGA1UEChMaaHR0cDovL0lORVQtQ29uc3VsdGluZy5jb20xKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xEjAQBgNVBAMTCXJveWVyLmNvbTEjMCEGCSqGSIb3 DQEJARYUaG9zdG1hc3RlckByb3llci5jb20wHhcNMDIwMzA1MDMyNjE2WhcNMDMwMzA1MDMy NjE2WjA0MRMwEQYDVQQDEwpEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5Eb3VnQFJveWVy LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzc8hKG7CQ+JVCSyc0Io0mnm9CQBv xe4DMR1GixatkHnOfmVvwQSA60DYRsvUMb1jRFHQponNYpQjqz4fQ84H+2uZzZ/iUiC1Gc6t Q5WNRJRhBynqr3j1vtseuGADvaQt40Jr5D9H9wlCerzYLwyMKicIoi+Ad37+cU/WUoVGKg0C AwEAAaNrMGkwGQYDVR0RBBIwEIEORG91Z0BSb3llci5jb20wDAYDVR0TAQH/BAIwADAfBgNV HSMEGDAWgBTkHEMyLr6zSzUbfb/pFHCefs3rtTAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAkZMlF6ZUmSmeWFhe0izRjz2Wf5DUW9UgvTfmFpFU nQrVP0ubarsKPMr1NwLF5fLfUGV9aXRf7cUc0PNT96pOF1pxm52lkHzkC6AyOxydKnPxIOZU NosBrYiMdph05irEE6FkKBQ5WrBflFGSqQ1OAcuhTaYn+mq0JzIMYcLQYOoxggL0MIIC8AIB ATCBwTCBuzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBUlkYWhvMRQwEgYDVQQHEwtJZGFobyBG YWxsczEjMCEGA1UEChMaaHR0cDovL0lORVQtQ29uc3VsdGluZy5jb20xKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xEjAQBgNVBAMTCXJveWVyLmNvbTEjMCEG CSqGSIb3DQEJARYUaG9zdG1hc3RlckByb3llci5jb20CAQEwCQYFKw4DAhoFAKCCAYgwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwMTE2MTY1NDEyWjAj BgkqhkiG9w0BCQQxFgQUtpVTFhbAJRSHv5XnmUChmL+q9PAwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgdQGCyqGSIb3DQEJEAILMYHEoIHBMIG7MQswCQYDVQQGEwJVUzEOMAwG A1UECBMFSWRhaG8xFDASBgNVBAcTC0lkYWhvIEZhbGxzMSMwIQYDVQQKExpodHRwOi8vSU5F VC1Db25zdWx0aW5nLmNvbTEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjESMBAGA1UEAxMJcm95ZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRob3N0bWFzdGVyQHJv eWVyLmNvbQIBATANBgkqhkiG9w0BAQEFAASBgCu/VAvFCUGznZ/j4f+fPXUX1QFG+1IZlVRs 6UP3RKNGQVNH7z1ykPVkbLIJQ9lm7uCj6i12pRQZ0ObVvcMG8yLK/fOTese9f2vXmQEgVDS7 CIYP43am5HmUBP4H799yiDkXljLtUuL/o138lByklOPKzJOVhTri/iBHx/PIbj6NAAAAAAAA --------------ms020607050700040105050509-- From owner-ietf-calendar@mail.imc.org Fri Jan 17 05:33:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17600 for ; Fri, 17 Jan 2003 05:33:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HANIC25760 for ietf-calendar-bks; Fri, 17 Jan 2003 02:23:18 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HANEo25753 for ; Fri, 17 Jan 2003 02:23:17 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 765F215533; Fri, 17 Jan 2003 11:23:09 +0100 (CET) Date: Fri, 17 Jan 2003 11:23:09 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: STORES-EXPANDED Message-ID: <20030117102309.GA63049@inet.it> References: <20030116002131.GB56931@inet.it> <3E26E33A.6020302@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E26E33A.6020302@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jan 16, 2003 at 09:52:10AM -0700, Doug Royer wrote: > Not all of the vendors had the same model. Rather then decide > on who would have to change (and they said they would not), > we ignored the differences and decided to appease everyone > by documenting the differences. [...] > > The capability properties are so that each endpoint can > tell what the other end can and can not do. That's all fine and good, but then I think we need to change: STORES-EXPANDED 1 If TRUE then it expands multiple instances separately when they are stored (RRULEs converted to RDATEs) and when sent. If FALSE then it expands instances dynamically during sending. Default is FALSE. to: STORES-EXPANDED 1 If TRUE then it expands multiple instances separately when they are stored (RRULEs converted to RDATEs) and when sent. If FALSE then it stores instances as they are. Default is FALSE. Also, reading this: RECUR-EXPAND 1 Whether or not it supports the expansion of recurrence rules. TRUE (default) or FALSE. If a CS has STORES-EXPANDED:FALSE RECUR-EXPAND:TRUE am I right in assuming it means that it will only expand recurrences if explicitely asked to, via the EXPAND parameter? Also, in both cases, we might need to clarify whether `it' refers to a CS only, or how would that apply to a CUA. While for instance RECUR-ACCEPTED is meaningful for a CUA as well, I don't see how STORES-EXPANDED would apply (a CUA doesn't really store, and the CS wouldn't care anyway). So I'd change STORES-EXPANDED and RECUR-EXPAND to read `the CS' instead of `it', and note they only apply to CS. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Jan 20 09:40:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21031 for ; Mon, 20 Jan 2003 09:40:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KEYIJ11588 for ietf-calendar-bks; Mon, 20 Jan 2003 06:34:18 -0800 (PST) Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KEYGo11578 for ; Mon, 20 Jan 2003 06:34:17 -0800 (PST) Received: from fuzzbox (81-86-188-66.dsl.pipex.com [81.86.188.66]) by colossus.systems.pipex.net (Postfix) with ESMTP id 428A716000485 for ; Mon, 20 Jan 2003 14:34:09 +0000 (GMT) Received: from 127.0.0.1 by fuzzbox ([127.0.0.1] running VPOP3) with SMTP for ; Mon, 20 Jan 2003 14:34:32 -0000 Message-ID: <022201c2c091$0b4cf920$0100a8c0@fuzzbox> From: "Mike Higginbottom" To: Subject: When to specify TARGET property Date: Mon, 20 Jan 2003 14:34:30 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_021F_01C2C091.0B0A4AD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Server: VPOP3 Enterprise V1.5.0 - Registered Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_021F_01C2C091.0B0A4AD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm just trying to get to grips with CAP and am not sure how 'drafty' = the current draft is since I seem to be finding quite a few = inconsistencies which I can't resolve. Quoting from Doug's recent = posting of cap-12-jan-2003 8.36 TARGET Property Property Name: TARGET Purpose: This property defines the container that the command that is issued will act upon. Its value is a capurl as defined in Section 5. The "TARGET" property MUST BE supplied when the CUA sends a command to the CS. which seems to imply the TARGET property must be supplied for ABORT = commands for example. Is this correct? Regards Mike Higginbottom ------=_NextPart_000_021F_01C2C091.0B0A4AD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm just trying to get to grips with = CAP and am not=20 sure how 'drafty' the current draft is since I seem to be finding quite = a few=20 inconsistencies which I can't resolve.  Quoting from Doug's recent = posting=20 of cap-12-jan-2003
 
<quote>
 
8.36 TARGET Property
 
   Property Name: = TARGET
 
   Purpose: This property = defines the=20 container that the command that is
   issued will act = upon. =20 Its value is a capurl as defined in Section 5.
   The = "TARGET"=20 property MUST BE supplied when the CUA sends a command
   = to the=20 CS.
</quote>
 
which seems to imply the TARGET = property must be=20 supplied for ABORT commands for example.  Is this = correct?
 
 
Regards
 
Mike = Higginbottom
------=_NextPart_000_021F_01C2C091.0B0A4AD0-- From owner-ietf-calendar@mail.imc.org Mon Jan 20 15:05:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29240 for ; Mon, 20 Jan 2003 15:05:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KJwHb25194 for ietf-calendar-bks; Mon, 20 Jan 2003 11:58:17 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KJwGo25190 for ; Mon, 20 Jan 2003 11:58:16 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0KJwGto005177 for ; Mon, 20 Jan 2003 11:58:17 -0800 Message-ID: <3E2C54D3.30207@Royer.com> Date: Mon, 20 Jan 2003 12:58:11 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to specify TARGET property References: <022201c2c091$0b4cf920$0100a8c0@fuzzbox> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070207030006000305090401" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070207030006000305090401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mike Higginbottom wrote: > I'm just trying to get to grips with CAP and am not sure how 'drafty' > the current draft is since I seem to be finding quite a few > inconsistencies which I can't resolve. PLEASE post - thanks! > Quoting from Doug's recent > posting of cap-12-jan-2003 > > > > 8.36 TARGET Property > > Property Name: TARGET > > Purpose: This property defines the container that the command that is > issued will act upon. Its value is a capurl as defined in Section 5. > The "TARGET" property MUST BE supplied when the CUA sends a command > to the CS. > > > which seems to imply the TARGET property must be supplied for ABORT > commands for example. Is this correct? Good point - I'll tweak the text. I do not think it is needed with the ABORT command. Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070207030006000305090401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjAxOTU4MTFaMCMGCSqGSIb3DQEJBDEWBBTX TDAVeq2vk/HX9EtGn+kA48VCaTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAssgVb8WxIaj6 ohY8oCAoTisUbX2ZXn6BaT4oLhFRgc7j3W2oqGZxHcUnH9sOaUEPzfdo7jbNi+I6n7NWPeO5 jMhIFme/ie8A91pbuM5YkxuvqrZXqAZmKVVsRtzr9ifbNHwUfShL9GwFke0LGIJa4aR4i6Hy wXNF3i0P3eOCauei/q0xmul4KHcZXyVeZhqVqdDUWc8adAnJ71ekXHes8K5asIVDLH+sym3k bsbVRBt3Hy2MDQmlIYckMfiL3RbprPi67F+agy6TfRk59e3g3Kq4tMB8grBS5WNjuvwlyFE1 1dO5gEfuMF2ROAhGG/4MYVGZFSMTVAbqlbc8gw52MwAAAAAAAA== --------------ms070207030006000305090401-- From owner-ietf-calendar@mail.imc.org Mon Jan 20 18:35:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04537 for ; Mon, 20 Jan 2003 18:35:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KNNba00945 for ietf-calendar-bks; Mon, 20 Jan 2003 15:23:37 -0800 (PST) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KNNZo00933 for ; Mon, 20 Jan 2003 15:23:35 -0800 (PST) Received: from fuzzbox (81-86-188-66.dsl.pipex.com [81.86.188.66]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 3A95B1600B639 for ; Mon, 20 Jan 2003 23:23:32 +0000 (GMT) Received: from 127.0.0.1 by fuzzbox ([127.0.0.1] running VPOP3) with SMTP for ; Mon, 20 Jan 2003 23:12:07 -0000 Message-ID: <027601c2c0d9$59a9c650$0100a8c0@fuzzbox> From: "Mike Higginbottom" To: References: <022201c2c091$0b4cf920$0100a8c0@fuzzbox> <3E2C54D3.30207@Royer.com> Subject: Re: When to specify TARGET property Date: Mon, 20 Jan 2003 23:12:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Server: VPOP3 Enterprise V1.5.0 - Registered Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Doug Royer" To: Sent: Monday, January 20, 2003 7:58 PM Subject: Re: When to specify TARGET property > > the current draft is since I seem to be finding quite a few > > inconsistencies which I can't resolve. > > PLEASE post - thanks! > Will do. Just wanted to check that there are still errors like this in the document rather than it just being my lack of a grasp of the content. There are also some trivial typos. Shall I post these direct to you off list rather than causing pollution for little gain? > > > > which seems to imply the TARGET property must be supplied for ABORT > > commands for example. Is this correct? > > Good point - I'll tweak the text. I do not think it is needed > with the ABORT command. > Ditto some other commands. IMO, the only commands that require a TARGET property are CREATE, DELETE, MODIFY, MOVE and SEARCH. REPLY commands require a TARGET property only if the original request command required one (e.g. a REPLY to a CREATE command does but not a REPLY to an ABORT command). Regards Mike Higginbottom From owner-ietf-calendar@mail.imc.org Mon Jan 20 18:39:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04613 for ; Mon, 20 Jan 2003 18:39:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KNNcQ00946 for ietf-calendar-bks; Mon, 20 Jan 2003 15:23:38 -0800 (PST) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KNNZo00934 for ; Mon, 20 Jan 2003 15:23:35 -0800 (PST) Received: from fuzzbox (81-86-188-66.dsl.pipex.com [81.86.188.66]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 213EB1600B579 for ; Mon, 20 Jan 2003 23:23:33 +0000 (GMT) Received: from 127.0.0.1 by fuzzbox ([127.0.0.1] running VPOP3) with SMTP for ; Mon, 20 Jan 2003 23:23:52 -0000 Message-ID: <028801c2c0da$fdff3680$0100a8c0@fuzzbox> From: "Mike Higginbottom" To: Subject: IDENTIFY command response Date: Mon, 20 Jan 2003 23:23:51 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0285_01C2C0DA.FDB7A630" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Server: VPOP3 Enterprise V1.5.0 - Registered Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0285_01C2C0DA.FDB7A630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The examples in 10.4 of cap-12-jan-2003 do not wrap the REQUEST-STATUS = in a VREPLY component. They seem to be left naked in the VCALENDAR = section. Is this correct? Regards Mike Higginbottom ------=_NextPart_000_0285_01C2C0DA.FDB7A630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The examples in 10.4 of cap-12-jan-2003 = do not wrap=20 the REQUEST-STATUS in a VREPLY component.  They seem to be left = naked in=20 the VCALENDAR section.  Is this correct?
 
Regards
 
Mike = Higginbottom
------=_NextPart_000_0285_01C2C0DA.FDB7A630-- From owner-ietf-calendar@mail.imc.org Mon Jan 20 19:26:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04536 for ; Mon, 20 Jan 2003 18:35:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KNNcX00947 for ietf-calendar-bks; Mon, 20 Jan 2003 15:23:38 -0800 (PST) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KNNao00938 for ; Mon, 20 Jan 2003 15:23:36 -0800 (PST) Received: from fuzzbox (81-86-188-66.dsl.pipex.com [81.86.188.66]) by shockwave.systems.pipex.net (Postfix) with ESMTP id A5F151600B6B9 for ; Mon, 20 Jan 2003 23:23:33 +0000 (GMT) Received: from 127.0.0.1 by fuzzbox ([127.0.0.1] running VPOP3) with SMTP for ; Mon, 20 Jan 2003 23:20:32 -0000 Message-ID: <027f01c2c0da$86c73180$0100a8c0@fuzzbox> From: "Mike Higginbottom" To: Subject: CREATE command response format Date: Mon, 20 Jan 2003 23:20:31 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027C_01C2C0DA.867FA130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Server: VPOP3 Enterprise V1.5.0 - Registered Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_027C_01C2C0DA.867FA130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From cap-12-jan-2203: create-vreply =3D "BEGIN" ":" "VREPLY" CRLF created-id request-status other-props "END" ":" "VREPLY" CRLF ; Where the id is appropriate for the ; type of object created: ; ; VAGENDA =3D calid ; VCAR =3D carid ; VEVENT, VFREEBUSY, VJOURNAL, VTODO =3D uid ; VQUERY =3D queryid ; x-component =3D x-id should be replaced with: create-vreply =3D "BEGIN" ":" "VREPLY" CRLF created-id request-status other-props "END" ":" "VREPLY" CRLF ; Where the id is appropriate for the ; type of object created: ; ; VAGENDA =3D calid ; VALARM =3D sequence ; VCAR =3D carid ; VEVENT, VFREEBUSY, VJOURNAL, VTODO =3D uid ; VQUERY =3D queryid ; VTIMEZONE =3D tzid ; x-component =3D x-id to include VALARM and VTIMEZONE Regards Mike Higginbottom ------=_NextPart_000_027C_01C2C0DA.867FA130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From cap-12-jan-2203:

   create-vreply  =3D = "BEGIN" ":"=20 "VREPLY"=20 CRLF
           = ;        =20 created-id
          = ;         =20 request-status
         &= nbsp;         =20 other-props
         &nbs= p;         =20 "END" ":" "VREPLY" CRLF

          &nbs= p;      =20 ; Where the id is appropriate for=20 the
           =       =20 ; type of object=20 created:
          &= nbsp;      =20 ;
           &n= bsp;     =20 ; VAGENDA =3D=20 calid
          &nbs= p;      =20 ; VCAR =3D=20 carid
          &nbs= p;      =20 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO =3D=20 uid
           =       =20 ; VQUERY =3D=20 queryid
          &n= bsp;      =20 ; x-component =3D x-id

should be replaced with:

   create-vreply  =3D = "BEGIN" ":"=20 "VREPLY"=20 CRLF
           = ;        =20 created-id
          = ;         =20 request-status
         &= nbsp;         =20 other-props
         &nbs= p;         =20 "END" ":" "VREPLY" CRLF

          &nbs= p;      =20 ; Where the id is appropriate for=20 the
           =       =20 ; type of object=20 created:
          &= nbsp;      =20 ;
           &n= bsp;     =20 ; VAGENDA =3D=20 calid
          &nbs= p;      =20 ; VALARM=20 =3D sequence
        &nbs= p;        =20 ; VCAR =3D=20 carid
          &nbs= p;      =20 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO =3D uid
          &nbs= p;      =20 ; VQUERY =3D queryid
         = ;        =20 ; VTIMEZONE =3D tzid
         = ;        =20 ; x-component =3D x-id

to include VALARM and = VTIMEZONE

 

Regards

 

Mike=20 Higginbottom

------=_NextPart_000_027C_01C2C0DA.867FA130-- From owner-ietf-calendar@mail.imc.org Tue Jan 21 14:00:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08904 for ; Tue, 21 Jan 2003 14:00:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LIqlf08008 for ietf-calendar-bks; Tue, 21 Jan 2003 10:52:47 -0800 (PST) Received: from ace.iris.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LIqko08004 for ; Tue, 21 Jan 2003 10:52:46 -0800 (PST) In-Reply-To: <3DF13B0B.1050507@Royer.com> To: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 21 Jan 2003 13:52:45 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/21/2003 01:52:39 PM, Serialize complete at 01/21/2003 01:52:39 PM Content-Type: multipart/alternative; boundary="=_alternative 0067B7E085256CB5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067B7E085256CB5_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 12/06/2002 07:04:27 PM: > > if I stored the QUERY? Why isnt the TARGET from the VCALENDAR > > sufficient to find the VQUERY in RELCALID01? > > Only when the stored query is in the current TARGET. The VQUERY > TARGET is for when it is not - I'll update the draft to say > that TARGET is used in the VQUERY when the stored QUERY is not > in the CMD-TARGET. Hmmm. Dont forget to add some relevant text with cavats about accessing stored VQUERYs in a different VAGENDA than the one(s) that are TARGETed. I can see being able to use a stored query from one of my other calendar (ie: the one I stored in my "work" calendar when searching my "personal" calendar). However there are some big security concerns to factor in when trying to use a TARGET that I may not have access to. That is, I try to search my calendar using my boses "SALARY_SUMMARY" stored query could result in either me getting some data OR being rejected by the CS since I do not have the ability to read the stored query to use it... The failure case for this scenario need to be clearly defined so its not left to the implementors imagination. (Its a different failure than "query not found" since it may exist but Im rejected for security reasons...) > > Hmm, are you trying to use a stored VQUERY from a someone elses > > calendar, is that it?? > > Yes - see this WG list over the last few months. Did a search and didnt see any thread on it. Can you refer to some threads I may have missed? I for one see this as being in the 5 category in the 95/5 Rule. It may be a niceity but I certainly do not expect to store querys for others OR use theirs on _my_ calendar in the average course of things. What kind of scenario does this realistically happen on a frequent basis to warrant its inclusion in the design?? Bruce PS: Im back from a ~4 week vacation that I really needed and have lots to catch up on. Ill try to keep resolved thread resurections to an absolute minimum... =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0067B7E085256CB5_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 12/06/2002 07:04:27 PM:
> > if I stored the QUERY?  Why isnt the TARGET from the VCALENDAR
> > sufficient to find the VQUERY in RELCALID01?
>
> Only when the stored query is in the current TARGET. The VQUERY
> TARGET is for when it is not - I'll update the draft to say
> that TARGET is used in the VQUERY when the stored QUERY is not
> in the CMD-TARGET.
Hmmm.  Dont forget to add some relevant text with cavats about accessing stored VQUERYs in a different VAGENDA than the one(s) that are TARGETed.

I can see being able to use a stored query from one of my other calendar (ie: the one I stored in my "work" calendar when searching my "personal" calendar).  However there are some big security concerns to factor in when trying to use a TARGET that I may not have access to.  That is, I try to search my calendar using my boses "SALARY_SUMMARY" stored query could result in either me getting some data OR being rejected by the CS since I do not have the ability to read the stored query to use it...  The failure case for this scenario need to be clearly defined so its not left to the implementors imagination.  (Its a different failure than "query not found" since it may exist but Im rejected for security reasons...)

> > Hmm, are you trying to use a stored VQUERY from a someone elses
> > calendar, is that it??
>
> Yes - see this WG list over the last few months.
Did a search and didnt see any thread on it.  Can you refer to some threads I may have missed?

I for one see this as being in the 5 category in the 95/5 Rule.  It may be a niceity but I certainly do not expect to store querys for others OR use theirs on _my_ calendar in the average course of things.  What kind of scenario does this realistically happen on a frequent basis to warrant its inclusion in the design??  

Bruce
PS: Im back from a ~4 week vacation that I really needed and have lots to catch up on.  Ill try to keep resolved thread resurections to an absolute minimum...
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0067B7E085256CB5_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 21 14:22:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09407 for ; Tue, 21 Jan 2003 14:22:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LJGxf08566 for ietf-calendar-bks; Tue, 21 Jan 2003 11:16:59 -0800 (PST) Received: from ace.iris.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LJGvo08561 for ; Tue, 21 Jan 2003 11:16:57 -0800 (PST) In-Reply-To: <3DF13C01.50109@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP ABNF and external references MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 21 Jan 2003 14:16:52 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/21/2003 02:16:49 PM, Serialize complete at 01/21/2003 02:16:49 PM Content-Type: multipart/alternative; boundary="=_alternative 0069ED2F85256CB5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069ED2F85256CB5_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 12/06/2002 07:08:33 PM: > > Sorry but that text does NOT cover partial results. > > Please explain 'partial results' and where it is in the draft. Really?!? Ok, mathematically stated its: partial results = NOT (all the results) In English its described as 'If you dont get _ALL_ the results then you only got _PARTIAL_ results." (For those nitpickers here I view "NO results = ALL results" since there set of results to results is empty.) Its not a term you put in the draft (09-submitted or before), its one _I_ used in this thread when discussing the issue of Bounded Latency and the text cited below. Previously I responded to you with: > > If a CS can both start sending the reply to a command and guarantee > > that all of the results can be sent from a command (short of > > something like network or power falure), prior to the "LATENCY" > > timeout value, then the "LETENCY" time has not expired. > > Sorry but that text does NOT cover partial results. It clearly says > "guarantee that _all_ of the results" (my emphasis) and that is > definitely NOT partial results! Perhaps you are thinking that "all > results" simply indicate that its a partial result and that another try is necessary??.. (Please say no... Please!) Your (double quoted above) text does NOT address the case where the CS cannot "guarantee that all of the results" can be sent in time. The CS may or may not be able to tell if it can send all 10M in 5 seconds or not (I have lots of calendar entries!) even though it was able to find all 10M in the blink of an eye. Taking a step back to try and clarify this, I see 2 distinct cases that seem to be blurred into 1 in the draft. Case 1 is that the CS cannot fulfill the request in the alloted time (too much data to sort thru, exceeds CS policy contstraints, etc). Case 2 is that the CS can fulfill the request in the alloted time but it cannot push the results back fast enough (ie: Cant shove a 10M ATTACHment and related entry thru a 500K Cable Modem in 10 seconds). For Case 1 failure should be presented as "The system needs more time to find the results you want". For Case 2 failure should be presented as "The system is pushing back the data as fast as it can but it will not complete by the time you want." I view Case 1 as the real bounded latency issue. I think Case 2 is getting lumped in incorrectly (by the cited text "guarantee that all of the results..."). I do not think that Case 2 is grounds for failing the request. If the CS is in the process of pushing back the data and the latency time is exceeded then WHAT should happen? The CUA has received some of the results from the CS (my "partial results" you asked about) but not all of them. Should the command be terminated and if so, by whom? If not, what means does the requesting side have for cancelling the stream? If the command is to ABORT then just how should we expect the CUA to "pick up where it left off" with the command? Or should it just retry the entire command again but with larger LATENCY values? SHOULD/MUST the CS send back a failure response of some kind to indicate 'I am unable to fully process your request in time, please try a large LATENCY.' or 'Data processing is complete but I cannot return all the data in the requested LATENCY time.'. The behaviour for when the CS _cannot_ guarantee that all the results "can be sent...prior to the LATENCY timeout value" is just not clearly defined and it really needs to be. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0069ED2F85256CB5_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 12/06/2002 07:08:33 PM:
> > Sorry but that text does NOT cover partial results.
>
> Please explain 'partial results' and where it is in the draft.
Really?!?  Ok, mathematically stated its:

        partial results = NOT (all the results)

In English its described as 'If you dont get _ALL_ the results then you only got _PARTIAL_ results."  (For those nitpickers here I view "NO results = ALL results" since there set of results to results is empty.)  

Its not a term you put in the draft (09-submitted or before), its one _I_ used in this thread when discussing the issue of Bounded Latency and the text cited below.

Previously I responded to you with:

> >      If a CS can both start sending the reply to a command and guarantee
> >      that all of the results can be sent from a command (short of
> >      something like network or power falure), prior to the "LATENCY"
> >      timeout value, then the "LETENCY" time has not expired.
>
> Sorry but that text does NOT cover partial results.  It clearly says
> "guarantee that _all_ of the results" (my emphasis) and that is
> definitely NOT partial results!  Perhaps you are thinking that "all
> results" simply indicate that its a partial result and that another try is necessary??..  (Please say no... Please!)

Your (double quoted above) text does NOT address the case where the CS cannot "guarantee that all of the results" can be sent in time.  The CS may or may not be able to tell if it can send all 10M in 5 seconds or not (I have lots of calendar entries!) even though it was able to find all 10M in the blink of an eye.

Taking a step back to try and clarify this, I see 2 distinct cases that seem to be blurred into 1 in the draft.  Case 1 is that the CS cannot fulfill the request in the alloted time (too much data to sort thru, exceeds CS policy contstraints, etc).  Case 2 is that the CS can fulfill the request in the alloted time but it cannot push the results back fast enough (ie: Cant shove a 10M ATTACHment and related entry thru a 500K Cable Modem in 10 seconds).

For Case 1 failure should be presented as "The system needs more time to find the results you want".  For Case 2 failure should be presented as "The system is pushing back the data as fast as it can but it will not complete by the time you want."

I view Case 1 as the real bounded latency issue.  I think Case 2 is getting lumped in incorrectly (by the cited text "guarantee that all of the results...").  I do not think that Case 2 is grounds for failing the request.  

If the CS is in the process of pushing back the data and the latency time is exceeded then WHAT should happen?  The CUA has received some of the results from the CS (my "partial results" you asked about) but not all of them.  Should the command be terminated and if so, by whom?  If not, what means does the requesting side have for cancelling the stream?

If the command is to ABORT then just how should we expect the CUA to "pick up where it left off" with the command?  Or should it just retry the entire command again but with larger LATENCY values?  SHOULD/MUST the CS send back a failure response of some kind to indicate 'I am unable to fully process your request in time, please try a large LATENCY.' or 'Data processing is complete but I cannot return all the data in the requested LATENCY time.'.

The behaviour for when the CS _cannot_ guarantee that all the results "can be sent...prior to the LATENCY timeout value" is just not clearly defined and it really needs to be.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0069ED2F85256CB5_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 21 14:34:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09809 for ; Tue, 21 Jan 2003 14:34:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LJPjl08768 for ietf-calendar-bks; Tue, 21 Jan 2003 11:25:45 -0800 (PST) Received: from ace.iris.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LJPio08764 for ; Tue, 21 Jan 2003 11:25:44 -0800 (PST) In-Reply-To: <3DF13B83.8060902@Royer.com> To: ietf-calendar@imc.org Subject: Re: [Fwd: Re: [Fwd: Re: CAP ABNF and external references]] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 21 Jan 2003 14:25:10 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/21/2003 02:25:35 PM, Serialize complete at 01/21/2003 02:25:35 PM Content-Type: multipart/alternative; boundary="=_alternative 006AAFF085256CB5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006AAFF085256CB5_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 12/06/2002 07:06:27 PM: > > Then please add some prose to clearly codify the no bounded latency > > case. Its never directly addressed in the text. A simple line or two > > along the lines of: > > > > If no LATENCY parameter is supplied the the command is not bounded > > and never expires. > > > > and possibly a blurb about command termination too. > > All commands ether return the data you asked for or an error(s). You missed my point. There is NO text in 09-submitted that clearly defines what it means when there is NO LATENCY parameter on a command. What Im suggesting is that we actually put in some explicit text to accurately describe what it means when a command has NO LATENCY (and what that may mean to the requestor). For example, if I send no LATENCY parameter then how would my CUA abort a command cleanly ("Hurry up log off! We gotta go now or miss the commuter train!"). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006AAFF085256CB5_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 12/06/2002 07:06:27 PM:
> > Then please add some prose to clearly codify the no bounded latency
> > case.  Its never directly addressed in the text.  A simple line or two
> > along the lines of:
> >
> >   If no LATENCY parameter is supplied the the command is not bounded
> >   and never expires.
> >
> > and possibly a blurb about command termination too.
>
> All commands ether return the data you asked for or an error(s).
You missed my point.  There is NO text in 09-submitted that clearly defines what it means when there is NO LATENCY parameter on a command.  

What Im suggesting is that we actually put in some explicit text to accurately describe what it means when a command has NO LATENCY (and what that may mean to the requestor).  For example, if I send no LATENCY parameter then how would my CUA abort a command cleanly ("Hurry up log off!  We gotta go now or miss the commuter train!").  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006AAFF085256CB5_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 21 15:05:32 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10721 for ; Tue, 21 Jan 2003 15:05:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LJrJ109361 for ietf-calendar-bks; Tue, 21 Jan 2003 11:53:19 -0800 (PST) Received: from ace.iris.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LJrIo09357 for ; Tue, 21 Jan 2003 11:53:18 -0800 (PST) In-Reply-To: <20021205092314.GB17308@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 21 Jan 2003 14:53:11 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/21/2003 02:53:07 PM, Serialize complete at 01/21/2003 02:53:07 PM Content-Type: multipart/alternative; boundary="=_alternative 006D406685256CB5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D406685256CB5_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 12/05/2002 04:23:14 AM: > Well, we have something like that; at least, we had a proposal which > several people including Doug agreed to. Ahh, this is the thread that Doug referenced in our ABNF discussion. It was in late August when I was totally occupied with our endgame release so I didnt comment on it. I never did play catch up on Aug/Sep 02 traffic yet, sorry. > The idea is to add a TARGET property when operating with stored queries, > to indicate where you want to store or fetch the query from. > > Don't you think this would address your objections? I dont think so. My biggest objection is really the usefullness of stored VQUERYs given that there is no wildcarding of parameters in the query. As such, each VQUERY used is going to have to be recrafted when sent. For example, its impossible in the current query lingua to specify 'Find me all events that have an ALARM that triggers in the next 10 minutes'. I can only craft querys for specific intervals: 'Find me all events that have an ALARM that triggers between 20030121T193000Z and 20030121T194000Z' As such I have an aversion to mandating the storage of queries that essentially can only be useful for a limited window. I do agree about scoping QUERYID to the container level ala VCARs in the proposal. However I have still have questions about A) the usefulness of stored querys and B) the applicability of stored queries to multiple TARGETs (VAGENDAs, etc). Perhaps if you and/or Doug can educate me as to the usefulness of stored queries I could resolve B on my own... > > I concur w/the "expect" bit. I would hope that a CS would try to store > > unknown components in some blobular way such that the CS (Calendar > > _Store_) can act as a true Store for newer data w/o having to actually > > grok it fully. Nowhere does it say in CAP that a CS needs to be able to > > decypher the intent/meaning of a component; it only talks about how it > > should be represented for querys, etc. This has an implicit "any blob > > will work" mentality but thats just my take on the text. > > I concur this is a desirable behavior, and one which would make > extensibility much much easier. However, if this is the expected > behavior, there should be something to that effect in the draft. I see > nothing like that currently. Neither do I. Perhaps we overlooked it. If not, then we need to chalk that gap up on the list of vague areas that need to be more clearly codified. Doug, did we miss some text or is it just an implcit assumption we are all making? > > If the CUA got back the 'empty' VQUERY you had at top then its not > > unlikely that a CU may see that there is nothing in the query and try to > > either delete it or modify it for their use. The CUA _could_ prohibit > > this but again this gets back to the name space issue we have not > > addressed... > > Personally, if my CS and my CUA both know that > cap://cap.example.com/inet.it-stored-queries, then I'd write my CUA so > that it doesn't show the CU anything about queries stored there. IMO this > is just a form of an RPC so it's internal to the CUA and CS couple. This > is useful if you have exclusive control of both; or if the stored queries > are standardized. Unless you are encoding in some name space prefix that you are hoping noone will also use (ie the "inet." prefix) then this is not a really safe thing to do. If Lotus Notes (actually Domino) used its own implicit prefix and your product used its own then we could A) collide by accident or B) not interoperate as expected. As noted its only useful "if you have exclusive control of both" and that defeats the interoperability we want to achieve. While we seem to be in agreement for the most part on the issue of stored queries I think we disagree on what path to take going forward. A compromise could be that we change QUERYID to be kind of like TZID in that if the first character is the soldus character then the rest of the ID is "CS defined". This would allow you to access stored querys that are NOT encodable as a VQUERY since creating them is "Administration" and thus OOB for CAP 1.0. The only other loose end would be to clearly define how a CS should respond to a query for unencodable data. That is, if the "~AndreasQuery1" is NOT encodable as a VQUERY then we need a clearly defined response code or definition of what the CS should return to the requestor. > I need to think more about this; I'm too busy ATM. Maybe we should > find a way to discuss this more in depth between a few of us in a more > interative way... Now that Im back from vacation Ive got a few cycles to spend on this if you and others are interested in some concerted effort to deal w/this. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D406685256CB5_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 12/05/2002 04:23:14 AM:
> Well, we have something like that; at least, we had a proposal which
> several people including Doug agreed to.

Ahh, this is the thread that Doug referenced in our ABNF discussion.  It was in late August when I was totally occupied with our endgame release so I didnt comment on it.  I never did play catch up on Aug/Sep 02 traffic yet, sorry.

> The idea is to add a TARGET property when operating with stored queries,
> to indicate where you want to store or fetch the query from.
>
> Don't you think this would address your objections?
I dont think so.  My biggest objection is really the usefullness of stored VQUERYs given that there is no wildcarding of parameters in the query.  As such, each VQUERY used is going to have to be recrafted when sent.  For example, its impossible in the current query lingua to specify 'Find me all events that have an ALARM that triggers in the next 10 minutes'.  I can only craft querys for specific intervals: 'Find me all events that have an ALARM that triggers between 20030121T193000Z and 20030121T194000Z'

As such I have an aversion to mandating the storage of queries that essentially can only be useful for a limited window.  

I do agree about scoping QUERYID to the container level ala VCARs in the proposal.

However I have still have questions about A) the usefulness of stored querys and B) the applicability of stored queries to multiple TARGETs (VAGENDAs, etc).  Perhaps if you and/or Doug can educate me as to the usefulness of stored queries I could resolve B on my own...

> > I concur w/the "expect" bit.  I would hope that a CS would try to store
> > unknown components in some blobular way such that the CS (Calendar
> > _Store_) can act as a true Store for newer data w/o having to actually
> > grok it fully.  Nowhere does it say in CAP that a CS needs to be able to
> > decypher the intent/meaning of a component; it only talks about how it
> > should be represented for querys, etc.  This has an implicit "any blob
> > will work" mentality but thats just my take on the text.
>
> I concur this is a desirable behavior, and one which would make
> extensibility much much easier. However, if this is the expected
> behavior, there should be something to that effect in the draft. I see
> nothing like that currently.
Neither do I.  Perhaps we overlooked it.  If not, then we need to chalk that gap up on the list of vague areas that need to be more clearly codified.

Doug, did we miss some text or is it just an implcit assumption we are all making?

> > If the CUA got back the 'empty' VQUERY you had at top then its not
> > unlikely that a CU may see that there is nothing in the query and try to
> > either delete it or modify it for their use.  The CUA _could_ prohibit
> > this but again this gets back to the name space issue we have not
> > addressed...
>
> Personally, if my CS and my CUA both know that
> cap://cap.example.com/inet.it-stored-queries, then I'd write my CUA so
> that it doesn't show the CU anything about queries stored there. IMO this
> is just a form of an RPC so it's internal to the CUA and CS couple. This
> is useful if you have exclusive control of both; or if the stored queries
> are standardized.
Unless you are encoding in some name space prefix that you are hoping noone will also use (ie the "inet." prefix) then this is not a really safe thing to do.  If Lotus Notes (actually Domino) used its own implicit prefix and your product used its own then we could A) collide by accident or B) not interoperate as expected.

As noted its only useful "if you have exclusive control of both" and that defeats the interoperability we want to achieve.  While we seem to be in agreement for the most part on the issue of stored queries I think we disagree on what path to take going forward.

A compromise could be that we change QUERYID to be kind of like TZID in that if the first character is the soldus character then the rest of the ID is "CS defined".  This would allow you to access stored querys that are NOT encodable as a VQUERY since creating them is "Administration" and thus OOB for CAP 1.0.  The only other loose end would be to clearly define how a CS should respond to a query for unencodable data.  That is, if the "~AndreasQuery1" is NOT encodable as a VQUERY then we need a clearly defined response code or definition of what the CS should return to the requestor.

> I need to think more about this; I'm too busy ATM. Maybe we should
> find a way to discuss this more in depth between a few of us in a more
> interative way...
Now that Im back from vacation Ive got a few cycles to spend on this if you and others are interested in some concerted effort to deal w/this.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006D406685256CB5_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 21 17:17:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13761 for ; Tue, 21 Jan 2003 17:17:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LMBdK12219 for ietf-calendar-bks; Tue, 21 Jan 2003 14:11:39 -0800 (PST) Received: from ace.iris.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LMBao12215 for ; Tue, 21 Jan 2003 14:11:36 -0800 (PST) In-Reply-To: <200212152043.45560.mark@WebServiceSolutions.com> To: Mark Swanson Cc: ietf-calendar@imc.org Subject: Re: Is Apple creating invalid iCalendar? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 21 Jan 2003 17:11:33 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/21/2003 05:11:39 PM, Serialize complete at 01/21/2003 05:11:39 PM Content-Type: multipart/alternative; boundary="=_alternative 0079EB7F85256CB5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079EB7F85256CB5_= Content-Type: text/plain; charset="US-ASCII" Mark asked on 12/15/2002 08:43:45 PM: > x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > ; Reservered for experimental use. Not intended for use in > ; released products. > > vendorid = 3*(ALPHA / DIGIT) ;Vendor identification > > This tells me that (if present) the vendorid MUST be at least 3 characters. > The snippet below shows they are creating X- properties with 2-character > vendorids. > > Would anyone disagree with this analysis? Your general analysis is correct; Apple is incorrectly generating 'vendor specific' items by using just 2 characters for an apparent vendorid value. I must point out though that it is legal iCalendar if you check the ABNF. The analysis of "X-WR-TIMEZONE" will legally break down as: "X-" 1*(ALPHA / DIGIT / "-") since the "WR-TIMEZONE" matches 1*(...). Apple really SHOULD be using something like: X-APL-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern Anyone here know how to let them know so they can fix it?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0079EB7F85256CB5_= Content-Type: text/html; charset="US-ASCII"
Mark asked on 12/15/2002 08:43:45 PM:
>       x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
>       ; Reservered for experimental use. Not intended for use in
>       ; released products.
>
>       vendorid   = 3*(ALPHA / DIGIT)     ;Vendor identification
>
>  This tells me that (if present) the vendorid MUST be at least 3 characters.
>  The snippet below shows they are creating X- properties with 2-character
>  vendorids.
>
>  Would anyone disagree with this analysis?
Your general analysis is correct; Apple is incorrectly generating 'vendor specific' items by using just 2 characters for an apparent vendorid value.

I must point out though that it is legal iCalendar if you check the ABNF.  The analysis of "X-WR-TIMEZONE" will legally break down as:

"X-" 1*(ALPHA / DIGIT / "-")

since the "WR-TIMEZONE" matches 1*(...).  Apple really SHOULD be using something like:

X-APL-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern

Anyone here know how to let them know so they can fix it??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0079EB7F85256CB5_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 21 17:29:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14023 for ; Tue, 21 Jan 2003 17:29:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LMOqw12634 for ietf-calendar-bks; Tue, 21 Jan 2003 14:24:52 -0800 (PST) Received: from ace.iris.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LMOpo12629 for ; Tue, 21 Jan 2003 14:24:51 -0800 (PST) In-Reply-To: <20021217094848.GJ93256@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: 12.2 BEEP Exchange Styles MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 21 Jan 2003 17:24:49 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/21/2003 05:24:53 PM, Serialize complete at 01/21/2003 05:24:53 PM Content-Type: multipart/alternative; boundary="=_alternative 007B225085256CB5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B225085256CB5_= Content-Type: text/plain; charset="US-ASCII" Andrea posited on 12/17/2002 04:48:48 AM: > A CAP request, targeted at more than one containers, MAY use a one- > to-many exchange, with a distinct answer associated with each target. > CAP request targeted at a single container MAY use a one-to-one > exchange or a one-to-many exchange. > > Maybe it's me, but I don't understand if the difference in the > wording between the two sentences is intentional. Perhaps stated this way it may help. If targeting more than one container there really should (MUST??) be a one-to-many exchange (the many being responses per each targeted container). I would NOT expect a one-to-one exchange when targeting multiple containers really. If targeting a single container then a one-to-one or one-to-many exchange may happen for the obvious reasons. Is there any case where multiple targets would really yield a single, combined response to form a one-to-one exchange? If not then the verbage in the draft should change to MUST. I for one would always expect multiple targets to result in a one-to-many exchange, even if all were identical failures. Much more logical and simple IMHO. > If it is, however, then I don't understand the first one. Is it > supposed to be a MUST? I agree. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007B225085256CB5_= Content-Type: text/html; charset="US-ASCII"
Andrea posited on 12/17/2002 04:48:48 AM:
>    A CAP request, targeted at more than one containers, MAY use a one-
>    to-many exchange, with a distinct answer associated with each target.
>    CAP request targeted at a single container MAY use a one-to-one
>    exchange or a one-to-many exchange.
>
> Maybe it's me, but I don't understand if the difference in the
> wording between the two sentences is intentional.

Perhaps stated this way it may help.  If targeting more than one container there really should (MUST??) be a one-to-many exchange (the many being responses per each targeted container).  I would NOT expect a one-to-one exchange when targeting multiple containers really.  If targeting a single container then a one-to-one or one-to-many exchange may happen for the obvious reasons.

Is there any case where multiple targets would really yield a single, combined response to form a one-to-one exchange?  If not then the verbage in the draft should change to MUST.  I for one would always expect multiple targets to result in a one-to-many exchange, even if all were identical failures.  Much more logical and simple IMHO.

> If it is, however, then I don't understand the first one. Is it
> supposed to be a MUST?
I agree.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 007B225085256CB5_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 21 19:16:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16174 for ; Tue, 21 Jan 2003 19:16:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0M0CkB15712 for ietf-calendar-bks; Tue, 21 Jan 2003 16:12:46 -0800 (PST) Received: from ace.iris.com (bi-02pt2.bluebird.ibm.com [129.42.208.183]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0M0Cio15705 for ; Tue, 21 Jan 2003 16:12:44 -0800 (PST) In-Reply-To: <3E0B7F38.4000608@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP - next version MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 21 Jan 2003 17:50:20 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/21/2003 07:12:42 PM, Serialize complete at 01/21/2003 07:12:42 PM Content-Type: multipart/alternative; boundary="=_alternative 007D787985256CB5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007D787985256CB5_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 12/26/2002 05:14:16 PM: > Then in a week or so when that is settled :-) move on > to any outstanding technical issues. > > Comments? Im still digging out from 4 week vacation but I dont see any postings that appear to be new draft notices. Did I miss it or is it still baking? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007D787985256CB5_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 12/26/2002 05:14:16 PM:
> Then in a week or so when that is settled :-) move on
> to any outstanding technical issues.
>
> Comments?

Im still digging out from 4 week vacation but I dont see any postings that appear to be new draft notices.  Did I miss it or is it still baking?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007D787985256CB5_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 21 19:18:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16206 for ; Tue, 21 Jan 2003 19:18:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0M0Cjc15708 for ietf-calendar-bks; Tue, 21 Jan 2003 16:12:45 -0800 (PST) Received: from ace.iris.com (bi-02pt2.bluebird.ibm.com [129.42.208.183]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0M0Cio15703 for ; Tue, 21 Jan 2003 16:12:44 -0800 (PST) In-Reply-To: <20021218092603.GL93256@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: VTIMEZONE in CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 21 Jan 2003 17:41:27 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/21/2003 07:12:41 PM, Serialize complete at 01/21/2003 07:12:41 PM Content-Type: multipart/alternative; boundary="=_alternative 007CA84D85256CB5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007CA84D85256CB5_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 12/18/2002 04:26:03 AM: > how do you people expect CAP to change the way VTIMEZONE are > handled according to previous standards? Im sorry but I dont understand the question. > For BOOKED components, iTIP is irrelevant, but when storing or > retrieving iTIP components I would expect 3.1 of iTIP to be > mandatory. So we need to always include the VTIMEZONEs the component(s) > specify? Not all iTIP messages are for DATE-TIME or TIME data types; they may be for DATE only types. For example: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//EN METHOD:PUBLISH BEGIN:VEVENT DTSTART;VALUE=DATE:20030214 SUMMARY:Valentines Day Party END:VEVENT END:VCALENDAR This is a valid all day event w/no associated TZ. > This seems to be a little bit absurd to me: the CUA only needs to > be able to retrieve the VTIMEZONEs from the CS; it can do so once > per session (and even cache them between sessions). > I propose we amend 3.1 and interpret 4.2.19 to mean all the VTIMEZONEs > must exist in the CAP store. If the CS doesnt have a definition that arrives w/an iTIP message (because the Admins have not kept their TZ tables updated) then what should happen? If my new beta CUA sends a METHOD:REQUEST for a newly added or updated TZID then would that new TZ be considered "in the CAP store" if its in the iTIP stream? Or would it have to be stored by some Admin first? Adding new TZ info is Administration and thus OOB for CAP 1.0 BUT if we are making a requirement that 'administratively added' data MUST exist then we need to make sure we consider the all the cases before making this kind of requirements change to 2445/2446. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007CA84D85256CB5_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 12/18/2002 04:26:03 AM:
> how do you people expect CAP to change the way VTIMEZONE are
> handled according to previous standards?

Im sorry but I dont understand the question.

> For BOOKED components, iTIP is irrelevant, but when storing or
> retrieving iTIP components I would expect 3.1 of iTIP to be
> mandatory. So we need to always include the VTIMEZONEs the component(s)
> specify?
Not all iTIP messages are for DATE-TIME or TIME data types; they may be for DATE only types.  For example:

     BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:-//hacksw/handcal//NONSGML v1.0//EN
     METHOD:PUBLISH
    BEGIN:VEVENT
    DTSTART;VALUE=DATE:20030214
    SUMMARY:Valentines Day Party
    END:VEVENT
    END:VCALENDAR

This is a valid all day event w/no associated TZ.  

> This seems to be a little bit absurd to me: the CUA only needs to
> be able to retrieve the VTIMEZONEs from the CS; it can do so once
> per session (and even cache them between sessions).
> I propose we amend 3.1 and interpret 4.2.19 to mean all the VTIMEZONEs
> must exist in the CAP store.

If the CS doesnt have a definition that arrives w/an iTIP message (because the Admins have not kept their TZ tables updated) then what should happen?  If my new beta CUA sends a METHOD:REQUEST for a newly added or updated TZID then would that new TZ be considered "in the CAP store" if its in the iTIP stream?  Or would it have to be stored by some Admin first?

Adding new TZ info is Administration and thus OOB for CAP 1.0 BUT if we are making a requirement that 'administratively added' data MUST exist then we need to make sure we consider the all the cases before making this kind of requirements change to 2445/2446.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 007CA84D85256CB5_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 05:20:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21130 for ; Wed, 22 Jan 2003 05:20:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MAGCe23950 for ietf-calendar-bks; Wed, 22 Jan 2003 02:16:12 -0800 (PST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MAGAo23946 for ; Wed, 22 Jan 2003 02:16:11 -0800 (PST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h0MAGAI25454 for ; Wed, 22 Jan 2003 02:16:10 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 22 Jan 2003 02:16:10 -0800 Received: from apple.com ([17.68.41.12]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id h0MAG7s12544 for ; Wed, 22 Jan 2003 02:16:08 -0800 (PST) Date: Wed, 22 Jan 2003 11:16:14 +0100 Subject: Re: Is Apple creating invalid iCalendar? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Olivier Gutknecht To: ietf-calendar@imc.org In-Reply-To: Message-Id: <8972CBF1-2DF2-11D7-83E7-003065EF8304@apple.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0MAGBo23947 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > Your general analysis is correct; Apple is incorrectly generating > 'vendor specific' items by using just 2 characters for an apparent > vendorid value. > > I must point out though that it is legal iCalendar if you check the > ABNF.  The analysis of "X-WR-TIMEZONE" will legally break down as: > "X-" 1*(ALPHA / DIGIT / "-") > > since the "WR-TIMEZONE" matches 1*(...).  Apple really SHOULD be using > something like: > X-APL-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern > > Anyone here know how to let them know so they can fix it?? Yes, we know about this issue and we do plan to comply with this SHOULD in our future releases. Ol. -- Apple Computer, Inc. From owner-ietf-calendar@mail.imc.org Wed Jan 22 08:54:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24951 for ; Wed, 22 Jan 2003 08:54:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MDj1V06695 for ietf-calendar-bks; Wed, 22 Jan 2003 05:45:01 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MDiwo06688 for ; Wed, 22 Jan 2003 05:45:00 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id CC3F34D5E for ; Wed, 22 Jan 2003 08:44:28 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: Q: Handling non-conforming ICalendar Date: Wed, 22 Jan 2003 00:21:25 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200301220021.28555.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Given that I am finding non-conforming ICalendar output from several of the most popular ICalendar implementations out there I was wondering how everyone else on this list is handling non-conforming ICalendar data? F.E. ignoring it, modifying your parser to handle bad data, etc... Thanks. - -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+LipVBtoFHHwdJ/cRAhN6AJsF1GnZXftDSqES5PuboTFYOrE83QCfeq7T HRKptGykSLAeOYH9dLL4CCo= =eNEL -----END PGP SIGNATURE----- From owner-ietf-calendar@mail.imc.org Wed Jan 22 08:59:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25045 for ; Wed, 22 Jan 2003 08:59:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MDivX06687 for ietf-calendar-bks; Wed, 22 Jan 2003 05:44:57 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MDiso06680 for ; Wed, 22 Jan 2003 05:44:54 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id C8F164D5C; Wed, 22 Jan 2003 08:44:24 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: Bruce_Kahn@notesdev.ibm.com Subject: Re: Is Apple creating invalid iCalendar? Date: Wed, 22 Jan 2003 00:07:37 -0500 User-Agent: KMail/1.5 References: In-Reply-To: Cc: ietf-calendar@imc.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200301220007.40722.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On January 21, 2003 05:11 pm, you wrote: > Mark asked on 12/15/2002 08:43:45 PM: > > x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > > ; Reservered for experimental use. Not intended for use in > > ; released products. > > > > vendorid = 3*(ALPHA / DIGIT) ;Vendor identification > > > > This tells me that (if present) the vendorid MUST be at least 3 > > characters. > > > The snippet below shows they are creating X- properties with > > 2-character > > > vendorids. > > > > Would anyone disagree with this analysis? > > Your general analysis is correct; Apple is incorrectly generating 'vendor > specific' items by using just 2 characters for an apparent vendorid value. > > I must point out though that it is legal iCalendar if you check the ABNF. > The analysis of "X-WR-TIMEZONE" will legally break down as: > > "X-" 1*(ALPHA / DIGIT / "-") > > since the "WR-TIMEZONE" matches 1*(...). Apple really SHOULD be using > something like: > > X-APL-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern > > Anyone here know how to let them know so they can fix it?? Good point Bruce. Upon further checking my parser was actually breaking on the incorrect "VALUE=TEXT" parameter: xparam =x-name "=" param-value *("," param-value) x-name may not be "VALUE" found above according to rfc2445: x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") An example of a valid non-standard property would be: X-SKI-TITLE;X-RSVP=TRUE: This is an extension property I also wonder who to let know so they can fix it. Cheers. - -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+LicZBtoFHHwdJ/cRAr+qAJ9bMTc1UiaO69uD/Hlr5ULXsbxG1ACfYunJ jge8Imno4JsYTAz6O0c4Z6g= =bWEL -----END PGP SIGNATURE----- From owner-ietf-calendar@mail.imc.org Wed Jan 22 09:35:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25751 for ; Wed, 22 Jan 2003 09:35:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MERpH08123 for ietf-calendar-bks; Wed, 22 Jan 2003 06:27:51 -0800 (PST) Received: from localhost.localdomain (24-240-234-245.charter.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MERoo08119 for ; Wed, 22 Jan 2003 06:27:50 -0800 (PST) Received: from jsoft.com (eeyore.jsoft.com [192.168.0.46]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0MEY2js024342 for ; Wed, 22 Jan 2003 08:34:02 -0600 Message-ID: <3E2EA8E8.4070001@jsoft.com> Date: Wed, 22 Jan 2003 08:21:28 -0600 From: Gary Frederick User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Q: Handling non-conforming ICalendar References: <200301220021.28555.mark@WebServiceSolutions.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The folks working on rdf-calendar are interested in having iCalendar test data. If anyone wants to contribute some test data and tests, I'll ask if they want to use it. Gary Re: reminder: next IRC calendar meeting 5pm GMT, 2003-01-22 ... http://www.timeanddate.com/worldclock/fixedtime.html?day=22&month=1&year=2003&hour=17&min=0&sec=0&p1=0 irc.freenode.net #rdfig irc://irc.freenode.net/rdfig From owner-ietf-calendar@mail.imc.org Wed Jan 22 09:47:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26097 for ; Wed, 22 Jan 2003 09:46:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MEdK108895 for ietf-calendar-bks; Wed, 22 Jan 2003 06:39:20 -0800 (PST) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MEdIo08885 for ; Wed, 22 Jan 2003 06:39:18 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 22 Jan 2003 14:39:06 +0000 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 18bM0u-00066B-00; Wed, 22 Jan 2003 14:38:00 +0000 Date: Wed, 22 Jan 2003 14:38:00 +0000 (GMT) From: Libby Miller X-X-Sender: ecemm@mail.ilrt.bris.ac.uk To: ietf-calendar@imc.org cc: mf@w3.org Subject: error in rfc2445 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A friend not on this list noticed this apparent error. is there an errata document for RFC 2445, or is it updated? Libby ---------- Forwarded message ---------- Date: Wed, 22 Jan 2003 15:33:33 +0100 From: Max Froumentin To: Libby.Miller@bristol.ac.uk Subject: error in rfc2445 RFC1445 says: > UNTIL= must be followed by enddate (4.3.10) > > 2223: ( ";" "UNTIL" "=" enddate ) / > > 2253: enddate = date > 1899: date = date-value > 1901: date-value = date-fullyear date-month date-mday But the prose (line 2341) and all the examples show that UNTIL= must followed by a date-time: > UNTIL=19980404T070000Z Is this an error? Max. From owner-ietf-calendar@mail.imc.org Wed Jan 22 12:08:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01285 for ; Wed, 22 Jan 2003 12:08:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MGtNj16863 for ietf-calendar-bks; Wed, 22 Jan 2003 08:55:23 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MGtMo16859 for ; Wed, 22 Jan 2003 08:55:22 -0800 (PST) In-Reply-To: <3E21E565.9040501@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP work in progress MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 11:55:19 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 11:55:22 AM, Serialize complete at 01/22/2003 11:55:22 AM Content-Type: multipart/alternative; boundary="=_alternative 005CF31785256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CF31785256CB6_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 01/12/2003 05:00:05 PM: > I put the current snapshot of 'cap-12-JAN-2003' on INET-Consulting.com : > > http://INET-Consulting.com/cap-12-JAN-2003.html > http://INET-Consulting.com/cap-12-JAN-2003.txt > http://INET-Consulting.com/cap-12-JAN-2003.diffs > http://INET-Consulting.com/cap-12-JAN-2003.xml Glad to see the updates made it out; ignore my query on it from yesterday (too much mail still). Couple things: This is draft-10 yes? The name makes it look like draft-12 a bit. Also, when I load the HTML and text versions in MSIE the name is "draft-ietf-calsch-cap-10-12-JAN-2002". The year should be 2003. Now on to the rest of the backlog and the new draft. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005CF31785256CB6_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 01/12/2003 05:00:05 PM:
> I put the current snapshot of 'cap-12-JAN-2003' on INET-Consulting.com :
>
>    http://INET-Consulting.com/cap-12-JAN-2003.html
>    http://INET-Consulting.com/cap-12-JAN-2003.txt
>    http://INET-Consulting.com/cap-12-JAN-2003.diffs
>    http://INET-Consulting.com/cap-12-JAN-2003.xml
Glad to see the updates made it out; ignore my query on it from yesterday (too much mail still).

Couple things:  This is draft-10 yes?  The name makes it look like draft-12 a bit.  Also, when I load the HTML and text versions in MSIE the name is "draft-ietf-calsch-cap-10-12-JAN-2002".  The year should be 2003.  Now on to the rest of the backlog and the new draft.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005CF31785256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 12:27:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01615 for ; Wed, 22 Jan 2003 12:27:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MHGIt18874 for ietf-calendar-bks; Wed, 22 Jan 2003 09:16:18 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MHGHo18868 for ; Wed, 22 Jan 2003 09:16:17 -0800 (PST) In-Reply-To: <3E21CF15.40001@Royer.com> To: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 12:16:14 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 12:16:15 PM, Serialize complete at 01/22/2003 12:16:15 PM Content-Type: multipart/alternative; boundary="=_alternative 005EDD7285256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005EDD7285256CB6_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 01/12/2003 03:24:53 PM: > I would like to add this text to the DELETE command in CAP: > > There is no partial success for a "DELETE" command. Ether > everything succeeds or nothing is done. So if the VREPLY > contains X number of successful replies and at least > one (1) failure then no objects were deleted or marked > for deletion. This is because a malformed "QUERY" property > value could have devastating effects and unintended > deletion of some objects could make a calendar unusable. > The CUA could inform the CU that their request must > be modified in order to succeed. > > Comments? Whoa!! This design change makes DELETEs into a transactional model command; something we _dont_ need. That is, there can be multiple entrys deleted that only actually get really deleted once all of them happen successfully. I VERY VERY strongly disagree with this design change. There are perfectly normal reasons why some deletions could fail: insufficient access, concurrent use by another CU, system maintenance on a VAGENDA, etc.. The new text creates a very very heavy burden on any CS implementor as they MUST now have a back end storage engine that does transactioning (in the DB sense of the term). They can no longer use just any back end engine that can remove records in the store. I strongly disagree w/this raising of the bar w/o any clear motivation for why it needs to be done. So what if 1 of my TARGETs fails to DELETE but my other 2 succeed?? Whats wrong w/that if the CS can clearly indicate this in the VREPLYs?? This can also be used as a justification for making the rest of the commands fully transactional ("Only successflly create and save the entry if I can save it on ALL of the TARGETs.", etc). I dont think we want to fall down that very very slippery and nasty slope just yet do we? Pardon me if this was already said but I wanted to make sure before I get sucked into some Real Work(TM) stuff. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005EDD7285256CB6_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 01/12/2003 03:24:53 PM:
> I would like to add this text to the DELETE command in CAP:
>
>    There is no partial success for a "DELETE" command. Ether
>    everything succeeds or nothing is done. So if the VREPLY
>    contains X number of successful replies and at least
>    one (1) failure then no objects were deleted or marked
>    for deletion. This is because a malformed "QUERY" property
>    value could have devastating effects and unintended
>    deletion of some objects could make a calendar unusable.
>    The CUA could inform the CU that their request must
>    be modified in order to succeed.
>
> Comments?
Whoa!!  This design change makes DELETEs into a transactional model command; something we _dont_ need.  That is, there can be multiple entrys deleted that only actually get really deleted once all of them happen successfully.  I VERY VERY strongly disagree with this design change.  

There are perfectly normal reasons why some deletions could fail: insufficient access, concurrent use by another CU, system maintenance on a VAGENDA, etc..  The new text creates a very very heavy burden on any CS implementor as they MUST now have a back end storage engine that does transactioning (in the DB sense of the term).  They can no longer use just any back end engine that can remove records in the store.

I strongly disagree w/this raising of the bar w/o any clear motivation for why it needs to be done.  So what if 1 of my TARGETs fails to DELETE but my other 2 succeed??  Whats wrong w/that if the CS can clearly indicate this in the VREPLYs??  

  This can also be used as a justification for making the rest of the commands fully transactional ("Only successflly create and save the entry if I can save it on ALL of the TARGETs.", etc).  I dont think we want to fall down that very very slippery and nasty slope just yet do we?

  Pardon me if this was already said but I wanted to make sure before I get sucked into some Real Work(TM) stuff.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 005EDD7285256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 14:01:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03680 for ; Wed, 22 Jan 2003 14:01:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MIbxB21615 for ietf-calendar-bks; Wed, 22 Jan 2003 10:37:59 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MIbvo21611 for ; Wed, 22 Jan 2003 10:37:58 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id E5DB0443B for ; Wed, 22 Jan 2003 13:37:31 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: Outlook incorrect parameter text Date: Wed, 22 Jan 2003 13:33:33 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301221333.33800.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, Can anyone confirm that this is non-conformant ICalendar: DTSTART;TZID="Eastern Time (US & Canada)":20030114T100000 The parameter text ("Eastern Time (US & Canada)") MUST be *SAFE-CHAR: paramtext = *SAFE-CHAR SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-US-ASCII ; Any character except CTLs, DQUOTE, ";", ":", "," It seems Outlook is creating parameters with the DQUOTE character, which is not correct. Is this analysis correct? Thanks. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Jan 22 14:08:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03810 for ; Wed, 22 Jan 2003 14:08:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MIr0H22002 for ietf-calendar-bks; Wed, 22 Jan 2003 10:53:00 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MIqwo21998 for ; Wed, 22 Jan 2003 10:52:58 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 33665443B for ; Wed, 22 Jan 2003 13:52:30 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: RFC 2445 Q: is TZID broken? Date: Wed, 22 Jan 2003 13:48:30 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301221348.30131.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, There seems to be an issue with time zones: (from the spec) "The specification of globally unique time zone identifiers is not addressed by this document and is left for future study." Since I'm seeing various popular ICalendar implementations use their own formats, how can anything be expected to interoperate? You obviously can not rely on GMT offset ("America/Phoenix" and "America/Denver" both have GMT-07:00, but differ in daylight savings behavior) so time zone identifiers are required. Would a list of timezones for every available implementation be required? As well as a mapping between them all? Anyone can see the time zones that ScheduleWorld uses by iterating through the available TimeZone.getAvailableIDs(). Thank you. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Jan 22 14:09:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03824 for ; Wed, 22 Jan 2003 14:09:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MIwHN22195 for ietf-calendar-bks; Wed, 22 Jan 2003 10:58:17 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MIwFo22190 for ; Wed, 22 Jan 2003 10:58:16 -0800 (PST) In-Reply-To: To: ietf-calendar@imc.org, Mark Swanson Subject: Re: Is Apple creating invalid iCalendar? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 13:58:09 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 01:58:09 PM, Serialize complete at 01/22/2003 01:58:09 PM Content-Type: multipart/alternative; boundary="=_alternative 006831D485256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006831D485256CB6_= Content-Type: text/plain; charset="US-ASCII" I wrote on 01/21/2003 05:11:33 PM: > > Would anyone disagree with this analysis? > > Your general analysis is correct; Apple is incorrectly generating > 'vendor specific' items by using just 2 characters for an apparent > vendorid value. An update to this topic after I did a 30 second peek at the .ICS mentioned in the RDFCal chat: 18:43:33 OK, http://www.w3.org/2002/12/cal/test/mtg.ics loaded fine. Rather nice to be able to do this... I've saved an xcal, checking it in now. I looked at the .ICS file mentioned and I see that iCal doesnt adhere to 2445. The file contains: BEGIN:VCALENDAR CALSCALE:GREGORIAN PRODID:-//Apple Computer\, Inc//iCal 1.0//EN X-WR-TIMEZONE;VALUE=TEXT:US/Eastern VERSION:2.0 BEGIN:VEVENT SEQUENCE:3 DTSTAMP:20021219T205357Z SUMMARY:icalendaring #rdfig meeting DTEND;TZID=US/Eastern:20030108T140000 DTSTART;TZID=US/Eastern:20030108T130000 UID:CDC474D4-1393-11D7-9A2C-000393914268 END:VEVENT END:VCALENDAR I agree that the X-WR-TIMEZONE is incorrectly done because its a vendor extension thats not properly labeled as such. The bigger problem is that DTSTART and DTEND have TZIDs but NO matching VTIMEZONE! This violates 2445 4.2.19 Time Zone Identifier: ... Description: The parameter MUST be specified on the "DTSTART", "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE- TIME or TIME value type is specified and when the value is not either a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type definition for a description of UTC and "floating time" formats. This property parameter specifies a text value which uniquely identifies the "VTIMEZONE" calendar component to be used when evaluating the time portion of the property. The value of the TZID property parameter will be equal to the value of the TZID property for the matching time zone definition. An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. This could make the .ics file generate errors on those clients that adhere to the RFCs. We really should find a contact @ Apple so they can correct this. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006831D485256CB6_= Content-Type: text/html; charset="US-ASCII"
I wrote on 01/21/2003 05:11:33 PM:
> >  Would anyone disagree with this analysis?
>
> Your general analysis is correct; Apple is incorrectly generating
> 'vendor specific' items by using just 2 characters for an apparent
> vendorid value.

An update to this topic after I did a 30 second peek at the .ICS mentioned in the RDFCal chat:

18:43:33 <danb_lap> OK, http://www.w3.org/2002/12/cal/test/mtg.ics loaded fine. Rather nice to be able to do this... I've saved an xcal, checking it in now.

 I looked at the .ICS file mentioned and I see that iCal doesnt adhere to 2445.  The file contains:

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Apple Computer\, Inc//iCal 1.0//EN
X-WR-TIMEZONE;VALUE=TEXT:US/Eastern
VERSION:2.0
BEGIN:VEVENT
SEQUENCE:3
DTSTAMP:20021219T205357Z
SUMMARY:icalendaring #rdfig meeting
DTEND;TZID=US/Eastern:20030108T140000
DTSTART;TZID=US/Eastern:20030108T130000
UID:CDC474D4-1393-11D7-9A2C-000393914268
END:VEVENT
END:VCALENDAR

I agree that the X-WR-TIMEZONE is incorrectly done because its a vendor extension thats not properly labeled as such.  The bigger problem is that DTSTART and DTEND have TZIDs but NO matching VTIMEZONE!  This violates 2445

4.2.19 Time Zone Identifier:
...
   Description: The parameter MUST be specified on the "DTSTART",
  "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
  TIME or TIME value type is specified and when the value is not either
  a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type
  definition for a description of UTC and "floating time" formats. This
  property parameter specifies a text value which uniquely identifies
  the "VTIMEZONE" calendar component to be used when evaluating the
  time portion of the property. The value of the TZID property
  parameter will be equal to the value of the TZID property for the
  matching time zone definition. An individual "VTIMEZONE" calendar
  component MUST be specified for each unique "TZID" parameter value
  specified in the iCalendar object.

This could make the .ics file generate errors on those clients that adhere to the RFCs.  We really should find a contact @ Apple so they can correct this.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006831D485256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 14:45:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04607 for ; Wed, 22 Jan 2003 14:45:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MJaBp23778 for ietf-calendar-bks; Wed, 22 Jan 2003 11:36:11 -0800 (PST) Received: from barrayar.local.thibault.org (sergyar.thibault.org [66.92.75.208]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MJaAo23774 for ; Wed, 22 Jan 2003 11:36:10 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by barrayar.local.thibault.org (8.12.5/8.12.5) with ESMTP id h0MJDIKE023496; Wed, 22 Jan 2003 14:13:18 -0500 Subject: Re: Outlook incorrect parameter text From: John Stracke To: Mark Swanson Cc: ietf-calendar@imc.org In-Reply-To: <200301221333.33800.mark@WebServiceSolutions.com> References: <200301221333.33800.mark@WebServiceSolutions.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 22 Jan 2003 14:13:18 -0500 Message-Id: <1043262798.21389.7561.camel@barrayar.local.thibault.org> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wed, 2003-01-22 at 13:33, Mark Swanson wrote: Can anyone confirm that this is non-conformant ICalendar: I think you're right. On the other hand, it's a pretty easy violation to accept, since you've got to have code to be able to parse quoted-strings anyway, and since the TZID is purely local. -- /=============================================================\ |John Stracke | http://www.centive.com |HTML OK | |Principal Engineer |========================================| |Centive |Maybe only the solipsists are imaginary.| |jstracke@centive.com| | \=============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jan 22 14:45:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04628 for ; Wed, 22 Jan 2003 14:45:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MJXFH23725 for ietf-calendar-bks; Wed, 22 Jan 2003 11:33:15 -0800 (PST) Received: from barrayar.local.thibault.org (sergyar.thibault.org [66.92.75.208]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MJXDo23721 for ; Wed, 22 Jan 2003 11:33:13 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by barrayar.local.thibault.org (8.12.5/8.12.5) with ESMTP id h0MJAJKE023472; Wed, 22 Jan 2003 14:10:20 -0500 Subject: Re: RFC 2445 Q: is TZID broken? From: John Stracke To: Mark Swanson Cc: ietf-calendar@imc.org In-Reply-To: <200301221348.30131.mark@WebServiceSolutions.com> References: <200301221348.30131.mark@WebServiceSolutions.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 22 Jan 2003 14:10:19 -0500 Message-Id: <1043262620.21469.7554.camel@barrayar.local.thibault.org> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wed, 2003-01-22 at 13:48, Mark Swanson wrote: Since I'm seeing various popular ICalendar implementations use their own formats, how can anything be expected to interoperate? From section 4.2.19 of RFC-2445: An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. In other words, even if a TZID starts with a "/", and so is nominally global, its scope is still local to the VCALENDAR. You obviously can not rely on GMT offset ("America/Phoenix" and "America/Denver" both have GMT-07:00, but differ in daylight savings behavior) so time zone identifiers are required. Global time zone identifiers are nearly impossible; at a minimum, they would have to come with a timestamp, since time zone definitions change over time. -- /===============================================================\ |John Stracke | http://www.centive.com |HTML OK | |Principal Engineer |==========================================| |Centive |"All gateways lose information. Some do it| |jstracke@centive.com|more efficiently than others." -- Einar | | |Stefferud | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jan 22 14:55:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05037 for ; Wed, 22 Jan 2003 14:55:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MJiCH24023 for ietf-calendar-bks; Wed, 22 Jan 2003 11:44:12 -0800 (PST) Received: from barrayar.local.thibault.org (sergyar.thibault.org [66.92.75.208]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MJiBo24018 for ; Wed, 22 Jan 2003 11:44:11 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by barrayar.local.thibault.org (8.12.5/8.12.5) with ESMTP id h0MJLHKE023555; Wed, 22 Jan 2003 14:21:17 -0500 Subject: Re: Is Apple creating invalid iCalendar? From: John Stracke To: Mark Swanson Cc: ietf-calendar@imc.org In-Reply-To: <200301220007.40722.mark@WebServiceSolutions.com> References: <200301220007.40722.mark@WebServiceSolutions.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 22 Jan 2003 14:21:17 -0500 Message-Id: <1043263277.21469.7577.camel@barrayar.local.thibault.org> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wed, 2003-01-22 at 00:07, Mark Swanson wrote: x-name may not be "VALUE" found above according to rfc2445: Then that's a bug in RFC-2445; obviously we want x-props to be able to use VALUE. -- /=================================================================\ |John Stracke | http://www.centive.com |HTML OK | |Principal Engineer |============================================| |Centive |Stupid, adj.: Losing $25 on the game and $50| |jstracke@centive.com|on the instant replay. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Wed Jan 22 14:59:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05087 for ; Wed, 22 Jan 2003 14:59:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MJloF24132 for ietf-calendar-bks; Wed, 22 Jan 2003 11:47:50 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MJlmo24127 for ; Wed, 22 Jan 2003 11:47:48 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 43FB8443B; Wed, 22 Jan 2003 14:47:22 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: John Stracke Subject: Re: Outlook incorrect parameter text Date: Wed, 22 Jan 2003 14:43:09 -0500 User-Agent: KMail/1.5 Cc: ietf-calendar@imc.org References: <200301221333.33800.mark@WebServiceSolutions.com> <1043262798.21389.7561.camel@barrayar.local.thibault.org> In-Reply-To: <1043262798.21389.7561.camel@barrayar.local.thibault.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301221443.10009.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On January 22, 2003 02:13 pm, John Stracke wrote: > > I think you're right. On the other hand, it's a pretty easy violation > to accept, since you've got to have code to be able to parse > quoted-strings anyway, and since the TZID is purely local. Perhaps it is a mistake in the spec to use "paramtext" when it chould be "param-value" which would allow "paramtext" OR "quoted-string". Thoughts? -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:01:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05190 for ; Wed, 22 Jan 2003 15:01:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MJpB724250 for ietf-calendar-bks; Wed, 22 Jan 2003 11:51:11 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MJpAo24246 for ; Wed, 22 Jan 2003 11:51:10 -0800 (PST) In-Reply-To: <20030113093656.GB44480@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 14:51:04 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 02:51:01 PM, Serialize complete at 01/22/2003 02:51:01 PM Content-Type: multipart/alternative; boundary="=_alternative 006D0A2785256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D0A2785256CB6_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 01/13/2003 04:36:56 AM: > I still think (as briefly mentioned before) that we should clearly > define failure modes for all commands. Isnt that already accomplished by the delete-reply (or any *-reply in the ABNF) that gets sent back for each TARGET?? The success or failure can be conveyed by the request-status? Isnt that why we have request-status? Or is there just something Im missing as I try to get back up to speed on missed traffic? > The text you are proposing > implies that all other commands can partly fail, Id state it somewhat differently in that the DELETE, or any other command, worked or not but the individual results, say per TARGET, can vary. If I cannot remove a VEVENT from a TARGET due to a VCAR then did the DELETE really fail? It worked for all the cases where I could actually delete. The command _itself_ did complete; just not all of the results were 'positive'! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D0A2785256CB6_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 01/13/2003 04:36:56 AM:
> I still think (as briefly mentioned before) that we should clearly
> define failure modes for all commands.

Isnt that already accomplished by the delete-reply (or any *-reply in the ABNF) that gets sent back for each TARGET??  The success or failure can be conveyed by the request-status?  Isnt that why we have request-status?  Or is there just something Im missing as I try to get back up to speed on missed traffic?

>                                        The text you are proposing
> implies that all other commands can partly fail,

Id state it somewhat differently in that the DELETE, or any other command, worked or not but the individual results, say per TARGET, can vary.  If I cannot remove a VEVENT from a TARGET due to a VCAR then did the DELETE really fail?  It worked for all the cases where I could actually delete.  The command _itself_ did complete; just not all of the results were 'positive'!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006D0A2785256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:04:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05340 for ; Wed, 22 Jan 2003 15:04:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MJrra24348 for ietf-calendar-bks; Wed, 22 Jan 2003 11:53:53 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MJrpo24338 for ; Wed, 22 Jan 2003 11:53:51 -0800 (PST) To: Mark Swanson Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: RFC 2445 Q: is TZID broken? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 22 Jan 2003 14:53:58 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 01/22/2003 02:53:54 PM, Serialize complete at 01/22/2003 02:53:54 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark, having different implementations is a hurdle to interoperability. This is one of the items that is being worked on during our interop testing. I know there was some work going on about having one place/table to use for timezones. The Olson table was suggested - although people have commented that it is not all-inclusive. Mr. Olson said he was willing to share this table with the IETF world so there would be one common repository. What he did not want to do was be responsible for communicating changes back and forth to the IETF. he has another person, anyway, who manages this. I brought it up to management at the IETF - and they said they were will to have someone "be responsible" for intereacting with the Olson table group. I think it simply fell off of the radar scope for someone to follow up and continue this effort. I keep hoping someone on this list is a zealot about timezones and would be willing to help "nudge" this along. Mark Swanson Sent by: owner-ietf-calendar@mail.imc.org 01/22/2003 13:48 To: ietf-calendar@imc.org cc: Subject: RFC 2445 Q: is TZID broken? Hello, There seems to be an issue with time zones: (from the spec) "The specification of globally unique time zone identifiers is not addressed by this document and is left for future study." Since I'm seeing various popular ICalendar implementations use their own formats, how can anything be expected to interoperate? You obviously can not rely on GMT offset ("America/Phoenix" and "America/Denver" both have GMT-07:00, but differ in daylight savings behavior) so time zone identifiers are required. Would a list of timezones for every available implementation be required? As well as a mapping between them all? Anyone can see the time zones that ScheduleWorld uses by iterating through the available TimeZone.getAvailableIDs(). Thank you. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:11:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05583 for ; Wed, 22 Jan 2003 15:11:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MJwKc24596 for ietf-calendar-bks; Wed, 22 Jan 2003 11:58:20 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MJwIo24591 for ; Wed, 22 Jan 2003 11:58:19 -0800 (PST) In-Reply-To: <200301221333.33800.mark@WebServiceSolutions.com> To: ietf-calendar@imc.org Subject: Re: Outlook incorrect parameter text MIME-Version: 1.0 X-Mailer: Lotus Notes Build V601_01092003NP January 09, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Wed, 22 Jan 2003 14:58:17 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 02:58:10 PM, Serialize complete at 01/22/2003 02:58:10 PM Content-Type: multipart/alternative; boundary="=_alternative 006DA4E585256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006DA4E585256CB6_= Content-Type: text/plain; charset="US-ASCII" This is a bug in the BNF .. Should be param-value not paramtext _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Mark Swanson Sent by: owner-ietf-calendar@mail.imc.org 01/22/2003 01:33 PM To ietf-calendar@imc.org cc Subject Outlook incorrect parameter text Hello, Can anyone confirm that this is non-conformant ICalendar: DTSTART;TZID="Eastern Time (US & Canada)":20030114T100000 The parameter text ("Eastern Time (US & Canada)") MUST be *SAFE-CHAR: paramtext = *SAFE-CHAR SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-US-ASCII ; Any character except CTLs, DQUOTE, ";", ":", "," It seems Outlook is creating parameters with the DQUOTE character, which is not correct. Is this analysis correct? Thanks. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp --=_alternative 006DA4E585256CB6_= Content-Type: text/html; charset="US-ASCII"
This is a bug in the BNF   .. Should be param-value not paramtext
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


Mark Swanson <mark@WebServiceSolutions.com>
Sent by: owner-ietf-calendar@mail.imc.org

01/22/2003 01:33 PM

To
ietf-calendar@imc.org
cc
Subject
Outlook incorrect parameter text






Hello,

Can anyone confirm that this is non-conformant ICalendar:

DTSTART;TZID="Eastern Time (US & Canada)":20030114T100000

The parameter text ("Eastern Time (US & Canada)") MUST be *SAFE-CHAR:

    paramtext  = *SAFE-CHAR

    SAFE-CHAR  = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
               / NON-US-ASCII
    ; Any character except CTLs, DQUOTE, ";", ":", ","

It seems Outlook is creating parameters with the DQUOTE character, which is
not correct.

Is this analysis correct?

Thanks.

--
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
Java Web Start:
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp
--=_alternative 006DA4E585256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:12:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05607 for ; Wed, 22 Jan 2003 15:12:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MK2KI24792 for ietf-calendar-bks; Wed, 22 Jan 2003 12:02:20 -0800 (PST) Received: from localhost.localdomain (24-240-234-245.charter.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MK2Jo24788 for ; Wed, 22 Jan 2003 12:02:19 -0800 (PST) Received: from jsoft.com (eeyore.jsoft.com [192.168.0.46]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0MK8Zjs026078; Wed, 22 Jan 2003 14:08:36 -0600 Message-ID: <3E2EF74C.4060506@jsoft.com> Date: Wed, 22 Jan 2003 13:55:56 -0600 From: Gary Frederick User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce_Kahn@notesdev.ibm.com, ietf-calendar@imc.org Subject: Re: Is Apple creating invalid iCalendar? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I was talking about iCalendar at the w3 chat today and was way way over my head - but I kept talking :-) The next chat is scheduled for two weeks from now at 11AM CST (1700Z?) It would be great to have someone there that actually knows the spec. :-) and Someone from Apple was there and is on the calsch list. and There is an interest in test data for iCalendar with the w3 folks. Gary Today's chat should be here http://ilrt.org/discovery/chatlogs/rdfig/2003-01-22.html#T17-01-55 Bruce_Kahn@notesdev.ibm.com wrote: > > I wrote on 01/21/2003 05:11:33 PM: > > > Would anyone disagree with this analysis? > > > > Your general analysis is correct; Apple is incorrectly generating > > 'vendor specific' items by using just 2 characters for an apparent > > vendorid value. > > An update to this topic after I did a 30 second peek at the .ICS > mentioned in the RDFCal chat: > > _18:43:33_ > > ** OK, http://www.w3.org/2002/12/cal/test/mtg.ics loaded fine. > Rather nice to be able to do this... I've saved an xcal, checking it in > now. > > I looked at the .ICS file mentioned and I see that iCal doesnt adhere > to 2445. The file contains: > > BEGIN:VCALENDAR > CALSCALE:GREGORIAN > PRODID:-//Apple Computer\, Inc//iCal 1.0//EN > X-WR-TIMEZONE;VALUE=TEXT:US/Eastern > VERSION:2.0 > BEGIN:VEVENT > SEQUENCE:3 > DTSTAMP:20021219T205357Z > SUMMARY:icalendaring #rdfig meeting > DTEND;TZID=US/Eastern:20030108T140000 > DTSTART;TZID=US/Eastern:20030108T130000 > UID:CDC474D4-1393-11D7-9A2C-000393914268 > END:VEVENT > END:VCALENDAR > > I agree that the X-WR-TIMEZONE is incorrectly done because its a vendor > extension thats not properly labeled as such. The bigger problem is > that DTSTART and DTEND have TZIDs but NO matching VTIMEZONE! This > violates 2445 > > 4.2.19 Time Zone Identifier: > ... > Description: The parameter MUST be specified on the "DTSTART", > "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE- > TIME or TIME value type is specified and when the value is not either > a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type > definition for a description of UTC and "floating time" formats. This > property parameter specifies a text value which uniquely identifies > the "VTIMEZONE" calendar component to be used when evaluating the > time portion of the property. The value of the TZID property > parameter will be equal to the value of the TZID property for the > matching time zone definition. An individual "VTIMEZONE" calendar > component MUST be specified for each unique "TZID" parameter value > specified in the iCalendar object. > > This could make the .ics file generate errors on those clients that > adhere to the RFCs. We really should find a contact @ Apple so they can > correct this. > > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... > From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:19:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05915 for ; Wed, 22 Jan 2003 15:19:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MK9HS25068 for ietf-calendar-bks; Wed, 22 Jan 2003 12:09:17 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MK9Fo25063 for ; Wed, 22 Jan 2003 12:09:15 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 0AD96443B; Wed, 22 Jan 2003 15:08:48 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: John Stracke Subject: Re: Is Apple creating invalid iCalendar? Date: Wed, 22 Jan 2003 15:04:41 -0500 User-Agent: KMail/1.5 Cc: ietf-calendar@imc.org References: <200301220007.40722.mark@WebServiceSolutions.com> <1043263277.21469.7577.camel@barrayar.local.thibault.org> In-Reply-To: <1043263277.21469.7577.camel@barrayar.local.thibault.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301221504.41813.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On January 22, 2003 02:21 pm, John Stracke wrote: > On Wed, 2003-01-22 at 00:07, Mark Swanson wrote: > > x-name may not be "VALUE" found above according to rfc2445: > > Then that's a bug in RFC-2445; obviously we want x-props to be able to > use VALUE. I have found and misplaced several small lists of 2445 bugs over time. Does anyone have a link to the definitive guide to: 1. rfc 2445 bugs 2. rfc 2445 bugs that you must conform to if you want to interoperate :-) Thank you. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:26:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06130 for ; Wed, 22 Jan 2003 15:26:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKENM25466 for ietf-calendar-bks; Wed, 22 Jan 2003 12:14:23 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKELo25460 for ; Wed, 22 Jan 2003 12:14:21 -0800 (PST) In-Reply-To: <3E22D34E.6090309@centive.com> To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 15:14:18 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 03:14:11 PM, Serialize complete at 01/22/2003 03:14:11 PM Content-Type: multipart/alternative; boundary="=_alternative 006F2AB685256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F2AB685256CB6_= Content-Type: text/plain; charset="US-ASCII" John replied on 01/13/2003 09:55:10 AM: > Atomicity does complicate the implementations; but it's possible to > provide it relatively simply. A low-end CS that doesn't need to perform > wonderfully could simplify its atomicity requirements by serializing its > writes--instead of doing full-fledged rollback logs, it could lock down > the store while doing a write, and only have one outstanding write at a > time. Hahaha. Do you really think that anyone building a CS NOT on top of a RDBMS is going to actually destroy and mangle their performance on purpose so they can serialize their writes and reads like that??! EVERY operation would have to wait to make sure that ALL the TARGETs were singularly available before it could proceed with any operation! Yeah, that's a really great design Id love to see implemented. Scales real well too... Doug's stated intent in proposing this new text was "because a malformed "QUERY" property value could have devastating effects and unintended deletion of some objects could make a calendar unusable." There is a distinct difference between a 'malformed' query and one that's just running amok but properly formed. NO command should attempt to do any work if there is bad data in the command or bad parameters on the command. That is, if the VQUERY is improperly formed then the command itself should immediately fail. That's a totally different case than if the query for "all VEVENTS and VTODOs on my jerk bosses calendar" is sent on the DELETE. If I properly craft a malicious query that's very different than if I miscraft a well meaning one. I am strongly against essentially mandating that the CS MUST have an RDBMS back end because I don't see that its necessary. We've taken pains to define a relatively abstract data and system model but this new text just nukes all that effort with no demonstrable gain or need. In addition, if we ever get back to considering multi-CS commands (TARGETing calendars in other CS, the old fanout issue we dropped for CAP 1.0) then not even an RDBMS will save you as I know of none that work across multiple actual servers. I would be strongly in favor of some text that puts strict behavior controls on stuff like improperly formed commands or requests. Something like "If the parameters or data in the command are incorrectly formed or unparsable then the command MUST fail, log a message and put a black tick next to that users name in their personal file." Ok, that last bit may be overkill but the rest I still like. This is akin to what Andrea was asking for too... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F2AB685256CB6_= Content-Type: text/html; charset="US-ASCII"
John replied on 01/13/2003 09:55:10 AM:
> Atomicity does complicate the implementations; but it's possible to
> provide it relatively simply.  A low-end CS that doesn't need to perform
> wonderfully could simplify its atomicity requirements by serializing its
> writes--instead of doing full-fledged rollback logs, it could lock down
> the store while doing a write, and only have one outstanding write at a
> time.

Hahaha.  Do you really think that anyone building a CS NOT on top of a RDBMS is going to actually destroy and mangle their performance on purpose so they can serialize their writes and reads like that??!  EVERY operation would have to wait to make sure that ALL the TARGETs were singularly available before it could proceed with any operation!  Yeah, that's a really great design Id love to see implemented.  Scales real well too...

Doug's stated intent in proposing this new text was "because a malformed "QUERY" property value could have devastating effects and unintended deletion of some objects could make a calendar unusable."  There is a distinct difference between a 'malformed' query and one that's just running amok but properly formed.  NO command should attempt to do any work if there is bad data in the command or bad parameters on the command.  That is, if the VQUERY is improperly formed then the command itself should immediately fail.  That's a totally different case than if the query for "all VEVENTS and VTODOs on my jerk bosses calendar" is sent on the DELETE.  If I properly craft a malicious query that's very different than if I miscraft a well meaning one.

I am strongly against essentially mandating that the CS MUST have an RDBMS back end because I don't see that its necessary.  We've taken pains to define a relatively abstract data and system model but this new text just nukes all that effort with no demonstrable gain or need.  In addition, if we ever get back to considering multi-CS commands (TARGETing calendars in other CS, the old fanout issue we dropped for CAP 1.0) then not even an RDBMS will save you as I know of none that work across multiple actual servers.

I would be strongly in favor of some text that puts strict behavior controls on stuff like improperly formed commands or requests.  Something like "If the parameters or data in the command are incorrectly formed or unparsable then the command MUST fail, log a message and put a black tick next to that users name in their personal file."  Ok, that last bit may be overkill but the rest I still like.  This is akin to what Andrea was asking for too...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006F2AB685256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:33:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06330 for ; Wed, 22 Jan 2003 15:33:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKLKf25803 for ietf-calendar-bks; Wed, 22 Jan 2003 12:21:20 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKLIo25792 for ; Wed, 22 Jan 2003 12:21:18 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 266A0443B; Wed, 22 Jan 2003 15:20:52 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: John Stracke Subject: Re: RFC 2445 Q: is TZID broken? Date: Wed, 22 Jan 2003 15:16:43 -0500 User-Agent: KMail/1.5 Cc: ietf-calendar@imc.org References: <200301221348.30131.mark@WebServiceSolutions.com> <1043262620.21469.7554.camel@barrayar.local.thibault.org> In-Reply-To: <1043262620.21469.7554.camel@barrayar.local.thibault.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200301221516.45194.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On January 22, 2003 02:10 pm, John Stracke wrote: > On Wed, 2003-01-22 at 13:48, Mark Swanson wrote: > > Since I'm seeing various popular ICalendar implementations use their > own > formats, how can anything be expected to interoperate? > > From section 4.2.19 of RFC-2445: > > An individual "VTIMEZONE" calendar > component MUST be specified for each unique "TZID" parameter > value > specified in the iCalendar object. > > In other words, even if a TZID starts with a "/", and so is nominally > global, its scope is still local to the VCALENDAR. > > You obviously can not rely on GMT offset ("America/Phoenix" and > "America/Denver" both have GMT-07:00, but differ in daylight savings > behavior) so time zone identifiers are required. > > Global time zone identifiers are nearly impossible; at a minimum, they > would have to come with a timestamp, since time zone definitions change > over time. Ah. I see the correlation to the offset and daylight savings. Thank you. - -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+LvwrBtoFHHwdJ/cRAlRjAJoCwAm/pn7Mfz0aRPDjiBTAWum85ACfdBc0 WaPOMKajSK2eCWqEJ9rKP0w= =ecHS -----END PGP SIGNATURE----- From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:33:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06344 for ; Wed, 22 Jan 2003 15:33:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKNf325922 for ietf-calendar-bks; Wed, 22 Jan 2003 12:23:41 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKNeo25918 for ; Wed, 22 Jan 2003 12:23:40 -0800 (PST) In-Reply-To: <20030113154436.GF44480@inet.it> To: Andrea Campi Cc: John Stracke , ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 15:23:32 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 03:23:30 PM, Serialize complete at 01/22/2003 03:23:30 PM Content-Type: multipart/alternative; boundary="=_alternative 0070031E85256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0070031E85256CB6_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 01/13/2003 10:44:36 AM: > - look at all queries (we may have more than one in the same command), if > any of them is invalid fail entire command > - look at all targets, if any of them is invalid fail entire command > - perform command in order This does not match the proposed texts intent. Doug's motivation was "because a malformed "QUERY" property value could have devastating effects and unintended deletion of some objects could make a calendar unusable." However the new text starts with: Ether everything succeeds or nothing is done. So if the VREPLY contains X number of successful replies and at least one (1) failure then no objects were deleted or marked for deletion. This all means that if there were any failures in your "-perform command in order" then the command would fail; it does not just match your first two lines. I agree w/you (see last msg) that the command itself should fail if there is any problem w/the parameters or inputs to it; it should succeed otherwise. Any failures during your "-perform command in order" step is NOT grounds for failing the entire command! There was nothing wrong w/the command itself, the 'problem' was due to something else and not necessarily anything malicious even! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0070031E85256CB6_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 01/13/2003 10:44:36 AM:
>  - look at all queries (we may have more than one in the same command), if
> any of them is invalid fail entire command
>  - look at all targets, if any of them is invalid fail entire command
>  - perform command in order
This does not match the proposed texts intent.  Doug's motivation was "because a malformed "QUERY" property value could have devastating effects and unintended deletion of some objects could make a calendar unusable."  However the new text starts with:

                                                                 Ether
                everything succeeds or nothing is done. So if the VREPLY
                contains X number of successful replies and at least
                one (1) failure then no objects were deleted or marked
                for deletion.

This all means that if there were any failures in your "-perform command in order" then the command would fail; it does not just match your first two lines.

I agree w/you (see last msg) that the command itself should fail if there is any problem w/the parameters or inputs to it; it should succeed otherwise.  Any failures during your "-perform command in order" step is NOT grounds for failing the entire command!  There was nothing wrong w/the command itself, the 'problem' was due to something else and not necessarily anything malicious even!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0070031E85256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:41:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06588 for ; Wed, 22 Jan 2003 15:41:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKTkt26281 for ietf-calendar-bks; Wed, 22 Jan 2003 12:29:46 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKTho26276 for ; Wed, 22 Jan 2003 12:29:44 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id DB81E443B; Wed, 22 Jan 2003 15:29:17 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: pregen@egenconsulting.com Subject: Re: RFC 2445 Q: is TZID broken? Date: Wed, 22 Jan 2003 15:25:09 -0500 User-Agent: KMail/1.5 Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200301221525.10902.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On January 22, 2003 02:53 pm, pregen@egenconsulting.com wrote: > Mark, having different implementations is a hurdle to interoperability. > This is one of the items that is being worked on during our interop > testing. I know there was some work going on about having one place/table > to use for timezones. The Olson table was suggested - although people > have commented that it is not all-inclusive. Mr. Olson said he was > willing to share this table with the IETF world so there would be one > common repository. What he did not want to do was be responsible for > communicating changes back and forth to the IETF. he has another person, > anyway, who manages this. I brought it up to management at the IETF - and > they said they were will to have someone "be responsible" for intereacting > with the Olson table group. I think it simply fell off of the radar scope > for someone to follow up and continue this effort. I keep hoping someone > on this list is a zealot about timezones and would be willing to help > "nudge" this along. Interesting. Thanks. Would it be feasible to say that it may have fallen off of the radar scope because strings like "US-Eastern" are just identifiers and the real time zone definition is in VTIMEZONE (which can define any past/present/future time zone including daylight savings)? - -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+Lv4lBtoFHHwdJ/cRAk4iAKCRgwLTKGFCJ7sFssAy0E/vjZTUHgCfZ0/5 bhnzNeAPWVlWwKSXsrk+Qjw= =UGv4 -----END PGP SIGNATURE----- From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:42:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06609 for ; Wed, 22 Jan 2003 15:42:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKXbt26453 for ietf-calendar-bks; Wed, 22 Jan 2003 12:33:37 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKXao26449 for ; Wed, 22 Jan 2003 12:33:36 -0800 (PST) In-Reply-To: <3E22F55F.2020901@Royer.com> To: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 15:33:29 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 03:33:25 PM, Serialize complete at 01/22/2003 03:33:25 PM Content-Type: multipart/alternative; boundary="=_alternative 0070EC8785256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0070EC8785256CB6_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 01/13/2003 12:20:31 PM: > Of the commands I would say: > > CMD My thoughts > --- ------------ > > ABORT Does not apply as there is no partial failure. > CONTINUE Does not apply as there is no partial failure. > CREATE Maybe an issue - YES > DELETE YES > GENERATE-UID Does not apply as there is no partial failure. > GET-CAPABILITY Does not apply as there is no partial failure. > IDENTIFY Does not apply as there is no partial failure. > MODIFY YES > MOVE YES > REPLY Does not apply as there is no partial failure of REPLY > SEARCH Does not apply as partial failures cause no harm. > SET-LOCALE Does not apply as there is no partial failure. > TIMEOUT Does not apply as there is no partial failure. > > It it would only apply to 3 commands not all of them. > Correct? Not quite. Nearly all commands could fail. For example, the Admins has begun system shutdown so no new commands should be accepted. Thus, instead of keeping the CS up as GENERATE-UIDs (or CONTINUEs or ...) come in, the command would fail with an appropriate reponse like "REQUEST-STATUS:6.5;System shutdown in progress\, no new commands accepted." as the reply. The same goes for the CONTINUE and nearly all commands. ABORT may be the sole holdout (REPLY is not a command)... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0070EC8785256CB6_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 01/13/2003 12:20:31 PM:
> Of the commands I would say:
>
>    CMD      My thoughts
>    ---      ------------
>
>    ABORT      Does not apply as there is no partial failure.
>    CONTINUE   Does not apply as there is no partial failure.
>    CREATE      Maybe an issue - YES
>    DELETE      YES
>    GENERATE-UID   Does not apply as there is no partial failure.
>    GET-CAPABILITY   Does not apply as there is no partial failure.
>    IDENTIFY   Does not apply as there is no partial failure.
>    MODIFY      YES
>    MOVE      YES
>    REPLY      Does not apply as there is no partial failure of REPLY
>    SEARCH      Does not apply as partial failures cause no harm.
>    SET-LOCALE   Does not apply as there is no partial failure.
>    TIMEOUT      Does not apply as there is no partial failure.
>
> It it would only apply to 3 commands not all of them.
> Correct?
Not quite.  Nearly all commands could fail.

For example, the Admins has begun system shutdown so no new commands should be accepted.  Thus, instead of keeping the CS up as GENERATE-UIDs (or CONTINUEs or ...) come in, the command would fail with an appropriate reponse like "REQUEST-STATUS:6.5;System shutdown in progress\, no new commands accepted." as the reply.  The same goes for the CONTINUE and nearly all commands.  ABORT may be the sole holdout (REPLY is not a command)...
Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0070EC8785256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:47:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06721 for ; Wed, 22 Jan 2003 15:47:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKbWe26603 for ietf-calendar-bks; Wed, 22 Jan 2003 12:37:32 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKbTo26593 for ; Wed, 22 Jan 2003 12:37:30 -0800 (PST) To: Mark Swanson Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: RFC 2445 Q: is TZID broken? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 22 Jan 2003 15:37:37 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 01/22/2003 03:37:33 PM, Serialize complete at 01/22/2003 03:37:33 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On January 22, 2003 02:53 pm, mark@WebServiceSolutions.com wrote: >Would it be feasible to say that it may have fallen off of the radar scope >because strings like "US-Eastern" are just identifiers and the real time zone >definition is in VTIMEZONE (which can define any past/present/future time >zone including daylight savings)? Not really. It fell off the radar screen because of time constraints for people. It had nothing to do with where it fell in the draft. It was where it fell on people's time schedules... From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:57:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06868 for ; Wed, 22 Jan 2003 15:57:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKnKQ27010 for ietf-calendar-bks; Wed, 22 Jan 2003 12:49:20 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKnIo27006 for ; Wed, 22 Jan 2003 12:49:18 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id h0MKjlQ9007290; Wed, 22 Jan 2003 15:45:47 -0500 Date: Wed, 22 Jan 2003 15:45:47 -0500 Message-Id: <200301222045.h0MKjlQ9007290@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: "ietf-calendar@imc.org" , John Stracke In-reply-to: <3E22D34E.6090309@centive.com> Subject: Re: No partial success when it comes to deletion? References: <3E21CF15.40001@Royer.com> <20030113093656.GB44480@inet.it> <3E22D34E.6090309@centive.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Mon, 13 Jan 2003 09:55:10 -0500 From: John Stracke [...] Atomicity does complicate the implementations; but it's possible to provide it relatively simply. A low-end CS that doesn't need to perform wonderfully could simplify its atomicity requirements by serializing its writes--instead of doing full-fledged rollback logs, it could lock down the store while doing a write, and only have one outstanding write at a time. And, of course, any CS built on an RDBMS can just piggyback on the DB's own rollback. What if the server fails in the middle of the operation? Is it acceptable that the operation is half-done? I don't think atomicity requirements are as burdensome as Bruce thinks they are, but if you're going to add them there should also be text about server failures. Requiring servers to maintain atomicity even when they crash is considerably more burdensome. (I suspect it can be left as a quality-of-implementation issue.) Larry From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:58:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06899 for ; Wed, 22 Jan 2003 15:58:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKkJW26906 for ietf-calendar-bks; Wed, 22 Jan 2003 12:46:19 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKkIo26902 for ; Wed, 22 Jan 2003 12:46:18 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: CREATE Command and ordering of responses. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 15:46:14 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 03:46:06 PM, Serialize complete at 01/22/2003 03:46:06 PM Content-Type: multipart/alternative; boundary="=_alternative 0072171285256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072171285256CB6_= Content-Type: text/plain; charset="US-ASCII" In scanning the 12Jan2003 draft I ran across the text: 10.1.4. CREATE Command ... When there are multiple "TARGET" properties in the original command object then the replies MUST BE in the exact same order as they were provided to the CS. Why MUST the responses be in the same order as the TARGETs? Properties in iCalendar, iTIP and iMIP are not ordered. Why MUST my CS return responses in a particular order? It sounds like someone wants to cut corners by just mathing "Response 1 to TARGET 1", "Respones 2 to TARGET 2", etc instead of actually looking at the enbedded ID in the reply (ie: the CARID in the VREPLYs) and then matching up the response. No other command mandates this (nor should they) so I propose this line be removed from 10.1.4. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0072171285256CB6_= Content-Type: text/html; charset="US-ASCII"
In scanning the 12Jan2003 draft I ran across the text:

10.1.4.  CREATE Command
...
When there are multiple "TARGET" properties in the original command object then the replies MUST BE in the exact same order as they were provided to the CS.

Why MUST the responses be in the same order as the TARGETs?  Properties in iCalendar, iTIP and iMIP are not ordered.  Why MUST my CS return responses in a particular order?   It sounds like someone wants to cut corners by just mathing "Response 1 to TARGET 1", "Respones 2 to TARGET 2", etc instead of actually looking at the enbedded ID in the reply (ie: the CARID in the VREPLYs) and then matching up the response.

No other command mandates this (nor should they) so I propose this line be removed from 10.1.4.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0072171285256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 15:58:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06913 for ; Wed, 22 Jan 2003 15:58:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKnqs27027 for ietf-calendar-bks; Wed, 22 Jan 2003 12:49:52 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKnpo27023 for ; Wed, 22 Jan 2003 12:49:51 -0800 (PST) In-Reply-To: <3E230CD4.8090007@Royer.com> To: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 15:49:46 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 03:49:40 PM, Serialize complete at 01/22/2003 03:49:40 PM Content-Type: multipart/alternative; boundary="=_alternative 007269F985256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007269F985256CB6_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 01/13/2003 02:00:36 PM: > > Let's see. A partial failure can certainly occur--say, if the system > > has enough disk space for the main VEVENT, but not for the VTIMEZONE in > > contains. In that case, the VEVENT would be invalid--and we probably do > > want to make sure that we don't put invalid iCalendar components into a > > CS, don't we? > > > > If there are no objections I'll add that restriction to I object to the proposed text as it essentially mandates that the CS be built on an RDBMS of some kind. I do NOT object to the intent of requireing ALL commands to safety check their _inputs_ prior to actually performing said command. The success or failure of individual TARGETs is NOT grounds for failing ALL TARGETs!! WRT to Johns concern: The VEVENT should NOT be CREATEd if the entire creation cannot be completed for that TARGET. That is, the CREATE command is creating the event and the definition in the store so either it works and both are there or it fails and neither are there. The VEVENT MUST NOT be created and left if the command for that TARGET fails! Otherwise any failures would result in all kinds of cruft being left in the TARGET! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007269F985256CB6_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 01/13/2003 02:00:36 PM:
> > Let's see.  A partial failure can certainly occur--say, if the system
> > has enough disk space for the main VEVENT, but not for the VTIMEZONE in
> > contains.  In that case, the VEVENT would be invalid--and we probably do
> > want to make sure that we don't put invalid iCalendar components into a
> > CS, don't we?
> >
>
> If there are no objections I'll add that restriction to
I object to the proposed text as it essentially mandates that the CS be built on an RDBMS of some kind.  I do NOT object to the intent of requireing ALL commands to safety check their _inputs_ prior to actually performing said command.  The success or failure of individual TARGETs is NOT grounds for failing ALL TARGETs!!

WRT to Johns concern: The VEVENT should NOT be CREATEd if the entire creation cannot be completed for that TARGET.  That is, the CREATE command is creating the event and the definition in the store so either it works and both are there or it fails and neither are there.  The VEVENT MUST NOT be created and left if the command for that TARGET fails!  Otherwise any failures would result in all kinds of cruft being left in the TARGET!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 007269F985256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 16:05:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07119 for ; Wed, 22 Jan 2003 16:05:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKv2u27343 for ietf-calendar-bks; Wed, 22 Jan 2003 12:57:02 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKv1o27338 for ; Wed, 22 Jan 2003 12:57:01 -0800 (PST) In-Reply-To: <20030115235101.GA56931@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: Missing description of parameters MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 15:56:57 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 03:56:50 PM, Serialize complete at 01/22/2003 03:56:50 PM Content-Type: multipart/alternative; boundary="=_alternative 0073127B85256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073127B85256CB6_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 01/15/2003 06:51:01 PM: > Besides, you mentioned before that some people get upset when > a property and a parameter have the same name - ACTION is one such > instance. You don't think we could rename ACTION to something else - > TIMEOUT or ONTIMEOUT maybe? There is precedence for this already in iCalendar. TZID is both a parameter (tzidparam) and a property (tzid). The name matches the function so keeping ACTION as ACTION in 2 places should be ok. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0073127B85256CB6_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 01/15/2003 06:51:01 PM:
> Besides, you mentioned before that some people get upset when
> a property and a parameter have the same name - ACTION is one such
> instance. You don't think we could rename ACTION to something else -
> TIMEOUT or ONTIMEOUT maybe?
There is precedence for this already in iCalendar.  TZID is both a parameter (tzidparam) and a property (tzid).  The name matches the function so keeping ACTION as ACTION in 2 places should be ok.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0073127B85256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 16:24:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07690 for ; Wed, 22 Jan 2003 16:24:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MLAsZ27849 for ietf-calendar-bks; Wed, 22 Jan 2003 13:10:54 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MLAro27844 for ; Wed, 22 Jan 2003 13:10:53 -0800 (PST) In-Reply-To: <20030117102309.GA63049@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: STORES-EXPANDED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 16:10:44 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 04:10:40 PM, Serialize complete at 01/22/2003 04:10:40 PM Content-Type: multipart/alternative; boundary="=_alternative 0074553985256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0074553985256CB6_= Content-Type: text/plain; charset="US-ASCII" Andrea responded on 01/17/2003 05:23:09 AM: > I don't see how > STORES-EXPANDED would apply (a CUA doesn't really store, and the > CS wouldn't care anyway). The information is also necessary if building CS <-> CS synchronization or replication. Thats NOT in CAP 1.0 (too hard) but its not a CUA / CS thing but more of a Sender / Receiver thing. In that frame of reference it should make more sense. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0074553985256CB6_= Content-Type: text/html; charset="US-ASCII"
Andrea responded on 01/17/2003 05:23:09 AM:
>                                                 I don't see how
> STORES-EXPANDED would apply (a CUA doesn't really store, and the
> CS wouldn't care anyway).

The information is also necessary if building CS <-> CS synchronization or replication.  Thats NOT in CAP 1.0 (too hard) but its not a CUA / CS thing but more of a Sender / Receiver thing.  In that frame of reference it should make more sense.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0074553985256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 16:43:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08433 for ; Wed, 22 Jan 2003 16:43:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MLRXZ28353 for ietf-calendar-bks; Wed, 22 Jan 2003 13:27:33 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MLRWo28349 for ; Wed, 22 Jan 2003 13:27:32 -0800 (PST) In-Reply-To: <3E2C54D3.30207@Royer.com> To: ietf-calendar@imc.org Subject: Re: When to specify TARGET property MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 16:27:28 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 04:27:19 PM, Serialize complete at 01/22/2003 04:27:19 PM Content-Type: multipart/alternative; boundary="=_alternative 0075DD8785256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075DD8785256CB6_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 01/20/2003 02:58:11 PM: > > which seems to imply the TARGET property must be supplied for ABORT > > commands for example. Is this correct? > > Good point - I'll tweak the text. I do not think it is needed > with the ABORT command. The cited text is at odds with the actual ABNF in the draft: 2. Additions to iCalendar: ... calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once. ; prodid /version / ; These are optional, but MUST NOT occur ; more than once. ; calscale / method / cmd / ; These are optional, and may occur more ; than once. ; target / other-props Thus TARGET is optional for all commands according to this ABNF, not required. Striking the cited line is probably the right thing to do. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0075DD8785256CB6_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 01/20/2003 02:58:11 PM:
> > which seems to imply the TARGET property must be supplied for ABORT
> > commands for example.  Is this correct?
>
> Good point - I'll tweak the text. I do not think it is needed
> with the ABORT command.
The cited text is at odds with the actual ABNF in the draft:

2.  Additions to iCalendar:
...
calprops   = 2*(

          ; 'prodid' and 'version' are both REQUIRED,
          ; but MUST NOT occur more than once.
          ;
            prodid /version /

          ; These are optional, but MUST NOT occur
          ; more than once.
          ;
            calscale        /
            method          /
            cmd             /

          ; These are optional, and may occur more
          ; than once.
          ;
            target / other-props
Thus TARGET is optional for all commands according to this ABNF, not required.  Striking the cited line is probably the right thing to do.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0075DD8785256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 16:47:52 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08603 for ; Wed, 22 Jan 2003 16:47:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MLX5w28524 for ietf-calendar-bks; Wed, 22 Jan 2003 13:33:05 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MLX3o28520 for ; Wed, 22 Jan 2003 13:33:03 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: GET-CAPABILITY to be updated? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 16:32:58 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 04:32:49 PM, Serialize complete at 01/22/2003 04:32:49 PM Content-Type: multipart/alternative; boundary="=_alternative 00765E7585256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00765E7585256CB6_= Content-Type: text/plain; charset="US-ASCII" This may be just a retread of an agreed on change (at least Andrea and I agreed) but in the latest draft I see the following: A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. The "GET-CAPABILITY" command MUST BE implemented by all CSs. The CS MUST send a "GET-CAPABILITY" command to a CUA after the initial connection. The CUA MUST recogonize the "GET-CAPABILITY" command and MAY return a not implemented reply meaning that the CUA supports only the default capababilities. Just wanted to make sure that this was slated to be changed in the next technical set of changes to be that ALL sides MUST support GET-CAPABILITY and that assuming defaults is BAD... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00765E7585256CB6_= Content-Type: text/html; charset="US-ASCII"
This may be just a retread of an agreed on change (at least Andrea and I agreed) but in the latest draft I see the following:

A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. The "GET-CAPABILITY" command MUST BE implemented by all CSs.

The CS MUST send a "GET-CAPABILITY" command to a CUA after the initial connection. The CUA MUST recogonize the "GET-CAPABILITY" command and MAY return a not implemented reply meaning that the CUA supports only the default capababilities.

Just wanted to make sure that this was slated to be changed in the next technical set of changes to be that ALL sides MUST support GET-CAPABILITY and that assuming defaults is BAD...

Bruce
 ===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00765E7585256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 17:01:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09169 for ; Wed, 22 Jan 2003 17:01:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MLmP828939 for ietf-calendar-bks; Wed, 22 Jan 2003 13:48:25 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MLmMo28935 for ; Wed, 22 Jan 2003 13:48:23 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: 10.1. CAP Commands (CMD) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Jan 2003 16:48:17 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 04:48:09 PM, Serialize complete at 01/22/2003 04:48:09 PM Content-Type: multipart/alternative; boundary="=_alternative 0077C59085256CB6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0077C59085256CB6_= Content-Type: text/plain; charset="US-ASCII" In looking at the ABNF in the latest draft (nice job Doug) I noticed something I consider to be a problem w/the ABNF in the draft. See: 10.1. CAP Commands (CMD) ... Description: All of the command to the CS are supplied in this property. The "OPTIONS" parameter is overloaded and its meaning is dependent on the CMD value supplied. Formal Definition: The property is defined by the following notation: cmd = "CMD" ( / abort-cmd / continue-cmd / create-cmd / delete-cmd / generate-uid-cmd / get-capability-cmd / identify-cmd / modify-cmd / move-cmd / reply-cmd / search-cmd / set-locale-cmd ) CRLF The concern I have is that there is no room for any future commands. That is, there is no iana-token (or x-token??) in the CMD value. As such there is no possibility to allow new commands so that older CSs will react consistantly to them. I think we should be allowing iana-token (or iana-cmd if you prefer to define it) and clearly state what the Receivers response MUST be to unknown command (or unsupported commands!). Currently several commands are flagged as "MUST BE implemented by all CSs ". This list in draft-10 is: CREATE DELETE GENERATE-UID GET-CAPABILITY IDENTIFY MODIFY MOVE REPLY (although this is technically NOT a command!) SEARCH SET-LOCALE I find it someone odd that not every CS MUST support ABORT and CONTINUE. If all of the CAP 1.0 defined commands are MUST to support then a single line of text in Section 10.0 is probably the way to go instead and any command that is NOT mandatory to support should be required to expressly define itself that way (and iana-cmds are that by default!). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0077C59085256CB6_= Content-Type: text/html; charset="US-ASCII"
In looking at the ABNF in the latest draft (nice job Doug) I noticed something I consider to be a problem w/the ABNF in the draft.  See:

10.1. CAP Commands (CMD)
...
Description: All of the command to the CS are supplied in this property. The "OPTIONS" parameter is overloaded and its meaning is dependent on the CMD value supplied.

Formal Definition: The property is defined by the following notation:

cmd              = "CMD" (
                / abort-cmd
                / continue-cmd
                / create-cmd
                / delete-cmd
                / generate-uid-cmd
                / get-capability-cmd
                / identify-cmd
                / modify-cmd
                / move-cmd
                / reply-cmd
                / search-cmd
                / set-locale-cmd
                 ) CRLF
The concern I have is that there is no room for any future commands.  That is, there is no iana-token (or x-token??) in the CMD value.  As such there is no possibility to allow new commands so that older CSs will react consistantly to them.

I think we should be allowing iana-token (or iana-cmd if you prefer to define it) and clearly state what the Receivers response MUST be to unknown command (or unsupported commands!).

Currently several commands are flagged as "MUST BE implemented by all CSs".  This list in draft-10 is:

CREATE
DELETE
GENERATE-UID
GET-CAPABILITY
IDENTIFY
MODIFY
MOVE
REPLY (although this is technically NOT a command!)
SEARCH
SET-LOCALE

I find it someone odd that not every CS MUST support ABORT and CONTINUE.  If all of the CAP 1.0 defined commands are MUST to support then a single line of text in Section 10.0 is probably the way to go instead and any command that is NOT mandatory to support should be required to expressly define itself that way (and iana-cmds are that by default!).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0077C59085256CB6_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 22:35:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15793 for ; Wed, 22 Jan 2003 22:35:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0N3U1r09809 for ietf-calendar-bks; Wed, 22 Jan 2003 19:30:01 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0N3Txo09800 for ; Wed, 22 Jan 2003 19:29:59 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0N3U2hA029893 for ; Wed, 22 Jan 2003 19:30:02 -0800 Message-ID: <3E2F61B5.9060601@Royer.com> Date: Wed, 22 Jan 2003 20:29:57 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Outlook incorrect parameter text References: <200301221333.33800.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020709060809090902060206" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020709060809090902060206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think that someone else pointed to this in another way. I seem to recall the real problem was that the ABNF should have used 'param-value' and not 'paramtext': param-value = paramtext / quoted-string Should be: tzidparam = "TZID" "=" [tzidprefix] param-value CRLF So I think that Outlook is correct in spirit. Mark Swanson wrote: > Hello, > > Can anyone confirm that this is non-conformant ICalendar: > > DTSTART;TZID="Eastern Time (US & Canada)":20030114T100000 > > The parameter text ("Eastern Time (US & Canada)") MUST be *SAFE-CHAR: > > paramtext = *SAFE-CHAR > > SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E > / NON-US-ASCII > ; Any character except CTLs, DQUOTE, ";", ":", "," > > It seems Outlook is creating parameters with the DQUOTE character, which is > not correct. > > Is this analysis correct? > > Thanks. > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020709060809090902060206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjMwMzI5NTdaMCMGCSqGSIb3DQEJBDEWBBRP ZUkBRW8OnC8C2IWGDOoJnn6HkzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAlOgzwmsAg7aI ifeUkcvv2i9bWEPYqt0L0pN+ShhZz869wIYflnfcxR2tdBbQDncAkXdKQMbBb23ZKi53Z9hr at4haBA2VJdIPD3ALx/QCJnO/ig2rpqmOPPe0PjxzD3x7fnBntIAXIZF8tasvIsAzULu0oty ocgRTwWWpLArKhUF/6f0eIFsDTt1chmjMXK7djSsOFy9X+etlCnUp+8e/7XyfI3rapQSqmer V90m9d5hUp00QQUzHLLHLAxVVkFHudzptX/ovkxOQyqZZ9P55+JxvEeoOe3P79ezrVzaUZs4 DApTFQmV+X894puKCW3HFZRtZO95ePM5dsfuWo38FQAAAAAAAA== --------------ms020709060809090902060206-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 22:36:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15827 for ; Wed, 22 Jan 2003 22:36:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0N3PJ609689 for ietf-calendar-bks; Wed, 22 Jan 2003 19:25:19 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0N3PIo09685 for ; Wed, 22 Jan 2003 19:25:18 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0N3PKhA029872 for ; Wed, 22 Jan 2003 19:25:21 -0800 Message-ID: <3E2F609B.1050804@Royer.com> Date: Wed, 22 Jan 2003 20:25:15 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040108070107060409050703" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040108070107060409050703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > ... > There are perfectly normal reasons why some deletions could fail: > insufficient access, concurrent use by another CU, system maintenance on > a VAGENDA, etc.. The new text creates a very very heavy burden on any > CS implementor as they MUST now have a back end storage engine that does > transactioning (in the DB sense of the term). They can no longer use > just any back end engine that can remove records in the store. Good points. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040108070107060409050703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjMwMzI1MTVaMCMGCSqGSIb3DQEJBDEWBBS6 4zifuU2YOOqONWIPYItQ73IM9zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAD/Vf1CSn5TfR gw/o7wUeuqNvFBzYeppn6uMs51mhpWOPlvsZlzBfOqWGHOx1xPHfmYLaNtu86TwXkuSAJ1ej UzvlHUrUTeiFQPvAQmmikS8QWvpn0oGJ3qK9V6S7bqfBlq5GIIGIF3GviDDjb1S9lBTH4dDL 7wEQMvcwEnat7/BAPmeko8//ZMbUO5u79fSzU//2zM0SqFcghdTrJ+itsJzoU+QHDwBEE/R5 atYkBzbDSIfQFggFkiIrqS83xsTdjgsDlxluDUDAhT4+VKPJJqNUFEs0FqrAvfDHzOsrjMbW DE/KblIUFFqEpy5ti6W27Edr2J5vfe0d1NZZAspAYwAAAAAAAA== --------------ms040108070107060409050703-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 22:43:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15990 for ; Wed, 22 Jan 2003 22:43:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0N3Zwl10053 for ietf-calendar-bks; Wed, 22 Jan 2003 19:35:58 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0N3Zvo10049 for ; Wed, 22 Jan 2003 19:35:57 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0N3ZxhA029940 for ; Wed, 22 Jan 2003 19:36:00 -0800 Message-ID: <3E2F631A.1070904@Royer.com> Date: Wed, 22 Jan 2003 20:35:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Is Apple creating invalid iCalendar? References: <200301220007.40722.mark@WebServiceSolutions.com> <1043263277.21469.7577.camel@barrayar.local.thibault.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000808040504080701050205" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000808040504080701050205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > On Wed, 2003-01-22 at 00:07, Mark Swanson wrote: > > x-name may not be "VALUE" found above according to rfc2445: > > Then that's a bug in RFC-2445; obviously we want x-props to be able to > use VALUE. I agree that the existing: Format Definition: The property is defined by the following notation: x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF ; Lines longer than 75 octets should be folded The above ABNF be modified to allow already defined parameters. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000808040504080701050205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjMwMzM1NTRaMCMGCSqGSIb3DQEJBDEWBBTF mmHM0LxZ+a3ur1lmyA7kj98hxzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAAQb1Z0yzMzy8 /zfk2hEE0Klc7IKi6kMxmLS2IYJcg/377jyBRn/+avj8TPJHPXrTkDHdjY7MWslaU7LXzaf3 4270hS0cVtRwtbRvJrpk86qoFp4jq/ZisTDyJJXKX3bT+bOXbA3pDsv0fv+5klRpS15vJ9gt 2jiAuPSHjA+mpS9Pi8PANfO6xehFF/+Xu0QZCgj25XkmZf/Ge3umQNssQ/CfqwxZ6SSY+jra 1lagtHI4uuO0z7sNOOpZVyc/DCBo1DlJRtz8baNHXfwwX06qkq96BDB4j9pTAHNkquTCiVF+ 9YDjMdhRy/QfrTJl13UJIr7Qj7H51Voey3Q0d26RTQAAAAAAAA== --------------ms000808040504080701050205-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 22:49:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16152 for ; Wed, 22 Jan 2003 22:49:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0N3fLM10234 for ietf-calendar-bks; Wed, 22 Jan 2003 19:41:21 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0N3fKo10230 for ; Wed, 22 Jan 2003 19:41:20 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0N3fMhA029978 for ; Wed, 22 Jan 2003 19:41:23 -0800 Message-ID: <3E2F645D.8040804@Royer.com> Date: Wed, 22 Jan 2003 20:41:17 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: CREATE Command and ordering of responses. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050505050506060902000609" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050505050506060902000609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think the text is left over from before we had the TARGET property (iRIP and being able to store iTIP directly). Your right - I do not think we need this restriction any more. Bruce_Kahn@notesdev.ibm.com wrote: > > In scanning the 12Jan2003 draft I ran across the text: > > 10.1.4. CREATE Command > ... > When there are multiple "TARGET" properties in the original command > object then the replies MUST BE in the exact same order as they were > provided to the CS. > ... > No other command mandates this (nor should they) so I propose this line > be removed from 10.1.4. >.... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050505050506060902000609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjMwMzQxMTdaMCMGCSqGSIb3DQEJBDEWBBTL 5Ug6+aInApj9JFtbzF8zyOO2njBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEATfEz2HYRIlnr xhJeZ9Hp83AcHTtsGeFQPpC7ry7VHxUFmVxOZuMKcVc9Cs7qsAeopfaFUAGu/0r335r6/R1K vUPVGnFlXAOTeFOH8tZE9A2ZLRkn+4Qdg0tawFrIM5khAgz5FEetr8hWFYjg7qNPel18SY+h 5ao40Lql3F4sKoZDKNkATS9COhcxA+gESjc6ZrZid+1fuk6er3BBJEEMLiMcHN4UWM0PNzfC yXWmxOXPIhZro1wLlMW+p9xfu6chi7ugz/eRBoGpW0wEcls01Bb+kEztefuhsS65NDL8a879 3Y0jVi1zO1GSrAIASWM4dWJVo6zY0eEl8+EBi0pXegAAAAAAAA== --------------ms050505050506060902000609-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 22:58:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16214 for ; Wed, 22 Jan 2003 22:58:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0N3pCN10534 for ietf-calendar-bks; Wed, 22 Jan 2003 19:51:12 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0N3pAo10529 for ; Wed, 22 Jan 2003 19:51:10 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0N3pDhA030054 for ; Wed, 22 Jan 2003 19:51:14 -0800 Message-ID: <3E2F66AC.9040102@Royer.com> Date: Wed, 22 Jan 2003 20:51:08 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: 10.1. CAP Commands (CMD) - X/IANA-CMD References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090104060902050202010301" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090104060902050202010301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In looking at the ABNF in the latest draft (nice job Doug) I noticed > something I consider to be a problem w/the ABNF in the draft. See: Thanks! :-) > 10.1. CAP Commands (CMD) > ... > Description: All of the command to the CS are supplied in this property. > The "OPTIONS" parameter is overloaded and its meaning is dependent on > the CMD value supplied. > > Formal Definition: The property is defined by the following notation: > ... > > The concern I have is that there is no room for any future commands. > That is, there is no iana-token (or x-token??) in the CMD value. As > such there is no possibility to allow new commands so that older CSs > will react consistantly to them. Good point. I'll add x-cmd and iana-cmd. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090104060902050202010301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjMwMzUxMDhaMCMGCSqGSIb3DQEJBDEWBBSv uIlpLW9aZsRcZwEHzzni/kTcqzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAPNn61PUMFhVO xOa65rpfN5cTvH/K8AIO5/1IE/pZzf59Y40GGDxu2gy1ZnIc/nNbpkP2fySf7zNSnIfUEqum xfRSzie2GfRIJLVlLSHp6wQKBHw+ZayvnNLdffVEnC+OfKdNxobHegk48FDqvHcOppxRDX00 W7Nd/4BDBYfAR+kNcE7sMMzyd1OKJz190oxAjVxCHMZoIXcQz3gNMCDsoCjY++ORmKaf943q 3BvPA1W/LrQq4w6wXuAYhPPGSIxSMm3dh/xA0Caz1ioaFwlrC19UHfUxkddNppq7S4YQXaCE afGrr9s9PkkNFTsmW9Xzowti5x8R8h1Dxr+QBJeQ5wAAAAAAAA== --------------ms090104060902050202010301-- From owner-ietf-calendar@mail.imc.org Wed Jan 22 23:02:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16284 for ; Wed, 22 Jan 2003 23:02:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0N3sQg10655 for ietf-calendar-bks; Wed, 22 Jan 2003 19:54:26 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0N3sOo10649 for ; Wed, 22 Jan 2003 19:54:25 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0N3sRhA030075 for ; Wed, 22 Jan 2003 19:54:28 -0800 Message-ID: <3E2F676E.4030309@Royer.com> Date: Wed, 22 Jan 2003 20:54:22 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050105010605030809080601" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050105010605030809080601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > ... > > Currently several commands are flagged as "MUST BE implemented by all > CSs". This list in draft-10 is: > ... > I find it someone odd that not every CS MUST support ABORT and CONTINUE. > If all of the CAP 1.0 defined commands are MUST to support then a > single line of text in Section 10.0 is probably the way to go instead > and any command that is NOT mandatory to support should be required to > expressly define itself that way (and iana-cmds are that by default!). I seem to recall objections that all CS's must support bounded latency. When we merged iRIP and CAP we agreed that we would add bounded latency to CAP and not make it required. A palm pilot for example I do not think can do bounded latency. Do we need a new CAPABILITY? SUPPORTS-LATENCY / boolean ? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050105010605030809080601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjMwMzU0MjJaMCMGCSqGSIb3DQEJBDEWBBQQ Ny4qajVeL+VoW6oBOm9UCudWtzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAhdIJzT0KGuxO ZSzxnqnHUpIj8dLv22YOEHFOsWk3SkhfIll2nRTeejpScQTi7R6huzjtbLOUxM11kS9JhbWW b16q5TyzxMyPdGr4Ra2f0FgXOIYs31ZJwk53AM2HXU9f0r4B7KqxNh5MfSCo9bpihe8WCapb EGHrKFtWahMjRbtnselPbn1r9XUbEZ6KeH6dUkYQIxsJvjM5hzu2Y55wU+vQA2lm9dYINNTo xHv4UE410V0/TZworubJjUdJC54TMkGl32Ikci/IaadhSJi93/H/4QsbTPsehkCj6e73GcvI ssMEymE9/KaJZP+N528siVoZr2459U8DMuPHLjjJggAAAAAAAA== --------------ms050105010605030809080601-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 04:45:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01553 for ; Thu, 23 Jan 2003 04:45:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0N9Vdg14635 for ietf-calendar-bks; Thu, 23 Jan 2003 01:31:39 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0N9Vbo14625 for ; Thu, 23 Jan 2003 01:31:38 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id D894C155AC; Thu, 23 Jan 2003 10:31:32 +0100 (CET) Date: Thu, 23 Jan 2003 10:31:32 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: STORES-EXPANDED Message-ID: <20030123093132.GB64946@inet.it> References: <20030117102309.GA63049@inet.it> <127.0.0.1+iuduOEI9IHbC31SKF9JbQX@space2.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+iuduOEI9IHbC31SKF9JbQX@space2.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 22, 2003 at 04:10:44PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Andrea responded on 01/17/2003 05:23:09 AM: > > I don't see how > > STORES-EXPANDED would apply (a CUA doesn't really store, and the > > CS wouldn't care anyway). > > The information is also necessary if building CS <-> CS synchronization or > replication. Thats NOT in CAP 1.0 (too hard) but its not a CUA / CS thing > but more of a Sender / Receiver thing. In that frame of reference it > should make more sense. Good point, but I was simply point out that the language vagueness (the use of 'it' in the description) wasn't helping understand the exact meaning of STORES-EXPANDED. More to the point, my proposal would still be good in your scenario: STORES-EXPANDED 1 If TRUE then the CS expands multiple instances separately when they are stored (RRULEs converted to RDATEs) and when sent. If FALSE then it stores instances as the are. Default is FALSE. I will admit this is very minor, but could help understand the intended use of STORES-EXPANDED. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 23 05:48:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02626 for ; Thu, 23 Jan 2003 05:48:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NAe9h21331 for ietf-calendar-bks; Thu, 23 Jan 2003 02:40:09 -0800 (PST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NAe7o21327 for ; Thu, 23 Jan 2003 02:40:07 -0800 (PST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h0NAe8I16281 for ; Thu, 23 Jan 2003 02:40:08 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 23 Jan 2003 02:40:07 -0800 Received: from apple.com ([17.68.41.12]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h0NAe6Q08292 for ; Thu, 23 Jan 2003 02:40:06 -0800 (PST) Date: Thu, 23 Jan 2003 11:40:17 +0100 Subject: Re: Is Apple creating invalid iCalendar? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Olivier Gutknecht To: ietf-calendar@imc.org In-Reply-To: Message-Id: <10082384-2EBF-11D7-9520-003065EF8304@apple.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0NAe8o21328 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, > I agree that the X-WR-TIMEZONE is incorrectly done because its a > vendor extension thats not properly labeled as such.  The bigger > problem is that DTSTART and DTEND have TZIDs but NO matching VTIMEZONE > [...] > This could make the .ics file generate errors on those clients that > adhere to the RFCs.   We are aware of this issue. This will be fixed in our future releases. Ol. -- iCal Engineering Apple Computer, Inc. From owner-ietf-calendar@mail.imc.org Thu Jan 23 07:19:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03991 for ; Thu, 23 Jan 2003 07:19:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NC8e328582 for ietf-calendar-bks; Thu, 23 Jan 2003 04:08:40 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NC8do28577 for ; Thu, 23 Jan 2003 04:08:39 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id E8B64155AC; Thu, 23 Jan 2003 13:08:36 +0100 (CET) Date: Thu, 23 Jan 2003 13:08:36 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Summary of thread: No partial success when it comes to deletion? Message-ID: <20030123120836.GG64946@inet.it> References: <3E230CD4.8090007@Royer.com> <127.0.0.1+usakpW4CT1vuGb18Ja9E5D@space2.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+usakpW4CT1vuGb18Ja9E5D@space2.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 22, 2003 at 03:49:46PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > I object to the proposed text as it essentially mandates that the CS be > built on an RDBMS of some kind. I do NOT object to the intent of > requireing ALL commands to safety check their _inputs_ prior to actually > performing said command. The success or failure of individual TARGETs is > NOT grounds for failing ALL TARGETs!! > > WRT to Johns concern: The VEVENT should NOT be CREATEd if the entire > creation cannot be completed for that TARGET. That is, the CREATE command > is creating the event and the definition in the store so either it works > and both are there or it fails and neither are there. The VEVENT MUST NOT > be created and left if the command for that TARGET fails! Otherwise any > failures would result in all kinds of cruft being left in the TARGET! Let me try to summarize the options I see: 1 - each part of the command succeeds or fails on its own 2 - the CS MUST do all the checking upfront, then: - if at least one part of the command fails validation, it MUST bail out immediately, returning appropriate REQUEST-STATUS - if all parts pass validation, the CS proceeds to execute the commands; each of them is handled separately, it can fail or succeed, as long as the CS returns an appropriate REQUEST-STATUS 3 - same as #2, except in case of error during command execution the CS bails out immediately without REQUEST-STATUS for the remaining parts 4 - same as #2, except the CS rollbacks everything and turns REQUEST-STATUS success into "would have succeeded" 5 - same as #3, except the CS rollbacks everything and turns REQUEST-STATUS success into "would have succeeded" Note that I used the voluntarily vague expression "part of a command", because in fact we have a lot of variations: commands can act on more than one target, MODIFY can match lots of components, etc etc. I consider "part of a command" to be an atomic item, and we need to decide what constitutes an atomic item. In John's example, VEVENT+VTIMEZONE would be an atomic item in my discussion above. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 23 08:09:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06163 for ; Thu, 23 Jan 2003 08:09:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ND3Sc05484 for ietf-calendar-bks; Thu, 23 Jan 2003 05:03:28 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ND3Ro05480 for ; Thu, 23 Jan 2003 05:03:27 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 96C9415507; Thu, 23 Jan 2003 14:03:27 +0100 (CET) Date: Thu, 23 Jan 2003 14:03:27 +0100 From: Andrea Campi To: Libby Miller Cc: ietf-calendar@imc.org, mf@w3.org Subject: Re: error in rfc2445 (fwd) Message-ID: <20030123130327.GH64946@inet.it> References: <127.0.0.1+I6d1lggdDbhkChka5tDPtU@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+I6d1lggdDbhkChka5tDPtU@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 22, 2003 at 02:38:00PM +0000, Libby Miller wrote: > > > > A friend not on this list noticed this apparent error. > is there an errata document for RFC 2445, or is it updated? RFC2445 has this text: enddate = date enddate =/ date-time ;An UTC value So, while I think this is a typo (the 'endate =' part on the second line), the intent is quite clear: enddate = date / date-time Bye, Andrea > > Libby > > ---------- Forwarded message ---------- > Date: Wed, 22 Jan 2003 15:33:33 +0100 > From: Max Froumentin > To: Libby.Miller@bristol.ac.uk > Subject: error in rfc2445 > > RFC1445 says: > > > UNTIL= must be followed by enddate (4.3.10) > > > > 2223: ( ";" "UNTIL" "=" enddate ) / > > > > 2253: enddate = date > > 1899: date = date-value > > 1901: date-value = date-fullyear date-month date-mday > > But the prose (line 2341) and all the examples show that UNTIL= must > followed by a date-time: > > > UNTIL=19980404T070000Z > > Is this an error? > > Max. > > -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 23 08:19:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06712 for ; Thu, 23 Jan 2003 08:19:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NDBFW06385 for ietf-calendar-bks; Thu, 23 Jan 2003 05:11:15 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NDBEo06380 for ; Thu, 23 Jan 2003 05:11:14 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 3799215507; Thu, 23 Jan 2003 14:11:14 +0100 (CET) Date: Thu, 23 Jan 2003 14:11:14 +0100 From: Andrea Campi To: Mark Swanson Cc: ietf-calendar@imc.org Subject: Re: Q: Handling non-conforming ICalendar Message-ID: <20030123131114.GI64946@inet.it> References: <127.0.0.1+t0P1V8yxUa9vjQLxBo9UDH@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+t0P1V8yxUa9vjQLxBo9UDH@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 22, 2003 at 12:21:25AM -0500, Mark Swanson wrote: > > Given that I am finding non-conforming ICalendar output from several of the > most popular ICalendar implementations out there I was wondering how everyone > else on this list is handling non-conforming ICalendar data? > > F.E. ignoring it, modifying your parser to handle bad data, etc... Speaking in the context of the libical project, we do have some hacks in the code to accomodate non conforming data known to be produced by one particular piece of software who shall remain unnamed... Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 23 08:25:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06800 for ; Thu, 23 Jan 2003 08:25:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NDECe06518 for ietf-calendar-bks; Thu, 23 Jan 2003 05:14:12 -0800 (PST) Received: from amsfep12-int.chello.nl (amsfep12-int.chello.nl [213.46.243.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NDEAo06509 for ; Thu, 23 Jan 2003 05:14:10 -0800 (PST) Received: from erebor.copa.nl ([212.83.72.215]) by amsfep12-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP id <20030123131346.UWUE27667.amsfep12-int.chello.nl@erebor.copa.nl> for ; Thu, 23 Jan 2003 14:13:46 +0100 Received: from martijn by erebor.copa.nl with local (Exim 3.36 #1 (Debian)) id 18bhAv-00024U-00 for ; Thu, 23 Jan 2003 14:13:45 +0100 Date: Thu, 23 Jan 2003 14:13:45 +0100 To: ietf-calendar@imc.org Subject: rfc 2445 issues list Message-ID: <20030123131345.GA7729@erebor.copa.nl> Mail-Followup-To: martijn, ietf-calendar@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline From: Martijn van Beers Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, is there an up-to-date issues list for rfc 2445 on the web somewhere? I only managed to find Eric Busboom's, which was last updated August 2001. Martijn From owner-ietf-calendar@mail.imc.org Thu Jan 23 09:07:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08075 for ; Thu, 23 Jan 2003 09:07:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NDtpU08430 for ietf-calendar-bks; Thu, 23 Jan 2003 05:55:51 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NDtno08423 for ; Thu, 23 Jan 2003 05:55:49 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 59C3615507; Thu, 23 Jan 2003 14:55:43 +0100 (CET) Date: Thu, 23 Jan 2003 14:55:43 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: VTIMEZONE in CAP Message-ID: <20030123135543.GJ64946@inet.it> References: <20021218092603.GL93256@inet.it> <127.0.0.1+DQlaXDUXnmgvlaJ89gdnCE@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+DQlaXDUXnmgvlaJ89gdnCE@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jan 21, 2003 at 05:41:27PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Andrea wrote on 12/18/2002 04:26:03 AM: > > how do you people expect CAP to change the way VTIMEZONE are > > handled according to previous standards? > > Im sorry but I dont understand the question. Let me rephrase it - how do we handle VTIMEZONE in the context of CAP? > > mandatory. So we need to always include the VTIMEZONEs the component(s) > > specify? > > Not all iTIP messages are for DATE-TIME or TIME data types; they may be > for DATE only types. For example: > [...] > > This is a valid all day event w/no associated TZ. Language issue again. I meant: "do we need to always include the VTIMEZONEs (if any") the component references? > > This seems to be a little bit absurd to me: the CUA only needs to > > be able to retrieve the VTIMEZONEs from the CS; it can do so once > > per session (and even cache them between sessions). > > I propose we amend 3.1 and interpret 4.2.19 to mean all the VTIMEZONEs > > must exist in the CAP store. Note that I was specifically referring to SEARCH (that's why I said, the CUA needs to retrieve VTIMEZONEs once). > If the CS doesnt have a definition that arrives w/an iTIP message (because > the Admins have not kept their TZ tables updated) then what should happen? > If my new beta CUA sends a METHOD:REQUEST for a newly added or updated > TZID then would that new TZ be considered "in the CAP store" if its in the > iTIP stream? Or would it have to be stored by some Admin first? > > Adding new TZ info is Administration and thus OOB for CAP 1.0 BUT if we > are making a requirement that 'administratively added' data MUST exist > then we need to make sure we consider the all the cases before making this > kind of requirements change to 2445/2446. No, I don't consider TZ info to be administrative stuff; VTIMEZONEs can be stored normally in a VCALSTORE or in a VAGENDA, or retrieved from there, so I see no reason to handle them differently from other components. I'm not saying a CUA can't or shouldn't send VTIMEZONE along in any iTIP message it wants to store on the server. I'm simply saying: - when storing components, the CUA can omit the VTIMEZONE, as long as any TZID the components references are present in the TARGETs or in the enclosing CALSTORE. - if the CUA sends VTIMEZONEs to the CS (along or together with other components that reference them), the CS checks if they are new or updated versions, if so it stores them - when a CUA retrieves a component, the CS can omit the VTIMEZONE - the CUA should retrieve the VTIMEZONEs from the CS at most once per session, and could probably cache them at least until the CUA is closed. The CUA should use LAST-MODIFIED to check for updated VTIMEZONEs. The advantage of course is reduced network and processing load for sending and processing data that changes very infrequently. iTIP messages do complicate matters, as a CUA may want to be able to forward them as they are (for example, by simply encapsulate them in iMIP). So we probably need a parameter for this, so that a CUA can specify on each SEARCH whether it wants the VTIMEZONE or not. Or it could be a CAPABILITY. To directly answer your concers: > If the CS doesnt have a definition that arrives w/an iTIP message (because > the Admins have not kept their TZ tables updated) then what should happen? The CUA should send it along and the CS would store it. > If my new beta CUA sends a METHOD:REQUEST for a newly added or updated > TZID then would that new TZ be considered "in the CAP store" if its in the > iTIP stream? Or would it have to be stored by some Admin first? I'm not sure I understand what you're saying here, but it the TZID is new or updated the CUA must send it and the CS must store it. At the end of the day, the way I see it is, RFC2445 and RFC2446 can be interpreted as requiring the VTIMEZONE to be in scope; the scope they consider is the enclosing VCALENDAR. I am proposing to extend this to consider the session between a CUA and a CS as the scope, so that they only need to exchange this data once. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 23 09:33:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08612 for ; Thu, 23 Jan 2003 09:33:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NENGw09943 for ietf-calendar-bks; Thu, 23 Jan 2003 06:23:16 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0NENFo09938 for ; Thu, 23 Jan 2003 06:23:15 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003012309242529552 for ; Thu, 23 Jan 2003 09:24:25 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 09:21:01 -0500 Message-ID: <3E2FFA4C.5080405@centive.com> Date: Thu, 23 Jan 2003 09:21:00 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Is Apple creating invalid iCalendar? References: <10082384-2EBF-11D7-9520-003065EF8304@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2003 14:21:01.0298 (UTC) FILETIME=[A7CA3D20:01C2C2EA] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Olivier Gutknecht wrote: >> I agree that the X-WR-TIMEZONE is incorrectly done because its a >> vendor extension thats not properly labeled as such. The bigger >> problem is that DTSTART and DTEND have TZIDs but NO matching >> VTIMEZONE [...] >> This could make the .ics file generate errors on those clients that >> adhere to the RFCs. > > > We are aware of this issue. This will be fixed in our future releases. Just so long as you're aware that there is absolutely no way you can interoperate with anybody else if you're not sending VTIMEZONEs. It seems clear that your marketing team is not aware of this, because the iCal Website (http://www.apple.com/ical/) states: > With iCal, you can [...] Send standards-based email event invitations > to people listed in your Mac OS X Address Book -- /==========================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==========================================| |Illiterate? Write today for free help! | \==========================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 23 09:42:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09054 for ; Thu, 23 Jan 2003 09:42:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NEWN410441 for ietf-calendar-bks; Thu, 23 Jan 2003 06:32:23 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0NEWLo10435 for ; Thu, 23 Jan 2003 06:32:21 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003012309334028538 for ; Thu, 23 Jan 2003 09:33:40 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 09:30:15 -0500 Message-ID: <3E2FFC77.8070606@centive.com> Date: Thu, 23 Jan 2003 09:30:15 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE in CAP References: <20021218092603.GL93256@inet.it> <127.0.0.1+DQlaXDUXnmgvlaJ89gdnCE@space1.inet.it> <20030123135543.GJ64946@inet.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2003 14:30:15.0998 (UTC) FILETIME=[F26ABDE0:01C2C2EB] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: >Let me rephrase it - how do we handle VTIMEZONE in the context of CAP? > Exactly the same as in any other iCalendar context. >Language issue again. I meant: "do we need to always include the VTIMEZONEs >(if any") the component references? > Yes, we do; otherwise, the component is not a legal VCALENDAR. > - when storing components, the CUA can omit the VTIMEZONE, >as long as any TZID the components references are present in the TARGETs >or in the enclosing CALSTORE. > And how does the CUA know that the VTIMEZONE stored in the CS is identical to the one the CUA knows? Timezone definitions do change. Besides, TZIDs aren't globally valid; we cannot assume that the same TZID from two different components refers to the same VTIMEZONE. As an extreme example, it would be perfectly legal for a CUA to assign TZIDs on the fly as it composed its VCALENDARs, so that the first VTIMEZONE in the VCALENDAR would always have a TZID of 1, the second would have a TZID of 2, etc. In that case, trying to extend the scope of those TZIDs beyond the VCALENDAR would be catastrophic. As a less extreme case, the same TZID from two different CUAs might refer to two different timezones--for example, if you have two CUAs written by parochial-minded people in the US and Australia, they both might have TZIDs of "Eastern" referring to two radically different timezones. -- /==========================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==========================================| |Illiterate? Write today for free help! | \==========================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 23 09:52:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09352 for ; Thu, 23 Jan 2003 09:52:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NEg2q11380 for ietf-calendar-bks; Thu, 23 Jan 2003 06:42:02 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0NEg0o11373 for ; Thu, 23 Jan 2003 06:42:00 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003012309431630800 for ; Thu, 23 Jan 2003 09:43:17 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 09:39:51 -0500 Message-ID: <3E2FFEB7.5080802@centive.com> Date: Thu, 23 Jan 2003 09:39:51 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RFC 2445 Q: is TZID broken? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2003 14:39:51.0402 (UTC) FILETIME=[49626CA0:01C2C2ED] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: >On January 22, 2003 02:53 pm, mark@WebServiceSolutions.com wrote: > > >>Would it be feasible to say that it may have fallen off of the radar scope >> >> > > > >>because strings like "US-Eastern" are just identifiers and the real time >> >> >zone > > >>definition is in VTIMEZONE (which can define any past/present/future time >> >> >>zone including daylight savings)? >> >> > >Not really. It fell off the radar screen because of time constraints for >people. It had nothing to do with where it fell in the draft. It was >where it fell on people's time schedules... > > Well, yes, but the fact that we don't really need global TZIDs has surely made a difference in people's priorities. -- /========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |========================================================| |Diplomacy: The art of letting someone else have your way| \========================================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 23 10:09:52 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09727 for ; Thu, 23 Jan 2003 10:09:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NF1w813210 for ietf-calendar-bks; Thu, 23 Jan 2003 07:01:58 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NF1vo13205 for ; Thu, 23 Jan 2003 07:01:57 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 0F03A15507; Thu, 23 Jan 2003 16:01:58 +0100 (CET) Date: Thu, 23 Jan 2003 16:01:58 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? Message-ID: <20030123150158.GL64946@inet.it> References: <20021205092314.GB17308@inet.it> <127.0.0.1+BmcI9PSie29LGh52wfK0gM@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+BmcI9PSie29LGh52wfK0gM@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jan 21, 2003 at 02:53:11PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Now that Im back from vacation Ive got a few cycles to spend on this if > you and others are interested in some concerted effort to deal w/this. > Bruce, before I answer each point in your email, let me remind you that in one of my last emails in this thread I said that, as far as I'm concerned, stored queries can be dropped from the draft altogether, and that we can design it properly from scratch in a separate draft; nobody objected to that. If we want to do that, we need to make sure CS can store components they (and we) don't know about yet. That said, I think it would probably be wise to start talking about how we'd like stored queries to be specified instead of what's wrong with what we currently have. ;-) Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 23 10:11:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09767 for ; Thu, 23 Jan 2003 10:11:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NEqUu12366 for ietf-calendar-bks; Thu, 23 Jan 2003 06:52:30 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NEqTo12360 for ; Thu, 23 Jan 2003 06:52:29 -0800 (PST) To: ietf-calendar@imc.org Subject: Interop Planning time again MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 23 Jan 2003 09:52:29 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 01/23/2003 09:52:31 AM, Serialize complete at 01/23/2003 09:52:31 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, this is a quick note to let you know we are planning for the next Interops. At this point, we are trying to decide when to do the next Virtual interop (which can be put together in about a week) or when to do the onsite interop (which will take a bit longer). I can be ready to hold a Virtual interop with in a week - I know you all will need more time. I'm proposing a couple of days in February, either the week of 2/10 or 2/17. An onsite interop would probably be best in the April/May timeframe. This way we can produce a good report for either the March IETF or the July IETF meetings. To help me make a decision, I am polling the list to see people's preferences. We really need to do both -the more testing, the better. it's time we got our RFC's to Standard level. The question is how many people could be ready to participate on a Virtual interop by February. As a refresher - the virtual interop means using the internet and devoting time - 2 days worth - to testing, attending conference calls, testing, conference calls, you get the idea. This would not require travel - it would require being available for the full 2 days. The onsite interop will mean traveling to a specific site - Novel has offered their location for an interop at some point. Please post to the list (or send me an email) your choice of the following: Hold just the virtual - and note if you will attend Hold just the onsite - and note if you will attend Hold both - and note whether you will/can attend one or both Hope that makes sense. It's easier to post this to the list - that way everyone gets a chance to see the interest level. From owner-ietf-calendar@mail.imc.org Thu Jan 23 10:13:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09817 for ; Thu, 23 Jan 2003 10:13:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NF6pH13727 for ietf-calendar-bks; Thu, 23 Jan 2003 07:06:51 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NF6oo13719 for ; Thu, 23 Jan 2003 07:06:50 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id E31A715507; Thu, 23 Jan 2003 16:06:50 +0100 (CET) Date: Thu, 23 Jan 2003 16:06:50 +0100 From: Andrea Campi To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: VTIMEZONE in CAP Message-ID: <20030123150650.GM64946@inet.it> References: <20021218092603.GL93256@inet.it> <127.0.0.1+DQlaXDUXnmgvlaJ89gdnCE@space1.inet.it> <20030123135543.GJ64946@inet.it> <127.0.0.1+UvJUf6CEXRXVuwvARpuisq@space2.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+UvJUf6CEXRXVuwvARpuisq@space2.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jan 23, 2003 at 09:30:15AM -0500, John Stracke wrote: > Besides, TZIDs aren't globally valid; we cannot assume that the same > TZID from two different components refers to the same VTIMEZONE. As an [...] > As a less extreme case, the same TZID from two different CUAs might > refer to two different timezones--for example, if you have two CUAs > written by parochial-minded people in the US and Australia, they both > might have TZIDs of "Eastern" referring to two radically different > timezones. Uhm... ok, you convinved me. That's too bad, but you're right, so I'll drop my argument. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 23 11:47:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12964 for ; Thu, 23 Jan 2003 11:47:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NGZ9Q22082 for ietf-calendar-bks; Thu, 23 Jan 2003 08:35:09 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NGZ8o22076 for ; Thu, 23 Jan 2003 08:35:08 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 3BA1715507; Thu, 23 Jan 2003 17:35:04 +0100 (CET) Date: Thu, 23 Jan 2003 17:35:04 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. Message-ID: <20030123163504.GA65203@inet.it> References: <127.0.0.1+VLX5AafrP4LQcR85L9TqOJ@space2.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+VLX5AafrP4LQcR85L9TqOJ@space2.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 22, 2003 at 03:46:14PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > iCalendar, iTIP and iMIP are not ordered. Why MUST my CS return responses > in a particular order? It sounds like someone wants to cut corners by By the way, this same argument holds for VQUERY with multiple QUERY properties: see 6.1.1 item 5. OTOH and for completeness sake: we can't take your argument to the extreme, in some cases we do need to mandate ordering. See results for CREATE - if results aren't in the same order as the components, the CUA won't be able to correlate them. [[ Either that, or we disallow creating more than one component at a time. Not that this would be a bad idea, given the lack of transaction and all. This would make our discussion about partial failure moot - if you need to create different components, send them as separate commands, even if in the same mime container... But I digress. ]] Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 23 14:24:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17474 for ; Thu, 23 Jan 2003 14:24:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NJFuL02760 for ietf-calendar-bks; Thu, 23 Jan 2003 11:15:56 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NJFso02756 for ; Thu, 23 Jan 2003 11:15:54 -0800 (PST) In-Reply-To: <200301220007.40722.mark@WebServiceSolutions.com> To: Mark Swanson Cc: ietf-calendar@imc.org Subject: Re: Is Apple creating invalid iCalendar? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 23 Jan 2003 14:15:52 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 02:15:49 PM, Serialize complete at 01/23/2003 02:15:49 PM Content-Type: multipart/alternative; boundary="=_alternative 0069CB6685256CB7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069CB6685256CB7_= Content-Type: text/plain; charset="US-ASCII" Mark replied on 01/22/2003 12:07:37 AM: > Good point Bruce. Upon further checking my parser was actually > breaking on the > incorrect "VALUE=TEXT" parameter: > > xparam =x-name "=" param-value *("," param-value) > > x-name may not be "VALUE" found above according to rfc2445: > > x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > > An example of a valid non-standard property would be: > > X-SKI-TITLE;X-RSVP=TRUE: This is an extension property > > I also wonder who to let know so they can fix it. I think that the problem may actually be in how you expanded the ABNF. Lets start w/the example line to analyze: X-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern The ABNF for a basic line is: contentline = name *(";" param ) ":" value CRLF name = x-name / iana-token iana-token = 1*(ALPHA / DIGIT / "-") x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") vendorid = 3*(ALPHA / DIGIT) ;Vendor identification param = param-name "=" param-value *("," param-value) param-name = iana-token / x-token param-value = paramtext / quoted-string paramtext = *SAFE-CHAR value = *VALUE-CHAR Sooo, the example line would be broken down as: name *(";" param ) ":" value CRLF to x-name *(";" param ) ":" value CRLF to "X-" 1*(ALPHA / DIGIT / "-")*(";" param ) ":" value CRLF by ignoring [vendorid "-"] so the "X-WR-TIMEZONE" matches the 1st 2 parts. The rest of the expansion (abreviated): "X-" "WR-TIMEZONE" ";" "VALUE" "=" "TEXT" ":" "Canada/Eastern" CRLF because "VALUE" is an iana-token that works for param-name and "TEXT" is basically *SAFE-CHAR. As such it looks like that is not an Apple iCal issue but rather how your generic line parser is constructed. There is no reason that a non-standard property ("X-") cannot use standard property parameters or property parameter values really. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0069CB6685256CB7_= Content-Type: text/html; charset="US-ASCII"
Mark replied on 01/22/2003 12:07:37 AM:
> Good point Bruce. Upon further checking my parser was actually
> breaking on the
> incorrect "VALUE=TEXT" parameter:
>
> xparam     =x-name "=" param-value *("," param-value)
>
> x-name may not be "VALUE" found above according to rfc2445:
>
> x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
>
> An example of a valid non-standard property would be:
>
> X-SKI-TITLE;X-RSVP=TRUE: This is an extension property
>
> I also wonder who to let know so they can fix it.
I think that the problem may actually be in how you expanded the ABNF.  Lets start w/the example line to analyze:

X-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern

The ABNF for a basic line is:

     contentline        = name *(";" param ) ":" value CRLF

    name               = x-name / iana-token

    iana-token = 1*(ALPHA / DIGIT / "-")

    x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")

    vendorid   = 3*(ALPHA / DIGIT)     ;Vendor identification

    param              = param-name "=" param-value
                         *("," param-value)

    param-name = iana-token / x-token

    param-value        = paramtext / quoted-string

    paramtext  = *SAFE-CHAR

    value      = *VALUE-CHAR

Sooo, the example line would be broken down as:

name *(";" param ) ":" value CRLF

to

x-name *(";" param ) ":" value CRLF

to

"X-" 1*(ALPHA / DIGIT / "-")*(";" param ) ":" value CRLF

by ignoring [vendorid "-"] so the "X-WR-TIMEZONE" matches the 1st 2 parts.  The rest of the expansion (abreviated):

"X-" "WR-TIMEZONE" ";" "VALUE" "=" "TEXT" ":" "Canada/Eastern" CRLF

because "VALUE" is an iana-token that works for param-name and "TEXT" is basically *SAFE-CHAR.

As such it looks like that is not an Apple iCal issue but rather how your generic line parser is constructed.  There is no reason that a non-standard property ("X-")  cannot use standard property parameters or property parameter values really.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0069CB6685256CB7_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 14:26:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17545 for ; Thu, 23 Jan 2003 14:26:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NIvdj01837 for ietf-calendar-bks; Thu, 23 Jan 2003 10:57:39 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NIvbo01832 for ; Thu, 23 Jan 2003 10:57:37 -0800 (PST) In-Reply-To: <200301220021.28555.mark@WebServiceSolutions.com> To: Mark Swanson Cc: ietf-calendar@imc.org Subject: Re: Q: Handling non-conforming ICalendar MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 23 Jan 2003 13:57:34 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 01:57:32 PM, Serialize complete at 01/23/2003 01:57:32 PM Content-Type: multipart/alternative; boundary="=_alternative 00681E7585256CB7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00681E7585256CB7_= Content-Type: text/plain; charset="US-ASCII" Mark wrote on 01/22/2003 12:21:25 AM: > I was wondering howeveryone > else on this list is handling non-conforming ICalendar data? > > F.E. ignoring it, modifying your parser to handle bad data, etc... I don't see any responses from any other implementors yet. I wonder if thats because of some backlog somewhere or everyone not wanting to go first... We (Lotus Notes) took the approach of dealing with some issues by adjusting our engine to deal with them but for the most part though we took the approach of "If we cannot fully parse it or what we parsed is not properly formed then do nothing with it and tell the user about the problems." It all depends on how 'severe' the non-conformace is. For example, we would NOT do any workflow on the Apple iCal object I used as an example yesterday because it had a TZID for the DTSTART and DTEND but NO matching (or any for that matter) VTIMEZONE. Had there been a VTIMEZEONE but the lines wrapped at 80 octets instead of 75 then we would have overlooked that and let the user act on it. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00681E7585256CB7_= Content-Type: text/html; charset="US-ASCII"
Mark wrote on 01/22/2003 12:21:25 AM:
>                                                I was wondering howeveryone
> else on this list is handling non-conforming ICalendar data?
>
> F.E. ignoring it, modifying your parser to handle bad data, etc...
I don't see any responses from any other implementors yet.    I wonder if thats because of some backlog somewhere or everyone not wanting to go first...

We (Lotus Notes) took the approach of dealing with some issues by adjusting our engine to deal with them but for the most part though we took the approach of "If we cannot fully parse it or what we parsed is not properly formed then do nothing with it and tell the user about the problems."  

It all depends on how 'severe' the non-conformace is.  For example, we would NOT do any workflow on the Apple iCal object I used as an example yesterday because it had a TZID for the DTSTART and DTEND but NO matching (or any for that matter) VTIMEZONE.  Had there been a VTIMEZEONE but the lines wrapped at 80 octets instead of 75 then we would have overlooked that and let the user act on it.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 00681E7585256CB7_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 14:47:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18360 for ; Thu, 23 Jan 2003 14:47:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NJfYb03959 for ietf-calendar-bks; Thu, 23 Jan 2003 11:41:34 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NJfXo03953 for ; Thu, 23 Jan 2003 11:41:33 -0800 (PST) In-Reply-To: <200301221333.33800.mark@WebServiceSolutions.com> To: Mark Swanson Cc: ietf-calendar@imc.org Subject: Re: Outlook incorrect parameter text MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 23 Jan 2003 14:41:28 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 02:41:27 PM, Serialize complete at 01/23/2003 02:41:27 PM Content-Type: multipart/alternative; boundary="=_alternative 006C235885256CB7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C235885256CB7_= Content-Type: text/plain; charset="US-ASCII" Mark wrote on 01/22/2003 01:33:33 PM: > It seems Outlook is creating parameters with the DQUOTE character, which is > not correct. > > Is this analysis correct? The analysis is correct. TZID as a parameter is defined by: tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF and paramtext is defined as: paramtext = *SAFE-CHAR I think that this was a mistake on the editors part when the did the ABNF for tzidparam. The normal ABNF for property parameter values was: param-value = paramtext / quoted-string so tzidparam SHOULD have been: tzidparam = "TZID" "=" [tzidprefix] param-value CRLF since the param-name part of the property parameter was fixed as "TZID". This may be a case where you want to special case tzidparam and possibly allow quoted-string values as well as paramtext values... Your call though. I think we should add a change to tzidparam to the RFC 2445 errata to allow for the ABNF that should have been there. Who's tracking that now? Eric? Shannon? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006C235885256CB7_= Content-Type: text/html; charset="US-ASCII"
Mark wrote on 01/22/2003 01:33:33 PM:
> It seems Outlook is creating parameters with the DQUOTE character, which is
> not correct.
>
> Is this analysis correct?
The analysis is correct.  TZID as a parameter is defined by:

     tzidparam  = "TZID" "=" [tzidprefix] paramtext CRLF
and paramtext is defined as:

     paramtext  = *SAFE-CHAR

I think that this was a mistake on the editors part when the did the ABNF for tzidparam.  The normal ABNF for property parameter values was:

     param-value        = paramtext / quoted-string
so tzidparam SHOULD have been:

     tzidparam  = "TZID" "=" [tzidprefix] param-value CRLF
since the param-name part of the property parameter was fixed as "TZID".  This may be a case where you want to special case tzidparam and possibly allow quoted-string values as well as paramtext values...  Your call though.

I think we should add a change to tzidparam to the RFC 2445 errata to allow for the ABNF that should have been there.  Who's tracking that now?  Eric? Shannon?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006C235885256CB7_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 15:11:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18876 for ; Thu, 23 Jan 2003 15:11:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NJu1u04689 for ietf-calendar-bks; Thu, 23 Jan 2003 11:56:01 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NJu0o04685 for ; Thu, 23 Jan 2003 11:56:00 -0800 (PST) In-Reply-To: <1043262798.21389.7561.camel@barrayar.local.thibault.org> To: John Stracke Cc: Mark Swanson , ietf-calendar@imc.org Subject: Re: Outlook incorrect parameter text MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 23 Jan 2003 14:55:58 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 02:55:53 PM, Serialize complete at 01/23/2003 02:55:53 PM Content-Type: multipart/alternative; boundary="=_alternative 006D772385256CB7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D772385256CB7_= Content-Type: text/plain; charset="US-ASCII" John responsed on 01/22/2003 02:13:18 PM: > I think you're right. On the other hand, it's a pretty easy violation > to accept, since you've got to have code to be able to parse > quoted-strings anyway Sure, its easy to just tweak and tweak and tweak an RFC 2445 compliant engine to allow for 'minor' stuff like this but there has to be a limit to when you say that the poorly constructed generator needs to be fixed instead. Granted the chances that Microsoft will fix Outlooks engine are not that great (do they even montior this list anymore??) but take it from someone who has to live with TONS of legacy tweaks; after a while the baggage of all the tweaking will catch up to ya and make you regret it. Hmm, maybe Microsoft assumed that tzidparam was defined as "TZID" "=" param-value as I suggested elsewhere... Could it be they are ahead of us on this one?? ;^) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D772385256CB7_= Content-Type: text/html; charset="US-ASCII"
John responsed on 01/22/2003 02:13:18 PM:
> I think you're right.  On the other hand, it's a pretty easy violation
> to accept, since you've got to have code to be able to parse
> quoted-strings anyway
Sure, its easy to just tweak and tweak and tweak an RFC 2445 compliant engine to allow for 'minor' stuff like this but there has to be a limit to when you say that the poorly constructed generator needs to be fixed instead.

Granted the chances that Microsoft will fix Outlooks engine are not that great (do they even montior this list anymore??) but take it from someone who has to live with TONS of legacy tweaks; after a while the baggage of all the tweaking will catch up to ya and make you regret it.

Hmm, maybe Microsoft assumed that tzidparam was defined as "TZID" "=" param-value as I suggested elsewhere... Could it be they are ahead of us on this one?? ;^)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006D772385256CB7_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 15:12:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18897 for ; Thu, 23 Jan 2003 15:12:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NK7ai05389 for ietf-calendar-bks; Thu, 23 Jan 2003 12:07:36 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NK7Zo05384 for ; Thu, 23 Jan 2003 12:07:35 -0800 (PST) In-Reply-To: <1043263277.21469.7577.camel@barrayar.local.thibault.org> To: John Stracke Cc: Mark Swanson , ietf-calendar@imc.org Subject: Re: Is Apple creating invalid iCalendar? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 23 Jan 2003 15:07:31 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 03:07:27 PM, Serialize complete at 01/23/2003 03:07:27 PM Content-Type: multipart/alternative; boundary="=_alternative 006E863185256CB7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E863185256CB7_= Content-Type: text/plain; charset="US-ASCII" John noted on 01/22/2003 02:21:17 PM: > Then that's a bug in RFC-2445; obviously we want x-props to be able to > use VALUE. Ok, it seems that there are 2 ways to define experimental properties in an implementation. One is using the ABNF from Section 4.8.8.1 Non-standard Properties: x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF ; Lines longer than 75 octets should be folded The other is to derive it from the generic ABNF defined in Section 4.1 Content Lines: contentline = name *(";" param ) ":" value CRLF ; This ABNF is just a general definition for an initial parsing ; of the content line into its property name, parameter list, ; and value string ... name = x-name / iana-token iana-token = 1*(ALPHA / DIGIT / "-") ; iCalendar identifier registered with IANA x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") ; Reservered for experimental use. Not intended for use in ; released products. ... The text and ABNF in 4.8.8.1 should NOT preclude any standard property parameters on an experimental property. We crafted our engine to use the Section 4.1 approach to experimental items since we needed a generic parser anyway. If someone takes the Section 4.8.8.1 approach then they clearly have a more restricted parser and one that could choke on arguably valid data. This psychosis should be resolved in our next revision of 2445. Pat/Bob: Please make sure that whomever is maintaining the 2445 Updates chalks this up (at least for later WG voting). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006E863185256CB7_= Content-Type: text/html; charset="US-ASCII"
John noted on 01/22/2003 02:21:17 PM:
> Then that's a bug in RFC-2445; obviously we want x-props to be able to
> use VALUE.
Ok, it seems that there are 2 ways to define experimental properties in an implementation.  One is using the ABNF from Section 4.8.8.1 Non-standard Properties:

     x-prop     = x-name *(";" xparam) [";" languageparam] ":" text CRLF
       ; Lines longer than 75 octets should be folded

The other is to derive it from the generic ABNF defined in Section 4.1 Content Lines:

     contentline        = name *(";" param ) ":" value CRLF
       ; This ABNF is just a general definition for an initial parsing
       ; of the content line into its property name, parameter list,
       ; and value string
...
     name               = x-name / iana-token

    iana-token = 1*(ALPHA / DIGIT / "-")
    ; iCalendar identifier registered with IANA

    x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
    ; Reservered for experimental use. Not intended for use in
    ; released products.
...

The text and ABNF in 4.8.8.1 should NOT preclude any standard property parameters on an experimental property.  We crafted our engine to use the Section 4.1 approach to experimental items since we needed a generic parser anyway.  If someone takes the Section 4.8.8.1 approach then they clearly have a more restricted parser and one that could choke on arguably valid data.

This psychosis should be resolved in our next revision of 2445.  

Pat/Bob: Please make sure that whomever is maintaining the 2445 Updates chalks this up (at least for later WG voting).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006E863185256CB7_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 15:18:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19085 for ; Thu, 23 Jan 2003 15:18:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NKBLI05713 for ietf-calendar-bks; Thu, 23 Jan 2003 12:11:21 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NKBKo05707 for ; Thu, 23 Jan 2003 12:11:20 -0800 (PST) In-Reply-To: To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org, Mark Swanson Subject: Re: RFC 2445 Q: is TZID broken? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 23 Jan 2003 15:11:16 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 03:11:12 PM, Serialize complete at 01/23/2003 03:11:12 PM Content-Type: multipart/alternative; boundary="=_alternative 006EDDE085256CB7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006EDDE085256CB7_= Content-Type: text/plain; charset="US-ASCII" Pat wrote on 01/22/2003 02:53:58 PM: > I know there was some work going on about having one place/table > to use for timezones. The Olson table was suggested - although people > have commented that it is not all-inclusive. Mr. Olson said he was > willing to share this table with the IETF world so there would be one > common repository. What he did not want to do was be responsible for > communicating changes back and forth to the IETF. he has another person, > anyway, who manages this. I brought it up to management at the IETF - and > they said they were will to have someone "be responsible" for intereacting > with the Olson table group. I think it simply fell off of the radar scope > for someone to follow up and continue this effort. A long time ago Doug has a side effort going to convert the Olsen info into VTIMEZONEs (or was that Daemon??) Perhaps we can get some zealot (or any other volunteer) to work on a tool to convert the Olsen info into VTIMEZONEs that we provide as reference data... Doug already has enough on his lap so Id see if someone else wants to revive that effort... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006EDDE085256CB7_= Content-Type: text/html; charset="US-ASCII"
Pat wrote on 01/22/2003 02:53:58 PM:
>           I know there was some work going on about having one place/table
> to use for timezones.  The Olson table was suggested - although people
> have commented that it is not all-inclusive.  Mr. Olson said he was
> willing to share this table with the IETF world so there would be one
> common repository.  What he did not want to do was be responsible for
> communicating changes back and forth to the IETF.  he has another person,
> anyway, who manages this.  I brought it up to management at the IETF - and
> they said they were will to have someone "be responsible" for intereacting
> with the Olson table group.  I think it simply fell off of the radar scope
> for someone to follow up and continue this effort.
A long time ago Doug has a side effort going to convert the Olsen info into VTIMEZONEs (or was that Daemon??)  Perhaps we can get some zealot (or any other volunteer) to work on a tool to convert the Olsen info into VTIMEZONEs that we provide as reference data...

Doug already has enough on his lap so Id see if someone else wants to revive that effort...

Bruce <sititng back down to hide from the volunteer selecting gaze of the WG chairs...>
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006EDDE085256CB7_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 15:19:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19136 for ; Thu, 23 Jan 2003 15:19:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NK3DP05119 for ietf-calendar-bks; Thu, 23 Jan 2003 12:03:13 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0NK3Bo05115 for ; Thu, 23 Jan 2003 12:03:11 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003012315043006945 for ; Thu, 23 Jan 2003 15:04:30 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 15:01:05 -0500 Message-ID: <3E304A00.5060608@centive.com> Date: Thu, 23 Jan 2003 15:01:04 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Outlook incorrect parameter text References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2003 20:01:05.0203 (UTC) FILETIME=[29771030:01C2C31A] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > Sure, its easy to just tweak and tweak and tweak an RFC 2445 compliant > engine to allow for 'minor' stuff like this but there has to be a > limit to when you say that the poorly constructed generator needs to > be fixed instead. True. Personally, though, I'd find it easier to accept quoted-strings everywhere, and have application logic validate the values instead of doing it in the parser. I know that's not a universal opinion, though--when I offered to donate eCal's iCalendar parser to libical in 1999, Eric turned it down because it took that approach. (My problem with having the parser validate everything is that it would choke on future extensions; IIRC, Eric's problem with not having the parser validate was that it would accept illegal constructs.) -- /==========================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==========================================| |I'm a .sig virus...and, boy, am I tired! | \==========================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 23 15:53:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19734 for ; Thu, 23 Jan 2003 15:53:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NKhj807655 for ietf-calendar-bks; Thu, 23 Jan 2003 12:43:45 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NKhio07651 for ; Thu, 23 Jan 2003 12:43:44 -0800 (PST) In-Reply-To: <200301222045.h0MKjlQ9007290@smtp6.andrew.cmu.edu> To: Lawrence Greenfield Cc: John Stracke , ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 23 Jan 2003 15:43:40 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 03:43:34 PM, Serialize complete at 01/23/2003 03:43:34 PM Content-Type: multipart/alternative; boundary="=_alternative 0071D52E85256CB7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071D52E85256CB7_= Content-Type: text/plain; charset="US-ASCII" Lawrence wrote on 01/22/2003 03:45:47 PM: > I don't think atomicity requirements are as burdensome as Bruce thinks > they are, but if you're going to add them there should also be text > about server failures. Requiring servers to maintain atomicity even > when they crash is considerably more burdensome. (I suspect it can be > left as a quality-of-implementation issue.) The burden will depend on what kind of back end engine your CS uses and how the data is stored. If your CS uses an RDBMS then you can utilize the engines transactioning abilities. If a CS uses a model like keeping each VAGENDA in a separate file or directory then the burden is much much greater (managing semaphores, deadlocks, delayed I/O, etc). In any case the proposed text does NOT address the proposed motivation for it. I am all for mandating that any command MUST fail if the inputs or parameters to it are bad. Is anyone really opposed to that?? I am against saying that individual failures of any kind are grounds for failing ALL the actions attempted. Just because a VAGENDA or actual entry is 'unavailable' for any number of reasons does not mean that the others that were available and already deleted should NOT be completed as expected. (After all a VREPLY with a success response was already sent back). I for one do not think that mandating a CS essentially be built like an RDBMS just to prevent possibly legitimate failures from undoing legitimate successes is a good thing. Why add ANY burden when there is no justification for even doing so? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0071D52E85256CB7_= Content-Type: text/html; charset="US-ASCII"
Lawrence wrote on 01/22/2003 03:45:47 PM:
> I don't think atomicity requirements are as burdensome as Bruce thinks
> they are, but if you're going to add them there should also be text
> about server failures. Requiring servers to maintain atomicity even
> when they crash is considerably more burdensome. (I suspect it can be
> left as a quality-of-implementation issue.)
The burden will depend on what kind of back end engine your CS uses and how the data is stored.  If your CS uses an RDBMS then you can utilize the engines transactioning abilities.  If a CS uses a model like keeping each VAGENDA in a separate file or directory then the burden is much much greater  (managing semaphores, deadlocks, delayed I/O, etc).

In any case the proposed text does NOT address the proposed motivation for it.  

I am all for mandating that any command MUST fail if the inputs or parameters to it are bad.  Is anyone really opposed to that??

I am against saying that individual failures of any kind are grounds for failing ALL the actions attempted.  Just because a VAGENDA or actual entry is 'unavailable' for any number of reasons does not mean that the others that were available and already deleted should NOT be completed as expected.  (After all a VREPLY with a success response was already sent back).  I for one do not think that mandating a CS essentially be built like an RDBMS just to prevent possibly legitimate failures from undoing legitimate successes is a good thing.

Why add ANY burden when there is no justification for even doing so?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0071D52E85256CB7_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 16:06:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20006 for ; Thu, 23 Jan 2003 16:06:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NKx7308553 for ietf-calendar-bks; Thu, 23 Jan 2003 12:59:07 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NKx5o08541 for ; Thu, 23 Jan 2003 12:59:05 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id h0NKtTQ9011210; Thu, 23 Jan 2003 15:55:29 -0500 Date: Thu, 23 Jan 2003 15:55:29 -0500 Message-Id: <200301232055.h0NKtTQ9011210@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org, John Stracke In-reply-to: Subject: Re: No partial success when it comes to deletion? References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 23 Jan 2003 15:43:40 -0500 [...] The burden will depend on what kind of back end engine your CS uses and how the data is stored. If your CS uses an RDBMS then you can utilize the engines transactioning abilities. If a CS uses a model like keeping each VAGENDA in a separate file or directory then the burden is much much greater (managing semaphores, deadlocks, delayed I/O, etc). Yes, I understand this very well. I am all for mandating that any command MUST fail if the inputs or parameters to it are bad. Is anyone really opposed to that?? It is obvious to me that servers should not tolerate any amount of broken protocol. I'm definitely in the "be liberal considered harmful" camp of the applications area---servers should strictly enforce all syntax to prevent bad client implementations from ever getting out into the real world. I am against saying that individual failures of any kind are grounds for failing ALL the actions attempted. Just because a VAGENDA or actual entry is 'unavailable' for any number of reasons does not mean that the others that were available and already deleted should NOT be completed as expected. (After all a VREPLY with a success response was already sent back). I for one do not think that mandating a CS essentially be built like an RDBMS just to prevent possibly legitimate failures from undoing legitimate successes is a good thing. Why add ANY burden when there is no justification for even doing so? I think the specific text under consideration: > There is no partial success for a "DELETE" command. Ether > everything succeeds or nothing is done. So if the VREPLY > contains X number of successful replies and at least > one (1) failure then no objects were deleted or marked > for deletion. This is because a malformed "QUERY" property > value could have devastating effects and unintended > deletion of some objects could make a calendar unusable. > The CUA could inform the CU that their request must > be modified in order to succeed. is ridiculous. The calendar server should never return a successful VREPLY for an action not taken. This would be highly unintuitive and I am very against this proposal. I think it would be more reasonable to say that commands must completely succeed or completely fail; having a VCALENDAR object result in either X successful replies OR X failures. Another possibility would be to add a parameter so that clients could request atomic behavior from the calendar server (";ATOMIC"?), and that servers SHOULD respect the client's request. (It then turns into a quality-of-implementation issue if they do or don't.) In all cases the server's VREPLYs must accurately reflect what actions were performed. Larry From owner-ietf-calendar@mail.imc.org Thu Jan 23 16:32:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20429 for ; Thu, 23 Jan 2003 16:32:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NLKPC09754 for ietf-calendar-bks; Thu, 23 Jan 2003 13:20:25 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NLKOo09750 for ; Thu, 23 Jan 2003 13:20:24 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0NLKPhA005533 for ; Thu, 23 Jan 2003 13:20:26 -0800 Message-ID: <3E305C94.7050401@Royer.com> Date: Thu, 23 Jan 2003 14:20:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Q: Handling non-conforming ICalendar References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020405030004070807030704" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020405030004070807030704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > I don't see any responses from any other implementors yet. I wonder > if thats because of some backlog somewhere or everyone not wanting to go > first... > > We (Lotus Notes) took the approach of dealing with some issues by > adjusting our engine to deal with them but for the most part though we > took the approach of "If we cannot fully parse it or what we parsed is > not properly formed then do nothing with it and tell the user about the > problems." My work is mostly on a CS, so I would expect that CUA's that are being written will have interoperability issues. But trying to guess what they are in advance is not on my 'to do' list. I agree with Burce for my project - if it is not parsable - reject it. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020405030004070807030704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjMyMTIwMjBaMCMGCSqGSIb3DQEJBDEWBBTH 2Y71lfNM9whdajvWI+1qK9QD5zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAaoMd322In32G gSAjp/RFK/HJks4l080yW1mLomk/VeyNPH+E5u+yj4IYlI+e8vnDgHa/meRsj7hWxaLvKUDy +MklJ+yoc6I2gSghBhgXkYfS2B/HgXHltXdegCzixFr7Xvsm0osal1T7a3h9qsTo/iA26T+l MR+By7+KuXcQN4xqvCyyC9qS+gku8R6ow70rLWUnYVB8Yxd+n7tONd4J/mIZuCpxzy9RzP6x 3AXjw9Pu3MNp5Zu8OlBZWtRwDvDM/9bvV/sfbN1rA0sbTRPJWkSTKv7i6kflZp1CA94tOdA/ A2Fpwcaeu+c79nMhZaN+qJOlh/VNbYSAVrBqvJuV/wAAAAAAAA== --------------ms020405030004070807030704-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 16:33:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20473 for ; Thu, 23 Jan 2003 16:33:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NLPCB10017 for ietf-calendar-bks; Thu, 23 Jan 2003 13:25:12 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NLPAo10012 for ; Thu, 23 Jan 2003 13:25:10 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0NLPChA005565 for ; Thu, 23 Jan 2003 13:25:12 -0800 Message-ID: <3E305DB2.90107@Royer.com> Date: Thu, 23 Jan 2003 14:25:06 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000501080404060401000804" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000501080404060401000804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree with Bruce. I was looking at it from an RDBMS point of view. It will make simpler devices much harder to implement. They tend to be thin clients or memory restricted anyway. And this debate has also reminded me that we had agreed a long time ago in CAP to NOT to do any kind of transaction locking. We can do that as an optional add-on later. > > I am all for mandating that any command MUST fail if the inputs or > parameters to it are bad. Is anyone really opposed to that?? > > I am against saying that individual failures of any kind are grounds for > failing ALL the actions attempted. Just because a VAGENDA or actual > entry is 'unavailable' for any number of reasons does not mean that the > others that were available and already deleted should NOT be completed > as expected. (After all a VREPLY with a success response was already > sent back). I for one do not think that mandating a CS essentially be > built like an RDBMS just to prevent possibly legitimate failures from > undoing legitimate successes is a good thing. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000501080404060401000804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjMyMTI1MDZaMCMGCSqGSIb3DQEJBDEWBBRp A4X88X/gKXT/4PsE+9+PhpdQfzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAfrPia8f4cHDj 0rogheZ+11ykJ9bB1Iok57Xx2wGLtHoETQVTJf/gzoktbUwR4epK4NOv6qIYTNzvB+lHTTra ldrGGHxtYNaRn4JgGCPJ8wg+6TBC37S0YVeg3wJTzO9lwZcMM2vUG9/yGtCbc5UxqPhxm6H/ OEIDzaPQn2kR4izeBMsXVP2jGx9YluqNp0QDppPC2l51DSTWmunPVvBTj/OHqG19O56imMgF OBvicQsn8Ky/JrmskE0DK42JuTbojyShHRCVVUibJ9pP4DOuRmxxipWjwkvXvVNdV9aCDSLL zpnrZrPYX2eOkauiVhGJd9YxQR5jG92rg9JxrXAjoQAAAAAAAA== --------------ms000501080404060401000804-- From owner-ietf-calendar@mail.imc.org Thu Jan 23 16:56:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21358 for ; Thu, 23 Jan 2003 16:56:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NLlsB11243 for ietf-calendar-bks; Thu, 23 Jan 2003 13:47:54 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0NLlqo11239 for ; Thu, 23 Jan 2003 13:47:52 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003012316491000694 for ; Thu, 23 Jan 2003 16:49:10 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 16:45:46 -0500 Message-ID: <3E306289.3040100@centive.com> Date: Thu, 23 Jan 2003 16:45:45 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? References: <3E305DB2.90107@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2003 21:45:46.0107 (UTC) FILETIME=[C92CF4B0:01C2C328] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > I agree with Bruce. I was looking at it from an RDBMS point of view. > It will make simpler devices much harder to implement. They tend > to be thin clients or memory restricted anyway. Why would a CS be a thin client? -- /===============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===============================================================| |The Net was designed to survive nukes, but not lawsuits. Wait a| |minute. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 23 19:24:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25375 for ; Thu, 23 Jan 2003 19:24:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O0Duj19311 for ietf-calendar-bks; Thu, 23 Jan 2003 16:13:56 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0O0Dto19306 for ; Thu, 23 Jan 2003 16:13:55 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0O0DvhA006836 for ; Thu, 23 Jan 2003 16:13:57 -0800 Message-ID: <3E30853F.6030109@Royer.com> Date: Thu, 23 Jan 2003 17:13:51 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? References: <3E305DB2.90107@Royer.com> <3E306289.3040100@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060106020004000407090509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060106020004000407090509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > >> I agree with Bruce. I was looking at it from an RDBMS point of view. >> It will make simpler devices much harder to implement. They tend >> to be thin clients or memory restricted anyway. > > > Why would a CS be a thin client? PDA -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060106020004000407090509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjQwMDEzNTJaMCMGCSqGSIb3DQEJBDEWBBRs 9ScMipTqSkK0fSXyPRL7L50isDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAUSLrrj00hOlq QxG9sqCHtW+s9Rm0upNXEu/T6X/ZSTtoHE3FZe4b3YX1ZNyWyQhTNXJpWM8Z3J1a61KQVVmT 5FbTdLRqP3z5zukhgp1gzsGwkHF1+lbwwEnZx/e1n8b6WTfy+8JvwNwg3nhxT7GWKSv5oKe0 npA+ILTHInXVIGDX4k1JpHfwD9LuW7d2gh918wUGuT3XTMqT1lmru8Am2llZL5Fa/6peQYfS 1fBujtTsJCgD7zkdEBMqiu/Hb3BcmN4zkdv4f8jFEAUdM2IPyWjjsNPFTbLfjEIyIurkmmDB TQkr9FeAoyIzyhePTOwC6hnv95k5tnYUqEbl1oqY5QAAAAAAAA== --------------ms060106020004000407090509-- From owner-ietf-calendar@mail.imc.org Fri Jan 24 04:46:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14405 for ; Fri, 24 Jan 2003 04:46:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O9b3i13103 for ietf-calendar-bks; Fri, 24 Jan 2003 01:37:03 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0O9b2o13093 for ; Fri, 24 Jan 2003 01:37:02 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id BA03F15507; Fri, 24 Jan 2003 10:36:56 +0100 (CET) Date: Fri, 24 Jan 2003 10:36:56 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: Lawrence Greenfield , John Stracke , ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? Message-ID: <20030124093656.GB70430@inet.it> References: <200301222045.h0MKjlQ9007290@smtp6.andrew.cmu.edu> <127.0.0.1+DDhdWak9QXNIYPuEyAg6Xu@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+DDhdWak9QXNIYPuEyAg6Xu@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jan 23, 2003 at 03:43:40PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > expected. (After all a VREPLY with a success response was already sent > back). I for one do not think that mandating a CS essentially be built Sorry? You mean, if the command succeeds for one target and fails for another one, right? But in any case, that's an implementation detail - you can't assume anything about when exactly the VREPLY gets sent. That's what worries me more about the protocol specification: if my CUA sends a command with multiple TARGETs, there's not telling whether the response will be one RPY or multiple ANS, whether any of them will be a complete VCALENDAR component, which of them contains the reponse for which TARGET, and so on - not until it parses everything. There are so many ways of doing the same thing! Anyway, back to the discussion. You still assume it IS meaningful to assume commands are not atomic; I contend that the CS simply has no way of knowing. Compare the following: - delete every components more than a year old on both of my VAGENDAs BEGIN:VCALENDAR CMD:DELETE TARGET:work TARGET:personal BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE .... QUERY:SELECT * FROM VTODO WHERE .... END:VQUERY END:VCALENDAR - propose two different but related meetings, book it on my VAGENDA BEGIN:VCALENDAR CMD:CREATE TARGET:attendee1 TARGET:attendee2 TARGET:attendee3 METHOD:REQUEST BEGIN:VEVENT ... END:VEVENT BEGIN:VEVENT ... END:VEVENT END:VCALENDAR BEGIN:VCALENDAR CMD:CREATE TARGET:work BEGIN:VEVENT ... END:VEVENT BEGIN:VEVENT ... END:VEVENT END:VCALENDAR I can agree #1 doesn't need to be atomic - if I get any failure I can simply retry. In case #2, I would actually love to be able to perform both CREATE as a single atomic transaction. Unfortunately, there's no way I can do that. Failing that, I surely want each CREATE to be an atomic transaction. What if there is an error, any kind of error, on one out of three VAGENDAs? If the CUA wants to retry it would need to either rollback (via DELETE), or change the original command to eliminate for TARGETs it already succeeded. And in case the error is non transient and CU intervention is required, it needs to either remember this. Couple this with the effective impossibility for a CUA to know whether it has permission to store into a TARGET (without retrieving the VCARs and trying to determine that by itself, that is). Look, I can see your point, but I see no reason why unreasonably simplistic implementations should effectively crimple the ability to have elegant and efficient implementations. It's not like we don't have free RDBMS after all... Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Jan 24 04:51:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14457 for ; Fri, 24 Jan 2003 04:51:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O9iap14645 for ietf-calendar-bks; Fri, 24 Jan 2003 01:44:36 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0O9iZo14638 for ; Fri, 24 Jan 2003 01:44:35 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 8D26515507; Fri, 24 Jan 2003 10:44:34 +0100 (CET) Date: Fri, 24 Jan 2003 10:44:34 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: pregen@egenconsulting.com, ietf-calendar@imc.org, Mark Swanson Subject: Re: RFC 2445 Q: is TZID broken? Message-ID: <20030124094434.GC70430@inet.it> References: <127.0.0.1+0ihTjWvoryiL1eKFUtUOnr@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+0ihTjWvoryiL1eKFUtUOnr@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jan 23, 2003 at 03:11:16PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > A long time ago Doug has a side effort going to convert the Olsen info > into VTIMEZONEs (or was that Daemon??) Perhaps we can get some zealot (or > any other volunteer) to work on a tool to convert the Olsen info into > VTIMEZONEs that we provide as reference data... What exactly you think is needed? I think several different projects already use the Olson database in VTIMEZONE form - the only question is, how updated do they keep their copies. Are you only talking about keeping a central repository up to date? If that's the case, I would like to step forward... Bye, andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Jan 24 06:10:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15675 for ; Fri, 24 Jan 2003 06:10:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OAuUE21209 for ietf-calendar-bks; Fri, 24 Jan 2003 02:56:30 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OAuTo21199 for ; Fri, 24 Jan 2003 02:56:29 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id B86C915507; Fri, 24 Jan 2003 11:56:27 +0100 (CET) Date: Fri, 24 Jan 2003 11:56:27 +0100 From: Andrea Campi To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: VTIMEZONE in CAP Message-ID: <20030124105627.GE70430@inet.it> References: <20021218092603.GL93256@inet.it> <127.0.0.1+DQlaXDUXnmgvlaJ89gdnCE@space1.inet.it> <20030123135543.GJ64946@inet.it> <127.0.0.1+UvJUf6CEXRXVuwvARpuisq@space2.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+UvJUf6CEXRXVuwvARpuisq@space2.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jan 23, 2003 at 09:30:15AM -0500, John Stracke wrote: > And how does the CUA know that the VTIMEZONE stored in the CS is > identical to the one the CUA knows? Timezone definitions do change. > Ok then - what use are VTIMEZONEs in CALSTORE and VAGENDAs? The CUA can't refer to them anyway. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Jan 24 09:35:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20794 for ; Fri, 24 Jan 2003 09:34:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OEQZ606278 for ietf-calendar-bks; Fri, 24 Jan 2003 06:26:35 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0OEQXo06274 for ; Fri, 24 Jan 2003 06:26:33 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003012409275105352 for ; Fri, 24 Jan 2003 09:27:51 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 09:24:27 -0500 Message-ID: <3E314C9B.1020903@centive.com> Date: Fri, 24 Jan 2003 09:24:27 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE in CAP References: <20021218092603.GL93256@inet.it> <127.0.0.1+DQlaXDUXnmgvlaJ89gdnCE@space1.inet.it> <20030123135543.GJ64946@inet.it> <127.0.0.1+UvJUf6CEXRXVuwvARpuisq@space2.inet.it> <20030124105627.GE70430@inet.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2003 14:24:27.0274 (UTC) FILETIME=[4CF96EA0:01C2C3B4] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: >On Thu, Jan 23, 2003 at 09:30:15AM -0500, John Stracke wrote: > > >>And how does the CUA know that the VTIMEZONE stored in the CS is >>identical to the one the CUA knows? Timezone definitions do change. >> >> >> > >Ok then - what use are VTIMEZONEs in CALSTORE and VAGENDAs? The >CUA can't refer to them anyway. > > Hmm. VCALENDARs can't refer to them, but I suppose it might be useful for a thin CUA to have access to a large supply of VTIMEZONEs, for use in composing new VCALENDARs, without having to store them all. -- /=======================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=======================================================| |Two words that do not go together: "Memorial Cookbook".| \=======================================================/ From owner-ietf-calendar@mail.imc.org Fri Jan 24 09:38:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20906 for ; Fri, 24 Jan 2003 09:38:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OEVlb06489 for ietf-calendar-bks; Fri, 24 Jan 2003 06:31:47 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OEVjo06483 for ; Fri, 24 Jan 2003 06:31:45 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id B7702443B for ; Fri, 24 Jan 2003 09:31:16 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: Re: Q: Handling non-conforming ICalendar Date: Fri, 24 Jan 2003 09:28:02 -0500 User-Agent: KMail/1.5 References: <3E305C94.7050401@Royer.com> In-Reply-To: <3E305C94.7050401@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301240928.02062.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On January 23, 2003 04:20 pm, Doug Royer wrote: > Bruce_Kahn@notesdev.ibm.com wrote: Thanks Bruce, Doug. As you have noticed (at least by my sig) I have released an ICalendar client and server, and it's top priority that I interoperate with everyone. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Fri Jan 24 09:38:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20919 for ; Fri, 24 Jan 2003 09:38:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OEPbS06245 for ietf-calendar-bks; Fri, 24 Jan 2003 06:25:37 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OEPVo06240 for ; Fri, 24 Jan 2003 06:25:35 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 8BC44443B for ; Fri, 24 Jan 2003 09:25:03 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: Re: Is Apple creating invalid iCalendar? Date: Fri, 24 Jan 2003 09:21:48 -0500 User-Agent: KMail/1.5 References: <200212151224.44953.mark@WebServiceSolutions.com> <200212152043.45560.mark@WebServiceSolutions.com> In-Reply-To: <200212152043.45560.mark@WebServiceSolutions.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200301240921.49508.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On December 15, 2002 08:43 pm, Mark Swanson wrote: > Hello, > > I'm looking at RFC 2445 messages that appear to be created by Apple Thanks to all for responding. I'm creating an updated document that contains bugs of rfc2445 and an appendix on minor tweaks that should be done to any conforming parser to interoperate. Does anyone have a link to an existing errata/bug report for rfc2445? Thank you. - -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+MUv8BtoFHHwdJ/cRAvPrAKC6EvSlPWlGtg8iFGMqW8E1TEy2nACfSR0z FGs9QIq56y7YQ4PPZrvkhdI= =+M7J -----END PGP SIGNATURE----- From owner-ietf-calendar@mail.imc.org Fri Jan 24 09:45:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21135 for ; Fri, 24 Jan 2003 09:45:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OEUmZ06454 for ietf-calendar-bks; Fri, 24 Jan 2003 06:30:48 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0OEUlo06447 for ; Fri, 24 Jan 2003 06:30:47 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003012409320527939 for ; Fri, 24 Jan 2003 09:32:05 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 09:28:41 -0500 Message-ID: <3E314D99.1000804@centive.com> Date: Fri, 24 Jan 2003 09:28:41 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? References: <3E305DB2.90107@Royer.com> <3E306289.3040100@centive.com> <3E30853F.6030109@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2003 14:28:41.0408 (UTC) FILETIME=[E4733400:01C2C3B4] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > > John Stracke wrote: > >> >> Doug Royer wrote: >> >>> I agree with Bruce. I was looking at it from an RDBMS point of view. >>> It will make simpler devices much harder to implement. They tend >>> to be thin clients or memory restricted anyway. >> >> >> Why would a CS be a thin client? > > > PDA Um. OK, I know we've discussed this before, but I never did grasp the utility. Sure, a PDA usually has a CUA with, in effect, its own calendar store (usually a file or some such); but I don't see why that CS would be exposed via CAP. If you want lightweight, you don't put the CS into a separate process on the PDA; you integrate the CS access into the same process as the CUA. Or are you talking about having a remote CUA or CS CAP into the PDA to sync with its CS? -- /=======================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=======================================================| |Two words that do not go together: "Memorial Cookbook".| \=======================================================/ From owner-ietf-calendar@mail.imc.org Fri Jan 24 09:50:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21241 for ; Fri, 24 Jan 2003 09:50:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OEZiI06711 for ietf-calendar-bks; Fri, 24 Jan 2003 06:35:44 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OEZgo06707 for ; Fri, 24 Jan 2003 06:35:42 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 86F02443B for ; Fri, 24 Jan 2003 09:35:10 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: Re: Outlook incorrect parameter text Date: Fri, 24 Jan 2003 09:31:55 -0500 User-Agent: KMail/1.5 References: <200301221333.33800.mark@WebServiceSolutions.com> <3E2F61B5.9060601@Royer.com> In-Reply-To: <3E2F61B5.9060601@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301240931.55713.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On January 22, 2003 10:29 pm, Doug Royer wrote: > So I think that Outlook is correct in spirit. LOL. Somehow I never envisioned "Correct in spirit" to be used wrt RFC compliance. I think I like it. :-) -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Fri Jan 24 09:55:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21358 for ; Fri, 24 Jan 2003 09:55:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OEhPF07028 for ietf-calendar-bks; Fri, 24 Jan 2003 06:43:25 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OEhPo07024 for ; Fri, 24 Jan 2003 06:43:25 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA22596; Fri, 24 Jan 2003 09:43:25 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA16825; Fri, 24 Jan 2003 09:42:17 -0500 (EST) Received: from [66.92.67.186] (airport.bobmah.com [66.92.67.186]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA11889; Fri, 24 Jan 2003 09:42:10 -0500 (EST) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: Date: Fri, 24 Jan 2003 09:42:07 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: CALSCH.ORG down Cc: Pat Egen Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The box at MIT that hosts our site appears to have crashed overnight... We're looking into it and hope to have it back up before long. (No data yet as to cause) -Bob PS: This is also the machine we have the CVS server running on From owner-ietf-calendar@mail.imc.org Fri Jan 24 10:46:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23003 for ; Fri, 24 Jan 2003 10:46:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OFY2i11360 for ietf-calendar-bks; Fri, 24 Jan 2003 07:34:02 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OFY1o11353 for ; Fri, 24 Jan 2003 07:34:01 -0800 (PST) In-Reply-To: <3E2F631A.1070904@Royer.com> To: ietf-calendar@imc.org Subject: Re: Is Apple creating invalid iCalendar? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 24 Jan 2003 10:27:58 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/24/2003 10:33:49 AM, Serialize complete at 01/24/2003 10:33:49 AM Content-Type: multipart/alternative; boundary="=_alternative 005574A285256CB8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005574A285256CB8_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 01/22/2003 10:35:54 PM: > I agree that the existing: > > Format Definition: The property is defined by the following notation: > > x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF > ; Lines longer than 75 octets should be folded > > The above ABNF be modified to allow already defined parameters. This just goes to show ya that Doug and I dont always disagree (or are always in violent semi-agreement)... :^} BTW: The x-prop should not be restricted to a text value since allowing a value-param could allow a binary or non-text value in the x-param. The behaviour should be the same as that of contentline: contentline = name *(";" param ) ":" value CRLF since name can be resolved to x-name, param can be resolved to x-token, etc and that effectively replaces the above strict ABNF w/one that allows for some breathing... Hmm, does that mean we can simplify x-prop's ABNF to be: x-prop = contentline Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005574A285256CB8_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 01/22/2003 10:35:54 PM:
> I agree that the existing:
>
>     Format Definition: The property is defined by the following notation:
>
>       x-prop     = x-name *(";" xparam) [";" languageparam] ":" text CRLF
>          ; Lines longer than 75 octets should be folded
>
> The above ABNF be modified to allow already defined parameters.
This just goes to show ya that Doug and I dont always disagree (or are always in violent semi-agreement)... :^}

BTW: The x-prop should not be restricted to a text value since allowing a value-param could allow a binary or non-text value in the x-param.  The behaviour should be the same as that of contentline:

     contentline        = name *(";" param ) ":" value CRLF
since name can be resolved to x-name, param can be resolved to x-token, etc and that effectively replaces the above strict ABNF w/one that allows for some breathing...  Hmm, does that mean we can simplify x-prop's ABNF to be:

       x-prop     = contentline

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 005574A285256CB8_=-- From owner-ietf-calendar@mail.imc.org Fri Jan 24 11:08:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23544 for ; Fri, 24 Jan 2003 11:08:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OFrre13224 for ietf-calendar-bks; Fri, 24 Jan 2003 07:53:53 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OFrqo13219 for ; Fri, 24 Jan 2003 07:53:52 -0800 (PST) In-Reply-To: <3E2F676E.4030309@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 24 Jan 2003 10:53:49 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/24/2003 10:53:39 AM, Serialize complete at 01/24/2003 10:53:39 AM Content-Type: multipart/alternative; boundary="=_alternative 0057462285256CB8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057462285256CB8_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 01/22/2003 10:54:22 PM: > I seem to recall objections that all CS's must support bounded > latency. When we merged iRIP and CAP we agreed that we would > add bounded latency to CAP and not make it required. A palm > pilot for example I do not think can do bounded latency. > > Do we need a new CAPABILITY? SUPPORTS-LATENCY / boolean ? Ill have to do some searching to check on that (Vacation induced relaxation is not totally worn off yet). If a CUA does not support latency then just how would it be able to control/stop a command it issued? That is, if the Palm CUA sent a search that was taking a long time (a very busy and impatient exec) and the CU wanted to stop the action then just how would the CU/CUA be able to do that if they didnt support at least ABORT? (Clearly CONTINUE is irrelvant to this discussion). The only way if ABORT is not supported by all implementations is to disconnect from the CS and then reconnect back... Ack! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0057462285256CB8_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 01/22/2003 10:54:22 PM:
> I seem to recall objections that all CS's must support bounded
> latency. When we merged iRIP and CAP we agreed that we would
> add bounded latency to CAP and not make it required. A palm
> pilot for example I do not think can do bounded latency.
>
> Do we need a new CAPABILITY?  SUPPORTS-LATENCY / boolean ?
Ill have to do some searching to check on that (Vacation induced relaxation is not totally worn off yet).  

If a CUA does not support latency then just how would it be able to control/stop a command it issued?  That is, if the Palm CUA sent a search that was taking a long time (a very busy and impatient exec) and the CU wanted to stop the action then just how would the CU/CUA be able to do that if they didnt support at least ABORT?  (Clearly CONTINUE is irrelvant to this discussion).  The only way if ABORT is not supported by all implementations is to disconnect from the CS and then reconnect back...  Ack!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0057462285256CB8_=-- From owner-ietf-calendar@mail.imc.org Fri Jan 24 12:11:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25146 for ; Fri, 24 Jan 2003 12:11:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OH3ir17300 for ietf-calendar-bks; Fri, 24 Jan 2003 09:03:44 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OH3ho17296 for ; Fri, 24 Jan 2003 09:03:43 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id BB72B15507; Fri, 24 Jan 2003 18:03:39 +0100 (CET) Date: Fri, 24 Jan 2003 18:03:39 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) Message-ID: <20030124170339.GJ70430@inet.it> References: <3E2F676E.4030309@Royer.com> <127.0.0.1+8aamAquHFMUdaOU49985hs@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+8aamAquHFMUdaOU49985hs@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Jan 24, 2003 at 10:53:49AM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > to this discussion). The only way if ABORT is not supported by all > implementations is to disconnect from the CS and then reconnect back... For that matter, since we're using BEEP, it can simply close the channel and open a new one, no need to drop the session. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Jan 24 12:50:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26505 for ; Fri, 24 Jan 2003 12:50:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OHeuW20283 for ietf-calendar-bks; Fri, 24 Jan 2003 09:40:56 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OHeto20279 for ; Fri, 24 Jan 2003 09:40:55 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0OHethA014526 for ; Fri, 24 Jan 2003 09:40:56 -0800 Message-ID: <3E317AA2.7040709@Royer.com> Date: Fri, 24 Jan 2003 10:40:50 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050905010007020003010007" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050905010007020003010007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 01/22/2003 10:54:22 PM: > > I seem to recall objections that all CS's must support bounded > > latency. When we merged iRIP and CAP we agreed that we would > > add bounded latency to CAP and not make it required. A palm > > pilot for example I do not think can do bounded latency. > > > > Do we need a new CAPABILITY? SUPPORTS-LATENCY / boolean ? > > Ill have to do some searching to check on that (Vacation induced > relaxation is not totally worn off yet). > > If a CUA does not support latency then just how would it be able to > control/stop a command it issued? My email said that the CS might not support LATENCY, I describe both: Many PDAs for example have a time out or alarm then they simply assume the remote end is not responding. That seems to be inherent to some implementations. They do not want the user to have to wait for another time out period sending an ABORT that may also time out because the other endpoint is down. Any CUA may send an ABORT. As CELL based CUA's use air time (like my Kyocera), I do not want to wait for a few more minutes to see if the other end is responding. Simply disconnect. As a user I would be happy if the PDA asked me if I wanted to wait longer. But many cell-PDAs are not that smart. And some CS's might not support LATENCY. If my cell-PDA contacts your cell-PDA - one will be a CS and it might not be able to do timed calculations. That is I can set the time out on the cell-PDA but that aborts the transaction and connection and no way to send an ABORT or TIMEOUT. > That is, if the Palm CUA sent a > search that was taking a long time (a very busy and impatient exec) and > the CU wanted to stop the action then just how would the CU/CUA be able > to do that if they didnt support at least ABORT? (Clearly CONTINUE is > irrelvant to this discussion). The only way if ABORT is not supported > by all implementations is to disconnect from the CS and then reconnect > back... Ack! In some PDAs that is the only option. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050905010007020003010007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjQxNzQwNTBaMCMGCSqGSIb3DQEJBDEWBBQQ IG0puC9QAdC4tSQAKw2mIaom5zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAA6qfp6IcJwBF 9IzZc6POCfV2qXal61pmkpsoxpzfSept0X/+w4pB2hXd5Jd+k0llOEsigJXxU2RjFOx09UF7 hmjzjHKJ89jHsVYPnPYVPoda4W/UkePoyKGPozLn+7xTJQ/3ENiZPfT2N4+gvQIQ7hGVrj5f S58qe17OdPnXlAr5kxv5BSbQ0uQqajS8PSqJXGHv4Eaj3woM0A789uxmjgrpPEquWUgOxbaD kNbSvjaKAJKqD6H7EfrGn+OBBDZXjon9ciIhNhOFFBRe3JGJfYJuZE/4w/tNDVig8T0X2dMR qulDx7jwJlssFozluC5aQGUia9eXMDo/pKI9C62LGQAAAAAAAA== --------------ms050905010007020003010007-- From owner-ietf-calendar@mail.imc.org Fri Jan 24 13:33:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27892 for ; Fri, 24 Jan 2003 13:33:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OIOrh23584 for ietf-calendar-bks; Fri, 24 Jan 2003 10:24:53 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OIOqo23579 for ; Fri, 24 Jan 2003 10:24:52 -0800 (PST) In-Reply-To: <20030123120836.GG64946@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: Summary of thread: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 24 Jan 2003 13:24:45 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/24/2003 01:24:50 PM, Serialize complete at 01/24/2003 01:24:50 PM Content-Type: multipart/alternative; boundary="=_alternative 006517D085256CB8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006517D085256CB8_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 01/23/2003 07:08:36 AM: > Let me try to summarize the options I see: > > 1 - each part of the command succeeds or fails on its own > > 2 - the CS MUST do all the checking upfront, then: > - if at least one part of the command fails validation, it MUST bail > out immediately, returning appropriate REQUEST-STATUS I think that we are talking different levels / concepts here. When I see "command fails validation" I think "Are the parameters and the inputs to command X valid and properly formed and is the requestor permitted to issue command X? If so, they are valid and I can try to do command X for the requestor." It sounds like you are treating command validation as "Will command X work for all TARGETs for the requestor?". These are two very distinct issues. Before we can go further Id like to check if this is a correct analysis of your thoughts... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006517D085256CB8_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 01/23/2003 07:08:36 AM:
> Let me try to summarize the options I see:
>
> 1 - each part of the command succeeds or fails on its own
>
> 2 - the CS MUST do all the checking upfront, then:
>    - if at least one part of the command fails validation, it MUST bail
> out immediately, returning appropriate REQUEST-STATUS

I think that we are talking different levels / concepts here.  

When I see "command fails validation" I think "Are the parameters and the inputs to command X valid and properly formed and is the requestor permitted to issue command X?  If so, they are valid and I can try to do command X for the requestor."  It sounds like you are treating command validation as "Will command X work for all TARGETs for the requestor?".  These are two very distinct issues.  Before we can go further Id like to check if this is a correct analysis of your thoughts...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006517D085256CB8_=-- From owner-ietf-calendar@mail.imc.org Fri Jan 24 13:35:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27979 for ; Fri, 24 Jan 2003 13:35:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OICtZ23061 for ietf-calendar-bks; Fri, 24 Jan 2003 10:12:55 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OICqo23055 for ; Fri, 24 Jan 2003 10:12:53 -0800 (PST) In-Reply-To: <20030123093132.GB64946@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: STORES-EXPANDED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 24 Jan 2003 13:12:42 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/24/2003 01:12:52 PM, Serialize complete at 01/24/2003 01:12:52 PM Content-Type: multipart/alternative; boundary="=_alternative 0063FD6F85256CB8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063FD6F85256CB8_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 01/23/2003 04:31:32 AM: > Good point, but I was simply point out that the language vagueness > (the use of 'it' in the description) wasn't helping understand the > exact meaning of STORES-EXPANDED. More to the point, my proposal > would still be good in your scenario: > > STORES-EXPANDED > 1 If TRUE then the CS expands multiple instances Sorry I wasnt clearer in my response. The use of CS in the explaination is misleading as it implys a CUA<->CS scenario. I was weakly suggesting that there is a CS<->CS scenario that will eventually be involved. As such any direct uses of terms like "CS" in the description should be avoided. The term "Recipient" or whatever the response sending side should be called is more appropriate. That way a CUA can send it to a CS as well... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0063FD6F85256CB8_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 01/23/2003 04:31:32 AM:
> Good point, but I was simply point out that the language vagueness
> (the use of 'it' in the description) wasn't helping understand the
> exact meaning of STORES-EXPANDED. More to the point, my proposal
> would still be good in your scenario:
>
>       STORES-EXPANDED
>                         1     If TRUE then the CS expands multiple instances
Sorry I wasnt clearer in my response.  The use of CS in the explaination is misleading as it implys a CUA<->CS scenario.  I was weakly suggesting that there is a CS<->CS scenario that will eventually be involved.  As such any direct uses of terms like "CS" in the description should be avoided.  The term "Recipient" or whatever the response sending side should be called is more appropriate.  That way a CUA can send it to a CS as well...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0063FD6F85256CB8_=-- From owner-ietf-calendar@mail.imc.org Fri Jan 24 14:19:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29409 for ; Fri, 24 Jan 2003 14:19:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OJ2w325023 for ietf-calendar-bks; Fri, 24 Jan 2003 11:02:58 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OJ2vo25019 for ; Fri, 24 Jan 2003 11:02:57 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: delete-vreply ABNF omission MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 24 Jan 2003 13:59:00 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/24/2003 02:02:54 PM, Serialize complete at 01/24/2003 02:02:54 PM Content-Type: multipart/alternative; boundary="=_alternative 0067F54C85256CB8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067F54C85256CB8_= Content-Type: text/plain; charset="US-ASCII" In looking at the new draft 10 12-Jan-2003 I noticed that the ABNF for delete-vreply is incomplete: delete-vreply = "BEGIN" ":" "VREPLY" CRLF deleted-id request-status "END" ":" "VREPLY" CRLF ; Where the id is appropriate for the ; type of object deleted: ; ; VAGENDA = calid ; VCAR = carid ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid ; VQUERY = queryid ; ALARM = sequence ; x-component = x-id ; deleted-id = ( calid / carid / uid / uid dtstamp / queryid / tzid / sequence / x-id ) the comment for delete-vreply should include: ; VTIMEZONE = tzid Also, its unclear when a delete-id of uid dtstamp would be used so is that cruft or is there some case Im not seeing? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0067F54C85256CB8_= Content-Type: text/html; charset="US-ASCII"
In looking at the new draft 10 12-Jan-2003 I noticed that the ABNF for delete-vreply is incomplete:

delete-vreply  = "BEGIN" ":" "VREPLY" CRLF
                deleted-id
                request-status
                "END" ":" "VREPLY" CRLF

               ; Where the id is appropriate for the
               ; type of object deleted:
               ;
               ; VAGENDA = calid
               ; VCAR = carid
               ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
               ; VQUERY = queryid
               ; ALARM = sequence
               ; x-component = x-id
               ;
deleted-id    = ( calid / carid / uid / uid dtstamp
              / queryid / tzid / sequence / x-id )
the comment for delete-vreply should include:

                ; VTIMEZONE = tzid
Also, its unclear when a delete-id of uid dtstamp would be used so is that cruft or is there some case Im not seeing?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0067F54C85256CB8_=-- From owner-ietf-calendar@mail.imc.org Fri Jan 24 14:50:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00462 for ; Fri, 24 Jan 2003 14:50:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OJgC726393 for ietf-calendar-bks; Fri, 24 Jan 2003 11:42:12 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OJgBo26388 for ; Fri, 24 Jan 2003 11:42:11 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0OJgChA015404 for ; Fri, 24 Jan 2003 11:42:12 -0800 Message-ID: <3E31970F.8080305@Royer.com> Date: Fri, 24 Jan 2003 12:42:07 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: delete-vreply ABNF omission References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090906050907050401020600" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090906050907050401020600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > deleted-id = ( calid / carid / uid / uid dtstamp > / queryid / tzid / sequence / x-id ) > > the comment for delete-vreply should include: > > ; VTIMEZONE = tzid Thanks > Also, its unclear when a delete-id of uid dtstamp would be used so is > that cruft or is there some case Im not seeing? When deleting an instance. I'll add text. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090906050907050401020600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjQxOTQyMDdaMCMGCSqGSIb3DQEJBDEWBBSU aTaPUm7xxKPsWI09qLX55KsTgDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEARWLYu99vxiKA 0ROqLXfiqrECUcO3iTC8wB3qUBa8AfJxynXo81vDDrSmA3cLRc5mPrQD7yupbYa/hrjrBZIJ 8Gh8zQ/sA7SiB5L01bScjp0oUdIsMOJ8yOikpilcA5judSrmulSd4RvGLxrsE71RFgg+LmgV bdaJhSQm9725JcEFNzhedSqH+ZPSBo40KZTR2KqYXsPtGyeNjUFhfWg2W+ctpKfuH8FmSdBf mGy5K6qUlcFsuKp1YicVj9oLa5h/4uNZmOqqu1Lifg1BxcghQlkhEpRG3KWZTk5YOPdQoHym JuavVI1Sa96kZp+++z3jDufrY+KmwGBWclNXkcO7GQAAAAAAAA== --------------ms090906050907050401020600-- From owner-ietf-calendar@mail.imc.org Fri Jan 24 17:22:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04090 for ; Fri, 24 Jan 2003 17:22:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OMCY802050 for ietf-calendar-bks; Fri, 24 Jan 2003 14:12:34 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OMCXo02046 for ; Fri, 24 Jan 2003 14:12:33 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA21460; Fri, 24 Jan 2003 17:12:33 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA28329; Fri, 24 Jan 2003 17:12:32 -0500 (EST) Received: from [18.18.1.170] (airport.bobmah.com [66.92.67.186]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA01760; Fri, 24 Jan 2003 17:12:32 -0500 (EST) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: Date: Fri, 24 Jan 2003 17:12:31 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: CALSCH.ORG down until Monday... Cc: Pat Egen Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have identified a replacement box, but it won't be up until Monday. (Be suspicious of computers on sale. :-) Sorry for the hassle. -Bob From owner-ietf-calendar@mail.imc.org Fri Jan 24 17:26:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04140 for ; Fri, 24 Jan 2003 17:25:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OMIIR02159 for ietf-calendar-bks; Fri, 24 Jan 2003 14:18:18 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OMIHo02155 for ; Fri, 24 Jan 2003 14:18:17 -0800 (PST) In-Reply-To: <20030123135543.GJ64946@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: VTIMEZONE in CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 24 Jan 2003 17:12:10 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/24/2003 05:18:04 PM, Serialize complete at 01/24/2003 05:18:04 PM Content-Type: multipart/alternative; boundary="=_alternative 007A772585256CB8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007A772585256CB8_= Content-Type: text/plain; charset="US-ASCII" Andrea noted on 01/23/2003 08:55:43 AM: > Let me rephrase it - how do we handle VTIMEZONE in the context of CAP? VTIMEZONEs are components just like VEVENTS, VTODOS, VALARMS, VCARs, etc. You can create/modify/delete them using the same commands. > Language issue again. I meant: "do we need to always include the VTIMEZONEs > (if any") the component references? From 2445, Section 4.2.19 Time Zone Identifier: An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. so the CUA MUST send the TZ info useful for the entry its creating/modifying. There is also the often overlooked requirement in Section 4.6.5 Time Zone Component: The "VTIMEZONE" calendar component MUST be present if the iCalendar object contains an RRULE that generates dates on both sides of a time zone shift too to consider. > No, I don't consider TZ info to be administrative stuff; VTIMEZONEs > can be stored normally in a VCALSTORE or in a VAGENDA, or retrieved > from there, so I see no reason to handle them differently from other > components. Well, there is no provision for creating or initing the DEFAULT-TZID or other 'default' properties of the VCALSTORE so Im guessing that its classified as "Administration" and OOB. Its not "Administration" if my CUA can create any VTIMEZONE it wishes in the VCALSTORE or VAGENDA but there is no provision for dealing with the defaults apart from reading them out. I agree though that they should be treated just like any component and that they can be dealt with in the context of an entity (ie: a VEVENT) or standalone. > - when storing components, the CUA can omit the VTIMEZONE, > as long as any TZID the components references are present in the TARGETs > or in the enclosing CALSTORE. That, as you probably know, would require a change to RFC 2445. If one does not consider omitted features like iTIP failover (or 'fanout' or fallback or whatever) then this could be a simple change (in multiple places). The change would NOT be to remove the requirement entirely from iCalendar but to modify it so that it MUST be sent if it does not exist in the CS or VAGENDA. BTW: Is there any text anywhere in CAP addressing merge/conflict resolution between VTIEMZONEs at the CALSTORE and VAGENDA level? I cant find any talk of comparison, etc. A VTIMEZONE can have mulitple yet distinct STANDARD and DAYLIGHT components so its not just checking (UID, SEQUENCE, DTSTAMP, RECURRENCE-ID) like on a VEVENT, subcomponent changes need to be analyzed, etc... > - if the CUA sends VTIMEZONEs to the CS (along or together with > other components that reference them), the CS checks if they are > new or updated versions, if so it stores them Having the correct, matching VTIMEZONE info sent w/the iCalendar stream is ALWAYS a safe thing to do. It precludes the CS making a incorrect inferrence based on just the name. Thats why it was mandated in iCalendar originally, in case my US-Eastern was different than your US-Eastern. After all the CU/CUA creating it may have a different VTIMEZONE than the recipient and so the safest way to avoid TZ related mixups was to send the creators definition of the TZ along. It costs a few more bytes in the data stream but it ensures workflow integrity. > - when a CUA retrieves a component, the CS can omit the VTIMEZONE Err, not a good idea on the 'reading' side of the operation to do this. The CUA can apriori query the CS for VTIMEZONEs just fine so it knows to omit them (sic) BUT the CS has no clue what TZs the CUA has so omitting them when a CUA reads the data out is therefore NOT safe. Doing so would require the CUA to turn around and to a query for the proper VTIMEZONE info from the CS (and that then assumes that the CS knows which VTIMEZONE to return, the one from the CALSTORE or the one from the VAGENDA!!). > - the CUA should retrieve the VTIMEZONEs from the CS at most once > per session, and could probably cache them at least until the CUA is > closed. The CUA should use LAST-MODIFIED to check for updated > VTIMEZONEs. Hmmm, I just had a flicker of anxiety here. A VTIMEZONE is a special kind of container in that it can have multiple subcontainers (DAYLIGHT & STANDARD) that augment each other. So, its possible that a VTIMEZONE is updated with a new DAYLIGHT when the TZ shift rules change (ie: the government changes them for next year). As such, the LAST-MODIFIED value will change but the relevant STANDARD/DAYLIGHT subcomponents actually do not (assuming you are not scheduling into the new DAYLIGHT time frame, etc). As such, using LAST-MODIFIED is not 100% useful in doing the check if a VTIMEZONE changed or not. Yes, it did change but the change may not actually affect the related VEVENT. (Net effect: the CUA will resend a VTIMEZONE with DAYLIGHT and STANDARD subcomponents that match the CS's copy)... > To directly answer your concers: > > > If the CS doesnt have a definition that arrives w/an iTIP message (because > > the Admins have not kept their TZ tables updated) then what should happen? > > The CUA should send it along and the CS would store it. At the CALSTORE or VAGENDA level? I cant find any text on when a VTIMEZONE is (or should) be saved at the CALSTORE level and when its stored at the VAGENDA level. Im guessing that all CU stored VTIMEZONEs are expected to be at the VAGENDA level but thats just an assumption on my part about the most likely case... > > If my new beta CUA sends a METHOD:REQUEST for a newly added or updated > > TZID then would that new TZ be considered "in the CAP store" if its in the > > iTIP stream? Or would it have to be stored by some Admin first? > > I'm not sure I understand what you're saying here, but it the TZID > is new or updated the CUA must send it and the CS must store it. You're ahead of the ball in your quandry. If my CUA crafts an iTIP message w/an updated VTIMEZONE and sends it to you then is that VTIMEZONE considered to be "in the CAP store" by virtue of the fact that its in the iTIP message (assuming no magic happens to pull the VTIMEZONE out of the iTIP message when its delivered). Asked another way, if your CUA pulled down just the VEVENT that I sent you then could your CUA later get the matching (and correct) VTIMEZONE info separately (ie: query for the VTIMEZONE from the CALSTORE or VAGENDA) OR would the CS have to send it w/the VEVENT to your CUA who would in turn have to remember to send it back to the CS as an update to some VTIMEZONE in the store? Just how/when would the new info in my iTIP message become an actual stored and queryable VEVENT and VTIMEZONE? > At the end of the day, the way I see it is, RFC2445 and RFC2446 can > be interpreted as requiring the VTIMEZONE to be in scope; the scope > they consider is the enclosing VCALENDAR. Yup. For workflow integrity reasons this was deemed necessary. > I am proposing to extend > this to consider the session between a CUA and a CS as the scope, > so that they only need to exchange this data once. This can be done but all the boundarys need to be fully identified. I think there are some duality issues or just murky areas that are not fully explored (or at least described). For example, how does the CUA know to use the TZID=US-Eastern from the VAGENDA and when to use the TZID=US-Eastern from the CALSTORE? If a change is made to the VTIMEZONE definition that affects actual entries (ie: a new DAYLIGHT subcomponent is added that changes when the shift occurs at some point in the future) then what happens to those entries and the TZ info they were created using? That is, if the shift occurs 2 weeks later than the previously used DAYLIGHT subcomponent was defined for then will the affected VEVENT have its affected RDATE updated to reflect the change or not? If not, is there any consideration towards preserving the originally used DAYLIGHT info only (in relation to that affected VEVENT _only_!)?? Hmm, VTIMEZONEs seem to be an area that needs some more cycles. Im out of caffine and time for today though... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007A772585256CB8_= Content-Type: text/html; charset="US-ASCII"
Andrea noted on 01/23/2003 08:55:43 AM:
> Let me rephrase it - how do we handle VTIMEZONE in the context of CAP?
VTIMEZONEs are components just like VEVENTS, VTODOS, VALARMS, VCARs, etc.  You can create/modify/delete them using the same commands.

> Language issue again. I meant: "do we need to always include the VTIMEZONEs
> (if any") the component references?

From 2445, Section 4.2.19 Time Zone Identifier:

                                  An individual "VTIMEZONE" calendar
  component MUST be specified for each unique "TZID" parameter value
  specified in the iCalendar object.

so the CUA MUST send the TZ info useful for the entry its creating/modifying.  There is also the often overlooked requirement in Section 4.6.5 Time Zone Component:

   The "VTIMEZONE" calendar component MUST be present if the iCalendar
  object contains an RRULE that generates dates on both sides of a time
  zone shift

too to consider.

> No, I don't consider TZ info to be administrative stuff; VTIMEZONEs
> can be stored normally in a VCALSTORE or in a VAGENDA, or retrieved
> from there, so I see no reason to handle them differently from other
> components.
Well, there is no provision for creating or initing the DEFAULT-TZID or other 'default' properties of the VCALSTORE so Im guessing that its classified as "Administration" and OOB.  

Its not "Administration" if my CUA can create any VTIMEZONE it wishes in the VCALSTORE or VAGENDA but there is no provision for dealing with the defaults apart from reading them out.

I agree though that they should be treated just like any component and that they can be dealt with in the context of an entity (ie: a VEVENT) or standalone.

>  - when storing components, the CUA can omit the VTIMEZONE,
> as long as any TZID the components references are present in the TARGETs
> or in the enclosing CALSTORE.
That, as you probably know, would require a change to RFC 2445.  If one does not consider omitted features like iTIP failover (or 'fanout' or fallback or whatever) then this could be a simple change (in multiple places).  The change would NOT be to remove the requirement entirely from iCalendar but to modify it so that it MUST be sent if it does not exist in the CS or VAGENDA.

BTW: Is there any text anywhere in CAP addressing merge/conflict resolution between VTIEMZONEs at the CALSTORE and VAGENDA level?  I cant find any talk of comparison, etc.  A VTIMEZONE can have mulitple yet distinct STANDARD and DAYLIGHT components so its not just checking (UID, SEQUENCE, DTSTAMP, RECURRENCE-ID) like on a VEVENT, subcomponent changes need to be analyzed, etc...

>  - if the CUA sends VTIMEZONEs to the CS (along or together with
> other components that reference them), the CS checks if they are
> new or updated versions, if so it stores them
Having the correct, matching VTIMEZONE info sent w/the iCalendar stream is ALWAYS a safe thing to do.  It precludes the CS making a incorrect inferrence based on just the name.  Thats why it was mandated in iCalendar originally, in case my US-Eastern was different than your US-Eastern.  After all the CU/CUA creating it may have a different VTIMEZONE than the recipient and so the safest way to avoid TZ related mixups was to send the creators definition of the TZ along.  It costs a few more bytes in the data stream but it ensures workflow integrity.

>  - when a CUA retrieves a component, the CS can omit the VTIMEZONE
Err, not a good idea on the 'reading' side of the operation to do this.  The CUA can apriori query the CS for VTIMEZONEs just fine so it knows to omit them (sic) BUT the CS has no clue what TZs the CUA has so omitting them when a CUA reads the data out is therefore NOT safe.  Doing so would require the CUA to turn around and to a query for the proper VTIMEZONE info from the CS (and that then assumes that the CS knows which VTIMEZONE to return, the one from the CALSTORE or the one from the VAGENDA!!).

>  - the CUA should retrieve the VTIMEZONEs from the CS at most once
> per session, and could probably cache them at least until the CUA is
> closed. The CUA should use LAST-MODIFIED to check for updated
> VTIMEZONEs.
Hmmm, I just had a flicker of anxiety here.  

A VTIMEZONE is a special kind of container in that it can have multiple subcontainers (DAYLIGHT & STANDARD) that augment each other.  So, its possible that a VTIMEZONE is updated with a new DAYLIGHT when the TZ shift rules change (ie: the government changes them for next year).  As such, the LAST-MODIFIED value will change but the relevant STANDARD/DAYLIGHT subcomponents actually do not (assuming you are not scheduling into the new DAYLIGHT time frame, etc).  As such, using LAST-MODIFIED is not 100% useful in doing the check if a VTIMEZONE changed or not.  Yes, it did change but the change may not actually affect the related VEVENT.  (Net effect: the CUA will resend a VTIMEZONE with DAYLIGHT and STANDARD subcomponents that match the CS's copy)...

> To directly answer your concers:
>
> > If the CS doesnt have a definition that arrives w/an iTIP message (because
> > the Admins have not kept their TZ tables updated) then what should happen?
>
> The CUA should send it along and the CS would store it.
At the CALSTORE or VAGENDA level?  I cant find any text on when a VTIMEZONE is (or should) be saved at the CALSTORE level and when its stored at the VAGENDA level.  Im guessing that all CU stored VTIMEZONEs are expected to be at the VAGENDA level but thats just an assumption on my part about the most likely case...

> >  If my new beta CUA sends a METHOD:REQUEST for a newly added or updated
> > TZID then would that new TZ be considered "in the CAP store" if its in the
> > iTIP stream?  Or would it have to be stored by some Admin first?
>
> I'm not sure I understand what you're saying here, but it the TZID
> is new or updated the CUA must send it and the CS must store it.
You're ahead of the ball in your quandry.  

If my CUA crafts an iTIP message w/an updated VTIMEZONE and sends it to you then is that VTIMEZONE considered to be "in the CAP store" by virtue of the fact that its in the iTIP message (assuming no magic happens to pull the VTIMEZONE out of the iTIP message when its delivered).  Asked another way, if your CUA pulled down just the VEVENT that I sent you then could your CUA later get the matching (and correct) VTIMEZONE info separately (ie: query for the VTIMEZONE from the CALSTORE or VAGENDA) OR would the CS have to send it w/the VEVENT to your CUA who would in turn have to remember to send it back to the CS as an update to some VTIMEZONE in the store?

Just how/when would the new info in my iTIP message become an actual stored and queryable VEVENT and VTIMEZONE?

> At the end of the day, the way I see it is, RFC2445 and RFC2446 can
> be interpreted as requiring the VTIMEZONE to be in scope; the scope
> they consider is the enclosing VCALENDAR.

Yup.  For workflow integrity reasons this was deemed necessary.

>                                            I am proposing to extend
> this to consider the session between a CUA and a CS as the scope,
> so that they only need to exchange this data once.
This can be done but all the boundarys need to be fully identified.  

I think there are some duality issues or just murky areas that are not fully explored (or at least described).  For example, how does the CUA know to use the TZID=US-Eastern from the VAGENDA and when to use the TZID=US-Eastern from the CALSTORE?  If a change is made to the VTIMEZONE definition that affects actual entries (ie: a new DAYLIGHT subcomponent is added that changes when the shift occurs at some point in the future) then what happens to those entries and the TZ info they were created using?  That is, if the shift occurs 2 weeks later than the previously used DAYLIGHT subcomponent was defined for then will the affected VEVENT have its affected RDATE updated to reflect the change or not?  If not, is there any consideration towards preserving the originally used DAYLIGHT info only (in relation to that affected VEVENT _only_!)??

Hmm, VTIMEZONEs seem to be an area that needs some more cycles.  Im out of caffine and time for today though...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 007A772585256CB8_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 07:13:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13292 for ; Mon, 27 Jan 2003 07:13:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RC19b01963 for ietf-calendar-bks; Mon, 27 Jan 2003 04:01:09 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RC17o01959 for ; Mon, 27 Jan 2003 04:01:08 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 80A3115526; Mon, 27 Jan 2003 13:01:00 +0100 (CET) Date: Mon, 27 Jan 2003 13:01:00 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: Summary of thread: No partial success when it comes to deletion? Message-ID: <20030127120100.GA515@inet.it> References: <20030123120836.GG64946@inet.it> <127.0.0.1+4W7QYJkPN3HgiC703mbUvp@> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+4W7QYJkPN3HgiC703mbUvp@> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Jan 24, 2003 at 01:24:45PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Andrea replied on 01/23/2003 07:08:36 AM: > > Let me try to summarize the options I see: > > > > 1 - each part of the command succeeds or fails on its own > > > > 2 - the CS MUST do all the checking upfront, then: > > - if at least one part of the command fails validation, it MUST bail > > out immediately, returning appropriate REQUEST-STATUS > > I think that we are talking different levels / concepts here. > > When I see "command fails validation" I think "Are the parameters and the > inputs to command X valid and properly formed and is the requestor > permitted to issue command X? If so, they are valid and I can try to do > command X for the requestor." It sounds like you are treating command > validation as "Will command X work for all TARGETs for the requestor?". > These are two very distinct issues. Before we can go further Id like to > check if this is a correct analysis of your thoughts... I think we agree, I define "command validation" as "Are the parameters and the inputs to command X valid and properly formed". I didn't think of your " is the requestor permitted to issue command X?" but that's logical, too. This I see as the first phase, and if the check is passed the CS can attempt to execute the command - but it can still fail for some or all targets, for transient or permanent reasons. Now we can go further ;-) Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Jan 27 08:18:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15162 for ; Mon, 27 Jan 2003 08:18:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RD8Cr07275 for ietf-calendar-bks; Mon, 27 Jan 2003 05:08:12 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RD8Bo07271 for ; Mon, 27 Jan 2003 05:08:11 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 21AA515526; Mon, 27 Jan 2003 14:08:11 +0100 (CET) Date: Mon, 27 Jan 2003 14:08:11 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: STORES-EXPANDED Message-ID: <20030127130811.GC515@inet.it> References: <20030123093132.GB64946@inet.it> <127.0.0.1+Jd9ItklYodolEhUd6xubOU@> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+Jd9ItklYodolEhUd6xubOU@> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Jan 24, 2003 at 01:12:42PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Andrea replied on 01/23/2003 04:31:32 AM: > > Good point, but I was simply point out that the language vagueness > > (the use of 'it' in the description) wasn't helping understand the > > exact meaning of STORES-EXPANDED. More to the point, my proposal > > would still be good in your scenario: > > > > STORES-EXPANDED > > 1 If TRUE then the CS expands multiple > instances > > Sorry I wasnt clearer in my response. The use of CS in the explaination > is misleading as it implys a CUA<->CS scenario. I was weakly suggesting > that there is a CS<->CS scenario that will eventually be involved. As > such any direct uses of terms like "CS" in the description should be What about `a CS' - so it is valid even if both parties are CS. Or what about making it explicitly a CS only property. > avoided. The term "Recipient" or whatever the response sending side > should be called is more appropriate. That way a CUA can send it to a CS > as well... That's exactly my question: what would it mean in that case? As far as I can tell, this property really means: when the party receives a component with recurrences, does it expand them immediately, store them and send them out expanded? If so, is there any case in which a CUA will behave like that (internal processing for its own purpose doesn't count obviously)? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Jan 27 14:05:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23008 for ; Mon, 27 Jan 2003 14:05:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RJ1v124434 for ietf-calendar-bks; Mon, 27 Jan 2003 11:01:57 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RJ1to24430 for ; Mon, 27 Jan 2003 11:01:56 -0800 (PST) In-Reply-To: <20030123150158.GL64946@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 27 Jan 2003 13:55:33 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/27/2003 02:01:55 PM, Serialize complete at 01/27/2003 02:01:55 PM Content-Type: multipart/alternative; boundary="=_alternative 00686AEF85256CBB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00686AEF85256CBB_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 01/23/2003 10:01:58 AM: > in one of my last emails in this thread I said that, as far as > I'm concerned, stored queries can be dropped from the draft > altogether, and that we can design it properly from scratch in > a separate draft; nobody objected to that. I agree. So far no proponent of stored VQUERYs has come forward. I would suggest that we remove them from the CAP 1.0 draft since they are inadequate or at best useless in the current form. > If we want to do that, > we need to make sure CS can store components they (and we) don't > know about yet. That was a topic I was going to broach next based mored on your VTIMEZONE questions than this really. Ill start that as a separate thread to avoid digressing from the VQUERY topic any more. > That said, I think it would probably be wise to start talking > about how we'd like stored queries to be specified instead of > what's wrong with what we currently have. ;-) I already stated why I think they are useless; essentially no saved query is reusable beyond a certain span of time. There may be other issues (or others may have some) but right now I haven't spent any cycles on how to best fix this. You seem to be more motivated to do this (or at least have some ideas in mind)... Since we seem to all agree about removing stored VQUERYs I say "Move along... These aren't the topics you are interested in...." Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00686AEF85256CBB_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 01/23/2003 10:01:58 AM:
> in one of my last emails in this thread I said that, as far as
> I'm concerned, stored queries can be dropped from the draft
> altogether, and that we can design it properly from scratch in
> a separate draft; nobody objected to that.

I agree.  So far no proponent of stored VQUERYs has come forward.  I would suggest that we remove them from the CAP 1.0 draft since they are inadequate or at best useless in the current form.  

>                                            If we want to do that,
> we need to make sure CS can store components they (and we) don't
> know about yet.
That was a topic I was going to broach next based mored on your VTIMEZONE questions than this really.  Ill start that as a separate thread to avoid digressing from the VQUERY topic any more.

> That said, I think it would probably be wise to start talking
> about how we'd like stored queries to be specified instead of
> what's wrong with what we currently have. ;-)
I already stated why I think they are useless; essentially no saved query is reusable beyond a certain span of time. There may be other issues (or others may have some) but right now I haven't spent any cycles on how to best fix this.  You seem to be more motivated to do this (or at least have some ideas in mind)...

Since we seem to all agree about removing stored VQUERYs I say "Move along... These aren't the topics you are interested in...."

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 00686AEF85256CBB_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 14:06:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23029 for ; Mon, 27 Jan 2003 14:06:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RJ0mP24388 for ietf-calendar-bks; Mon, 27 Jan 2003 11:00:48 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RJ0lo24384 for ; Mon, 27 Jan 2003 11:00:47 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 1.0 & Unknown components/subcomponents MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 27 Jan 2003 13:54:25 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/27/2003 02:00:47 PM, Serialize complete at 01/27/2003 02:00:47 PM Content-Type: multipart/alternative; boundary="=_alternative 0068507585256CBB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068507585256CBB_= Content-Type: text/plain; charset="US-ASCII" Based on the thread on VTIMEZONEs that Andrea started and as an offshoot of the VQUERY thread I have a concern about the handling of unknown components in CAP. Currently in the GET-CAPABILITY command the side sending the response specifically indicates the components/subcomponent that it specifically supports. The relevant text is: COMPONENTS 1 A comma separated list of the names of components that are supported. This includes any components inside of other components (VALARM for example). It MUST include at least VCALSTORE, VCALENDAR, VREPLY, and VAGENDA and at least one of VEVENT, VTODO, VTIMEZONE, or VJOURNAL. The defalt is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO, DAYLIGHT,STANDARD" As such, there appears to be no onus or expectation that a CS can support just any component. That is, if I create a VBILBO and want to save it to someone elses CS, if they do not respond with COMPONENTS:...,VBILBO... then I cannot save that component to their store. As such its never going to be possible to save newer types into older stores. This doesn't sound good to me... Why cant the CS just save the unknown component/subcomponent as a 'blob' that is likely ungrokable BUT is preservable?? After all, a CS MUST preserve the unknown properties in a VEVENT or other supported component, right!? So why cant it do the same for unknown components or subcomponents?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0068507585256CBB_= Content-Type: text/html; charset="US-ASCII"
Based on the thread on VTIMEZONEs that Andrea started and as an offshoot of the VQUERY thread I have a concern about the handling of unknown components in CAP.

Currently in the GET-CAPABILITY command the side sending the response specifically indicates the components/subcomponent that it specifically supports.  The relevant text is:

  COMPONENTS        1     A comma separated list of the names of
                          components that are supported. This
                          includes any components inside of
                          other components (VALARM for example).
                          It MUST include at least VCALSTORE, VCALENDAR,
                          VREPLY, and VAGENDA and at least one of VEVENT,
                          VTODO, VTIMEZONE, or VJOURNAL. The defalt
                          is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,
                          VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO,
                          DAYLIGHT,STANDARD"
As such, there appears to be no onus or expectation that a CS can support just any component.  That is, if I create a VBILBO and want to save it to someone elses CS, if they do not respond with COMPONENTS:...,VBILBO... then I cannot save that component to their store.  As such its never going to be possible to save newer types into older stores.  This doesn't sound good to me...  

Why cant the CS just save the unknown component/subcomponent as a 'blob' that is likely ungrokable BUT is preservable??  After all, a CS MUST preserve the unknown properties in a VEVENT or other supported component, right!?  So why cant it do the same for unknown components or subcomponents??  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0068507585256CBB_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 14:13:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23274 for ; Mon, 27 Jan 2003 14:13:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RJ7hP24598 for ietf-calendar-bks; Mon, 27 Jan 2003 11:07:43 -0800 (PST) Received: from amsfep16-int.chello.nl (amsfep16-int.chello.nl [213.46.243.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RJ7eo24593 for ; Mon, 27 Jan 2003 11:07:40 -0800 (PST) Received: from erebor.copa.nl ([212.83.72.215]) by amsfep16-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP id <20030127190724.KOZY28492.amsfep16-int.chello.nl@erebor.copa.nl> for ; Mon, 27 Jan 2003 20:07:24 +0100 Received: from martijn by erebor.copa.nl with local (Exim 3.36 #1 (Debian)) id 18dEbD-00086N-00 for ; Mon, 27 Jan 2003 20:07:15 +0100 Date: Mon, 27 Jan 2003 20:07:14 +0100 To: ietf-calendar@imc.org Subject: list copyright policy? Message-ID: <20030127190714.GA30990@erebor.copa.nl> Mail-Followup-To: martijn, ietf-calendar@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline From: Martijn van Beers Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I'm trying to write a tutorial on recurrence (in progress version at http://tipi.sf.net/doc/recur/), and I wanted to add a few sections where I summarize discussions on ietf-calendar to show what kind of issues there are, and what the proposed solutions are. I started doing this by quoting email extensively. Now I'm wondering if there is an ietf or list policy on what you can or cannot do with messages sent to the list or that I have to mail every author individually to ask for permission to use the email. Martijn From owner-ietf-calendar@mail.imc.org Mon Jan 27 14:32:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23791 for ; Mon, 27 Jan 2003 14:32:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RJSvS25231 for ietf-calendar-bks; Mon, 27 Jan 2003 11:28:57 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0RJSto25226 for ; Mon, 27 Jan 2003 11:28:55 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003012714300427525 for ; Mon, 27 Jan 2003 14:30:05 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Jan 2003 14:26:40 -0500 Message-ID: <3E3587EF.80908@centive.com> Date: Mon, 27 Jan 2003 14:26:39 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: list copyright policy? References: <20030127190714.GA30990@erebor.copa.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2003 19:26:40.0243 (UTC) FILETIME=[044E2C30:01C2C63A] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Martijn van Beers wrote: >Now I'm wondering if there is an ietf or list policy on >what you can or cannot do with messages sent to the list or >that I have to mail every author individually to ask for >permission to use the email. > > I believe all list messages are copyright ISOC. See the Note Well message we get at IETF meetings, and also RFC-2026. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Mon Jan 27 14:38:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23955 for ; Mon, 27 Jan 2003 14:38:12 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RJWZ325634 for ietf-calendar-bks; Mon, 27 Jan 2003 11:32:35 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RJWYo25629 for ; Mon, 27 Jan 2003 11:32:35 -0800 (PST) In-Reply-To: <20030123163504.GA65203@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 27 Jan 2003 14:26:12 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/27/2003 02:32:33 PM, Serialize complete at 01/27/2003 02:32:33 PM Content-Type: multipart/alternative; boundary="=_alternative 006B39A485256CBB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B39A485256CBB_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 01/23/2003 11:35:04 AM: > By the way, this same argument holds for VQUERY with multiple QUERY > properties: see 6.1.1 item 5. Yes, thanks you. > OTOH and for completeness sake: we can't take your argument to the > extreme, in some cases we do need to mandate ordering. See results > for CREATE - if results aren't in the same order as the components, > the CUA won't be able to correlate them. Huh?? Sure it can. From the draft-10 12-Jan-2003: In the following example two new top level "VAGENDA" components are created. [Snip, snip] C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: PRODID:-//someone's prodid C: VERSION:2.0 C: CMD;ID=creation01:CREATE C: TARGET:cal.example.com C: BEGIN:VAGENDA <- data for 1st new calendar C: CALID:relcalz1 C: NAME;LANGUAGE=en_US:Bill's Soccer Team C: OWNER:bill C: CALMASTER:mailto:bill@example.com C: TZID:US/Pacific C: END:VAGENDA C: BEGIN:VAGENDA <- data for 2nd new calendar C: CALID:relcalz2 C: NAME;LANGUAGE=EN-us:Mary's personal calendar C: OWNER:mary C: CALMASTER:mailto:mary@example.com C: TZID:US/Pacific C: END:VAGENDA C: END:VCALENDAR [Snip, snip] S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR S: VERSION:2.0 S: PRODID:-//someone's prodid S: CMD;ID=creation01:REPLY S: TARGET:cal.example.com S: BEGIN:VREPLY <- Reply for 1st calendar create S: CALID:relcalz1 S: REQUEST-STATUS:2.0 S: END:REPLY S: BEGIN:VREPLY <- Reply for 2nd calendar create S: CALID:relcalz2 S: REQUEST-STATUS:2.0 S: END:VREPLY S: END:VCALENDAR In this case, the CALID's are in separate VREPLYs that can easily be used by the CUA to match up the reponse. The CS could just as easily have returned: S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR S: VERSION:2.0 S: PRODID:-//someone's prodid S: CMD;ID=creation01:REPLY S: TARGET:cal.example.com S: BEGIN:VREPLY <- Reply for 2nd calendar create S: CALID:relcalz2 S: REQUEST-STATUS:2.0 S: END:VREPLY S: BEGIN:VREPLY <- Reply for 1st calendar create S: CALID:relcalz1 S: REQUEST-STATUS:2.0 S: END:REPLY S: END:VCALENDAR and there is NO difference. I see no justification for the text inbetween the request and reply that I cut out that claims: When there are multiple "TARGET" properties in the original command object then the replies MUST BE in the exact same order as they were provided to the CS. The same is true for the objects created, their responses MUST BE in the exact same order as they were supplied to the CS. since the CUA can simply use the CALIDs to match responses with the matching request. The same goes for the creation of entries w/in the VAGENDAs. There is ALWAYS info in the VREPLY to match the reply up with the command and the right target. Thats _exactly_ how the create-vreply is crafted in the draft: create-vreply = "BEGIN" ":" "VREPLY" CRLF created-id request-status other-props "END" ":" "VREPLY" CRLF ; Where the id is appropriate for the ; type of object created: ; ; VAGENDA = calid ; VCAR = carid ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid ; VQUERY = queryid ; x-component = x-id ; so that the proper id can be matched up w/the proper objects. Given the TARGET info from the VCALENDAR and the info in the VREPLY matching is pretty straight forward unless Im missing something. If Im not then why is ordering important? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006B39A485256CBB_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 01/23/2003 11:35:04 AM:
> By the way, this same argument holds for VQUERY with multiple QUERY
> properties: see 6.1.1 item 5.
Yes, thanks you.  

> OTOH and for completeness sake: we can't take your argument to the
> extreme, in some cases we do need to mandate ordering. See results
> for CREATE - if results aren't in the same order as the components,
> the CUA won't be able to correlate them.
Huh??  Sure it can.  From the draft-10 12-Jan-2003:

In the following example two new top level "VAGENDA" components are created. [Snip, snip]

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: PRODID:-//someone's prodid
C: VERSION:2.0
C: CMD;ID=creation01:CREATE
C: TARGET:cal.example.com
C: BEGIN:VAGENDA                 <- data for 1st new calendar
C: CALID:relcalz1
C: NAME;LANGUAGE=en_US:Bill's Soccer Team
C: OWNER:bill
C: CALMASTER:mailto:bill@example.com
C: TZID:US/Pacific
C: END:VAGENDA
C: BEGIN:VAGENDA                 <- data for 2nd new calendar
C: CALID:relcalz2
C: NAME;LANGUAGE=EN-us:Mary's personal calendar
C: OWNER:mary
C: CALMASTER:mailto:mary@example.com
C: TZID:US/Pacific
C: END:VAGENDA
C: END:VCALENDAR
[Snip, snip]

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=creation01:REPLY
S: TARGET:cal.example.com
S: BEGIN:VREPLY                    <- Reply for 1st calendar create
S: CALID:relcalz1
S: REQUEST-STATUS:2.0
S: END:REPLY
S: BEGIN:VREPLY                    <- Reply for 2nd calendar create
S: CALID:relcalz2
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR
In this case, the CALID's are in separate VREPLYs that can easily be used by the CUA to match up the reponse.  The CS could just as easily have returned:

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=creation01:REPLY
S: TARGET:cal.example.com
S: BEGIN:VREPLY                    <- Reply for 2nd calendar create
S: CALID:relcalz2
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: BEGIN:VREPLY                    <- Reply for 1st calendar create
S: CALID:relcalz1
S: REQUEST-STATUS:2.0
S: END:REPLY
S: END:VCALENDAR

and there is NO difference. I see no justification for the text inbetween the request and reply that I cut out that claims:

When there are multiple "TARGET" properties in the original command object then the replies MUST BE in the exact same order as they were provided to the CS. The same is true for the objects created, their responses MUST BE in the exact same order as they were supplied to the CS.

since the CUA can simply use the CALIDs to match responses with the matching request.  The same goes for the creation of entries w/in the VAGENDAs.  There is ALWAYS info in the VREPLY to match the reply up with the command and the right target.  Thats _exactly_  how the create-vreply is crafted in the draft:

create-vreply  = "BEGIN" ":" "VREPLY" CRLF
                created-id
                request-status
                other-props
                "END" ":" "VREPLY" CRLF

              ; Where the id is appropriate for the
              ; type of object created:
              ;
              ; VAGENDA = calid
              ; VCAR = carid
              ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
              ; VQUERY = queryid
              ; x-component = x-id
              ;
so that the proper id can be matched up w/the proper objects.  Given the TARGET info from the VCALENDAR and the info in the VREPLY matching is pretty straight forward unless Im missing something.  If Im not then why is ordering important?  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006B39A485256CBB_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 15:28:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25623 for ; Mon, 27 Jan 2003 15:28:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RKIVl26835 for ietf-calendar-bks; Mon, 27 Jan 2003 12:18:31 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RKIUo26831 for ; Mon, 27 Jan 2003 12:18:31 -0800 (PST) In-Reply-To: <3E305C94.7050401@Royer.com> To: ietf-calendar@imc.org Subject: Re: Q: Handling non-conforming ICalendar MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 27 Jan 2003 15:12:06 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/27/2003 03:18:27 PM, Serialize complete at 01/27/2003 03:18:27 PM Content-Type: multipart/alternative; boundary="=_alternative 006F6D2E85256CBB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F6D2E85256CBB_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 01/23/2003 04:20:20 PM: > I agree with Burce > for my project - if it is not parsable - reject it. May I suggest that we put in CAP an explicit text/requirement to the effect that any bad or incorrectly formed parameters or inputs MUST be rejected outright and the command terminated or considered complete? This applys both ways considering that a command can be sent by either side. I can draft up some explicit text if we dont have anything useful already; its only a couple lines that are needed I think. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F6D2E85256CBB_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 01/23/2003 04:20:20 PM:
>                                              I agree with Burce
> for my project - if it is not parsable - reject it.
May I suggest that we put in CAP an explicit text/requirement to the effect that any bad or incorrectly formed parameters or inputs MUST be rejected outright and the command terminated or considered complete?  This applys both ways considering that a command can be sent by either side.  I can draft up some explicit text if we dont have anything useful already; its only a couple lines that are needed I think.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006F6D2E85256CBB_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 15:35:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25823 for ; Mon, 27 Jan 2003 15:35:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RKVLK27192 for ietf-calendar-bks; Mon, 27 Jan 2003 12:31:21 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RKVKo27186 for ; Mon, 27 Jan 2003 12:31:20 -0800 (PST) In-Reply-To: <20030124094434.GC70430@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org, Mark Swanson , pregen@egenconsulting.com Subject: Re: RFC 2445 Q: is TZID broken? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 27 Jan 2003 15:24:40 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/27/2003 03:31:15 PM, Serialize complete at 01/27/2003 03:31:15 PM Content-Type: multipart/alternative; boundary="=_alternative 007093F285256CBB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007093F285256CBB_= Content-Type: text/plain; charset="US-ASCII" Andrea responded on 01/24/2003 04:44:34 AM: > What exactly you think is needed? Id like to see one effort to develop and maintain an Olsen dB -> VTIMEZONE dB tool that we as a community could rely on. I knew of several efforts but none are still around (or I just got dropped from their distribution lists). > I think several different projects > already use the Olson database in VTIMEZONE form - the only question > is, how updated do they keep their copies. And each probably rolled their own conversion tool that probably have different bugs and thus possibly different VTIMEZONE defintions. Id love to see 1 effort that we can all rely on. > Are you only talking about keeping a central repository up to date? Actually IANA already signed up for that a while ago. Last I knew that effort was awaiting data (that had been safety checked for accuracy) and the nomination of someone to be the submitter to IANA. Frank (does he even lurk here anymore??) or Pat or Bob should be able to speak better to this though. > If that's the case, I would like to step forward... Paaaattt! Grab him quickly! Ill get the leg irons... ;^) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007093F285256CBB_= Content-Type: text/html; charset="US-ASCII"
Andrea responded on 01/24/2003 04:44:34 AM:
> What exactly you think is needed?

Id like to see one effort to develop and maintain an Olsen dB -> VTIMEZONE dB tool that we as a community could rely on.  I knew of several efforts but none are still around (or I just got dropped from their distribution lists).  

>                                    I think several different projects
> already use the Olson database in VTIMEZONE form - the only question
> is, how updated do they keep their copies.
And each probably rolled their own conversion tool that probably have different bugs and thus possibly different VTIMEZONE defintions.  Id love to see 1 effort that we can all rely on.

> Are you only talking about keeping a central repository up to date?
Actually IANA already signed up for that a while ago.  Last I knew that effort was awaiting data (that had been safety checked for accuracy) and the nomination of someone to be the submitter to IANA.  Frank (does he even lurk here anymore??) or Pat or Bob should be able to speak better to this though.

> If that's the case, I would like to step forward...
Paaaattt!  Grab him quickly!  Ill get the leg irons... ;^)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 007093F285256CBB_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 16:02:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26557 for ; Mon, 27 Jan 2003 16:01:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RKsVB27824 for ietf-calendar-bks; Mon, 27 Jan 2003 12:54:31 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RKsTo27819 for ; Mon, 27 Jan 2003 12:54:29 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0RKsVhA005604 for ; Mon, 27 Jan 2003 12:54:31 -0800 Message-ID: <3E359C81.4050800@Royer.com> Date: Mon, 27 Jan 2003 13:54:25 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Q: Handling non-conforming ICalendar References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030901050006050004010408" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030901050006050004010408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 01/23/2003 04:20:20 PM: > > I agree with Burce > > for my project - if it is not parsable - reject it. > > May I suggest that we put in CAP an explicit text/requirement to the > effect that any bad or incorrectly formed parameters or inputs MUST be > rejected outright and the command terminated or considered complete? > This applys both ways considering that a command can be sent by either > side. I can draft up some explicit text if we dont have anything useful > already; its only a couple lines that are needed I think. I would agree and please send text. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030901050006050004010408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjcyMDU0MjVaMCMGCSqGSIb3DQEJBDEWBBSa 9UAurxM9xHcHe9UZQQ4NVCd/STBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAZKhDubK2da41 NA4WyQnuNR6Wkwp3DvkyZo2yl14jWP0FK5Nz1yvWf235mhqwFbJiUcwXtt7FrnPX1FHQ9PlN G9Pwc+ClZj6xGozi8ybDFC9jIteCGsvhaXOZiwcd6lLwmCNU4ptAipk2wMSi9mvDA/IbJIei cM4hRH6UKQBg8WaW2LfQ/6/Xfrp8r2Eb4BhZIoeBIyJm7/9cWrIOWLs4ZufS6ZGsjxvR9OAR EhtmWdNkyz6H1H3xmIGdtEZn6Jjsqmesx6XCSTyZwmIO6zFMLL7/SeJ1R4ocLAW2AmG7DhyK G55QF00nGIcq/3eTWh85j8v/qTG7zhbHQ7HZYqm3/wAAAAAAAA== --------------ms030901050006050004010408-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 16:12:52 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27082 for ; Mon, 27 Jan 2003 16:12:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RL6iL28071 for ietf-calendar-bks; Mon, 27 Jan 2003 13:06:44 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RL6ho28067 for ; Mon, 27 Jan 2003 13:06:43 -0800 (PST) In-Reply-To: <20030124170339.GJ70430@inet.it> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 27 Jan 2003 16:06:40 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/27/2003 04:06:37 PM, Serialize complete at 01/27/2003 04:06:37 PM Content-Type: multipart/alternative; boundary="=_alternative 0073D8EB85256CBB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073D8EB85256CBB_= Content-Type: text/plain; charset="US-ASCII" Andrea noted on 01/24/2003 12:03:39 PM: > For that matter, since we're using BEEP, it can simply close the > channel and open a new one, no need to drop the session. Sure thats just as valid. It does however have the undesirable side effect of keeping the unwanted, unbounded, uncontrollable command going since the CUA is still connected. (And the CS may refuse to drop the erant BEEP channel if there is an active command on it or at least it should if I grok BEEP prose well enough...) I would expect that a good CS would take steps to make sure to detect CUA disconnect and deal with it like aborting in progress commands, doing session related cleanup, etc. Having the CUA create a new channel though would NOT cause the same to happen so the unbounded command would continue its rampage... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0073D8EB85256CBB_= Content-Type: text/html; charset="US-ASCII"
Andrea noted on 01/24/2003 12:03:39 PM:
> For that matter, since we're using BEEP, it can simply close the
> channel and open a new one, no need to drop the session.
Sure thats just as valid.  

It does however have the undesirable side effect of keeping the unwanted, unbounded, uncontrollable command going since the CUA is still connected.  (And the CS may refuse to drop the erant BEEP channel if there is an active command on it or at least it should if I grok BEEP prose well enough...)

I would expect that a good CS would take steps to make sure to detect CUA disconnect and deal with it like aborting in progress commands, doing session related cleanup, etc.  Having the CUA create a new channel though would NOT cause the same to happen so the unbounded command would continue its rampage...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0073D8EB85256CBB_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 16:38:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27764 for ; Mon, 27 Jan 2003 16:38:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RLT4J28638 for ietf-calendar-bks; Mon, 27 Jan 2003 13:29:04 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0RLT2o28634 for ; Mon, 27 Jan 2003 13:29:02 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003012716303714473 ; Mon, 27 Jan 2003 16:30:37 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Jan 2003 16:26:42 -0500 Message-ID: <3E35A412.7010804@centive.com> Date: Mon, 27 Jan 2003 16:26:42 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce_Kahn@notesdev.ibm.com CC: Andrea Campi , ietf-calendar@imc.org, Mark Swanson , pregen@egenconsulting.com Subject: Re: RFC 2445 Q: is TZID broken? References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2003 21:26:42.0381 (UTC) FILETIME=[C91D37D0:01C2C64A] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > If that's the case, I would like to step forward... > > Paaaattt! Grab him quickly! Ill get the leg irons... ;^) Nah, no need for leg irons; the work can be done anywhere there's connectivity. We just need an RFID tag on the back of the neck so we can find them. :-) -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |"A dog will eat pretty much anything; one major reason why there| |are no restaurants for dogs is that the customers would eat the | |menus." -- Dave Barry | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Jan 27 16:38:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27779 for ; Mon, 27 Jan 2003 16:38:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RLY8228752 for ietf-calendar-bks; Mon, 27 Jan 2003 13:34:08 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RLY7o28748 for ; Mon, 27 Jan 2003 13:34:08 -0800 (PST) In-Reply-To: <3E317AA2.7040709@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 27 Jan 2003 16:34:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/27/2003 04:34:00 PM, Serialize complete at 01/27/2003 04:34:00 PM Content-Type: multipart/alternative; boundary="=_alternative 00765C5A85256CBB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00765C5A85256CBB_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 01/24/2003 12:40:50 PM: > > If a CUA does not support latency then just how would it be able to > > control/stop a command it issued? ... > Many PDAs for example have a time out or alarm then they simply > assume the remote end is not responding. Ok, Im trying to not be dense but your PDA w/alarms CAN do latency since it obviously has the ability to deal with time outs, etc. Is there a real case where a CUA does NOT have this ability and is it a likely candidate for hosting something as robust as CAP? (Ok I digress a bit but it helps me think sometimes...) > They do not want the > user to have to wait for another time out period sending > an ABORT that may also time out because the other endpoint > is down. Umm, network disconnects were not part of this discussion so far; lets keep it simple and just focus on the case of controlling unbounded commands. > Any CUA may send an ABORT. As CELL based CUA's use air time > (like my Kyocera), I do not want to wait for a few more minutes > to see if the other end is responding. Simply disconnect. I havent seen any text/requirement that a CS must support multiple concurrent commands on the same BEEP channel. As such, if the unbounded command is going on then when would/should/can/MUST(?) the CS do any command polling for new commands on the same channel to detect the ABORT command? (Is this something in BEEP that Ive just overlooked or forgotten over the holidays?) > And some CS's might not support LATENCY. If my cell-PDA contacts > your cell-PDA - one will be a CS and it might not be able to > do timed calculations. That is I can set the time out on the cell-PDA > but that aborts the transaction and connection and no way to > send an ABORT or TIMEOUT. Is it really likely that a PDA that has no ability to do timers or alarms is going to really host a CS?? Doesnt sound like it to me. Sure, there will be someone out there who may want to write one to prove me wrong but they wont be anywhere near the majority I bet. Hmm, your last bit sounds like it agrees with my question about about being able to send an ABORT to a CS who is going unbounded. But I think its slightly different too. One case is a CS cannot support latency (and Ive yet to see an example of a 'server' CS that would not be able to support latency) and the other flavor is that both sides DO support bounded latency but the command was NOT bounded. Just how is the latter case controlled short of disconnecting? > > That is, if the Palm CUA sent a > > search that was taking a long time (a very busy and impatient exec) and > > the CU wanted to stop the action then just how would the CU/CUA be able > > to do that if they didnt support at least ABORT? (Clearly CONTINUE is > > irrelvant to this discussion). The only way if ABORT is not supported > > by all implementations is to disconnect from the CS and then reconnect > > back... Ack! > > In some PDAs that is the only option. Thats like telling a user they have to reboot their computer to exit from their mail reader. Ugh!! Still, if that is the only option then I think we should put that into the draft as a big cavat to bounded latency so its perfectly clear what the consequences are of unbounded commands. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00765C5A85256CBB_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 01/24/2003 12:40:50 PM:
> > If a CUA does not support latency then just how would it be able to
> > control/stop a command it issued?
...
> Many PDAs for example have a time out or alarm then they simply
> assume the remote end is not responding.

Ok, Im trying to not be dense but your PDA w/alarms CAN do latency since it obviously has the ability to deal with time outs, etc.  Is there a real case where a CUA does NOT have this ability and is it a likely candidate for hosting something as robust as CAP?  (Ok I digress a bit but it helps me think sometimes...)

>                                      They do not want the
> user to have to wait for another time out period sending
> an ABORT that may also time out because the other endpoint
> is down.
Umm, network disconnects were not part of this discussion so far; lets keep it simple and just focus on the case of controlling unbounded commands.

> Any CUA may send an ABORT. As CELL based CUA's use air time
> (like my Kyocera), I do not want to wait for a few more minutes
> to see if the other end is responding. Simply disconnect.
I havent seen any text/requirement that a CS must support multiple concurrent commands on the same BEEP channel.  As such, if the unbounded command is going on then when would/should/can/MUST(?) the CS do any command polling for new commands on the same channel to detect the ABORT command?  (Is this something in BEEP that Ive just overlooked or forgotten over the holidays?)

> And some CS's might not support LATENCY. If my cell-PDA contacts
> your cell-PDA - one will be a CS and it might not be able to
> do timed calculations. That is I can set the time out on the cell-PDA
> but that aborts the transaction and connection and no way to
> send an ABORT or TIMEOUT.
Is it really likely that a PDA that has no ability to do timers or alarms is going to really host a CS??  Doesnt sound like it to me.  Sure, there will be someone out there who may want to write one to prove me wrong but they wont be anywhere near the majority I bet.

Hmm, your last bit sounds like it agrees with my question about about being able to send an ABORT to a CS who is going unbounded.  But I think its slightly different too.  One case is a CS cannot support latency (and Ive yet to see an example of a 'server' CS that would not be able to support latency) and the other flavor is that both sides DO support bounded latency but the command was NOT bounded.  Just how is the latter case controlled short of disconnecting?

>  > That is, if the Palm CUA sent a
> > search that was taking a long time (a very busy and impatient exec) and
> > the CU wanted to stop the action then just how would the CU/CUA be able
> > to do that if they didnt support at least ABORT?  (Clearly CONTINUE is
> > irrelvant to this discussion).  The only way if ABORT is not supported
> > by all implementations is to disconnect from the CS and then reconnect
> > back...  Ack!
>
> In some PDAs that is the only option.
Thats like telling a user they have to reboot their computer to exit from their mail reader.  Ugh!!

Still, if that is the only option then I think we should put that into the draft as a big cavat to bounded latency so its perfectly clear what the consequences are of unbounded commands.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 00765C5A85256CBB_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 16:50:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28225 for ; Mon, 27 Jan 2003 16:50:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RLavb28805 for ietf-calendar-bks; Mon, 27 Jan 2003 13:36:57 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RLauo28801 for ; Mon, 27 Jan 2003 13:36:56 -0800 (PST) In-Reply-To: <3E31970F.8080305@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: delete-vreply ABNF omission MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 27 Jan 2003 16:36:55 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/27/2003 04:36:48 PM, Serialize complete at 01/27/2003 04:36:48 PM Content-Type: multipart/alternative; boundary="=_alternative 00769DFF85256CBB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00769DFF85256CBB_= Content-Type: text/plain; charset="US-ASCII" Doug answered on 01/24/2003 02:42:07 PM: > > Also, its unclear when a delete-id of uid dtstamp would be used so is > > that cruft or is there some case Im not seeing? > > When deleting an instance. I'll add text. Umm, wouldn't you use the RECURRENCE-ID to identify the target instance instead (along w/the UID, etc)?? The DTSTAMP is only good for identifying the date-time stamp that the object was written out. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00769DFF85256CBB_= Content-Type: text/html; charset="US-ASCII"
Doug answered on 01/24/2003 02:42:07 PM:
> > Also, its unclear when a delete-id of uid dtstamp would be used so is
> > that cruft or is there some case Im not seeing?
>
> When deleting an instance. I'll add text.
Umm, wouldn't you use the RECURRENCE-ID to identify the target instance instead (along w/the UID, etc)??  The DTSTAMP is only good for identifying the date-time stamp that the object was written out.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 00769DFF85256CBB_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 18:01:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00123 for ; Mon, 27 Jan 2003 18:01:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RMvjc01226 for ietf-calendar-bks; Mon, 27 Jan 2003 14:57:45 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RMvgo01220 for ; Mon, 27 Jan 2003 14:57:42 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id F103B15526; Mon, 27 Jan 2003 23:57:37 +0100 (CET) Date: Mon, 27 Jan 2003 23:57:37 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) Message-ID: <20030127225737.GA72452@inet.it> References: <20030124170339.GJ70430@inet.it> <127.0.0.1+a4qXivyKhR54sPdwFDY8mU@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+a4qXivyKhR54sPdwFDY8mU@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jan 27, 2003 at 04:06:40PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Andrea noted on 01/24/2003 12:03:39 PM: > > For that matter, since we're using BEEP, it can simply close the > > channel and open a new one, no need to drop the session. > > Sure thats just as valid. > > It does however have the undesirable side effect of keeping the unwanted, > unbounded, uncontrollable command going since the CUA is still connected. [...] > I would expect that a good CS would take steps to make sure to detect CUA > disconnect and deal with it like aborting in progress commands, doing > session related cleanup, etc. Having the CUA create a new channel though > would NOT cause the same to happen so the unbounded command would continue > its rampage... I agree opening a new channel wouldn't cancel outstanding commands - but closing one had better! I'm not talking about forcefully dropping a connection; rather, about sending the other party a notification that we're about to close (or that we'd like to close it, if you prefer; a BEEP peer could still deny the request, as you mentioned). Do you have in mind a specific BEEP implementation which doesn't allow you to do clean shutdown? The one I'm using most surely does, and my CS is taking advantage of that (even the very dumb one I am going to release as part of libical). Of course, once your server is notified of the channel shutdown, there's still the problem of actually stopping the runaway process - but this depends solely on your server architecture. Anyway - I'm not advocating that we should go this way. It's just that any alternative gets complicated pretty quickly. After all, it seems to me aborting a command should be an exceptional event (like the CU pressing a cancel button on a 'wait' dialog, or outright quitting the app) and less common than use of bounded latency. For instance, imagine we add a CANCEL command. First of all, if there are multiple channels open, where do we send it? On the same channel I guess, but what if the CS was stuck in a state where it doesn't react on that channel only (quite possible in a multithread server)? Or do we introduce the concept of a control channel (I hope not, and forget I mentioned the possibility)? Should we put a latency on CANCEL as well? Also, what if we have several outstanding commands on the channel? We would need to use the ID parameter together with CANCEL - but then if a CUA wants to be able to cancel all commands it needs to keep a list of them (ok, it probably needs to keep the list anyway)... OTOH, if you see this as a non-exceptional mechanism - that is, a peer might opt to use CANCEL commands as an alternative or in addition to LATENCY in normal operations - then we have two ways of doing the same thing (since you can always transform a timed abort into an immediate cancel or viceversa). Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Jan 27 18:23:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00666 for ; Mon, 27 Jan 2003 18:23:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RNFeL01560 for ietf-calendar-bks; Mon, 27 Jan 2003 15:15:40 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RNFco01556 for ; Mon, 27 Jan 2003 15:15:38 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0RNFehA006727 for ; Mon, 27 Jan 2003 15:15:41 -0800 Message-ID: <3E35BD97.4060608@Royer.com> Date: Mon, 27 Jan 2003 16:15:35 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010304070303080302050604" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010304070303080302050604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 01/24/2003 12:40:50 PM: > > > If a CUA does not support latency then just how would it be able to > > > control/stop a command it issued? > ... > > Many PDAs for example have a time out or alarm then they simply > > assume the remote end is not responding. > > Ok, Im trying to not be dense but your PDA w/alarms CAN do latency since > it obviously has the ability to deal with time outs, etc. Is there a > real case where a CUA does NOT have this ability and is it a likely > candidate for hosting something as robust as CAP? (Ok I digress a bit > but it helps me think sometimes...) It disconnects on alarm. Too late to send ABORT. > > They do not want the > > user to have to wait for another time out period sending > > an ABORT that may also time out because the other endpoint > > is down. > > Umm, network disconnects were not part of this discussion so far; lets > keep it simple and just focus on the case of controlling unbounded > commands. My point is that they do not have that kind of control. You have no choice - on alarm the BEEP connection is terminated and you can not get in side of it and send an ABORT. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010304070303080302050604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjcyMzE1MzVaMCMGCSqGSIb3DQEJBDEWBBS1 wEMy087SNdBz4VxDj3/6ge/jyjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAIhs43lGoE4ah 2C3+QMmdXLvW2T2rxtnGDmChYkORElDHzXdb9fGn5wUbOQ5CrstLGqSmqbfRUlZQGGiAFM+Z Ijr1Xd6t9joJ4Sn2HL4rbpiSJV2zRWdjLECFvwLFO/BIffa9GpZOLilQKSmsC700D3dhC2yy UPrByAvzqu5zEOuxR63IPJiVrX2CLOtaYg3Hu8aBu/fNqBOTxKydrJ9CFkzpBk5qiog1G0Ea uH5bkAVKuOS2IW4TATuxl6qmKd/jc8nlxjxXQ/nXipMb9BsZLm/UwkGSgnk6i5v6gmrQGkzR JUcNd/2MgPR/VOWxBqhoL4xdjpwmGPDfohZQIepADAAAAAAAAA== --------------ms010304070303080302050604-- From owner-ietf-calendar@mail.imc.org Mon Jan 27 18:23:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00695 for ; Mon, 27 Jan 2003 18:23:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RNIVK01603 for ietf-calendar-bks; Mon, 27 Jan 2003 15:18:31 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RNIUo01599 for ; Mon, 27 Jan 2003 15:18:30 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0RNIWhA006739 for ; Mon, 27 Jan 2003 15:18:32 -0800 Message-ID: <3E35BE42.9080104@Royer.com> Date: Mon, 27 Jan 2003 16:18:26 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: delete-vreply ABNF omission References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020104040702060403000201" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020104040702060403000201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug answered on 01/24/2003 02:42:07 PM: > > > Also, its unclear when a delete-id of uid dtstamp would be used so is > > > that cruft or is there some case Im not seeing? > > > > When deleting an instance. I'll add text. > > Umm, wouldn't you use the RECURRENCE-ID to identify the target instance > instead (along w/the UID, etc)?? The DTSTAMP is only good for > identifying the date-time stamp that the object was written out. Yes :-) Let me think more and search the archives. I seem to remember a conversation that added it. I think it was Patrice that started the thread. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020104040702060403000201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjcyMzE4MjZaMCMGCSqGSIb3DQEJBDEWBBSm eD6EQKk3qkx7k++jV5JFyR8gLjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAu687ZFZeV0zn qCsNTkZS6Fb+A/ryS7Oj5TZq3QwNwW/t58K8yOsEC1gX7z6w0gTNk1ANgVTeaZmuD4PmFfUV Mq7T9RKVcJBwHOAimEZ+tL86KcT8Z+kzDHBMBuX8JhOG3hSJ+NkSwvr+FmbXX6SQ3CVfWzIE 3XpObctTCzkMTYzSCmZSDCochEtF9kNHtviHNALdWw25T0Yp0aUYdwm2hsQPbGp5ETDEalHr xI/markomS5XR6mNIcaVFN1J/ncaXPkoZ96MFYhbYnWpqdK1UYWys5OVbCKG9eVhaxoYEEcU nP47JjNlgFfxxfE9ncFfa8ErKb/LhgHbNIVk5zalmQAAAAAAAA== --------------ms020104040702060403000201-- From owner-ietf-calendar@mail.imc.org Wed Jan 29 12:20:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23911 for ; Wed, 29 Jan 2003 12:20:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TH6Ex21283 for ietf-calendar-bks; Wed, 29 Jan 2003 09:06:14 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TH6Ao21270 for ; Wed, 29 Jan 2003 09:06:13 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 1112E155D2; Wed, 29 Jan 2003 18:06:00 +0100 (CET) Date: Wed, 29 Jan 2003 18:06:00 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. Message-ID: <20030129170600.GD81678@inet.it> References: <20030123163504.GA65203@inet.it> <127.0.0.1+J2ncjTQM4d30yO2ighXq2b@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+J2ncjTQM4d30yO2ighXq2b@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jan 27, 2003 at 02:26:12PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Andrea replied on 01/23/2003 11:35:04 AM: > > By the way, this same argument holds for VQUERY with multiple QUERY > > properties: see 6.1.1 item 5. > > Yes, thanks you. > > > OTOH and for completeness sake: we can't take your argument to the > > extreme, in some cases we do need to mandate ordering. See results > > for CREATE - if results aren't in the same order as the components, > > the CUA won't be able to correlate them. > > Huh?? Sure it can. From the draft-10 12-Jan-2003: Sorry, you're right. I was thinking of the MUST from the draft. So basically, there's no need for ordering anywhere, right? I'm all for removing the requirement then. But let me insist: we need to clarify how should multiple VQUERY (or multiple QUERY properties) behave. There is more to this than SEARCH, since VQUERY are used all over. In addition to the basic question (that I think I've asked many times), there's the issue of the same component matching more than once. Example: BEGIN:VCOMPONENT CMD:DELETE BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE DTSTART > '20030101' END:VQUERY BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE LOCATION = 'Milan, Italy' END:VQUERY END:VCOMPONENT Should this return: 1 - all results for both in one VREPLY BEGIN:VCOMPONENT BEGIN:VREPLY UID:.... UID:.... END:VREPLY END:VCOMPONENT 2 - one VREPLY per query BEGIN:VCOMPONENT BEGIN:VREPLY UID:.... ... END:VREPLY BEGIN:VREPLY UID:.... ... END:VREPLY END:VCOMPONENT 3 - one VCALENDAR per query BEGIN:VCOMPONENT BEGIN:VREPLY UID:.... ... END:VREPLY END:VCOMPONENT BEGIN:VCOMPONENT BEGIN:VREPLY UID:.... ... END:VREPLY END:VCOMPONENT 4 - undefined Now what happens if the query matched the same component? Do we return it in both replies or in one (which one)? That's my main reason for choosing #1. After all, if we wanted to separate the answers, we wouldn't send them in one query, right? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Jan 29 13:21:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25231 for ; Wed, 29 Jan 2003 13:21:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TI6CA25384 for ietf-calendar-bks; Wed, 29 Jan 2003 10:06:12 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TI6Ao25379 for ; Wed, 29 Jan 2003 10:06:11 -0800 (PST) In-Reply-To: <20030127120100.GA515@inet.it> To: ietf-calendar@imc.org Subject: Re: Summary of thread: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 29 Jan 2003 13:06:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/29/2003 01:05:56 PM, Serialize complete at 01/29/2003 01:05:56 PM Content-Type: multipart/alternative; boundary="=_alternative 00636C0185256CBD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00636C0185256CBD_= Content-Type: text/plain; charset="US-ASCII" Andrea responsed on 01/27/2003 07:01:00 AM: > I think we agree, I define "command validation" as "Are the parameters and the > inputs to command X valid and properly formed". I didn't think of > your " is the > requestor permitted to issue command X?" but that's logical, too. I think I should clarify something WRT that last bit. In Notes/Domino we have the concept of "Who can access the server", "Who can create new databases", etc. so in our frame of reference its valid for me to be able to access the server and databases on it (read calendars there when thinking CAP) but I may not be allowed to delete from the server. This was what I was thinking when I wrote that last bit. Of course such access control is CS Administration and OOB for CAP 1.0 but its a factor... In Notes/Domino a database (ack: calendar) can also have some restrictions on them so while the server may allow me to delete, the particular db may not. This is akin to the VCARs that prevent me from removing stuff from someone elses calendar and would result in a VRESULT to that effect rather than the command failing itself. This sounds a bit like having my cake and eating it too but its not really. The "Can Bruce delete/create stuff from/on the CS" check is different from "Can Bruce delete stuff off of Pats and Bobs calendars". The former is really "Is Bruce allowed to try any deletions w/in the server?" and the latter is "Does Pat allow Bruce to delete from his calendar?" and "Does Bob allow Bruce to dlete from his calendar?". The former results in an up front check of the attempted command and complete outright rejection of it. The latter results in letting the command be attempted subject to access rights on the individual dBs (sic, calendars) where it may work for some and not others. I also want to be clear that Im not proposing this kind of policy stuff be added to CAP; I was merely using it as part of getting clarifcation from Andrea. (Of course that doesnt preclude me from coding my CS to do that now does it..?) > This I see as the first phase, and if the check is passed the CS > can attempt to execute the command - but it can still fail for > some or all targets, for transient or permanent reasons. > > Now we can go further ;-) Ok, as typical you and I seem to be in agreement (it was just a phrasing quandry). So my next question is do you agree (w/Dougs text) that any failures should result in the automatic negation of any previously returned VREPLYs that were successful? I think we all like the idea of expresslly codifying the behaviour required for any implementation as described above to prevent poorly formed commands from causing havoc. As I noted before, there are lots of perfectly valid reasons that a DELETE command could fail so I strongly disagree w/the proposal there. I also think that the implicit requirement of an RDBMS backend though has not been justified to warrant the change yet. Is there some reason that Im just not seeing that would warrant an RDBMS backend for a CS at this point? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00636C0185256CBD_= Content-Type: text/html; charset="US-ASCII"
Andrea responsed on 01/27/2003 07:01:00 AM:
> I think we agree, I define "command validation" as "Are the parameters and the
> inputs to command X valid and properly formed". I didn't think of
> your " is the
> requestor permitted to issue command X?" but that's logical, too.
I think I should clarify something WRT that last bit.  In Notes/Domino we have the concept of "Who can access the server", "Who can create new databases", etc. so in our frame of reference its valid for me to be able to access the server and databases on it (read calendars there when thinking CAP) but I may not be allowed to delete from the server.  This was what I was thinking when I wrote that last bit.  Of course such access control is CS Administration and OOB for CAP 1.0 but its a factor...

In Notes/Domino a database (ack: calendar) can also have some restrictions on them so while the server may allow me to delete, the particular db may not.  This is akin to the VCARs that prevent me from removing stuff from someone elses calendar and would result in a VRESULT to that effect rather than the command failing itself.

This sounds a bit like having my cake and eating it too but its not really.  The "Can Bruce delete/create stuff from/on the CS" check is different from "Can Bruce delete stuff off of Pats and Bobs calendars".  The former is really "Is Bruce allowed to try any deletions w/in the server?" and the latter is "Does Pat allow Bruce to delete from his calendar?" and "Does Bob allow Bruce to dlete from his calendar?".  The former results in an up front check of the attempted command and complete outright rejection of it.  The latter results in letting the command be attempted subject to access rights on the individual dBs (sic, calendars) where it may work for some and not others.

I also want to be clear that Im not proposing this kind of policy stuff be added to CAP; I was merely using it as part of getting clarifcation from Andrea.  (Of course that doesnt preclude me from coding my CS to do that now does it..?)

> This I see as the first phase, and if the check is passed the CS
> can attempt to execute the command - but it can still fail for
> some or all targets, for transient or permanent reasons.
>
> Now we can go further ;-)
Ok, as typical you and I seem to be in agreement (it was just a phrasing quandry).  So my next question is do you agree (w/Dougs text) that any failures should result in the automatic negation of any previously returned VREPLYs that were successful?

I think we all like the idea of expresslly codifying the behaviour required for any implementation as described above to prevent poorly formed commands from causing havoc.  As I noted before, there are lots of perfectly valid reasons that a DELETE command could fail so I strongly disagree w/the proposal there.  

I also think that the implicit requirement of an RDBMS backend though has not been justified to warrant the change yet.  Is there some reason that Im just not seeing that would warrant an RDBMS backend for a CS at this point?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 00636C0185256CBD_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 29 13:35:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25548 for ; Wed, 29 Jan 2003 13:35:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TINht26144 for ietf-calendar-bks; Wed, 29 Jan 2003 10:23:43 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TINgo26140 for ; Wed, 29 Jan 2003 10:23:42 -0800 (PST) In-Reply-To: <20030127130811.GC515@inet.it> To: ietf-calendar@imc.org Subject: Re: STORES-EXPANDED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 29 Jan 2003 13:23:39 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/29/2003 01:23:27 PM, Serialize complete at 01/29/2003 01:23:27 PM Content-Type: multipart/alternative; boundary="=_alternative 006506DF85256CBD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006506DF85256CBD_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 01/27/2003 08:08:11 AM: > > > > > > STORES-EXPANDED > > > 1 If TRUE then the CS expands multiple > > instances > > > > Sorry I wasnt clearer in my response. The use of CS in the explaination > > is misleading as it implys a CUA<->CS scenario. I was weakly suggesting > > that there is a CS<->CS scenario that will eventually be involved. As > > such any direct uses of terms like "CS" in the description should be > > What about `a CS' - so it is valid even if both parties are CS. Or > what about making it explicitly a CS only property. Since GET-CAPABILITY is (or will be) required to be supported by both sides of the CAP session, its not correct to use "the CS" in the text. It could be 2 CS's doing sync/replication (or a CS doing the dreaded CAP Fanout where the CS acts as a CUA). As such BOTH sides are actually CS's; one side is not always going to be an actual CUA. Hence my suggestion to change "the CS" to "the sender" in the description. This should apply to ALL properties returned by the GET-CAPABILITY command. > > avoided. The term "Recipient" or whatever the response sending side > > should be called is more appropriate. That way a CUA can send it to a CS > > as well... > > That's exactly my question: what would it mean in that case? For a CUA<-CS connection this property may not be that useful. Its more useful in the CUA->CS case or the CS<->CS case (where sync/replication come into play). Is there any reason that the CS would need to know if the CUA stores data a particular way if the CS isnt going to ask the CUA for data? In CAP 1.0, probably not. When we get into CUA<->CS sync/replication (not CS<->CS) then the answer is yes (but thats at least a rev of CAP away)... My point is simply that we should not use terms like "the CS" in describing properties so that we implictly make the property CUA<-CS since we will eventually have to deal with a CS<->CS scenario where there is no CUA or for CUA->CS when we look at sync/replication. Our current prose is heavily focused on a CUA<->CS model and it may become ambiguous when we extend CAP. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006506DF85256CBD_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 01/27/2003 08:08:11 AM:
> > >
> > >       STORES-EXPANDED
> > >                         1     If TRUE then the CS expands multiple
> > instances
> >
> > Sorry I wasnt clearer in my response.  The use of CS in the explaination
> > is misleading as it implys a CUA<->CS scenario.  I was weakly suggesting
> > that there is a CS<->CS scenario that will eventually be involved.  As
> > such any direct uses of terms like "CS" in the description should be
>
> What about `a CS' - so it is valid even if both parties are CS. Or
> what about making it explicitly a CS only property.
Since GET-CAPABILITY is (or will be) required to be supported by both sides of the CAP session, its not correct to use "the CS" in the text.  It could be 2 CS's doing sync/replication (or a CS doing the dreaded CAP Fanout where the CS acts as a CUA).  As such BOTH sides are actually CS's; one side is not always going to be an actual CUA.  Hence my suggestion to change "the CS" to "the sender" in the description.  This should apply to ALL properties returned by the GET-CAPABILITY command.

> > avoided.  The term "Recipient" or whatever the response sending side
> > should be called is more appropriate.  That way a CUA can send it to a CS
> > as well...
>
> That's exactly my question: what would it mean in that case?

For a CUA<-CS connection this property may not be that useful.  Its more useful in the CUA->CS case or the CS<->CS case (where sync/replication come into play).  Is there any reason that the CS would need to know if the CUA stores data a particular way if the CS isnt going to ask the CUA for data?  In CAP 1.0, probably not.  When we get into CUA<->CS sync/replication (not CS<->CS) then the answer is yes (but thats at least a rev of CAP away)...

My point is simply that we should not use terms like "the CS" in describing properties so that we implictly make the property CUA<-CS since we will eventually have to deal with a CS<->CS scenario where there is no CUA or for CUA->CS when we look at sync/replication.  Our current prose is heavily focused on a CUA<->CS model and it may become ambiguous when we extend CAP.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006506DF85256CBD_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 29 14:55:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27892 for ; Wed, 29 Jan 2003 14:55:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TJkxB28806 for ietf-calendar-bks; Wed, 29 Jan 2003 11:46:59 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TJkwo28802 for ; Wed, 29 Jan 2003 11:46:58 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: Bad other-props constuction/ABNF MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 29 Jan 2003 14:46:56 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/29/2003 02:46:58 PM, Serialize complete at 01/29/2003 02:46:58 PM Content-Type: multipart/alternative; boundary="=_alternative 006CA6BF85256CBD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CA6BF85256CBD_= Content-Type: text/plain; charset="US-ASCII" In drafting some new text to propose to resolve another issue I ran across a problem w/the ABNF for other-props. The Draft 10-12Jan2003 has: other-props = *(";" x-prop) *(";" iana-prop) *(";" x-prop) which does work as expected when actually used. In the context of 2445 corrections it is defined to be used as: calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once. ; prodid /version / ; These are optional, but MUST NOT occur ; more than once. ; calscale / method / cmd / ; These are optional, and may occur more ; than once. ; target / other-props (I already told Doug about the missing closing paren...) So the resulting iCalendar from this SHOULD be: BEGIN:VCALENDAR PRODID:-//someone's prodid VERSION:2.0 CMD;ID=creation01:CREATE TARGET:cal.example.com FRODO-LIVES:TRUE X-LDC-NOTES:Buy Notes R6 ... but thats NOT what the ABNF says. By the ABNF I should prefix ALL X- properties and IANA properties with a ';': BEGIN:VCALENDAR PRODID:-//someone's prodid VERSION:2.0 CMD;ID=creation01:CREATE TARGET:cal.example.com ;FRODO-LIVES:TRUE ;X-LDC-NOTES:Buy Notes R6 ... This violates 2445 parsing rules for a basic content line: contentline = name *(";" param ) ":" value CRLF by making the name property NULL and turning the actual property name into a paramter name. The ABNF for other-props needs to be fixed. I _think_ that changing it to: other-props = *( x-prop [";" other-props] / iana-prop [";" other-props] ) should work. I have _not_ taken the time to check this against all references in the draft as Im on a short leash today and Im working to get a well formed proposal out for the other pressing issues. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006CA6BF85256CBD_= Content-Type: text/html; charset="US-ASCII"
In drafting some new text to propose to resolve another issue I ran across a problem w/the ABNF for other-props.  The Draft 10-12Jan2003 has:

 other-props  = *(";" x-prop) *(";" iana-prop) *(";" x-prop)
which does work as expected when actually used.  In the context of 2445 corrections it is defined to be used as:

calprops   = 2*(

          ; 'prodid' and 'version' are both REQUIRED,
          ; but MUST NOT occur more than once.
          ;
            prodid /version /

          ; These are optional, but MUST NOT occur
          ; more than once.
          ;
            calscale        /
            method          /
            cmd             /

          ; These are optional, and may occur more
          ; than once.
          ;
            target / other-props
(I already told Doug about the missing closing paren...)

So the resulting iCalendar from this SHOULD be:

BEGIN:VCALENDAR
PRODID:-//someone's prodid
VERSION:2.0
CMD;ID=creation01:CREATE
TARGET:cal.example.com
FRODO-LIVES:TRUE
X-LDC-NOTES:Buy Notes R6
...

but thats NOT what the ABNF says.  By the ABNF I should prefix ALL X- properties and IANA properties with a ';':

BEGIN:VCALENDAR
PRODID:-//someone's prodid
VERSION:2.0
CMD;ID=creation01:CREATE
TARGET:cal.example.com
;FRODO-LIVES:TRUE
;X-LDC-NOTES:Buy Notes R6
...

This violates 2445 parsing rules for a basic content line:

     contentline        = name *(";" param ) ":" value CRLF
by making the name property NULL and turning the actual property name into a paramter name.  The ABNF for other-props needs to be fixed.  I _think_ that changing it to:

 other-props  = *(
              x-prop [";" other-props] /
              iana-prop [";" other-props]
                 )
should work.  I have _not_ taken the time to check this against all references in the draft as Im on a short leash today and Im working to get a well formed proposal out for the other pressing issues.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006CA6BF85256CBD_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 29 15:10:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28393 for ; Wed, 29 Jan 2003 15:10:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TJujC29081 for ietf-calendar-bks; Wed, 29 Jan 2003 11:56:45 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TJuho29077 for ; Wed, 29 Jan 2003 11:56:44 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: ABNF for latency-param and action-param MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 29 Jan 2003 14:56:40 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/29/2003 02:56:43 PM, Serialize complete at 01/29/2003 02:56:43 PM Content-Type: multipart/alternative; boundary="=_alternative 006D8AF685256CBD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D8AF685256CBD_= Content-Type: text/plain; charset="US-ASCII" I applaud Dougs efforts to edit the draft solo but I would like to propose that the ABNF relating to all latency-param and action-param instances be slightly amended to be clearer from an ABNF POV (and to aid in better defining 'properly' formed commands from the ABNF frame). Currently all ABNFs that involve latency-param and action-param are like this one: deleteparam = *( ; the following are optional, ; but MUST NOT occur more than once ; id-param / localize-param / latency-param / option-param "MARK" ; The following MUST occur exactly once and only ; when the latency-param has been supplied and ; MUST NOT be supplied if the latency-param is ; not supplied. ; / action-param ; the following is optional, ; and MAY occur more than once ; / other-params ) Strictly speaking the ABNF does not actually link action-param to latency-param; the prose in the comment does. I would ask that we change the ABNF to be: deleteparam = *( ; the following are optional, ; but MUST NOT occur more than once ; id-param / localize-param / ( latency-param [action-param] ) / option-param "MARK" ; the following is optional, ; and MAY occur more than once ; / other-params ) It does impart an orrder to the occurance of LATENCY=... and ACTION=... but since the latter MUST occur only if the former does this is not necessarily a bad thing. It also serves to directly link action-param to latency-param which is good for doing command validity checking... The bounding parens are just for visual keying, they are not necessary really. Thoughts? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D8AF685256CBD_= Content-Type: text/html; charset="US-ASCII"
I applaud Dougs efforts to edit the draft solo but I would like to propose that the ABNF relating to all latency-param and action-param instances be slightly amended to be clearer from an ABNF POV (and to aid in better defining 'properly' formed commands from the ABNF frame).  Currently all ABNFs that involve latency-param and action-param are like this one:

deleteparam  = *(

            ; the following are optional,
            ; but MUST NOT occur more than once
            ;
             id-param
            / localize-param
            / latency-param
            / option-param "MARK"

            ; The following MUST occur exactly once and only
            ; when the latency-param has been supplied and
            ; MUST NOT be supplied if the latency-param is
            ; not supplied.
            ;
            / action-param

            ; the following is optional,
            ; and MAY occur more than once
            ;
            / other-params
           )

Strictly speaking the ABNF does not actually link action-param to latency-param; the prose in the comment does.  I would ask that we change the ABNF to be:

deleteparam  = *(

            ; the following are optional,
            ; but MUST NOT occur more than once
            ;
             id-param
            / localize-param
            / ( latency-param [action-param] )
            / option-param "MARK"

            ; the following is optional,
            ; and MAY occur more than once
            ;
            / other-params
           )
It does impart an orrder to the occurance of LATENCY=... and ACTION=... but since the latter MUST occur only if the former does this is not necessarily a bad thing.  It also serves to directly link action-param to latency-param which is good for doing command validity checking...  The bounding parens are just for visual keying, they are not necessary really.  

Thoughts?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006D8AF685256CBD_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 29 15:15:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28559 for ; Wed, 29 Jan 2003 15:15:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TK2Ob29318 for ietf-calendar-bks; Wed, 29 Jan 2003 12:02:24 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TK2No29314 for ; Wed, 29 Jan 2003 12:02:24 -0800 (PST) In-Reply-To: <3E359C81.4050800@Royer.com> To: ietf-calendar@imc.org Subject: Re: Q: Handling non-conforming ICalendar MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 29 Jan 2003 15:02:21 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/29/2003 03:02:23 PM, Serialize complete at 01/29/2003 03:02:23 PM Content-Type: multipart/alternative; boundary="=_alternative 006E105485256CBD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E105485256CBD_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 01/27/2003 03:54:25 PM: > I would agree and please send text. Here is my attempt at additions to CAP draft 10-12Jan2003 under Section 10. Commands and Responses: =============================================== 10.1 Command input validity All commands MUST perform a validity check of their inputs to ensure they are properly formed for the particular command. Any invalid, irregular or omitted properties or property parameters MUST result in the command failing immediately and returning a suitable failure response. Omission of optional properties or property parameters is not grounds for failure; only omission of required properties or property parameters is grounds for command failure. For example, failure to include an "ACTION" parameter with a "LATENCY" parameter MUST result in rejecting the command entirely. Inclusion of unknown but properly formatted properties or property parameters is not grounds for command failure. [Not sure how to best phrase this really so that new parameters can be added later that will not cause command failure just because they are unknown.] Command failure results in no action being taken on the inputs and an immediate failure response being sent back to the sender. All CAP command MUST perform input validity checking in order to prevent a malformed property or property parameter value having devastating effects and unintended side effects. The failure repsonse is constructed using the following ABNF: failure-reply = "BEGIN" ":" "VCALENDAR" CRLF calprops failure-vreply "END" ":" "VCALENDAR" CRLF failure-vreply = "BEGIN" ":" "VREPLY" CRLF request-status other-props "END" ":" "VREPLY" CRLF The REQUEST-STATUS property SHOULD provide some indication as to the cause of the failure so that corrective action may be taken. It is recommended that a diagnostic entry also be logged in the event of a command failure. =============================================== There probably is a better or more consistant way to craft a reply that indicates the command failed rather than crafting a failure-vreply for every TARGET. I defer to Doug on how to best describe this in an ABNF. In addition I would change the following text in Section 10.1.5. DELETE Command: There is no partial success for a "DELETE" command. Ether everything succeeds or nothing is done. So if the VREPLY contains X number of successful replies and at least one (1) failure then no objects were deleted or marked for deletion. This is because a malformed "QUERY" property value could have devastating effects and unintended deletion of some objects could make a calendar unusable. The CUA could inform the CU that their request must be modified in order to succeed. by removing the 'if any fail, all fail' text and rephrasing: The VREPLY may contain any number of successful and failure replies. If the VREPLY indicates success then objects were deleted or marked for deletion for the indicated TARGET. If the VREPLY indicates failure then no objects were deleted or marked for deletion in the indicated TARGET. Success or failure is determined on a per TARGET basis rather than on a collective basis. Thoughts? Comments? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006E105485256CBD_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 01/27/2003 03:54:25 PM:
> I would agree and please send text.
Here is my attempt at additions to CAP draft 10-12Jan2003 under Section 10.  Commands and Responses:

===============================================
10.1 Command input validity

All commands MUST perform a validity check of their inputs to ensure they are properly formed for the particular command.  Any invalid, irregular or omitted properties or property parameters MUST result in the command failing immediately and returning a suitable failure response.  

Omission of optional properties or property parameters is not grounds for failure; only omission of required properties or property parameters is grounds for command failure.  For example, failure to include an "ACTION" parameter with a "LATENCY" parameter MUST result in rejecting the command entirely.

Inclusion of unknown but properly formatted properties or property parameters is not grounds for command failure.  [Not sure how to best phrase this really so that new parameters can be added later that will not cause command failure just because they are unknown.]

Command failure results in no action being taken on the inputs and an immediate failure response being sent back to the sender.

All CAP command MUST perform input validity checking in order to prevent a malformed property or property parameter value having devastating effects and unintended side effects.

The failure repsonse is constructed using the following ABNF:


     failure-reply  = "BEGIN" ":" "VCALENDAR" CRLF
                       calprops
                       failure-vreply
                      "END" ":" "VCALENDAR" CRLF

    failure-vreply  = "BEGIN" ":" "VREPLY" CRLF
                        request-status
                        other-props
                       "END" ":" "VREPLY" CRLF
The REQUEST-STATUS property SHOULD provide some indication as to the cause of the failure so that corrective action may be taken.  It is recommended that a diagnostic entry also be logged in the event of a command failure.

===============================================

There probably is a better or more consistant way to craft a reply that indicates the command failed rather than crafting a failure-vreply for every TARGET.  I defer to Doug on how to best describe this in an ABNF.

In addition I would change the following text in Section 10.1.5. DELETE Command:

There is no partial success for a "DELETE" command. Ether everything succeeds or nothing is done. So if the VREPLY contains X number of successful replies and at least one (1) failure then no objects were deleted or marked for deletion. This is because a malformed "QUERY" property value could have devastating effects and unintended deletion of some objects could make a calendar unusable. The CUA could inform the CU that their request must be modified in order to succeed.

by removing the 'if any fail, all fail' text and rephrasing:

The VREPLY may contain any number of successful and failure replies.  If the VREPLY indicates success then objects were deleted or marked for deletion for the indicated TARGET. If the VREPLY indicates failure then no objects were deleted or marked for deletion in the indicated TARGET.   Success or failure is determined on a per TARGET basis rather than on a collective basis.

Thoughts?  Comments?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006E105485256CBD_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 29 16:51:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01266 for ; Wed, 29 Jan 2003 16:51:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TLg1a03096 for ietf-calendar-bks; Wed, 29 Jan 2003 13:42:01 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TLg0o03089 for ; Wed, 29 Jan 2003 13:42:00 -0800 (PST) In-Reply-To: <20030127225737.GA72452@inet.it> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 29 Jan 2003 16:41:57 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/29/2003 04:41:54 PM, Serialize complete at 01/29/2003 04:41:54 PM Content-Type: multipart/alternative; boundary="=_alternative 00772EAA85256CBD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00772EAA85256CBD_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 01/27/2003 05:57:37 PM: > I agree opening a new channel wouldn't cancel outstanding commands - > but closing one had better! I'm not talking about forcefully > dropping a connection; rather, about sending the other party a > notification that we're about to close (or that we'd like to close > it, if you prefer; a BEEP peer could still deny the request, as you > mentioned). My take on BEEP was that the Listener side would reject the BEEP session close if there was still outstanding I/O on it. From BEEP, Section 2.3.1.3 The Close Message: A BEEP peer may send a "close" message for a channel whenever all "MSG" messages it has sent on that channel have been acknowledged. which means that the CUA can try to close the session after the CS acknowledges the unbounded command. However just below that is: Otherwise, before accepting the request to close the channel, and sending an "ok" message in a positive reply, it must: o finish sending any queued "MSG" messages on that channel of its own; o await complete replies to any outstanding "MSG" messages it has sent on that channel; and, o finish sending complete replies to any outstanding "MSG" messages it has received on that channel, and ensure that the final frames of those replies have been successfully delivered, i.e., which tells me that the CS wont accept the session close attempt until it finishes dealing w/the unbounded query; there may be outstanding response messages to send back still as the command progresses!. Im still no BEEP guru so Ill defer to them when Im slapped and corrected otherwise. So I still think the only way to terminate an unbounded command is to drop the connection to the CS. Ugh!! Thats painful and costly... > Do you have in mind a specific BEEP implementation which doesn't > allow you to do clean shutdown? No, just my reading of the BEEP RFC... > The one I'm using most surely does, > and my CS is taking advantage of that (even the very dumb one I > am going to release as part of libical). Ok, then how does that not violate the BEEP RFC cited text above? > Of course, once your server is notified of the channel shutdown, > there's still the problem of actually stopping the runaway > process - but this depends solely on your server architecture. You cannot shutdown cleanly if there is an outstanding command so Im at a loss to see how you did this w/o violating BEEP. Is there a BEEP 102 class I can take?? > For instance, imagine we add a CANCEL command. First of all, if > there are multiple channels open, where do we send it? On the > same channel I guess, but what if the CS was stuck in a state > where it doesn't react on that channel only (quite possible in > a multithread server)? Or do we introduce the concept of a control > channel (I hope not, and forget I mentioned the possibility)? > Should we put a latency on CANCEL as well? IF (a BIG IF) we added a CANCEL command then Id say NO (KISS!). You cannot unclick the Cancel button in the GUI can you? You cannot unpress Cmd-. can you? You cannot intercept the signal to die, etc... > Also, what if we have several outstanding commands on the channel? > We would need to use the ID parameter together with CANCEL - but > then if a CUA wants to be able to cancel all commands it needs > to keep a list of them (ok, it probably needs to keep the list anyway)... Realistically speaking would you pipeline 2 unbounded commands on the same channel?? I would think that you'd do them on separate channels to get concurrency instead of serialization... Sighh.... Taking a big step back here to refocus on the overall picture. The big motivation for not requiring bounded latency was described by Doug as being related to some platforms like Palm not being able to support it. In doing a search I found a discussion in relation to alarms or the lack of them on some platforms so the context was NOT in processing commands but in dealing w/stuff like triggering alarms. I went and got 2 others here including a Palm owner and did some marker board presentation about CAP and bounded latency and tried to figure out if this was really an issue for Palms. Then we realized that the issue of timing out a command is really a CS side issue and NOT a CUA side issue per se. We also could not think of any realistic case where we would want a command to be attempted possibly forever given we have no way to abort it. We could find none. We also agreed that its totally unrealistic to use Palm as an example platform when considering building a real CS given its constraints. So I must therefore question the CAP design and the rationale for unbounded commands. If there is no way to terminate an unbounded command short of actual termination of the connection and there is no real world case where an unbounded command is actually useful then why are we putting them into CAP (and not clearly creating an in-protocol means to cancel them)?? If we must put unbounded commands into CAP then there must be some easy way in CAP to terminate them (ie: CANCEL). Arrgh! My head hirts! %^| Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00772EAA85256CBD_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 01/27/2003 05:57:37 PM:
> I agree opening a new channel wouldn't cancel outstanding commands -
> but closing one had better! I'm not talking about forcefully
> dropping a connection; rather, about sending the other party a
> notification that we're about to close (or that we'd like to close
> it, if you prefer; a BEEP peer could still deny the request, as you
> mentioned).
My take on BEEP was that the Listener side would reject the BEEP session close if there was still outstanding I/O on it.  From BEEP, Section 2.3.1.3 The Close Message:

   A BEEP peer may send a "close" message for a channel whenever all
  "MSG" messages it has sent on that channel have been acknowledged.
which means that the CUA can try to close the session after the CS acknowledges the unbounded command.  However just below that is:

   Otherwise, before accepting the request to close the channel, and
  sending an "ok" message in a positive reply, it must:

  o  finish sending any queued "MSG" messages on that channel of its
     own;

  o  await complete replies to any outstanding "MSG" messages it has
     sent on that channel; and,

  o  finish sending complete replies to any outstanding "MSG" messages
     it has received on that channel, and ensure that the final frames
     of those replies have been successfully delivered, i.e.,

which tells me that the CS wont accept the session close attempt until it finishes dealing w/the unbounded query; there may be outstanding response messages to send back still as the command progresses!.  Im still no BEEP guru so Ill defer to them when Im slapped and corrected otherwise.

So I still think the only way to terminate an unbounded command is to drop the connection to the CS.  Ugh!!  Thats painful and costly...

> Do you have in mind a specific BEEP implementation which doesn't
> allow you to do clean shutdown?

No, just my reading of the BEEP RFC...

>                                  The one I'm using most surely does,
> and my CS is taking advantage of that (even the very dumb one I
> am going to release as part of libical).
Ok, then how does that not violate the BEEP RFC cited text above?

> Of course, once your server is notified of the channel shutdown,
> there's still the problem of actually stopping the runaway
> process - but this depends solely on your server architecture.
You cannot shutdown cleanly if there is an outstanding command so Im at a loss to see how you did this w/o violating BEEP.  Is there a BEEP 102 class I can take??

> For instance, imagine we add a CANCEL command. First of all, if
> there are multiple channels open, where do we send it? On the
> same channel I guess, but what if the CS was stuck in a state
> where it doesn't react on that channel only (quite possible in
> a multithread server)? Or do we introduce the concept of a control
> channel (I hope not, and forget I mentioned the possibility)?
> Should we put a latency on CANCEL as well?

IF (a BIG IF) we added a CANCEL command then Id say NO (KISS!).  You cannot unclick the Cancel button in the GUI can you?  You cannot unpress Cmd-. can you?  You cannot intercept the signal to die, etc...

> Also, what if we have several outstanding commands on the channel?
> We would need to use the ID parameter together with CANCEL - but
> then if a CUA wants to be able to cancel all commands it needs
> to keep a list of them (ok, it probably needs to keep the list anyway)...
Realistically speaking would you pipeline 2 unbounded commands on the same channel??  I would think that you'd do them on separate channels to get concurrency instead of serialization...

Sighh.... Taking a big step back here to refocus on the overall picture.

The big motivation for not requiring bounded latency was described by Doug as being related to some platforms like Palm not being able to support it.  In doing a search I found a discussion in relation to alarms or the lack of them on some platforms so the context was NOT in processing commands but in dealing w/stuff like triggering alarms.  

I went and got 2 others here including a Palm owner and did some marker board presentation about CAP and bounded latency and tried to figure out if this was really an issue for Palms.  Then we realized that the issue of timing out a command is really a CS side issue and NOT a CUA side issue per se.  We also could not think of any realistic case where we would want a command to be attempted possibly forever given we have no way to abort it.  We could find none.  We also agreed that its totally unrealistic to use Palm as an example platform when considering building a real CS given its constraints.

So I must therefore question the CAP design and the rationale for unbounded commands.  If there is no way to terminate an unbounded command short of actual termination of the connection and there is no real world case where an unbounded command is actually useful then why are we putting them into CAP (and not clearly creating an in-protocol means to cancel them)??  If we must put unbounded commands into CAP then there must be some easy way in CAP to terminate them (ie: CANCEL).

Arrgh!  My head hirts!  %^|

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00772EAA85256CBD_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 29 17:05:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01875 for ; Wed, 29 Jan 2003 17:05:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TLpxw03386 for ietf-calendar-bks; Wed, 29 Jan 2003 13:51:59 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TLpvo03382 for ; Wed, 29 Jan 2003 13:51:58 -0800 (PST) In-Reply-To: <3E35BD97.4060608@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 29 Jan 2003 16:51:52 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/29/2003 04:51:52 PM, Serialize complete at 01/29/2003 04:51:52 PM Content-Type: multipart/alternative; boundary="=_alternative 007816F685256CBD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007816F685256CBD_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 01/27/2003 06:15:35 PM: > It disconnects on alarm. Too late to send ABORT. If the alarm code just does the disconnect then it can just as easily do an ABORT can't it? What am I missing here? > My point is that they do not have that kind of control. You > have no choice - on alarm the BEEP connection is terminated > and you can not get in side of it and send an ABORT. This sounds like poor design if some coded alarm system triggers terminating the transport layer session rather than the application command in progress. Also, since there is network latency involved here I find it a bit irregular that the PDA would use an internal alarm to do some action instead of dealing w/the returned VREPLYs and the possible TIMEOUT command from the CS. The previously mentioned Palm owner questioned why the PDA app would have any timer set since there is network latency involved and the time actually starts when the CS begins to process the command NOT when the PDA sends it. (Dumb design to use a local timer that matches the requested design when you can pipeline commands and there is latency involved he says.) Besides, if the PDA can do some alarm of some kind then how does that justify the use of unbounded commands? Ill keep searching the archives for some more justification since it must have made sense at some point... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007816F685256CBD_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 01/27/2003 06:15:35 PM:
> It disconnects on alarm. Too late to send ABORT.
If the alarm code just does the disconnect then it can just as easily do an ABORT can't it?  What am I missing here?

> My point is that they do not have that kind of control. You
> have no choice - on alarm the BEEP connection is terminated
> and you can not get in side of it and send an ABORT.
This sounds like poor design if some coded alarm system triggers terminating the transport layer session rather than the application command in progress.  

Also, since there is network latency involved here I find it a bit irregular that the PDA would use an internal alarm to do some action instead of dealing w/the returned VREPLYs and the possible TIMEOUT command from the CS.  

The previously mentioned Palm owner questioned why the PDA app would have any timer set since there is network latency involved and the time actually starts when the CS begins to process the command NOT when the PDA sends it.  (Dumb design to use a local timer that matches the requested design when you can pipeline commands and there is latency involved he says.)

Besides, if the PDA can do some alarm of some kind then how does that justify the use of unbounded commands?  Ill keep searching the archives for some more justification since it must have made sense at some point...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007816F685256CBD_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 29 17:40:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02475 for ; Wed, 29 Jan 2003 17:40:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TMS1l04574 for ietf-calendar-bks; Wed, 29 Jan 2003 14:28:01 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TMS0o04568 for ; Wed, 29 Jan 2003 14:28:00 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0TMS1hA027362 for ; Wed, 29 Jan 2003 14:28:01 -0800 Message-ID: <3E38556C.102@Royer.com> Date: Wed, 29 Jan 2003 15:27:56 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040304030101010507080100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040304030101010507080100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 01/27/2003 06:15:35 PM: > > It disconnects on alarm. Too late to send ABORT. > > If the alarm code just does the disconnect then it can just as easily do > an ABORT can't it? What am I missing here? > > > My point is that they do not have that kind of control. You > > have no choice - on alarm the BEEP connection is terminated > > and you can not get in side of it and send an ABORT. > > This sounds like poor design if some coded alarm system triggers > terminating the transport layer session rather than the application > command in progress. It's a failsafe alarm that can be used by an application to keep the connection from being held open ($$$) on a pay by the minute cell phone. You get - time out - your app is dead and we did a favor and closed the connection even if that is not what you want. --------------ms040304030101010507080100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjkyMjI3NTZaMCMGCSqGSIb3DQEJBDEWBBSP mfcVdlp6DyZ7wG8+VUqXfSXJjDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEApqMPhXog5VC4 4EJDPr5uGruibhE6YwjWpW1bVlAm0uVQM+JTyUNr5w1VqHN9S9dCwz5D9ma6EVb+I2FNK/KS QXXtRdrxwFQNAn14VKprbBNTIadZoE7vE9TxKl3LLVwn02bEUVCMa0lx5glIdCuBJ/ZhQ6gG Tz5gsSImHnM5qS/AoyW5E7WWBXE5w8C13LENDTb7FAsGSlpRc1CffH48O7zQrhJ6dCi6shr/ 7ZIYXHa4ki/rMxG/HNbNUtX8Z311Sl0QbPHutL4B5RDUOJIdwvLnsvKOnbkfLe+fqqXqVNvC ktqF1Yiz/U8R0zgu3RVoceCRxi3FBMMVU5uuktio7QAAAAAAAA== --------------ms040304030101010507080100-- From owner-ietf-calendar@mail.imc.org Wed Jan 29 18:15:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03165 for ; Wed, 29 Jan 2003 18:15:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TN4ND05509 for ietf-calendar-bks; Wed, 29 Jan 2003 15:04:23 -0800 (PST) Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TN4Lo05505 for ; Wed, 29 Jan 2003 15:04:21 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp7.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id h0TN4LBH023059; Wed, 29 Jan 2003 18:04:21 -0500 Date: Wed, 29 Jan 2003 18:04:21 -0500 Message-Id: <200301292304.h0TN4LBH023059@smtp7.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: ietf-calendar@imc.org, Bruce_Kahn@notesdev.ibm.com In-reply-to: Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 29 Jan 2003 16:41:57 -0500 [...] So I still think the only way to terminate an unbounded command is to drop the connection to the CS. Ugh!! Thats painful and costly... This is what almost every other IETF application protocol does. Establishing connections really isn't that costly if it's only going to happen to what should be "rare" circumstances. [...] So I must therefore question the CAP design and the rationale for unbounded commands. If there is no way to terminate an unbounded command short of actual termination of the connection and there is no real world case where an unbounded command is actually useful then why are we putting them into CAP (and not clearly creating an in-protocol means to cancel them)?? If we must put unbounded commands into CAP then there must be some easy way in CAP to terminate them (ie: CANCEL). The addition of "cancel" and "bounded latency" commands are more complicated than what's present in CAP's peer protocols (SMTP, IMAP, LDAP, for instance). Larry From owner-ietf-calendar@mail.imc.org Thu Jan 30 04:35:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22999 for ; Thu, 30 Jan 2003 04:35:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U9NLJ12970 for ietf-calendar-bks; Thu, 30 Jan 2003 01:23:21 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U9NKo12965 for ; Thu, 30 Jan 2003 01:23:20 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 5F098155D2; Thu, 30 Jan 2003 10:23:10 +0100 (CET) Date: Thu, 30 Jan 2003 10:23:09 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: STORES-EXPANDED Message-ID: <20030130092309.GE81678@inet.it> References: <20030127130811.GC515@inet.it> <127.0.0.1+w2aJnCYbFESqCTrPXpxFRj@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+w2aJnCYbFESqCTrPXpxFRj@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 29, 2003 at 01:23:39PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > > What about `a CS' - so it is valid even if both parties are CS. Or > > what about making it explicitly a CS only property. > > Since GET-CAPABILITY is (or will be) required to be supported by both > sides of the CAP session, its not correct to use "the CS" in the text. It > could be 2 CS's doing sync/replication (or a CS doing the dreaded CAP > Fanout where the CS acts as a CUA). As such BOTH sides are actually CS's; > one side is not always going to be an actual CUA. Hence my suggestion to > change "the CS" to "the sender" in the description. This should apply to > ALL properties returned by the GET-CAPABILITY command. Well, a CS is still a CS even if both parties are CS's ;-) In addition, in a CS<->CS synx situation we might have no way of knowing which one is the sender, if they are doing bidirectional replication they might be both senders and receivers at the same time. > For a CUA<-CS connection this property may not be that useful. Its more > useful in the CUA->CS case or the CS<->CS case (where sync/replication > come into play). Is there any reason that the CS would need to know if My point really. > the CUA stores data a particular way if the CS isnt going to ask the CUA > for data? In CAP 1.0, probably not. When we get into CUA<->CS > sync/replication (not CS<->CS) then the answer is yes (but thats at least > a rev of CAP away)... I'm not sure I follow you wrt CUA<->CS sync/replication; do you mean something like a CUA which downloads one or more VAGENDAS, allows you to work disconnected, then syncs back to the CS when you reconnect? If so, yes I think I see your point. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 30 05:25:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23701 for ; Thu, 30 Jan 2003 05:25:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UAGwG21772 for ietf-calendar-bks; Thu, 30 Jan 2003 02:16:58 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UAGuo21768 for ; Thu, 30 Jan 2003 02:16:56 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id DEB461554D; Thu, 30 Jan 2003 11:16:54 +0100 (CET) Date: Thu, 30 Jan 2003 11:16:54 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) Message-ID: <20030130101654.GF81678@inet.it> References: <20030127225737.GA72452@inet.it> <127.0.0.1+pjIrH1BYR4qeUXf2RlGNBo@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+pjIrH1BYR4qeUXf2RlGNBo@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 29, 2003 at 04:41:57PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > My take on BEEP was that the Listener side would reject the BEEP session > close if there was still outstanding I/O on it. From BEEP, Section > 2.3.1.3 The Close Message: > > A BEEP peer may send a "close" message for a channel whenever all > "MSG" messages it has sent on that channel have been acknowledged. Well, this text is the only real block to clean shutdown, since the CS doesn't acknowledge the message until it start replying: (Acknowledgement consists of the first frame of a reply being received by the BEEP peer that sent the MSG "message".) However, this could easily worked around by a clever implementation by sending an empty ANS message, so let me ignore this for now. I can get it back to this later if you so desire. > o finish sending complete replies to any outstanding "MSG" messages > it has received on that channel, and ensure that the final frames > of those replies have been successfully delivered, i.e., > > which tells me that the CS wont accept the session close attempt until it > finishes dealing w/the unbounded query; there may be outstanding response > messages to send back still as the command progresses!. Im still no BEEP > guru so Ill defer to them when Im slapped and corrected otherwise. This is implementation independent really. Nothing here says you have to complete processing the query, you only need to send a failure ANS or RPY to each outstanding command for the channel, before accepting the shutdown request. Do you agree or do I have to get into more details? > The big motivation for not requiring bounded latency was described by Doug > as being related to some platforms like Palm not being able to support it. [...] > I went and got 2 others here including a Palm owner and did some marker > board presentation about CAP and bounded latency and tried to figure out > if this was really an issue for Palms. Then we realized that the issue of > timing out a command is really a CS side issue and NOT a CUA side issue > per se. We also could not think of any realistic case where we would want > a command to be attempted possibly forever given we have no way to abort > it. We could find none. We also agreed that its totally unrealistic to > use Palm as an example platform when considering building a real CS given > its constraints. *nod* > So I must therefore question the CAP design and the rationale for > unbounded commands. If there is no way to terminate an unbounded command > short of actual termination of the connection and there is no real world > case where an unbounded command is actually useful then why are we putting > them into CAP (and not clearly creating an in-protocol means to cancel > them)?? If we must put unbounded commands into CAP then there must be > some easy way in CAP to terminate them (ie: CANCEL). I can understand your points, I can't really question their validity, however no matter what you do, you will still have to deal with interactive CUAs which need to deal with a user. A CU might decide to cancel a command before the latency expires, so we still need a mechanism for that, right? So this is orthogonal to bounded / unbounded, don't you agree? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 30 06:30:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24491 for ; Thu, 30 Jan 2003 06:30:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UBDm525177 for ietf-calendar-bks; Thu, 30 Jan 2003 03:13:48 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UBDlo25173 for ; Thu, 30 Jan 2003 03:13:47 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 7239F1554D; Thu, 30 Jan 2003 12:13:46 +0100 (CET) Date: Thu, 30 Jan 2003 12:13:46 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: Summary of thread: No partial success when it comes to deletion? Message-ID: <20030130111346.GG81678@inet.it> References: <20030127120100.GA515@inet.it> <127.0.0.1+Gjl6gRDOq90H39DI7VA7lh@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+Gjl6gRDOq90H39DI7VA7lh@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 29, 2003 at 01:06:07PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Ok, as typical you and I seem to be in agreement (it was just a phrasing > quandry). So my next question is do you agree (w/Dougs text) that any > failures should result in the automatic negation of any previously > returned VREPLYs that were successful? > > I think we all like the idea of expresslly codifying the behaviour > required for any implementation as described above to prevent poorly > formed commands from causing havoc. As I noted before, there are lots of > perfectly valid reasons that a DELETE command could fail so I strongly > disagree w/the proposal there. See my message with Message-ID <20030124093656.GB70430@inet.it> for an example of why I think we need some kind of atomicity, or transactions. Did you miss it or did you find it irrelevant? So yes, I guess I agree with Doug - but only if we go this way for all commands. This is an all or nothing thing, we either support transactions or we KISS. > I also think that the implicit requirement of an RDBMS backend though has > not been justified to warrant the change yet. Is there some reason that > Im just not seeing that would warrant an RDBMS backend for a CS at this > point? The main reason is one of simplicity. No matter how you look at it, if we don't have transactions, the CUA will need to be more complex. Moreover, a CUA might not be able to rollback a partially failed command (because of VCARs if nothing else). Is this a reasonable tradeoff? I don't think so, but it might be that I'm looking things from a different perspective. What about having optional support for transactions? This means: - a capability which tells us if the peer supports transactions - and either - a parameter that indicates if this command should be handled as an atomic transaction, or - explicit BEGIN, COMMIT and ROLLBACK commands. Granted, all of this (exp. if we want to add 3 commands) could be in a separate RFC, if you (plural) don't want to touch on this yet. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Jan 30 10:21:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00857 for ; Thu, 30 Jan 2003 10:21:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UF73Z08686 for ietf-calendar-bks; Thu, 30 Jan 2003 07:07:03 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UF72o08682 for ; Thu, 30 Jan 2003 07:07:02 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: ABNF 'ordering' thought MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 10:07:00 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 10:06:58 AM, Serialize complete at 01/30/2003 10:06:58 AM Content-Type: multipart/alternative; boundary="=_alternative 0053009685256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053009685256CBE_= Content-Type: text/plain; charset="US-ASCII" While looking at the latest draft I noticed that the ABNF ordering of mandatory and optional bits is somewhat odd (or at least different than Im used to from RFC 2445). For example, from Section 9.6. VQUERY Component:: queryprop = 1*( ; 'queryid' is OPTIONAL but MUST NOT occur ; more than once. If the "TARGET" property ; is supplied then the "QUERYID" property ; MUST BE supplied. ; queryid / target ; the following are OPTIONAL, and MAY occur ; more than once ; / name / other-props ; the following MUST occur at least once. ; / query ) The mandatory property is at the bottom after the optional ones. This seems a bit odd to me given that in 2445 we ordered the mandatory first and then the optional bits so that any "1*", "2*", etc. grammars had the mandatory bits up front and then the optional bits. For example, from Section 4.6 Calendar Components: calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once prodid /version / ; 'calscale' and 'method' are optional, ; but MUST NOT occur more than once calscale / method / x-prop ) I would ask that we try to keep the same kind of ordering in our CAP ABNF. This is more a preference and request than an actual "we must do this" kind of note. I find it easier if we are consistant w/the base RFCs when doing a quick analysis of the ABNF... (Back to injesting caffine and waking up fully...) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0053009685256CBE_= Content-Type: text/html; charset="US-ASCII"
While looking at the latest draft I noticed that the ABNF ordering of mandatory and optional bits is somewhat odd (or at least different than Im used to from RFC 2445).  For example, from Section 9.6. VQUERY Component::

queryprop = 1*(

         ; 'queryid' is OPTIONAL but MUST NOT occur
         ; more than once. If the "TARGET" property
         ; is supplied then the "QUERYID" property
         ; MUST BE supplied.
         ;
          queryid / target

         ; the following are OPTIONAL, and MAY occur
         ; more than once
         ;
         / name / other-props

         ; the following MUST occur at least once.
         ;
         / query
       )
The mandatory property is at the bottom after the optional ones.  This seems a bit odd to me given that in 2445 we ordered the mandatory first and then the optional bits so that any "1*",  "2*", etc. grammars had the mandatory bits up front and then the optional bits.  For example, from Section 4.6 Calendar Components:

     calprops   = 2*(

               ; 'prodid' and 'version' are both REQUIRED,
               ; but MUST NOT occur more than once

               prodid /version /

               ; 'calscale' and 'method' are optional,
               ; but MUST NOT occur more than once

               calscale        /
               method          /
               x-prop
               )

I would ask that we try to keep the same kind of ordering in our CAP ABNF.  This is more a preference and request than an actual "we must do this" kind of note.  I find it easier if we are consistant w/the base RFCs when doing a quick analysis of the ABNF...  (Back to injesting caffine and waking up fully...)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0053009685256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 11:40:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03277 for ; Thu, 30 Jan 2003 11:40:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UGODs15266 for ietf-calendar-bks; Thu, 30 Jan 2003 08:24:13 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UGOCo15262 for ; Thu, 30 Jan 2003 08:24:13 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: alarm-seq MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 11:24:11 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 11:24:05 AM, Serialize complete at 01/30/2003 11:24:05 AM Content-Type: multipart/alternative; boundary="=_alternative 005A118385256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A118385256CBE_= Content-Type: text/plain; charset="US-ASCII" Gee, I think I need to stop comparing my marked up draft 09 and just start afresh w/draft 10-12Jan2003. In doing some deeper reading for another topic I ran across something I find added to iCalendar but not actually described in CAP. In Section 2. Additions to iCalendar there is: These local alarms are not to be forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property and the "ENABLE" parameter. So for the protocol between a CUA and a CS, the following changes apply to the CAP protocol from [iCAL] section 4.6.6 page 67: alarmc = "BEGIN" ":" "VALARM" CRLF alarm-seq other-props (audioprop / dispprop / emailprop / procprop) "END" ":" "VALARM" CRLF alarm-seq = "SEQUENCE" alarmseqparams ":" posint CRLF alarmseqparams = other-params [";" local-param] other-params ; Where DIGIT is defined in [iCAL] ; posint = posintfirst 1*DIGIT ; A number starting with 1 through 9. ; posintfirst = %x31-39 I saw alarm-seq before but I never consciously grokd the addition of it to VALARMs. I find no discussion of this in the WG archives. Prior to CAP we sent all messages as full snapshots so we did not have to consider just revising the VALARM (we would sequence the containing VEVENT, etc instead and do whole substitutions). So now w/CAP we can just modify the VALARM on any particular component. As such Doug thoughtfully added alarm-seq to the spec. However I think that its not fully fleshed out. For example, when I first create a VALARM on a, say, VEVENT, the SEQUENCE of it SHOULD be 0 to follow the existing schema. This is not possible given the ABNF above; the first value could only be 1 (or higher) but never 0. Why make SEQUENCE on VALARMs different from all other components? I say just use the same prose/logic from 2445 and call it a day. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005A118385256CBE_= Content-Type: text/html; charset="US-ASCII"
Gee, I think I need to stop comparing my marked up draft 09 and just start afresh w/draft 10-12Jan2003.  In doing some deeper reading for another topic I ran across something I find added to iCalendar but not actually described in CAP.  In Section 2. Additions to iCalendar there is:

These local alarms are not to be forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property and the "ENABLE" parameter. So for the protocol between a CUA and a CS, the following changes apply to the CAP protocol from [iCAL] section 4.6.6 page 67:

 alarmc     = "BEGIN" ":" "VALARM" CRLF
                       alarm-seq
              other-props
                       (audioprop / dispprop / emailprop / procprop)
                       "END" ":" "VALARM" CRLF

alarm-seq   = "SEQUENCE" alarmseqparams ":" posint CRLF

alarmseqparams = other-params [";" local-param] other-params

              ; Where DIGIT is defined in [iCAL]
              ;
posint      = posintfirst 1*DIGIT

              ; A number starting with 1 through 9.
              ;
posintfirst = %x31-39

I saw alarm-seq before but I never consciously grokd the addition of it to VALARMs.  I find no discussion of this in the WG archives.  Prior to CAP we sent all messages as full snapshots so we did not have to consider just revising the VALARM (we would sequence the containing VEVENT, etc instead and do whole substitutions).  So now w/CAP we can just modify the VALARM on any particular component.  As such Doug thoughtfully added alarm-seq to the spec.  

However I think that its not fully fleshed out.  For example, when I first create a VALARM on a, say, VEVENT, the SEQUENCE of it SHOULD be 0 to follow the existing schema.  This is not possible given the ABNF above; the first value could only be 1 (or higher) but never 0.  Why make SEQUENCE on VALARMs different from all other components?  I say just use the same prose/logic from 2445 and call it a day.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005A118385256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 11:45:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03424 for ; Thu, 30 Jan 2003 11:45:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UGTVS15446 for ietf-calendar-bks; Thu, 30 Jan 2003 08:29:31 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UGTUo15442 for ; Thu, 30 Jan 2003 08:29:30 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: 7.2. LOCAL Parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 11:29:27 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 11:29:23 AM, Serialize complete at 01/30/2003 11:29:23 AM Content-Type: multipart/alternative; boundary="=_alternative 005A8D2C85256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A8D2C85256CBE_= Content-Type: text/plain; charset="US-ASCII" In Section 7.2. LOCAL Parameter we define the LOCAL parameter for VALARMs. The intent of the property parameter is: Purpose: Indicates if the "VALARM" component should be exported to any non-organizer calendar. This description make me think that LOCAL should be a property added to the VALARM, NOT a property parameter added to SEQUENCE. The function of a parameter is to modify the property it is on (or to augment the property value). In the case of LOCAL it does not actually have any relation to SEQUENCE. It should be its own property since its an attribute of the VALARM and not any particular property. At one point in the text it is referred to as "the "LOCAL" property" but not in all cases. Any reason we cannot make LOCAL a new VALARM property instead of just a property parameter? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005A8D2C85256CBE_= Content-Type: text/html; charset="US-ASCII"
In Section 7.2. LOCAL Parameter we define the LOCAL parameter for VALARMs.  The intent of the property parameter is:

Purpose: Indicates if the "VALARM" component should be exported to any non-organizer calendar.

This description make me think that LOCAL should be a property added to the VALARM, NOT a property parameter added to SEQUENCE.  The function of a parameter is to modify the property it is on (or to augment the property value).  In the case of LOCAL it does not actually have any relation to SEQUENCE.  It should be its own property since its an attribute of the VALARM and not any particular property.

At one point in the text it is referred to as "the "LOCAL" property" but not in all cases.  Any reason we cannot make LOCAL a new VALARM property instead of just a property parameter?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005A8D2C85256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 11:55:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04074 for ; Thu, 30 Jan 2003 11:55:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UGhWh15852 for ietf-calendar-bks; Thu, 30 Jan 2003 08:43:32 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UGhVo15847 for ; Thu, 30 Jan 2003 08:43:31 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10: icalbody ABNF change MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 11:43:30 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 11:43:23 AM, Serialize complete at 01/30/2003 11:43:23 AM Content-Type: multipart/alternative; boundary="=_alternative 005BD63685256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005BD63685256CBE_= Content-Type: text/plain; charset="US-ASCII" The draft 10-12Jan2003 has a revised 2445 ABNF of: icalbody = calprops component ; If the "VCALENDAR" component contains the "CMD" ; component then the 'component' is optional: ; / calprops ; Which MUST include a "CMD" property There are a couple little things amiss here. First off, there is no "CMD" component, its a new property (a tiny change). Secondly there is no critter defined in 2446 or CAP as a "VCALENDAR" component. In 2445 there is icalobject defined as: icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF icalbody "END" ":" "VCALENDAR" CRLF) but its never called the "VCALENDAR" component. We build several "VCALENDAR" containers in several places like abort-reply, continue-reply, etc but we never have actually defined a specific "VCALENDAR" component. Should we define one or should we use the phrase "VCALENDAR" container instead?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005BD63685256CBE_= Content-Type: text/html; charset="US-ASCII"
The draft 10-12Jan2003 has a revised 2445 ABNF of:

icalbody = calprops component

         ; If the "VCALENDAR" component contains the "CMD"
         ; component then the 'component' is optional:
         ;
         / calprops     ; Which MUST include a "CMD" property
There are a couple little things amiss here.  First off, there is no "CMD" component, its a new property (a tiny change).  Secondly there is no critter defined in 2446 or CAP as a "VCALENDAR" component.  In 2445 there is icalobject defined as:

     icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
                 icalbody
                 "END" ":" "VCALENDAR" CRLF)
but its never called the "VCALENDAR" component.  We build several "VCALENDAR" containers in several places like abort-reply, continue-reply, etc but we never have actually defined a specific "VCALENDAR" component.  Should we define one or should we use the phrase "VCALENDAR" container instead??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005BD63685256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 12:55:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05613 for ; Thu, 30 Jan 2003 12:55:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UHhWb18274 for ietf-calendar-bks; Thu, 30 Jan 2003 09:43:32 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UHhUo18267 for ; Thu, 30 Jan 2003 09:43:31 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0UHhUhA003385 for ; Thu, 30 Jan 2003 09:43:31 -0800 Message-ID: <3E39643D.8010009@Royer.com> Date: Thu, 30 Jan 2003 10:43:25 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: 7.2. LOCAL Parameter References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060608010506000705050006" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060608010506000705050006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In Section 7.2. LOCAL Parameter we define the LOCAL parameter for > VALARMs. The intent of the property parameter is: > > Purpose: Indicates if the "VALARM" component should be exported to any > non-organizer calendar. > > This description make me think that LOCAL should be a property added to > the VALARM, NOT a property parameter added to SEQUENCE. The function of > a parameter is to modify the property it is on (or to augment the > property value). In the case of LOCAL it does not actually have any > relation to SEQUENCE. It should be its own property since its an > attribute of the VALARM and not any particular property. > > At one point in the text it is referred to as "the "LOCAL" property" but > not in all cases. Any reason we cannot make LOCAL a new VALARM property > instead of just a property parameter? This was discussed months ago. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060608010506000705050006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMzAxNzQzMjVaMCMGCSqGSIb3DQEJBDEWBBTM tq12qROTI74JfLR6Wf7wBpB9FzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAJ3tm8p17J0cF U/sitvBOVn/7x5VFkXG5aNUBT4vGygRt9ubm7cH26LQu29ZOJkYu3wM5zy9FpZaU5yj+BoXJ 2+Wm5Y8dJ+pWdhBQ84xy8ynilBpVzUnzpoo4kt4oGhSI9tbhqFpPgbbZZ4Rk9MuaOP92qcu7 qrxkzRW26D3fLJwjVPqlRSLX6uYqxLGu78GSdqt9iq61gzBGBWDs8NwLOycxMHazR9Ah3FPb bGwSqCxgQYtW8G1yCGxUH7tAdULgu1Q+7JGL9dlK0JOBoXVBrpztBlMxemyrpuv6gltXmG/l aU13gG3G6rWMQ5T/tI2iTafU0gsmFMocGicbJP5FzQAAAAAAAA== --------------ms060608010506000705050006-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 12:58:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05662 for ; Thu, 30 Jan 2003 12:58:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UHfJV18036 for ietf-calendar-bks; Thu, 30 Jan 2003 09:41:19 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UHfHo18031 for ; Thu, 30 Jan 2003 09:41:17 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0UHf7hA003375 for ; Thu, 30 Jan 2003 09:41:08 -0800 Message-ID: <3E3963AD.5030209@Royer.com> Date: Thu, 30 Jan 2003 10:41:01 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP 10: alarm-seq References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080009090100040100080300" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080009090100040100080300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > I saw alarm-seq before but I never consciously grokd the addition of it > to VALARMs. I find no discussion of this in the WG archives. Prior to > CAP we sent all messages as full snapshots so we did not have to > consider just revising the VALARM (we would sequence the containing > VEVENT, etc instead and do whole substitutions). So now w/CAP we can > just modify the VALARM on any particular component. As such Doug > thoughtfully added alarm-seq to the spec. Please re-search the archives Bruce. This is over a YEAR old and was in several previous drafts. It is in the archives. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080009090100040100080300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMzAxNzQxMDFaMCMGCSqGSIb3DQEJBDEWBBSN kXA9xBasit44mgNJ9HgYPvev7jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAsgWoFKBLk+Qn 0PY8+pUlPjvltIK303bCwg2bW1YhhgNhF+Szb9L640ej30Tj6nqO9nIMQ4Z04BI8EvwEjud7 cE7ayp/DW7kcr3IVgSf3Nn4R23ldSidujmf/PT3PWW+vatq+FE5Gbyg5+uxp+3Cj+OLvo46D oMtAXGyBVbD+xL0H4BY+rwvb2rYmaC0kOITwJ38h8obevJzlJksPG8fXFpfAk0eTfAHHaaeb nDwYOURr6aOzKPcPZ0xbvcJ2YXs7tzIKHucyGTQS1UoaEWbtM2J/x+c/+72aDin1QCOeG9cQ g4z4BOTzk/ZdzyEJSoZjPn1dTC/LbsVk0PAlS2fQjAAAAAAAAA== --------------ms080009090100040100080300-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 14:57:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08813 for ; Thu, 30 Jan 2003 14:57:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UJkkO23535 for ietf-calendar-bks; Thu, 30 Jan 2003 11:46:46 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UJkjo23530 for ; Thu, 30 Jan 2003 11:46:45 -0800 (PST) In-Reply-To: <3E38556C.102@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 14:46:41 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 02:46:46 PM, Serialize complete at 01/30/2003 02:46:46 PM Content-Type: multipart/alternative; boundary="=_alternative 006C9BD185256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C9BD185256CBE_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 01/29/2003 05:27:56 PM: > It's a failsafe alarm that can be used by an application > to keep the connection from being held open ($$$) on a pay > by the minute cell phone. > > You get - time out - your app is dead and we did > a favor and closed the connection even > if that is not what you want. So essentially the app has to reset the alarm timer every time it gets data from the CS so that the timer does not consider the app dead when in fact its just waiting for the CS to return more data? If it does this then it still has no way to terminate the unbounded command on the CS short of actual disconnecting. Right? Also why wouldn't the Palm, or any CUA for that matter want the command on the CS to eventually time out? I can't think of any scenario where this is useful. Help me!... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006C9BD185256CBE_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 01/29/2003 05:27:56 PM:
> It's a failsafe alarm that can be used by an application
> to keep the connection from being held open ($$$) on a pay
> by the minute cell phone.
>
> You get -  time out - your app is dead and we did
>             a favor and closed the connection even
>             if that is not what you want.
So essentially the app has to reset the alarm timer every time it gets data from the CS so that the timer does not consider the app dead when in fact its just waiting for the CS to return more data?  If it does this then it still has no way to terminate the unbounded command on the CS short of actual disconnecting.  Right?

Also why wouldn't the Palm, or any CUA for that matter want the command on the CS to eventually time out?  I can't think of any scenario where this is useful.  Help me!...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006C9BD185256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 14:58:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08887 for ; Thu, 30 Jan 2003 14:58:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UJfTS23367 for ietf-calendar-bks; Thu, 30 Jan 2003 11:41:29 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UJfSo23363 for ; Thu, 30 Jan 2003 11:41:28 -0800 (PST) In-Reply-To: <20030129170600.GD81678@inet.it> To: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 14:41:24 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 02:41:30 PM, Serialize complete at 01/30/2003 02:41:30 PM Content-Type: multipart/alternative; boundary="=_alternative 006C1FCB85256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C1FCB85256CBE_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 01/29/2003 12:06:00 PM: > So basically, there's no need for ordering anywhere, right? I'm > all for removing the requirement then. Anyone not agree?? > But let me insist: we need to clarify how should multiple VQUERY > (or multiple QUERY properties) behave. A very good idea but I thought it was covered (in the non-overlapping cases) in Subsections 6.1.1.[15-18]. Although as I revisit this area I see that no text clearly indicates the kind for responses that would be generated for the example querys. I could guess at the responses given the text under the DELETE command (see next bits). > There is more to this than > SEARCH, since VQUERY are used all over. In addition to the basic > question (that I think I've asked many times), there's the issue > of the same component matching more than once. There is text for the DELETE command already and I think thats what you had in mind at one point: There MUST BE one "VREPLY" component returned for each object that is deleted or marked for delete. So if Im deleting multiple VEVENTs or VTODOs then I should get back 1 delete-vreply per deleted entry. They can be in all in 1 delete-reply OR in any number of delete-replys (as long as there is at least 1 delete-vreply in each delete-reply). I havent spent a lot of cycles on it but why can't this apply to all commands too? A spot check of a couple other commands reveals no similar text for them. Perhaps thats what we need... > Example: > > BEGIN:VCOMPONENT > CMD:DELETE > BEGIN:VQUERY > QUERY:SELECT * FROM VEVENT WHERE DTSTART > '20030101' > END:VQUERY > BEGIN:VQUERY > QUERY:SELECT * FROM VEVENT WHERE LOCATION = 'Milan, Italy' > END:VQUERY > END:VCOMPONENT Ok, this effectively does 2 sets of DELETEs in 1 transaction. Not sure that this is a normal CU action but its possible (though I am curious to see what UI can manage this cleanly) given our current design. The design also permits 2 VQUERYs that select from different components (ie: the 1st is VEVENT and the 2nd could be for VTODOs). What a tangled web we weave... > Should this return: > > 1 - all results for both in one VREPLY Not cool. There should not be 2 UID properties in a single VREPLY component. This also violates the cited text above. > 2 - one VREPLY per query Better in that no duplicate UIDs happen. It also violates the cited text above. > 3 - one VCALENDAR per query Overload... Ugh! > 4 - undefined Not cool either. What happend to just getting back 1 delete-vreply (VREPLY) per matching entry? These VREPLYs can be in any number of VCALENDARsn as long as there is at least 1 VREPLY per VCALENDAR. This does NOT preclude sending back ALL the VREPLYs in 1 VCALENDAR. There is also nothing in the draft that prevents sending back 1 VREPLY per VCALENDAR and sending back 1 per matching entry. Recheck the ABNF for delete-reply. > Now what happens if the query matched the same component? Do we > return it in both replies or in one (which one)? IMHO: The responses should (MUST?) be per unique matching entity. One could say that its dependent on the internal CS design on how operations are sequenced. If the deletes happened serially then there is no way for the 2nd to 'reDELETE' a match from the first set is there? If they happen concurrently then its possible that you'd get back 2 VREPLYs that indicate deletion (unless you actually semaphored your container pool so that you dont get contention issues!! Hint, hint...). However concurrent operations on the same data set can be dangerous (esp. if the operations are different like DELETE and MODIFY) so Id guess that most CS implementations would serialize them. Still, its kinda dumb in my mind to indicate that something got deleted twice (or more really) by a single command... My preference is that we get back 1 XXX-reply per unique affected component so 1 delete-vreply per UID in the case of of the DELETE command no matter how many VQUERYs or QUERYs match it. I have a mild aversion to the idea of returning multiple delete-vreplys per matching entity because it serves no purpose to tell the CUA "I deleted the VEVENT with UID:EVENT1. Oh yeah, I deleted the VEVENT with UID:EVENT1 (again)." Does it serve any real purpose? You really cant doubly delete it can you? Try changing the command to be a another command like, say, SEARCH and see if the logic still holds. The CUA asked for VEVENTs that match a couple sets of criteria. Would it make any sense to return 2 copies of the same VEVENT?? I dont think so. > That's my main reason for choosing #1. I dont like your #1 because it does not conform to current practices of a single UID per component. Besides, your #1 does not address the "issue of the same component matching more than once." > After all, if we wanted to > separate the answers, we wouldn't send them in one query, right? I still wonder how realistic this example is but it is possible... I think that if we restrict the XXX-reply responses to be per unique matching entity no matter the command then that should answer your questions. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006C1FCB85256CBE_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 01/29/2003 12:06:00 PM:
> So basically, there's no need for ordering anywhere, right? I'm
> all for removing the requirement then.
Anyone not agree??

> But let me insist: we need to clarify how should multiple VQUERY
> (or multiple QUERY properties) behave.

A very good idea but I thought it was covered (in the non-overlapping cases) in Subsections 6.1.1.[15-18].  Although as I revisit this area I see that no text clearly indicates the kind for responses that would be generated for the example querys.  I could guess at the responses given the text under the DELETE command (see next bits).

>                                         There is more to this than
> SEARCH, since VQUERY are used all over. In addition to the basic
> question (that I think I've asked many times), there's the issue
> of the same component matching more than once.
There is text for the DELETE command already and I think thats what you had in mind at one point:

There MUST BE one "VREPLY" component returned for each object that is deleted or marked for delete.

So if Im deleting multiple VEVENTs or VTODOs then I should get back 1 delete-vreply per deleted entry.  They can be in all in 1 delete-reply OR in any number of delete-replys (as long as there is at least 1 delete-vreply in each delete-reply).  

I havent spent a lot of cycles on it but why can't this apply to all commands too?  A spot check of a couple other commands reveals no similar text for them.  Perhaps thats what we need...

> Example:
>
> BEGIN:VCOMPONENT
> CMD:DELETE
> BEGIN:VQUERY
> QUERY:SELECT * FROM VEVENT WHERE DTSTART > '20030101'
> END:VQUERY
> BEGIN:VQUERY
> QUERY:SELECT * FROM VEVENT WHERE LOCATION = 'Milan, Italy'
> END:VQUERY
> END:VCOMPONENT
Ok, this effectively does 2 sets of DELETEs in 1 transaction.  Not sure that this is a normal CU action but its possible (though I am curious to see what UI can manage this cleanly) given our current design.  The design also permits 2 VQUERYs that select from different components (ie: the 1st is VEVENT and the 2nd could be for VTODOs).  What a tangled web we weave...

> Should this return:
>
> 1 - all results for both in one VREPLY
Not cool.  There should not be 2 UID properties in a single VREPLY component.  This also violates the cited text above.

> 2 - one VREPLY per query
Better in that no duplicate UIDs happen.   It also violates the cited text above.

> 3 - one VCALENDAR per query
Overload...  Ugh!

> 4 - undefined
Not cool either.

What happend to just getting back 1 delete-vreply (VREPLY) per matching entry?  These VREPLYs can be in any number of VCALENDARsn as long as there is at least 1 VREPLY  per VCALENDAR.  This does NOT preclude sending back ALL the VREPLYs in 1 VCALENDAR.  There is also nothing in the draft that prevents sending back 1 VREPLY per VCALENDAR and sending back 1 per matching entry.  Recheck the ABNF for delete-reply.

> Now what happens if the query matched the same component? Do we
> return it in both replies or in one (which one)?
IMHO: The responses should (MUST?) be per unique matching entity.  

One could say that its dependent on the internal CS design on how operations are sequenced.  If the deletes happened serially then there is no way for the 2nd to 'reDELETE' a match from the first set is there?  If they happen concurrently then its possible that you'd get back 2 VREPLYs that indicate deletion (unless you actually semaphored your container pool so that you dont get contention issues!!  Hint, hint...).  However concurrent operations on the same data set can be dangerous (esp. if the operations are different like DELETE and MODIFY) so Id guess that most CS implementations would serialize them.  Still, its kinda dumb in my mind to indicate that something got deleted twice (or more really) by a single command...

My preference is that we get back 1 XXX-reply per unique affected component so 1 delete-vreply per UID in the case of of the DELETE command no matter how many VQUERYs or QUERYs match it.  

I have a mild aversion to the idea of returning multiple delete-vreplys per matching entity because it serves no purpose to tell the CUA "I deleted the VEVENT with UID:EVENT1.  Oh yeah, I deleted the VEVENT with UID:EVENT1 (again)."  Does it serve any real purpose?  You really cant doubly delete it can you?

Try changing the command to be a another command like, say, SEARCH and see if the logic still holds.  The CUA asked for VEVENTs that match a couple sets of criteria.  Would it make any sense to return 2 copies of the same VEVENT??  I dont think so.

> That's my main reason for choosing #1.

I dont like your #1 because it does not conform to current practices of a single UID per component.   Besides, your #1 does not address the "issue of the same component matching more than once."

>                                         After all, if we wanted to
> separate the answers, we wouldn't send them in one query, right?
I still wonder how realistic this example is but it is possible...

I think that if we restrict the XXX-reply responses to be per unique matching entity no matter the command then that should answer your questions.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006C1FCB85256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 15:14:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09258 for ; Thu, 30 Jan 2003 15:14:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UK4I424066 for ietf-calendar-bks; Thu, 30 Jan 2003 12:04:18 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UK4Go24062 for ; Thu, 30 Jan 2003 12:04:17 -0800 (PST) In-Reply-To: <200301292304.h0TN4LBH023059@smtp7.andrew.cmu.edu> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 15:04:14 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 03:04:18 PM, Serialize complete at 01/30/2003 03:04:18 PM Content-Type: multipart/alternative; boundary="=_alternative 006E36F985256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E36F985256CBE_= Content-Type: text/plain; charset="US-ASCII" Larry noted on 01/29/2003 06:04:21 PM: > Establishing connections really isn't that costly if it's only > going to happen to what should be "rare" circumstances. Disconnecting and restablishing a connection (and thus reauthentication, etc) is much more costly than being able to simply abort the command on an existing connection. Then again unbounded commands should be rare if not useless in our world view... What is a good justification for having a command that is unbounded in how long it can take AND has no means for aborting or cancelling it short of actual disconnection from the CS? Getting my head around that would make swallowing this much easier... > The addition of "cancel" and "bounded latency" commands are more > complicated than what's present in CAP's peer protocols (SMTP, IMAP, > LDAP, for instance). Adding a CANCEL command does not at first glance appear to be that hard really. It could be as simple as using BEEP channel 0 to send a CANCEL command with some info needed like the BEEP channel to cancel on. We could include info like the CMDID to uniquely identify the command w/in that channel if we had to. Still, why invent more stuff if unbounded commands do not make sense given our current model?... Or if we are going to keep unbounded commands then we really should expreslly codify the way that a CUA terminates them so we have consistant behaviour among all implementations. I can go with the crowd on most any solution here as long as I can at least see the rationale for the answer... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006E36F985256CBE_= Content-Type: text/html; charset="US-ASCII"
Larry noted on 01/29/2003 06:04:21 PM:
>       Establishing connections really isn't that costly if it's only
> going to happen to what should be "rare" circumstances.
Disconnecting and restablishing a connection (and thus reauthentication, etc) is much more costly than being able to simply abort the command on an existing connection.   Then again unbounded commands should be rare if not useless in our world view...

What is a good justification for having a command that is unbounded in how long it can take AND has no means for aborting or cancelling it short of actual disconnection from the CS?  Getting my head around that would make swallowing this much easier...

> The addition of "cancel" and "bounded latency" commands are more
> complicated than what's present in CAP's peer protocols (SMTP, IMAP,
> LDAP, for instance).
Adding a CANCEL command does not at first glance appear to be that hard really.  It could be as simple as using BEEP channel 0 to send a CANCEL command with some info needed like the BEEP channel to cancel on.  We could include info like the CMDID to uniquely identify the command w/in that channel if we had to.

Still, why invent more stuff if unbounded commands do not make sense given our current model?...  Or if we are going to keep unbounded commands then we really should expreslly codify the way that a CUA terminates them so we have consistant behaviour among all implementations.

I can go with the crowd on most any solution here as long as I can at least see the rationale for the answer...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006E36F985256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 15:32:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09823 for ; Thu, 30 Jan 2003 15:32:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UKJ1F24611 for ietf-calendar-bks; Thu, 30 Jan 2003 12:19:01 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UKIxo24603 for ; Thu, 30 Jan 2003 12:18:59 -0800 (PST) In-Reply-To: <20030130092309.GE81678@inet.it> To: ietf-calendar@imc.org Subject: Re: STORES-EXPANDED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 15:18:51 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 03:18:59 PM, Serialize complete at 01/30/2003 03:18:59 PM Content-Type: multipart/alternative; boundary="=_alternative 006F8D9385256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F8D9385256CBE_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 01/30/2003 04:23:09 AM: > Well, a CS is still a CS even if both parties are CS's ;-) So both sides should return STORES-EXPANDED properties in their GET-CAPABILITYs response packet then... :^b > In addition, in > a CS<->CS synx situation we might have no way of knowing which one is the > sender, if they are doing bidirectional replication they might be both > senders and receivers at the same time. When I referred to sender/reciever I was referring to the role in the sense of the GET-CAPABILITY command. That is, CS1 is the sender when it sends the GET-CAPABILITY to CS2 (which is the receiver then). When CS2 turns around and sends a GET-CAPABILITY command then its the 'sender' and CS1 is the 'receiver'. In both cases a STORES-EXPANDED property should be sent. > > For a CUA<-CS connection this property may not be that useful. Its more > > useful in the CUA->CS case or the CS<->CS case (where sync/replication > > come into play). Is there any reason that the CS would need to know if > > My point really. I did not say it was useless. There is such a concept as "server push" where the CS initiates the connection/action to the CUA (using our terms instead of Client/Server really). Examples could be a company who wants/needs to push updates down to the desktop such as company wide events, site specific events, work assignments from centralized call systems (ie: assigning TODOs from a central site in a timely manner), etc. Since the CS is going to push data to the CUA it may need to know the CUAs capabilities so it can properly poll back later for status changes, etc. ("What is the status of VTODO with UID:Customer1.Job32?", "We have more details about the assigned task to push down to the CUA so we need to know to send it." etc). Pardon me now while I go and code this up for IBM... %^} > I'm not sure I follow you wrt CUA<->CS sync/replication; do you > mean something like a CUA which downloads one or more VAGENDAS, allows > you to work disconnected, then syncs back to the CS when you > reconnect? If so, yes I think I see your point. So you can see where a CUA could send that info then to the CS. Thus it is not just a "the CS" property... All properties returned by GET-CAPABILITY should be generically described and not tied to "the CS" or "the CUA". Thats all Ive been trying to get across... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F8D9385256CBE_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 01/30/2003 04:23:09 AM:
> Well, a CS is still a CS even if both parties are CS's ;-)

So both sides should return STORES-EXPANDED properties in their GET-CAPABILITYs response packet then... :^b

>                                                            In addition, in
> a CS<->CS synx situation we might have no way of knowing which one is the
> sender, if they are doing bidirectional replication they might be both
> senders and receivers at the same time.
When I referred to sender/reciever I was referring to the role in the sense of the GET-CAPABILITY command.  That is, CS1 is the sender when it sends the GET-CAPABILITY to CS2 (which is the receiver then).  When CS2 turns around and sends a GET-CAPABILITY command then its the 'sender' and CS1 is the 'receiver'.  In both cases a STORES-EXPANDED property should be sent.

> > For a CUA<-CS connection this property may not be that useful.  Its more
> > useful in the CUA->CS case or the CS<->CS case (where sync/replication
> > come into play).  Is there any reason that the CS would need to know if
>
> My point really.
I did not say it was useless.  There is such a concept as "server push" where the CS initiates the connection/action to the CUA (using our terms instead of Client/Server really).  Examples could be a company who wants/needs to push updates down to the desktop such as company wide events, site specific events, work assignments from centralized call systems (ie: assigning TODOs from a central site in a timely manner), etc.

Since the CS is going to push data to the CUA it may need to know the CUAs capabilities so it can properly poll back later for status changes, etc. ("What is the status of VTODO with UID:Customer1.Job32?", "We have more details about the assigned task to push down to the CUA so we need to know to send it." etc).

Pardon me now while I go and code this up for IBM... %^}

> I'm not sure I follow you wrt CUA<->CS sync/replication; do you
> mean something like a CUA which downloads one or more VAGENDAS, allows
> you to work disconnected, then syncs back to the CS when you
> reconnect? If so, yes I think I see your point.
So you can see where a CUA could send that info then to the CS.  Thus it is not just a "the CS" property...   All properties returned by GET-CAPABILITY should be generically described and not tied to "the CS" or "the CUA".  Thats all Ive been trying to get across...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006F8D9385256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 15:33:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09849 for ; Thu, 30 Jan 2003 15:33:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UKRAX24907 for ietf-calendar-bks; Thu, 30 Jan 2003 12:27:10 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UKR9o24903 for ; Thu, 30 Jan 2003 12:27:10 -0800 (PST) In-Reply-To: <20030130111346.GG81678@inet.it> To: ietf-calendar@imc.org Subject: Re: Summary of thread: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 15:27:02 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 03:27:09 PM, Serialize complete at 01/30/2003 03:27:09 PM Content-Type: multipart/alternative; boundary="=_alternative 00704D4985256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00704D4985256CBE_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 01/30/2003 06:13:46 AM: > See my message with Message-ID <20030124093656.GB70430@inet.it> for an > example of why I think we need some kind of atomicity, or transactions. > Did you miss it or did you find it irrelevant? I missed it. Its in my archive but its flagged as unread so I must have overlooked it somehow. Ill go take a gander at it now... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00704D4985256CBE_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 01/30/2003 06:13:46 AM:
> See my message with Message-ID <20030124093656.GB70430@inet.it> for an
> example of why I think we need some kind of atomicity, or transactions.
> Did you miss it or did you find it irrelevant?
I missed it.  Its in my archive but its flagged as unread so I must have overlooked it somehow.  Ill go take a gander at it now...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00704D4985256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 15:35:32 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09901 for ; Thu, 30 Jan 2003 15:35:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UKT0W24950 for ietf-calendar-bks; Thu, 30 Jan 2003 12:29:00 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UKSwo24946 for ; Thu, 30 Jan 2003 12:28:58 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0UKSxhA004681 for ; Thu, 30 Jan 2003 12:29:00 -0800 Message-ID: <3E398B06.7090401@Royer.com> Date: Thu, 30 Jan 2003 13:28:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: CREATE Command and ordering of responses. References: <20030123163504.GA65203@inet.it> <127.0.0.1+J2ncjTQM4d30yO2ighXq2b@space1.inet.it> <20030129170600.GD81678@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070806000607080900060404" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070806000607080900060404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > On Mon, Jan 27, 2003 at 02:26:12PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > >>Andrea replied on 01/23/2003 11:35:04 AM: >> >>>By the way, this same argument holds for VQUERY with multiple QUERY >>>properties: see 6.1.1 item 5. >> >>Yes, thanks you. >> >> >>>OTOH and for completeness sake: we can't take your argument to the >>>extreme, in some cases we do need to mandate ordering. See results >>>for CREATE - if results aren't in the same order as the components, >>>the CUA won't be able to correlate them. >> >>Huh?? Sure it can. From the draft-10 12-Jan-2003: > > > Sorry, you're right. I was thinking of the MUST from the draft. > > So basically, there's no need for ordering anywhere, right? I'm > all for removing the requirement then. > > But let me insist: we need to clarify how should multiple VQUERY > (or multiple QUERY properties) behave. There is more to this than > SEARCH, since VQUERY are used all over. In addition to the basic > question (that I think I've asked many times), there's the issue > of the same component matching more than once. As we are not doing transactions there can not be more than one match in your example provided. Once it is deleted by the 1st QUERY it could not have existed for the 2nd QUERY to match. (no matter which one of them you process 1st). And even with transactions it will not be possible to delete the same item more than once so it would not be listed more than once. The above facts are valid no matter what kind of database your CS uses. Had the 2nd query specifically listed a UID that was deleted by the 1st, then the 2nd would return an error. For QUERYs that are not deletes I would say return each VREPLY that matches the supplied QUERY value. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070806000607080900060404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMzAyMDI4NTRaMCMGCSqGSIb3DQEJBDEWBBSB v/ffKEQq1DETnxJ6VlYER5uFtTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAGrugNnlT7gcM EYjDCop5nMD/lsK6pWa/ZhnV8/83099WFh+uu6c+lP4cFCwGZoHXLAaG1nwG2IniX2QwICUN UuCd+18rTvFZ9pj7UgduV9nLrFfA39y3a6jNxDxk6/91ISofSw6xPw2HISMRAvJPYFO0yXYA lNjgBKXn26LO5LrTYr/KMyhkyIIORFj635aZCKfAlZzhL5gESjeVE25geeeOlrcj1joSSpi3 0dOsyfLM84eSOiR4evpFJdVJAEWE88ja4KHX6a/3ULQEviwQhAtr2XzahGPt2wTKIsUqq6Gj +tTTAVEP6IfF8e8ZIFAI/KKvu6Yxzyu348vLbxN90QAAAAAAAA== --------------ms070806000607080900060404-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 16:04:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10410 for ; Thu, 30 Jan 2003 16:04:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UKucD25732 for ietf-calendar-bks; Thu, 30 Jan 2003 12:56:38 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UKubo25728 for ; Thu, 30 Jan 2003 12:56:37 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id h0UKubQ9002466; Thu, 30 Jan 2003 15:56:37 -0500 Date: Thu, 30 Jan 2003 15:56:37 -0500 Message-Id: <200301302056.h0UKubQ9002466@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: ietf-calendar@imc.org, Bruce_Kahn@notesdev.ibm.com In-reply-to: Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 15:04:14 -0500 [...] What is a good justification for having a command that is unbounded in how long it can take AND has no means for aborting or cancelling it short of actual disconnection from the CS? Getting my head around that would make swallowing this much easier... It simplifies implementations. (You do want people to implement this, right?) What happens if you submit a bounded command (3 seconds, say), wait 3 seconds, and the server doesn't come back? What if it doesn't come back in 30 seconds? What if you submit an unbounded command, wait 1 second, submit a CANCEL, and the server still hasn't replied in 30 seconds? What if the network is down or tremendously slow? [...] Still, why invent more stuff if unbounded commands do not make sense given our current model?... Or if we are going to keep unbounded commands then we really should expreslly codify the way that a CUA terminates them so we have consistant behaviour among all implementations. How am I, as a client, suppose to know how long something is going to take the server? Maybe the server is really loaded. Maybe it affects a lot of data on the server. The last thing I want, as a server, is for clients to try an operation for 5 seconds, then try it for 10, then 20, etc., until it's done. Larry From owner-ietf-calendar@mail.imc.org Thu Jan 30 16:44:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11261 for ; Thu, 30 Jan 2003 16:44:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ULcFs26953 for ietf-calendar-bks; Thu, 30 Jan 2003 13:38:15 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ULcDo26949 for ; Thu, 30 Jan 2003 13:38:13 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 30 Jan 2003 16:38:08 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/30/2003 04:38:10 PM, Serialize complete at 01/30/2003 04:38:10 PM Content-Type: multipart/alternative; boundary="=_alternative 0076CFAA85256CBE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076CFAA85256CBE_= Content-Type: text/plain; charset="US-ASCII" CAVEAT: This may appear very long but you can just skip over the example data if you want to get to the discussion bits at the bottom. /CAVEAT Andrea wrote on 01/24/2003 10:36:56 AM CET: > On Thu, Jan 23, 2003 at 03:43:40PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > > expected. (After all a VREPLY with a success response was already sent > > back). I for one do not think that mandating a CS essentially be built > > Sorry? You mean, if the command succeeds for one target and fails > for another one, right? Sure. From Section 10.1.15 DELETE command I grok: There MUST BE one "VREPLY" component returned for each object that is deleted or marked for delete. and the ABNF of: delete-reply = "BEGIN" ":" "VCALENDAR" CRLF calprops ; MUST include 'reply-cmd' 1*(delete-vreply) "END" ":" "VCALENDAR" CRLF so the DELETE command: BEGIN:VCALENDAR CMD;ID:"random but unique per CUA":DELETE TARGET:work TARGET:personal BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE .... END:VQUERY END:VCALENDAR would result in responses like: BEGIN:VCALENAR TARGET:work CMD;ID:"random but unique per CUA":REPLY BEGIN:VREPLY UID:abcd12345 REQUEST-STATUS:2.0 END:VREPLY BEGIN:VREPLY UID:abcd67890 REQUEST-STATUS:2.0 END:VREPLY END:VCALENDAR [Some pause here...] BEGIN:VCALENAR TARGET:personal CMD;ID:"random but unique per CUA":REPLY BEGIN:VREPLY UID:1234567890 REQUEST-STATUS:2.0 BEGIN:VREPLY UID:abcd12345 REQUEST-STATUS:2.0 END:VREPLY END:VCALENDAR [Another pause...] BEGIN:VCALENAR TARGET:work CMD;ID:"random but unique per CUA":REPLY BEGIN:VREPLY UID:0987654321 REQUEST-STATUS:4.0 END:VREPLY END:VCALENDAR BEGIN:VCALENAR TARGET:personal CMD;ID:"random but unique per CUA":REPLY BEGIN:VREPLY UID:qwerty01 REQUEST-STATUS:2.0 END:VREPLY END:VCALENDAR All of the DELETEs worked except the one for UID:0987654321 in TARGET:work which failed with a REQUEST-STATUS:4.0. (made up value for demonstation purposes only). Why should the previously successful DELETEs be undeleted because of an unrelated failure?? It makes no sense to me. > But in any case, that's an implementation > detail - you can't assume anything about when exactly the VREPLY > gets sent. No. A CS could craft and send VREPLYs as it goes or it can craft and queue them for sending when its done or it could craft VREPLYs and cache them into a buffer and only send when the cache got full or... We never mandated either way. Does it really matter?? I would expect that a CS would send results in a manner other than "hold all results until the command is done." since we have bounded latency on commands to factor in but thats just my philosophy... > That's what worries me more about the protocol specification: > if my CUA sends a command with multiple TARGETs, there's not telling > whether the response will be one RPY or multiple ANS, whether any > of them will be a complete VCALENDAR component, which of them > contains the reponse for which TARGET, and so on - not until it > parses everything. There are so many ways of doing the same thing! If matching the responses to each TARGET is important to you then you'd probably want to use separate DELETE commands with single TARGETs in them (on different channels even). Is it critical for you to tell when the DELETE command is done per TARGET? Are you displaying some kind of progress bar for each TARGET concurrently that you want to update the bar? The VREPLYs are not that big nor complex (just the UID and REQUEST-STATUS really) so its not that difficult to quickly parse 'em and match them to the proper TARGET. If ordering by TARGET is important to you then Id say that concurrent DELETEs on separate channels is the way you would probably want to go. Or am I missing the root of the concern here? > Anyway, back to the discussion. You still assume it IS meaningful > to assume commands are not atomic; I contend that the CS simply > has no way of knowing. Compare the following: Not quite. I think that atomicity of the command varys with the command. For example, a DELETE of a VEVENT in 1 VAGENDA succeeds and a positive VREPLY is sent back. Then the attempted deletion of a different VEVENT fails. Why should this make the first success now a failure?? A MOVE is slightly different in that it involves essentially a CREATE and then a DELETE and both must succeed for a single success VREPLY to be sent. Again though the command scopped to the effected component, NOT to the TARGET or the entire command. > - delete every components more than a year old on both of my VAGENDAs > > BEGIN:VCALENDAR > CMD:DELETE > TARGET:work > TARGET:personal > BEGIN:VQUERY > QUERY:SELECT * FROM VEVENT WHERE .... > QUERY:SELECT * FROM VTODO WHERE .... > END:VQUERY > END:VCALENDAR See my example at top... > - propose two different but related meetings, book it on my VAGENDA > > BEGIN:VCALENDAR > CMD:CREATE > TARGET:attendee1 > TARGET:attendee2 > TARGET:attendee3 > METHOD:REQUEST > BEGIN:VEVENT > ... > END:VEVENT > BEGIN:VEVENT > ... > END:VEVENT > END:VCALENDAR > BEGIN:VCALENDAR > CMD:CREATE > TARGET:work > BEGIN:VEVENT > ... > END:VEVENT > BEGIN:VEVENT > ... > END:VEVENT > END:VCALENDAR Umm, Ill assume each has a separate CMDID... > I can agree #1 doesn't need to be atomic - if I get any failure > I can simply retry. Thats a start toward full agreement... ;^) > In case #2, I would actually love to be able to perform both CREATE > as a single atomic transaction. Unfortunately, there's no way I > can do that. Nope. The act of creating the 2 entries on your calendar should happen first. Otherwise you've sent out invitations to something that isn't on your calendar and thus any responses you get back from the invitees wont be able to matchable to where they should go. Once you have the entries on your calendar you can then send out the invitations to other folks. No safe way around this problem unless your design allows you to retract sent messages (like unsending that nasty gram to your boss after you decide NOT to quit...). You'd also need to factor in that you may not have sufficient rights to delete the invitations, etc (nasty thing VCARs)... For CREATE it could easily be argued that ALL contained components MUST be successfully created or all fail (but it would be on a per TARGET basis!). I could also see sending back a success VREPLY and a failure VREPLY for your example too. We just need to reach a concensus on behaviour and clearly spell it out on a per command basis. (I will strongly resist deletions being "All or nothing" no matter the approach used for reasons already given.) > Failing that, I surely want each CREATE to be an atomic transaction. > What if there is an error, any kind of error, on one out of three > VAGENDAs? Yeah, so? The 1st and 2nd VAGENDAs allow you write permission so you can CREATE the invitation. The 3rd does not (what a weenie for not wanting me to access their calendar!). So does that mean that you were unable to invite the first 2 people? Certainly not. Does that mean the entire CREATE command should be failed? Nope. > If the CUA wants to retry it would need to either rollback > (via DELETE), What are you going to DELETE? If you could not CREATE the invitation then you certainly cant DELETE it can you? Then you also have to factor in VCARs that allow you to only write to the VAGENDA but not remove from it. How you gonna deal with that? Does failing to invite #3 mean you have to uninvite the others? I dont think so. It just means you have to try again to invite #3... > or change the original command to eliminate for TARGETs > it already succeeded. Why?? Just because you cant invite one person does not mean that you have to uninvite the others does it?? I just cant make that connection in my mind... > And in case the error is non transient and > CU intervention is required, it needs to either remember this. Thats outside the scope of the CAP commands though. A good thing to remember for later though. > Couple this with the effective impossibility for a CUA to know > whether it has permission to store into a TARGET (without retrieving > the VCARs and trying to determine that by itself, that is). The REQUEST-STATUS for the grouch TARGET _SHOULD_ provide some indication like this. I see REQUEST-STATUS:6.4 in the CAP draft matches this just nicely... > Look, I can see your point, but I see no reason why unreasonably > simplistic implementations should effectively crimple the ability > to have elegant and efficient implementations. It's not like we don't > have free RDBMS after all... Some actions CANNOT be just crammed into one massive command and treated like a Hail Mary operation. See the example above about first sending invitations without first having the entry on your own VAGENDA as a good example why not. Most vendors have some kind RDBMS handy (anyone for SQL and SQL.Slammer in the calendar? ;^]) but not everyone does and it makes building Open Source or lightweight servers impossible. The entire thread was focused on controlling run amok commands based on bad inputs but it had some bad prose on it. Ive proposed an alternative so that we do not _mandate_ RDBMS in every CS. (You got an RDBMS that fits in a Palm so it can be a CS??) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0076CFAA85256CBE_= Content-Type: text/html; charset="US-ASCII"
CAVEAT: This may appear very long but you can just skip over the example data if you want to get to the discussion bits at the bottom. /CAVEAT

Andrea wrote on 01/24/2003 10:36:56 AM CET:
> On Thu, Jan 23, 2003 at 03:43:40PM -0500, Bruce_Kahn@notesdev.ibm.com wrote:
> > expected.  (After all a VREPLY with a success response was already sent
> > back).  I for one do not think that mandating a CS essentially be built
>
> Sorry? You mean, if the command succeeds for one target and fails
> for another one, right?

Sure.  From Section 10.1.15 DELETE command I grok:

There MUST BE one "VREPLY" component returned for each object that is deleted or marked for delete.

and the ABNF of:

delete-reply   = "BEGIN" ":" "VCALENDAR" CRLF
                calprops   ; MUST include 'reply-cmd'
                1*(delete-vreply)
                "END" ":" "VCALENDAR" CRLF
so the DELETE command:

BEGIN:VCALENDAR
CMD;ID:"random but unique per CUA":DELETE
TARGET:work
TARGET:personal
BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE ....
END:VQUERY
END:VCALENDAR
would result in responses like:

BEGIN:VCALENAR
TARGET:work
CMD;ID:"random but unique per CUA":REPLY
BEGIN:VREPLY
UID:abcd12345
REQUEST-STATUS:2.0
END:VREPLY
BEGIN:VREPLY
UID:abcd67890
REQUEST-STATUS:2.0
END:VREPLY
END:VCALENDAR
[Some pause here...]
BEGIN:VCALENAR
TARGET:personal
CMD;ID:"random but unique per CUA":REPLY
BEGIN:VREPLY
UID:1234567890
REQUEST-STATUS:2.0
BEGIN:VREPLY
UID:abcd12345
REQUEST-STATUS:2.0
END:VREPLY
END:VCALENDAR
[Another pause...]
BEGIN:VCALENAR
TARGET:work
CMD;ID:"random but unique per CUA":REPLY
BEGIN:VREPLY
UID:0987654321
REQUEST-STATUS:4.0
END:VREPLY
END:VCALENDAR
BEGIN:VCALENAR
TARGET:personal
CMD;ID:"random but unique per CUA":REPLY
BEGIN:VREPLY
UID:qwerty01
REQUEST-STATUS:2.0
END:VREPLY
END:VCALENDAR
All of the DELETEs worked except the one for UID:0987654321 in TARGET:work which failed with a REQUEST-STATUS:4.0. (made up value for demonstation purposes only).  Why should the previously successful DELETEs be undeleted because of an unrelated failure??  It makes no sense to me.

>                         But in any case, that's an implementation
> detail - you can't assume anything about when exactly the VREPLY
> gets sent.

No.  A CS could craft and send VREPLYs as it goes or it can craft and queue them for sending when its done or it could craft VREPLYs and cache them into a buffer and only send when the cache got full or...  We never mandated either way.  Does it really matter??

I would expect that a CS would send results in a manner other than "hold all results until the command is done." since we have bounded latency on commands to factor in but thats just my philosophy...

>             That's what worries me more about the protocol specification:
> if my CUA sends a command with multiple TARGETs, there's not telling
> whether the response will be one RPY or multiple ANS, whether any
> of them will be a complete VCALENDAR component, which of them
> contains the reponse for which TARGET, and so on - not until it
> parses everything. There are so many ways of doing the same thing!
If matching the responses to each TARGET is important to you then you'd probably want to use separate DELETE commands with single TARGETs in them (on different channels even).  Is it critical for you to tell when the DELETE command is done per TARGET?  Are you displaying some kind of progress bar for each TARGET concurrently that you want to update the bar?  The VREPLYs are not that big nor complex (just the UID and REQUEST-STATUS really) so its not that difficult to quickly parse 'em and match them to the proper TARGET.

If ordering by TARGET is important to you then Id say that concurrent DELETEs on separate channels is the way you would probably want to go.  Or am I missing the root of the concern here?

> Anyway, back to the discussion. You still assume it IS meaningful
> to assume commands are not atomic; I contend that the CS simply
> has no way of knowing. Compare the following:
Not quite.  I think that atomicity of the command varys with the command.  For example, a DELETE of a VEVENT in 1 VAGENDA succeeds and a positive VREPLY is sent back.  Then the attempted deletion of a different VEVENT fails.  Why should this make the first success now a failure??

A MOVE is slightly different in that it involves essentially a CREATE and then a DELETE and both must succeed for a single success VREPLY to be sent.  Again though the command scopped to the effected component, NOT to the TARGET or the entire command.

>  - delete every components more than a year old on both of my VAGENDAs
>
> BEGIN:VCALENDAR
> CMD:DELETE
> TARGET:work
> TARGET:personal
> BEGIN:VQUERY
> QUERY:SELECT * FROM VEVENT WHERE ....
> QUERY:SELECT * FROM VTODO WHERE ....
> END:VQUERY
> END:VCALENDAR
See my example at top...

>  - propose two different but related meetings, book it on my VAGENDA
>
> BEGIN:VCALENDAR
> CMD:CREATE
> TARGET:attendee1
> TARGET:attendee2
> TARGET:attendee3
> METHOD:REQUEST
> BEGIN:VEVENT
> ...
> END:VEVENT
> BEGIN:VEVENT
> ...
> END:VEVENT
> END:VCALENDAR
> BEGIN:VCALENDAR
> CMD:CREATE
> TARGET:work
> BEGIN:VEVENT
> ...
> END:VEVENT
> BEGIN:VEVENT
> ...
> END:VEVENT
> END:VCALENDAR
Umm, Ill assume each has a separate CMDID...

> I can agree #1 doesn't need to be atomic - if I get any failure
> I can simply retry.
Thats a start toward full agreement... ;^)

> In case #2, I would actually love to be able to perform both CREATE
> as a single atomic transaction. Unfortunately, there's no way I
> can do that.

Nope.  The act of creating the 2 entries on your calendar should happen first.  Otherwise you've sent out invitations to something that isn't on your calendar and thus any responses you get back from the invitees wont be able to matchable to where they should go.  Once you have the entries on your calendar you can then send out the invitations to other folks.  No safe way around this problem unless your design allows you to retract sent messages (like unsending that nasty gram to your boss after you decide NOT to quit...).  You'd also need to factor in that you may not have sufficient rights to delete the invitations, etc (nasty thing VCARs)...

For CREATE it could easily be argued that ALL contained components MUST be successfully created or all fail (but it would be on a per TARGET basis!).  I could also see sending back a success VREPLY and a failure VREPLY for your example too.  We just need to reach a concensus on behaviour and clearly spell it out on a per command basis.  (I will strongly resist deletions being "All or nothing" no matter the approach used for reasons already given.)

> Failing that, I surely want each CREATE to be an atomic transaction.
> What if there is an error, any kind of error, on one out of three
> VAGENDAs?

Yeah, so?  The 1st and 2nd VAGENDAs allow you write permission so you can CREATE the invitation.  The 3rd does not (what a weenie for not wanting me to access their calendar!).  So does that mean that you were unable to invite the first 2 people?  Certainly not.  Does that mean the entire CREATE command should be failed?  Nope.

>           If the CUA wants to retry it would need to either rollback
> (via DELETE),

What are you going to DELETE?  If you could not CREATE the invitation then you certainly cant DELETE it can you?  Then you also have to factor in VCARs that allow you to only write to the VAGENDA but not remove from it.  How you gonna deal with that?

Does failing to invite #3 mean you have to uninvite the others?  I dont think so.  It just means you have to try again to invite #3...

>               or change the original command to eliminate for TARGETs
> it already succeeded.

Why??  Just because you cant invite one person does not mean that you have to uninvite the others does it??  I just cant make that connection in my mind...

>                        And in case the error is non transient and
> CU intervention is required, it needs to either remember this.
Thats outside the scope of the CAP commands though.  A good thing to remember for later though.

> Couple this with the effective impossibility for a CUA to know
> whether it has permission to store into a TARGET (without retrieving
> the VCARs and trying to determine that by itself, that is).
The REQUEST-STATUS for the grouch TARGET _SHOULD_ provide some indication like this.  I see REQUEST-STATUS:6.4 in the CAP draft matches this just nicely...

> Look, I can see your point, but I see no reason why unreasonably
> simplistic implementations should effectively crimple the ability
> to have elegant and efficient implementations. It's not like we don't
> have free RDBMS after all...
Some actions CANNOT be just crammed into one massive command and treated like a Hail Mary operation.  See the example above about first sending invitations without first having the entry on your own VAGENDA as a good example why not.

Most vendors have some kind RDBMS handy (anyone for SQL and SQL.Slammer in the calendar? ;^]) but not everyone does and it makes building Open Source or lightweight servers impossible.  The entire thread was focused on controlling run amok commands based on bad inputs but it had some bad prose on it.  Ive proposed an alternative so that we do not _mandate_ RDBMS in every CS.  (You got an RDBMS that fits in a Palm so it can be a CS??)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0076CFAA85256CBE_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 30 18:09:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12922 for ; Thu, 30 Jan 2003 18:09:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UMthN29016 for ietf-calendar-bks; Thu, 30 Jan 2003 14:55:43 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UMtfo29012 for ; Thu, 30 Jan 2003 14:55:41 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h0UMtghA005834 for ; Thu, 30 Jan 2003 14:55:42 -0800 Message-ID: <3E39AD69.7030807@Royer.com> Date: Thu, 30 Jan 2003 15:55:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No partial success when it comes to deletion? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010603010207070204020207" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010603010207070204020207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > But in any case, that's an implementation > > detail - you can't assume anything about when exactly the VREPLY > > gets sent. > > No. A CS could craft and send VREPLYs as it goes or it can craft and > queue them for sending when its done or it could craft VREPLYs and cache > them into a buffer and only send when the cache got full or... We never > mandated either way. Does it really matter?? > > I would expect that a CS would send results in a manner other than "hold > all results until the command is done." since we have bounded latency on > commands to factor in but thats just my philosophy... I agree that both are valid. They could be sent as determined or held until the last and sent. And I agree that it does not matter. > > That's what worries me more about the protocol specification: > > if my CUA sends a command with multiple TARGETs, there's not telling > > whether the response will be one RPY or multiple ANS, whether any > > of them will be a complete VCALENDAR component, which of them > > contains the reponse for which TARGET, and so on - not until it > > parses everything. There are so many ways of doing the same thing! > > If matching the responses to each TARGET is important to you then you'd > probably want to use separate DELETE commands with single TARGETs in > them (on different channels even). Is it critical for you to tell when > the DELETE command is done per TARGET? Are you displaying some kind of > progress bar for each TARGET concurrently that you want to update the > bar? The VREPLYs are not that big nor complex (just the UID and > REQUEST-STATUS really) so its not that difficult to quickly parse 'em > and match them to the proper TARGET. I would agree with Bruce. Maybe there is something I am missing as I do not see that it would be difficult to match up the TARGETs to the replies. > > See my example at top... > > > - propose two different but related meetings, book it on my VAGENDA > > > > BEGIN:VCALENDAR > > CMD:CREATE > > TARGET:attendee1 > > TARGET:attendee2 > > TARGET:attendee3 > > METHOD:REQUEST > > BEGIN:VEVENT > > ... > > END:VEVENT > > BEGIN:VEVENT > > ... > > END:VEVENT > > END:VCALENDAR > > BEGIN:VCALENDAR > > CMD:CREATE > > TARGET:work > > BEGIN:VEVENT > > ... > > END:VEVENT > > BEGIN:VEVENT > > ... > > END:VEVENT > > END:VCALENDAR > > Umm, Ill assume each has a separate CMDID... > > > In case #2, I would actually love to be able to perform both CREATE > > as a single atomic transaction. Unfortunately, there's no way I > > can do that. > > Nope. The act of creating the 2 entries on your calendar should happen > first. Otherwise you've sent out invitations to something that isn't on > your calendar and thus any responses you get back from the invitees wont > be able to matchable to where they should go. Especially if they have a BOT doing work for them. Their BOT could reply and fail and cause all kinds of confusion. > ... > > For CREATE it could easily be argued that ALL contained components MUST > be successfully created or all fail (but it would be on a per TARGET > basis!). I could also see sending back a success VREPLY and a failure > VREPLY for your example too. We just need to reach a concensus on > behaviour and clearly spell it out on a per command basis. (I will > strongly resist deletions being "All or nothing" no matter the approach > used for reasons already given.) I agree that could be done on a per TARGET basis. However it is possible for one to fail and another to succeed within a single TARGET. I could allow you CREATE/REQUEST permission and disallow you CREATE/REPLY permission. So I think we are going the correct direction to just make each VREPLY independent of all others. Your point of if the CUA can not handle complex replies, then it better not send complex commands - (send one TARGET at a time). > > Failing that, I surely want each CREATE to be an atomic transaction. > > What if there is an error, any kind of error, on one out of three > > VAGENDAs? > > Yeah, so? The 1st and 2nd VAGENDAs allow you write permission so you > can CREATE the invitation. The 3rd does not (what a weenie for not > wanting me to access their calendar!). So does that mean that you were > unable to invite the first 2 people? Certainly not. Does that mean the > entire CREATE command should be failed? Nope. > > > If the CUA wants to retry it would need to either rollback > > (via DELETE), > > What are you going to DELETE? If you could not CREATE the invitation > then you certainly cant DELETE it can you? Then you also have to factor > in VCARs that allow you to only write to the VAGENDA but not remove from > it. How you gonna deal with that? This debate is one of the reasons we decided to defer transactions. Any transaction implementation will have to be a draft on its own and consider and explain all of these situations. > > > Look, I can see your point, but I see no reason why unreasonably > > simplistic implementations should effectively crimple the ability > > to have elegant and efficient implementations. It's not like we don't > > have free RDBMS after all... The issue to consider is that it will take more time to consider all of the interactions and the fact that we have moved forward with this entire list saying we are not doing transactions at this time in CAP. We can do transactions later. Allow the simplistic implementations to be released now (or soon), release CAP, and we can continue to expand CAP to allow transactions (and other things) later. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010603010207070204020207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMzAyMjU1MzdaMCMGCSqGSIb3DQEJBDEWBBRF WZfq6xOn2V1O9ILK0NbES5fo+zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAVwzy8IWGuadL vbopKNPPdSfqLkRDHaK1I4Az2LQVJce/WjhkWijlcwUYvx8MNfgCdZW86NvHPR6pZJbQACa4 3HUT0yREpq1rfFYuPsEL5ZJJs6X8Mz94znbnyPA5G11tkcA8XDt5ciY1hHPTDKeEdZ8lzZi8 hnxJz/NMVuADuUrwAT80Z3EatLVV1AtvCmGb7QHDg+nQzUrk4lmJdyMPqiLIWqByVG1E8fU3 R7LsLyIg7c7qoTqEENVDmKO3FhqfwRg5Lrj/4n8O7mSnZQ5AuTzo6e/Y96IXh7XoEqKqzuXY SBbp++pZA0ax17Z71tx0t35vTQB16SptZm7g/HToZQAAAAAAAA== --------------ms010603010207070204020207-- From owner-ietf-calendar@mail.imc.org Fri Jan 31 03:14:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01118 for ; Fri, 31 Jan 2003 03:14:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0V836h27068 for ietf-calendar-bks; Fri, 31 Jan 2003 00:03:06 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V833o27060 for ; Fri, 31 Jan 2003 00:03:04 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 524341554D; Fri, 31 Jan 2003 09:02:58 +0100 (CET) Date: Fri, 31 Jan 2003 09:02:58 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. Message-ID: <20030131080258.GA44085@inet.it> References: <20030129170600.GD81678@inet.it> <127.0.0.1+ja2SoRoWn7fnRa5BP98eaF@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+ja2SoRoWn7fnRa5BP98eaF@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jan 30, 2003 at 02:41:24PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > > But let me insist: we need to clarify how should multiple VQUERY > > (or multiple QUERY properties) behave. > A very good idea but I thought it was covered (in the non-overlapping > cases) in Subsections 6.1.1.[15-18]. Although as I revisit this area I > > There is more to this than > > SEARCH, since VQUERY are used all over. In addition to the basic > > question (that I think I've asked many times), there's the issue > > of the same component matching more than once. > There is text for the DELETE command already and I think thats what you > had in mind at one point: Sorry no, I thought I'd voiced my concern so many that it would be clear. This is the text I have in mind: 5. When multiple "QUERY" properties are supplied in a single "VQUERY" component, the results returned are the same as the results returned for multiple "VQUERY" components having each a single "QUERY" property and the results are return in the same order as the "VQUERY" properties were specified in the original command. Right now, I have no idea what: the results returned are the same as the results returned for multiple "VQUERY" components having each a single "QUERY" property because we haven't defined that yet (or agreed upon it, for that matter). My reading of it was that it added a requirement for keeping results for different QUERY separater (otherwise how could you possibly order them?) And there's still a mention to ordering, which I'd like to get removed. > There MUST BE one "VREPLY" component returned for each object that is > deleted or marked for delete. Uhm yes sorry I overlooked that (maybe because SEARCH doesn't behave like that: all commands return one match per VREPLY, apart from SEARCH where it's not clear); but I think I got it right in the code ;-) > What happend to just getting back 1 delete-vreply (VREPLY) per matching > entry? These VREPLYs can be in any number of VCALENDARsn as long as there > is at least 1 VREPLY per VCALENDAR. This does NOT preclude sending back > ALL the VREPLYs in 1 VCALENDAR. There is also nothing in the draft that > prevents sending back 1 VREPLY per VCALENDAR and sending back 1 per > matching entry. Recheck the ABNF for delete-reply. I think we agree then. So what about we change the text I quoted to: 5. When multiple "QUERY" properties are supplied in a single "VQUERY" component, the results are returned just like they were matches for a single "VQUERY" component having a single "QUERY" property. When multiple "VQUERY" componentns are supplied, the results are returned just like they were matches for a single "VQUERY" component having a single "QUERY" property. Is that fine with you? > > Now what happens if the query matched the same component? Do we > > return it in both replies or in one (which one)? > > IMHO: The responses should (MUST?) be per unique matching entity. [...] > My preference is that we get back 1 XXX-reply per unique affected > component so 1 delete-vreply per UID in the case of of the DELETE command > no matter how many VQUERYs or QUERYs match it. > > I have a mild aversion to the idea of returning multiple delete-vreplys > per matching entity because it serves no purpose to tell the CUA "I > deleted the VEVENT with UID:EVENT1. Oh yeah, I deleted the VEVENT with > UID:EVENT1 (again)." Does it serve any real purpose? You really cant > doubly delete it can you? I agree. Now can you show me where in the text is that stated? > Try changing the command to be a another command like, say, SEARCH and see > if the logic still holds. The CUA asked for VEVENTs that match a couple > sets of criteria. Would it make any sense to return 2 copies of the same > VEVENT?? I dont think so. Aha! Now you're really seeing my point! Look it might be that I'm being silly, but I really interpreted the above text as allowing, nah, mandating that we return 2 copies if they are matched from separate queries. So just to make sure we agree. From a high level point of view, we basically: - for each TARGET: - merge all results from all the QUERYs, keeping only 1 copy of each - if CMD != SEARCH act on them - send them back. SEARCH defines the order in which we need to send results back, the other commands return results in undefined order. OK? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Jan 31 03:36:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01360 for ; Fri, 31 Jan 2003 03:36:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0V8SrR01072 for ietf-calendar-bks; Fri, 31 Jan 2003 00:28:53 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V8Soo01065 for ; Fri, 31 Jan 2003 00:28:50 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id B32581554D; Fri, 31 Jan 2003 09:28:49 +0100 (CET) Date: Fri, 31 Jan 2003 09:28:49 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? Message-ID: <20030131082849.GB44085@inet.it> References: <127.0.0.1+DcYRu2slk9g8MRVsKKHITU@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+DcYRu2slk9g8MRVsKKHITU@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Now, before I get carried away again: if the consensus is to have no transactions for now, I'm fine. See the answer to Doug (which I'll send in a minute). If you are still interested, read through ;-) On Thu, Jan 30, 2003 at 04:38:08PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > All of the DELETEs worked except the one for UID:0987654321 in TARGET:work > which failed with a REQUEST-STATUS:4.0. (made up value for demonstation > purposes only). Why should the previously successful DELETEs be undeleted > because of an unrelated failure?? It makes no sense to me. OK. > > parses everything. There are so many ways of doing the same thing! > > If ordering by TARGET is important to you then Id say that concurrent > DELETEs on separate channels is the way you would probably want to go. Or > am I missing the root of the concern here? It's not that which is worrying me, it's a matter of simplicity, consistency and regression tests to cover all possible cases. If one implementor gets one of the many cases wrong, we end up facing hard times... > > Anyway, back to the discussion. You still assume it IS meaningful > > to assume commands are not atomic; I contend that the CS simply > > has no way of knowing. Compare the following: > > Not quite. I think that atomicity of the command varys with the command. > For example, a DELETE of a VEVENT in 1 VAGENDA succeeds and a positive > VREPLY is sent back. Then the attempted deletion of a different VEVENT > fails. Why should this make the first success now a failure?? That's what I say: the CS has no way of kowing, the CUA has some more hints. > A MOVE is slightly different in that it involves essentially a CREATE and > then a DELETE and both must succeed for a single success VREPLY to be > sent. Again though the command scopped to the effected component, NOT to > the TARGET or the entire command. Agreed. > > I can agree #1 doesn't need to be atomic - if I get any failure > > I can simply retry. > > Thats a start toward full agreement... ;^) Yes. > > In case #2, I would actually love to be able to perform both CREATE > > as a single atomic transaction. Unfortunately, there's no way I > > can do that. > > Nope. The act of creating the 2 entries on your calendar should happen > first. Otherwise you've sent out invitations to something that isn't on > your calendar and thus any responses you get back from the invitees wont Yes you're right, ok. But this doesn't change the main problem. See below. > Yeah, so? The 1st and 2nd VAGENDAs allow you write permission so you can > CREATE the invitation. The 3rd does not (what a weenie for not wanting me > to access their calendar!). So does that mean that you were unable to > invite the first 2 people? Certainly not. Does that mean the entire > CREATE command should be failed? Nope. You could argue that and you would be correct. At the same time my HR manager who just wanted to book the meeting with the 3 guys would arguee that he wanted to meet all 3 of them, not 2, so the computer failed; and he'd be correct as well. :-P Now seriously: if the CUA gets back the error, it must take corrective actions. As a minimum it should change the VEVENT to show that the invitation failed (how?). Surely it should ask the CU what to do now. However, the CU might be leaving just now etc so the CUA should probably also update the VEVENT on the organizer VAGENDA. Also, as Doug mentioned, there could be a bot on one of the attendees VAGENDA which could act immediately on it etc. So no matter how you look at it, creating an event IS a transaction - we just get to pick whether it's implemented on the server or on the client. It would be different if we had ways of avoiding most problems (apart from exceptional, transient ones) - for instance, a CUA could first of all verify that all TARGETs exist, ask the CS if it has access to them etc. So that it could inform the CU even BEFORE she pressed the Ok button. In that case, failure would be really an exception. But as things stand, even something as simple as a mistyped URI could cause a sequence of CAP commands, failure, phone calls ("look, I'm trying to accept your meeting proposal, but this darn program keeps giving me an error message!") etc. How do you handle all this? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Jan 31 03:45:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01515 for ; Fri, 31 Jan 2003 03:45:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0V8d5c03003 for ietf-calendar-bks; Fri, 31 Jan 2003 00:39:05 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V8d4o02993 for ; Fri, 31 Jan 2003 00:39:04 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id C935B1554D; Fri, 31 Jan 2003 09:39:03 +0100 (CET) Date: Fri, 31 Jan 2003 09:39:03 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? Message-ID: <20030131083903.GD44085@inet.it> References: <127.0.0.1+DIitsdDGVKJQBljs4LiXok@space1.inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127.0.0.1+DIitsdDGVKJQBljs4LiXok@space1.inet.it> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jan 30, 2003 at 03:55:37PM -0700, Doug Royer wrote: > independent of all others. Your point of if the CUA can not handle complex > replies, then it better not send complex commands - (send one TARGET at a > time). I just want to make sure we all realize avoiding transactions doesn't avoid the complexity per se, it just moves it to the CUA. Or, it allows you to write naive CUAs. > This debate is one of the reasons we decided to defer transactions. > Any transaction implementation will have to be a draft on its own > and consider and explain all of these situations. [...] > The issue to consider is that it will take more time to consider > all of the interactions and the fact that we have moved forward > with this entire list saying we are not doing transactions at > this time in CAP. We can do transactions later. Allow the simplistic > implementations to be released now (or soon), release CAP, and > we can continue to expand CAP to allow transactions (and other > things) later. Ok, if this is the consensus I will agree. Then I will focus my effort on making sure nothing prevents the CS from implementing transactions when they are added down the road. Also, I will start working on a proposal for adding transactions later on. Ok? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy