From owner-ietf-calendar@mail.imc.org Mon Sep 1 12:42:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09253 for ; Mon, 1 Sep 2003 12:42:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h81GHlgc014463 for ; Mon, 1 Sep 2003 09:17:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h81GHlHh014462 for ietf-calendar-bks; Mon, 1 Sep 2003 09:17:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h81GHjgc014456 for ; Mon, 1 Sep 2003 09:17:45 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h81GHhS5018542 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 1 Sep 2003 09:17:45 -0700 Message-ID: <3F537121.4010500@Royer.com> Date: Mon, 01 Sep 2003 10:17:37 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ADD does not INVALIDATE current PATTERN References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070101060808020106080200" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070101060808020106080200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As I suspected, you did not read the email. The subject is 'ADD' not 'REQUEST'. Now read 'ADD': 3.2.4 ADD ... RECURRENCE-ID 0 Robert_Ransdell@notesdev.ibm.com wrote: > > Doug wrote: > > I can not find any text or example that says you can invite someone > > to a new instance by sending REQUEST and RECURRENCE-ID. I can find > > text that says you can modify an existing instance with REQUEST > > and RECURRENCE-ID. I can also find text that describes how to invite > > an attendee. So equivalent to what? > > > See ITIP REQUEST METHOD 3.2.2 REQUEST > > > RECURRENCE-ID 0 or 1 only if referring to an instance of a > recurring calendar component. Otherwise it > MUST NOT be present. > > > The text does not say "This does not apply to new request" so it is > valid for all METHOD REQUEST. > > > > Doug Royer > Sent by: owner-ietf-calendar@mail.imc.org > > 08/30/2003 01:43 PM > Please respond to > "ietf-calendar@imc.org" > > > > To > "ietf-calendar@imc.org" > cc > > Subject > Re: ADD does not INVALIDATE current PATTERN > > > > > > > > > > > Robert_Ransdell@notesdev.ibm.com wrote: > > > > An ADD does not INVALIDATE any RECURRENCE-ID in current set. Thus it > > does not change the pattern of existing set. > > If an ADD INVALIDATED the existing set, than you would be forced to send > > a new RRULE/RDATES/EXRULE/EXDATES with ADD. > > In that case the ADD would be pointless, just include the new DATE in > > the new rules. > > The ADD method was added after a discussion on how to add instances > to an existing set that had something such as LOCATION different. > > For example a series of meetings that take place around the world > (The IETF meetings for example). As each meeting may have a unique > LOCATION there is no way to describe the next few meetings in one > object. With the ADD method you can add to the instances of an > existing UID. So if the original object sent is a multipart/realted > MIME object. With one REQUEST and five ADD objects, then that is > describing the meeting set (pattern) for that UID. There are also > other valid reasons that a set of meetings could not be described > in on object. > > So how could an iMIP CUA that can not do multipart differentiate > between the one multipart/related object that contained two MIME > objects (1 REQUEST + (5 ADD)) and a series of single MIME objects > (1 REQUEST + 1 ADD + 1 ADD + 1 ADD + 1 ADD + 1 ADD) if they are not > equivalent? It could not. So the net result has to be that the ADD > method also adds to the pattern exactly the same as if ADD was used > in the initial REQUEST multipart/mime object - it changes the pattern. > > > An ADD is equivalent to sending the invitee an REQUEST with a > > RECURRENCE-ID that he does not currently have. > > The ADD method is the only iTIP way described to add an instance > (RECURRENCE-ID) to an ATTENDEEs view that does not already exist in an > object known to the ATTENDEE. And RECURRENCE-ID is disallowed from > the ADD method in the iTIP restriction tables because it would limit > ADD to adding one instance at a time to the set. > > I can not find any text or example that says you can invite someone > to a new instance by sending REQUEST and RECURRENCE-ID. I can find > text that says you can modify an existing instance with REQUEST > and RECURRENCE-ID. I can also find text that describes how to invite > an attendee. So equivalent to what? > > > The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his > > calendar, storing off RECURRENCE-ID that CHAIR supplied. > > iTIP specifically disallows RECURRENCE-ID in ADD methods. Or do > you mean it would store the additional patterns described in the > DTSTART, RRULE, RDATE, EXRULE and EXDATE? > > > The CHAIR does not really care either. He is in control and just adds > > it to his set. > > -- > > 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 > -- 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 --------------ms070101060808020106080200 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwMTE2MTczN1owIwYJKoZIhvcNAQkEMRYEFJys5C3G mcf20SK0TE4nVQfSuYtyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJB5Tn7w+yjDka1Gonrp0AeQeG2f/iekxrPLWGRQnAwdmzdORrdV J/6Lqfem9N1ZQfoIwyHP1HLJBB12yt2mLxOSmyconjQyyF88REzxs5lFSgarHWCJHzEf6//I XWQdt0+BVHZNxsXnw7/naMbas1WNHQ+yPxZjlVsGnpYVSh4mF3Up9Sue5KFl/zeyr4L/OqeE XNdlRihCpKnKGKfw1M4TGgLjUoWLmMJYZBK66f5o6YDAG+eBrYdD3yRJ9F52aNc0b9oyqH0p vEmeoxHAz7/EgGqAK2i50zHcGx7iO5BdKmqCF2BH7uOiAa0V1tIXpwBKk96cP8wRxaioLh3i E60AAAAAAAA= --------------ms070101060808020106080200-- From owner-ietf-calendar@mail.imc.org Tue Sep 2 11:08:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04911 for ; Tue, 2 Sep 2003 11:08:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Eltgc022204 for ; Tue, 2 Sep 2003 07:47:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82Eltwg022203 for ietf-calendar-bks; Tue, 2 Sep 2003 07:47:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Elsgc022195 for ; Tue, 2 Sep 2003 07:47:55 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F4E84E5.5090207@Royer.com> To: ietf-calendar@imc.org Subject: Re: MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 2 Sep 2003 10:42:43 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/02/2003 10:47:51 AM, Serialize complete at 09/02/2003 10:47:51 AM Content-Type: multipart/alternative; boundary="=_alternative 005150B685256D95_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005150B685256D95_= Content-Type: text/plain; charset="US-ASCII" Doug asked on 08/28/2003 06:40:37 PM: > > > but the last sentence > > > definitely says that RECURRENCE-ID changes, and the wording and order is > > > such that it implies that this happens for an instance change. > > > > This last sentence is the only text in iCalendar or iTIP that says > > RECURRENCE-ID changes. Its contrary to the text immediately above it, > > to the text in iCalendar and to all the logic in elsewhere in iTIP > > describing workflow sequencing and recovery. > > So do you also claim that Derik's and Frank's recient post also > is in error when it says they change? Where they in error again? Not at all. If you actually read what both I and they wrote you will find they are agreement. They wrote: 4) It is worth noting that those discussion in the related WG email threads referring to examples in iTIP are problematic, as section 3 of RFC2446 was intended to be illustrative text and was not reviewed as thoroughly as other sections of the RFC for consistency with iCalendar semantics or conformity to iTIP normative sections. This text defines a set of examples, or informational material. Further, this text is known to have numerous typographic errors. and I agree. I was merely pointing out that the ONLY conflicting text cited so far is the last line of 3.7.1 that Tim referred to (the rest jives just fine w/iCalendar and the rest of iTIP). You (and Chris) seem to be the only ones who think this single line in the _semantics_ RFC has some kind of fiat over the _defintion_ RFC in defining the behaviour of the property and is allowed to redefine the property instead of provide semantics to it. Even if you ignore the prose in iCalendar, all the other text in iTIP and the recent posting by Frank/Derik, the analysis of how both models perform still stands and is still accurate despite wishes to the contrary: the delta model performs poorly or can totally break down when message missequencing or loss occurs, the fixed model does not. 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 005150B685256D95_= Content-Type: text/html; charset="US-ASCII"
Doug asked on 08/28/2003 06:40:37 PM:
> >  >                                                    but the last sentence
> >  > definitely says that RECURRENCE-ID changes, and the wording and order is
> >  > such that it implies that this happens for an instance change.
> >
> > This last sentence is the only text in iCalendar or iTIP that says
> > RECURRENCE-ID changes.  Its contrary to the text immediately above it,
> > to the text in iCalendar and to all the logic in elsewhere in iTIP
> > describing workflow sequencing and recovery.
>
> So do you also claim that Derik's and Frank's recient post also
> is in error when it says they change? Where they in error again?
Not at all.  If you actually read what both I and they wrote you will find they are agreement.  They wrote:

4) It is worth noting that those discussion in the related WG email threads referring to examples in iTIP are problematic, as section 3 of RFC2446 was intended to be illustrative text and was not reviewed as thoroughly as other sections of the RFC for consistency with iCalendar semantics or conformity to iTIP normative sections. This text defines a set of examples, or informational material. Further, this text is known to have numerous typographic errors.

and I agree.  I was merely pointing out that the ONLY conflicting text cited so far is the last line of 3.7.1 that Tim referred to (the rest jives just fine w/iCalendar and the rest of iTIP).   You (and Chris) seem to be the only ones who think this single line in the _semantics_ RFC has some kind of fiat over the _defintion_ RFC in defining the behaviour of the property and is allowed to redefine the property instead of provide semantics to it.

Even if you ignore the prose in iCalendar, all the other text in iTIP and the recent posting by Frank/Derik, the analysis of how both models perform still stands and is still accurate despite wishes to the contrary: the delta model performs poorly or can totally break down when message missequencing  or loss occurs, the fixed model does not.  

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 005150B685256D95_=-- From owner-ietf-calendar@mail.imc.org Tue Sep 2 12:39:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13201 for ; Tue, 2 Sep 2003 12:39:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82G2Zgc026118 for ; Tue, 2 Sep 2003 09:02:35 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82G2Zma026117 for ietf-calendar-bks; Tue, 2 Sep 2003 09:02:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82G2Ygc026112 for ; Tue, 2 Sep 2003 09:02:34 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F537121.4010500@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: ADD does not INVALIDATE current PATTERN MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 2 Sep 2003 12:01:20 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/02/2003 12:02:28 PM, Serialize complete at 09/02/2003 12:02:28 PM Content-Type: multipart/alternative; boundary="=_alternative 00580B2085256D95_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00580B2085256D95_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 09/01/2003 12:17:37 PM: > As I suspected, you did not read the email. The subject > is 'ADD' not 'REQUEST'. Now read 'ADD': Actually you misread what Tom wrote. He said: An ADD is equivalent to sending the invitee an REQUEST with a RECURRENCE-ID that he does not currently have. The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his calendar, storing off RECURRENCE-ID that CHAIR supplied. The latter line is referring to the receiving the equivalent REQUEST with RECURRENCE-ID in it that the invitee does not have and thus treating it as an invitation to a new instance they do not currently have (Section 3.2.2 REQUEST). He was NOT referring to the ADD method in the second sentence. 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 00580B2085256D95_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 09/01/2003 12:17:37 PM:
> As I suspected, you did not read the email. The subject
> is 'ADD' not 'REQUEST'. Now read 'ADD':
Actually you misread what Tom wrote.  He said:

An ADD is equivalent to sending the invitee an REQUEST with a RECURRENCE-ID that he does not currently have.
The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his calendar, storing off RECURRENCE-ID that CHAIR supplied.

The latter line is referring to the receiving the equivalent REQUEST with RECURRENCE-ID in it that the invitee does not have and thus treating it as an invitation to a new instance they do not currently have (Section 3.2.2 REQUEST).  He was NOT referring to the ADD method in the second sentence.

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 00580B2085256D95_=-- From owner-ietf-calendar@mail.imc.org Tue Sep 2 13:11:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16086 for ; Tue, 2 Sep 2003 13:11:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82GwNgc030457 for ; Tue, 2 Sep 2003 09:58:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82GwNRE030456 for ietf-calendar-bks; Tue, 2 Sep 2003 09:58:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82GwLgc030448 for ; Tue, 2 Sep 2003 09:58:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h82GwIS5002917 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 2 Sep 2003 09:58:22 -0700 Message-ID: <3F54CC24.70102@Royer.com> Date: Tue, 02 Sep 2003 10:58:12 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ADD does not INVALIDATE current PATTERN References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040405020404090108060205" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040405020404090108060205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 09/01/2003 12:17:37 PM: > > As I suspected, you did not read the email. The subject > > is 'ADD' not 'REQUEST'. Now read 'ADD': > > Actually you misread what Tom wrote. He said: Please re-read my post, I replied to what Robert sent and not what Tom sent. > An ADD is equivalent to sending the invitee an REQUEST with a > RECURRENCE-ID that he does not currently have. > The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his > calendar, storing off RECURRENCE-ID that CHAIR supplied. > > The latter line is referring to the receiving the equivalent REQUEST > with RECURRENCE-ID in it that the invitee does not have and thus > treating it as an invitation to a new instance they do not currently > have (Section 3.2.2 REQUEST). He was NOT referring to the ADD method in > the second sentence. So - I'll ask again, equivalent to WHAT as there is NO SUCH text in iTIP or iCAL? iTIP specifically tells the reader how to invite an ATTENDEE, and it is NOT what was included in that email. So if he was not talking about the "ADD" method, equivalent to what? -- 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 --------------ms040405020404090108060205 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwMjE2NTgxMlowIwYJKoZIhvcNAQkEMRYEFP4H3cRU VEfyzhbl5KRGeZsDVZsnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJyacjrIns64ISu+OWJSBOFkONuKfI3GoiAliw9vonQj2p3eop8f 1h8A8b7Lxd5D2WXIoSBRAU70QSm0McKKQUzvVYysHBltRwmLfbPOsuBAA+O/PEKIZjyNauBD 4Jo04ZqXxtlfBjpYle+h565WXKfWPRGomG5wi9Xk3JhogMhtlWnNbPnmN2SFVi7YaevNIlao 3K/QeM/+GAyZYeWmAyqr1LJLMy4kC2/HeZkO0RtfGfm6+8BYJjBDW4q8KIkwSzgnqXMfIbP0 c97oRNEVAG1/As+QZa3kvjsy3461BcWGY05612C6g3/Kfvh5GUCR1aJRJcuUD8hq6Sf/njh4 MIMAAAAAAAA= --------------ms040405020404090108060205-- From owner-ietf-calendar@mail.imc.org Tue Sep 2 13:12:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16153 for ; Tue, 2 Sep 2003 13:12:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Gs9gc029730 for ; Tue, 2 Sep 2003 09:54:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82Gs9xk029729 for ietf-calendar-bks; Tue, 2 Sep 2003 09:54:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Gs7gc029720 for ; Tue, 2 Sep 2003 09:54:07 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h82Gs6S5002868 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 2 Sep 2003 09:54:07 -0700 Message-ID: <3F54CB28.5040405@Royer.com> Date: Tue, 02 Sep 2003 10:54:00 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040004040600020601080008" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040004040600020601080008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug asked on 08/28/2003 06:40:37 PM: > > > > but the last > sentence > > > > definitely says that RECURRENCE-ID changes, and the wording and > order is > > > > such that it implies that this happens for an instance change. > > > > > > This last sentence is the only text in iCalendar or iTIP that says > > > RECURRENCE-ID changes. Its contrary to the text immediately above it, > > > to the text in iCalendar and to all the logic in elsewhere in iTIP > > > describing workflow sequencing and recovery. > > > > So do you also claim that Derik's and Frank's recient post also > > is in error when it says they change? Where they in error again? > > Not at all. If you actually read what both I and they wrote you will > find they are agreement. They wrote: > ... Your conclusions seem to be that they made the same typographical errors in their recent email post. And that as you believe it is a consistent typographical error you feel is in iTIP. I find that overly odd. Perhaps you should contact them and have them correct their email and iTIP on this list? Until then I do no think that it is odd they claim that the RECURRENCE-ID changes when the pattern changes. And despite your assertions that only iTIP says that the RECURRENCE-ID changes and only once. And as iTIP *is* the scheduling definition for calsch, it seems odd to me that you would think that iTIP text does not apply to scheduling. iCAL: ...the "RECURRENCE-ID" for a given recurrence instance might also change. iTIP: (Your assertion that iTIP does not modify or update iCAL is not supported by the text of iTIP). ... iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. ... (This next paragraph includes a definition of "REQUEST" to include "reschedule" and "change" of recurrence intervals.) ... The "REQUEST" method may be used to reschedule an event. A rescheduled event involves a change to the existing event in terms of its time or recurrence intervals and possibly the location or description. ... And iCAL says: ...Purpose: This property is used in conjunction with the "UID" and "SEQUENCE" property to identify a specific instance of a recurring "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property value is the effective value of the "DTSTART" property of the recurrence instance. ... Looks to me to be supportive and not two more typographical errors. (Note that iTIP specifically defines what it calls "update" to NOT change instances, later it defines the term "modify" to mean change instances. Your quotes of this section to mean invite are out of context. This is for VEVENT, a similar paragraph exists for VTODO.). ...The "REQUEST" method may be used to update or reconfirm an event. An update to an existing event does not involve changes to the time or recurrence intervals, and might not involve a change to the location or description for the event. If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar and that the "SEQUENCE" property value in the "REQUEST" is the same as the value for the existing event, then the "REQUEST" method describes an update of the event details, but no rescheduling of the event. ... And iTIP 4.4.2 shows how to modify instances. Your assertion that Derik and Frank meant typographical error to mean that they accidentally added an entire section in iTIP and included examples is absurd. The WG (and you were on the mailing list at that time) concluded that that entire section was valid. Yet now you want to assert that 58 lines (129-ish words, 1754 characters), are all one big typographical error that everyone including you agreed to at the time? And as 'Steve' was the lead on iTIP, lets ask him if (4.4.2) is a huge typographical error. -- 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 --------------ms040004040600020601080008 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwMjE2NTQwMVowIwYJKoZIhvcNAQkEMRYEFDes5VdQ N0nA8KA9/huuwJamtPAXMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAA55qyNAqkkhUvF69zlNNdKS8Yab7rXKvj9SX+sCDiKVvmDrSwEU 7ZVUMnGnQjdQUu00HyhFOCmeYXFc5ocxmTqwpYHumkB2j4BOSNE9AhP0V4WIKIaYna1HxGFi TdrhIcss1ZMGNNLbsmDN9Dd4lMhXOLueZDYXA/wC5izQmyv3begmT94iCr2/R8YXWDS/9meE 8QfcNjirfm/qBI5Xd47mOlVCRaT15Pa+BCNYjrmramZhb+GuIZHh9D73eKCfoh+0oWLZ3LEX ekkomJOGrEts9XUhCRmHXMAwduZt+k2ixClfMMlGhguBGO9MGtKEejHT//7XMPCrMFb6r+wX PvEAAAAAAAA= --------------ms040004040600020601080008-- From owner-ietf-calendar@mail.imc.org Tue Sep 2 13:42:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20301 for ; Tue, 2 Sep 2003 13:42:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HSAgc032536 for ; Tue, 2 Sep 2003 10:28:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82HSAMu032535 for ietf-calendar-bks; Tue, 2 Sep 2003 10:28:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HS9gc032530 for ; Tue, 2 Sep 2003 10:28:09 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h82HS4S5003349 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 2 Sep 2003 10:28:09 -0700 Message-ID: <3F54D31F.7010601@Royer.com> Date: Tue, 02 Sep 2003 11:27:59 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-calsch-dynamic-upn-01.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040001010305050701050301" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040001010305050701050301 Content-Type: multipart/mixed; boundary="------------020700090109000000020008" This is a multi-part message in MIME format. --------------020700090109000000020008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-royer-calsch-dynamic-upn-01.txt Date: Tue, 02 Sep 2003 12:59:15 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : How to create dynamic UPNs for invited ATTENDEEs Author(s) : D. Royer Filename : draft-royer-calsch-dynamic-upn-01.txt Pages : 11 Date : 2003-9-2 This is an extension to the [CAP] protocol and can be used within [iTIP] objects. A CU may wish to invite a UPN to an event where the UPN does not have a account on the CU's CS. This memo describes two methods to dynamically create UPNs in order for those UPNs to gain access to the 'Organizers' CS. This memo also includes a description of how to include an [OTP] challenge in an object directed to a CU. The CUA must compute the password in order to respond to the object. This challenge and its response can be sent in the clear as the values are computed using a secret that would not be known to anyone snooping the line. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-calsch-dynamic-upn-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-calsch-dynamic-upn-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-calsch-dynamic-upn-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- 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 --------------020700090109000000020008 Content-Type: Message/External-body; name="draft-royer-calsch-dynamic-upn-01.txt" Content-Disposition: inline; filename="draft-royer-calsch-dynamic-upn-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-9-2100226.I-D@ietf.org> --------------020700090109000000020008-- --------------ms040001010305050701050301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwMjE3Mjc1OVowIwYJKoZIhvcNAQkEMRYEFKa+3wRf ExssLFpdrdAYgKxx99aTMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBACGPCpDuf1Akv2uQ4f2RoVy2y8NYzF5TL+X+K54F4EwrlN8sN+uw rrHZSGaydrRsX0PqSbPqTjeEtQc39FFl9dYxbo+Jw3C4DYmyV/qVeTJh7JFWY2FloCBzqo9d q7xc8Rrmv7tlg3fgz43H6m0R39rE61ziA6Vl6w2x49kUMQrPEr1Qd+eie1H2PNBarhM9TV68 knxNoYcs+61beMhI4A6Q1oP7YULSq52rm7MZniu+XoSYd6tbrbhvpmYnfi24rRNuZspZ19kT uE1OByPS8pIBN0iYT3XJkecGJetqq5pVk+VvTLDTnm2FVOwRK6sX3XqgAC7SF73rIg92f2fM oq4AAAAAAAA= --------------ms040001010305050701050301-- From owner-ietf-calendar@mail.imc.org Tue Sep 2 13:42:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20305 for ; Tue, 2 Sep 2003 13:42:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HRVgc032486 for ; Tue, 2 Sep 2003 10:27:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82HRVIb032485 for ietf-calendar-bks; Tue, 2 Sep 2003 10:27:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HRTgc032471 for ; Tue, 2 Sep 2003 10:27:29 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h82HRSS5003343 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 2 Sep 2003 10:27:30 -0700 Message-ID: <3F54D2FB.4090805@Royer.com> Date: Tue, 02 Sep 2003 11:27:23 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-cap-sort-01.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050001040404070600070406" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050001040404070600070406 Content-Type: multipart/mixed; boundary="------------050107000701000807040008" This is a multi-part message in MIME format. --------------050107000701000807040008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-royer-cap-sort-01.txt Date: Tue, 02 Sep 2003 12:58:51 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CAP (Calendar Access Protocol) sorting extension Author(s) : D. Royer Filename : draft-royer-cap-sort-01.txt Pages : 13 Date : 2003-9-2 Small devices may not have sufficient memory to store and then sort query results from a CAP server. This memo suggests an expendable CAP CAPABILITY extension called 'CAP-SORT' and a new parameters 'SORT' and 'LOCALE'. This memo specifies an optional minimum sort order and and locale sort extension. These extensions will only effect CUA's that have specifically requested these extensions be used in the session or for specific queries. The reader should be familiar with the CAP protocol prior to reading this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-cap-sort-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-cap-sort-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-cap-sort-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- 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 --------------050107000701000807040008 Content-Type: Message/External-body; name="draft-royer-cap-sort-01.txt" Content-Disposition: inline; filename="draft-royer-cap-sort-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-9-2100136.I-D@ietf.org> --------------050107000701000807040008-- --------------ms050001040404070600070406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwMjE3MjcyM1owIwYJKoZIhvcNAQkEMRYEFCp88hyZ yEGreZTtvJjEgCpFqv1dMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIoUzRWaG2FzvZHk7CqOnFBC01A0qCwyehbCygJUpyBd4+80b78c /hCSayQ4/yMENRxDAxXm1i/mItScqaovRVPA+NNLmOjK9W/vaPaiN7cG7GaODjdJecdk1ihD 21JMsyfrLGYdYUiFrm4h0gs7XguOCo4jk0vFmeDWNT8bnHM3s8Q8NM+/ZOnr+h4KVG+zh126 /vZTy3zoSqhqK3yodnrh+yCejbuVAcLN8YGXJXKTxC2PAgD21Qm1e9oPMAWuROqleAamNL9A +E3ejGipABZREiIODrfMuaab3fnPNC+czF5oMiv6PsLWsas9amJl8VMU9X6Zi1c58bo6O7wA rrcAAAAAAAA= --------------ms050001040404070600070406-- From owner-ietf-calendar@mail.imc.org Tue Sep 2 13:43:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20563 for ; Tue, 2 Sep 2003 13:43:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HSdgc032568 for ; Tue, 2 Sep 2003 10:28:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82HSddb032566 for ietf-calendar-bks; Tue, 2 Sep 2003 10:28:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HSbgc032560 for ; Tue, 2 Sep 2003 10:28:37 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h82HSaS5003355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 2 Sep 2003 10:28:38 -0700 Message-ID: <3F54D33F.80108@Royer.com> Date: Tue, 02 Sep 2003 11:28:31 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-cap-notify-01.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070107010300040605010307" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070107010300040605010307 Content-Type: multipart/mixed; boundary="------------060800080802000101020102" This is a multi-part message in MIME format. --------------060800080802000101020102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-royer-cap-notify-01.txt Date: Tue, 02 Sep 2003 12:58:55 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CAP notification of upcoming VEVENTs, VTODOs or any changes Author(s) : D. Royer Filename : draft-royer-cap-notify-01.txt Pages : 11 Date : 2003-9-2 This memo describes a method used to ask for and receive notifications. These notifications will be the direct result of a stored VALARM and the notifications or changes to components or the store and are represented in iCalendar format. This is an extensions to CAP. This memo includes a new CAP command types of 'REQUEST-NOTIFY', 'NOTIFICATION', and 'CANCEL-NOTIFY', a new property of 'OBSERVER', a new component 'NOTIFICATION', CAP capabilities of 'CAN-NOTIFY', 'NOTIFY-UPDATES', and 'ALLOW-NOTIFY-BOT'. A 'REQUEST-NOTIFY' command is a request to add an observer to an component in the 'TARGET' calendar. In addition the 'REQUEST-NOTIFY' command can alert the CUA of changes to specific components or in the calendar or calendar store. Everything is subject to VCAR restrictions. These are asynchronous notifications must be advertised by the CS and requested by the CUA. This memo discusses how to transport them using CAP. In addition if the CS and CUA support the 'NOTIFY-UPDATES' capability, then the CS will send 'NOTIFICATION' components to the CUA describing the UIDs or TARGETS that have changed since the currently authenticated CU was last connected allowing for easier synchronization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-cap-notify-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-cap-notify-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-cap-notify-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- 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 --------------060800080802000101020102 Content-Type: Message/External-body; name="draft-royer-cap-notify-01.txt" Content-Disposition: inline; filename="draft-royer-cap-notify-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-9-2100147.I-D@ietf.org> --------------060800080802000101020102-- --------------ms070107010300040605010307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwMjE3MjgzMVowIwYJKoZIhvcNAQkEMRYEFHXp5q/+ hUNcJVMQAmoZaHFWUaP5MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAE+MlVT7Qu71sdE80BpXYt5Wp0c4WDSjLIKCZ8P8/VDSQC5kW+Lz Pzo7ZHclyjd0qfoWAcQyg50tVoxr5PK9Ipeibjx+AOOUBEMI9LXMztjvFIfF+aTBIVwHH9O6 gtvrSMu4XRUwVaGnyobhwA2JiRbftNbTF8zPDkLDeN9fHIqWKirQkAsFsYZc5dCbrFO1awFq JtP1ofdbq+l9LS9R5zsdvepNybOBsvLEFbH1iOzmolOe2GWFNExEoYUdwl576x2/tIb/QQ8A 9wU3ZMSaEVEYnpUqFW/U+KO93wEuLwoUhmWg+oyRqT6tt/WZtFNB8qgKdcdkoDqWm/Mjn4BF 1moAAAAAAAA= --------------ms070107010300040605010307-- From owner-ietf-calendar@mail.imc.org Tue Sep 2 17:42:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09977 for ; Tue, 2 Sep 2003 17:42:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82LQNgc053066 for ; Tue, 2 Sep 2003 14:26:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82LQNIc053065 for ietf-calendar-bks; Tue, 2 Sep 2003 14:26:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82LQHgc053044 for ; Tue, 2 Sep 2003 14:26:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h82LQHS5006093 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 2 Sep 2003 14:26:19 -0700 Message-ID: <3F550AF4.4060701@Royer.com> Date: Tue, 02 Sep 2003 15:26:12 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: I-D ACTION:draft-royer-calsch-dynamic-upn-01.txt] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070605000400010005020606" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070605000400010005020606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks: [OTP] Haller, N. and C. Metz, "A One-Time Password System," RFC 1938, May 1996. Satya Vempati wrote: > Minor: reference to [OTP] missing. -- 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 --------------ms070605000400010005020606 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwMjIxMjYxMlowIwYJKoZIhvcNAQkEMRYEFP1TFW5i uYnMEvJ+D5e2rJeYwz0LMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAG6OfLXrNyM44bl8tBHkUQMnL4FvrRRqBUwUVP+LcdgvqNnbSWrJ ajruEfFEO7nSQBGz4RUZEW7MXCRknGPEM+j9Xr9Yi/gERxYatitPyMW8DbCxxNn/CqWgpItV SeUtNX62ZBH4rwO0LAKkUX69BJXNkYoYf+U1ueb5GVDCa4dQ0kvqIokEmAvQl8A9NJZLdztn D9i9hOb9IXBTKvi9fB72X5xdjha2SjwKN58RH1wmp5+cQiJCUZ0mN3nQFBAqRw/HGBjKmhiA ZswXG8E01/hj23vDoAt7oyucQC/1pT246pLJMpuNRPEy7tLeESVtR5DDrfDRr7+O2Y64innQ KvEAAAAAAAA= --------------ms070605000400010005020606-- From owner-ietf-calendar@mail.imc.org Wed Sep 3 17:06:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08087 for ; Wed, 3 Sep 2003 17:06:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83Kidgc070555 for ; Wed, 3 Sep 2003 13:44:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83KidbS070554 for ietf-calendar-bks; Wed, 3 Sep 2003 13:44:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83Kicgc070548 for ; Wed, 3 Sep 2003 13:44:38 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12-a: Stored queries still? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 3 Sep 2003 16:41:21 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/03/2003 04:44:36 PM, Serialize complete at 09/03/2003 04:44:36 PM Content-Type: multipart/alternative; boundary="=_alternative 0071A85F85256D96_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071A85F85256D96_= Content-Type: text/plain; charset="US-ASCII" We never reached a clear concensus on the issue of stored queries in CAP. The thread just stopped in mid-January 2003 and I still question the usefulness of them in CAP. As a refresher for those that may not recall that thread or are new: CAP has the ability to store and refer to 'named' queries in the protocol. However, since there is no ability to wildcard any values in the query (ie: "Find me all VALARMs that TRIGGER in the next 15 minutes" or "Find me all VEVENTs that have a DTSTART sometime Today" are _not_ possible) I contend that the usefulness of stored queries is too limited to be of any use in CAP. A CUA must rewrite and restore the 'named' query every time the parameters change. For example, "Find me all VALARMs where TRIGGER >= 20030903T090000Z AND TRIGGER <= 20030903T091500Z", and then "Find me all VALARMs where TRIGGER >= 20030903T091500Z AND TRIGGER <= 20030903T093000Z", and then it need to be changed again... The concept was originally added for 'thin' clients (ie: PDAs or cell phones) to minimize bandwidth or footprint needs but its demonstratable that their real usefulness is very limited compared to what any CUA or CS would have to do to use or support them. In the interest of KISS I re-propose that we remove all references to them in CAP 1.0 unless someone can show a real benefit from using them. 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 0071A85F85256D96_= Content-Type: text/html; charset="US-ASCII"
We never reached a clear concensus on the issue of stored queries in CAP.  The thread just stopped in mid-January 2003 and I still question the usefulness of them in CAP.

As a refresher for those that may not recall that thread or are new:

CAP has the ability to store and refer to 'named' queries in the protocol.  However, since there is no ability to wildcard any values in the query (ie: "Find me all VALARMs that TRIGGER in the next 15 minutes" or "Find me all VEVENTs that have a DTSTART sometime Today" are _not_ possible) I contend that the usefulness of stored queries is too limited to be of any use in CAP.   A CUA must rewrite and restore the 'named' query every time the parameters change.  For example, "Find me all VALARMs where TRIGGER >= 20030903T090000Z AND TRIGGER <= 20030903T091500Z", and then  "Find me all VALARMs where TRIGGER >= 20030903T091500Z AND TRIGGER <= 20030903T093000Z", and then it need to be changed again...

The concept was originally added for 'thin' clients (ie: PDAs or cell phones) to minimize bandwidth or footprint needs but its demonstratable that their real usefulness is very limited compared to what any CUA or CS would have to do to use or support them.

In the interest of KISS I re-propose that we remove all references to them in CAP 1.0 unless someone can show a real benefit from using them.

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 0071A85F85256D96_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 3 17:08:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08143 for ; Wed, 3 Sep 2003 17:08:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83KtVgc070963 for ; Wed, 3 Sep 2003 13:55:33 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83KtVH0070962 for ietf-calendar-bks; Wed, 3 Sep 2003 13:55:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83KtUgc070957 for ; Wed, 3 Sep 2003 13:55:30 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12-a: 8.30 RECUR-ACCEPTED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 3 Sep 2003 16:55:27 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/03/2003 04:55:28 PM, Serialize complete at 09/03/2003 04:55:28 PM Content-Type: multipart/alternative; boundary="=_alternative 0072F2B885256D96_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072F2B885256D96_= Content-Type: text/plain; charset="US-ASCII" I see that we have a Section 8.30 RECUR-ACCEPTED Property that defined as: Purpose: This property specifies if the endpoint supports recurring instances. ... Description: Indicates if recurrence rules are supported. If FALSE then the endpoint can not process any kind of recurring rules. The Purpose text talks about general recurrence but the Description text talks about recurrence rules. This is a disjoin since: A) Recurrence also involves RDATEs/EXDATEs and not just RRULEs/EXRULEs and B) I think there needs to be some distinction of any recurrence grammar support versus Recurrence Rule vs Exception Rule support (at least in the 2nd bit of text) Just because an implementation supports some forms of the recurrence grammar (iCalendar, Section 4.3.10 Recurrence Rule) does not mean that it supports both the RRULE (iCalendar, Section 4.8.5.4 Recurrence Rule) and EXRULE (iCalendar, Section 4.8.5.2 Exception Rule) forms. Some implemenations may not support the EXRULE but this is not conveyable in CAP currently. (Supporting EXRULE and not RRULE is a crazy combination to me but perhaps its logical to some...) Anyway, the text above seems to be an indication of general Recurrence Rule support rather than explicit RRULE or EXRULE support. We need to fix the disjoin between the described Purpose and the actual Description and we need to make the "rule" distiction clearer. Likely we will also need to make a finer distinction between RRULE & EXRULE. The original intent of this was not just to convey recurrence grammar support but general recurrence support (for PD or simple implementations that didnt want to have the complexity necessary for repeating instances) so I suggest that Description gets reworked to be more akin to the Purpose's intent rather than its current intent. If we want to drill down to recurrence rule support, that should be done separately and with RRULE/EXRULE distinction included. 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 0072F2B885256D96_= Content-Type: text/html; charset="US-ASCII"
I see that we have a Section 8.30 RECUR-ACCEPTED Property that defined as:

   Purpose: This property specifies if the endpoint supports recurring
  instances.
...
   Description: Indicates if recurrence rules are supported.  If FALSE
  then the endpoint can not process any kind of recurring rules.
The Purpose text talks about general recurrence but the Description text talks about recurrence rules.  This is a disjoin since:

A) Recurrence also involves RDATEs/EXDATEs and not just RRULEs/EXRULEs and
B) I think there needs to be some distinction of any recurrence grammar support versus Recurrence Rule vs Exception Rule support (at least in the 2nd bit of text)

Just because an implementation supports some forms of the recurrence grammar (iCalendar, Section 4.3.10 Recurrence Rule) does not mean that it supports both the RRULE (iCalendar, Section 4.8.5.4 Recurrence Rule) and EXRULE (iCalendar, Section 4.8.5.2 Exception Rule) forms.  Some implemenations may not support the EXRULE but this is not conveyable in CAP currently.  (Supporting EXRULE and not RRULE is a crazy combination to me but perhaps its logical to some...)  Anyway, the text above seems to be an indication of general Recurrence Rule support rather than explicit RRULE or EXRULE support.

We need to fix the disjoin between the described Purpose and the actual Description and we need to make the "rule" distiction clearer.  Likely we will also need to make a finer distinction between RRULE & EXRULE.  

The original intent of this was not just to convey recurrence grammar support but general recurrence support (for PD or simple implementations that didnt want to have the complexity necessary for repeating instances) so I suggest that Description gets reworked to be more akin to the Purpose's intent rather than its current intent.  If we want to drill down to recurrence rule support, that should be done separately and with RRULE/EXRULE distinction included.
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 0072F2B885256D96_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 3 18:20:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12905 for ; Wed, 3 Sep 2003 18:20:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83M6Tgc076745 for ; Wed, 3 Sep 2003 15:06:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83M6Tno076744 for ietf-calendar-bks; Wed, 3 Sep 2003 15:06:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83M6Sgc076737 for ; Wed, 3 Sep 2003 15:06:28 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h83M6RS5022131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 3 Sep 2003 15:06:29 -0700 Message-ID: <3F5665DE.1030600@Royer.com> Date: Wed, 03 Sep 2003 16:06:22 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 8.30 RECUR-ACCEPTED References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040309070008060309040602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040309070008060309040602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > I see that we have a Section 8.30 RECUR-ACCEPTED Property that defined as: > > Purpose: This property specifies if the endpoint supports recurring > instances. > ... > Description: Indicates if recurrence rules are supported. If FALSE > then the endpoint can not process any kind of recurring rules. > > The Purpose text talks about general recurrence but the Description text > talks about recurrence rules. This is a disjoin since: > > A) Recurrence also involves RDATEs/EXDATEs and not just RRULEs/EXRULEs and 1) It does not say 'RRULE' or 'EXRULE'. 2) Do you have a suggestion as to what it should say? -- 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 --------------ms040309070008060309040602 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwMzIyMDYyMlowIwYJKoZIhvcNAQkEMRYEFBq9PtHQ Bu7SH2tmDcltiwkxBVe0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAH1WfTIM4NpZ8Bfu/PB331b2V+zzgXsZjZiHMTXY9JIPKgttZE8v hivKHUGYPvMBHgU5tIysqo32g0fkC0bpVM7uEw6hOoYGUg6Ww8VM3LOPs3pHGbC+Mg7B66gh Hd/9cUWZwTontVv8GZ9YzofBjwJPV/pOKoPp4D+jRzjTXqqJs7F2cgzBZ7ct/HnjChm6YW4c tTl93XEK9/gGZSC6yWGj2qavB60eh2eZW2LhCp2ivPmtwtrRREPySy/dV0dLWKNZUDPmtVF+ yQGMQtZ2xfr3z6llQFINjkKSHUzzJE0K2s+Y3ey3K8j2UCebui4N1cowY9etwKD+u/S1Ukry thEAAAAAAAA= --------------ms040309070008060309040602-- From owner-ietf-calendar@mail.imc.org Wed Sep 3 18:22:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13009 for ; Wed, 3 Sep 2003 18:22:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83M7Vgc076800 for ; Wed, 3 Sep 2003 15:07:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83M7V74076799 for ietf-calendar-bks; Wed, 3 Sep 2003 15:07:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83M7Tgc076794 for ; Wed, 3 Sep 2003 15:07:30 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h83M7TS5022142 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 3 Sep 2003 15:07:31 -0700 Message-ID: <3F56661C.5090300@Royer.com> Date: Wed, 03 Sep 2003 16:07:24 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: Re: CAP-12-a: Stored queries still?] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020209030509010701060501" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020209030509010701060501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit (I accidentally sent this to Bruce - I meant to send it to the list) Bruce_Kahn@notesdev.ibm.com wrote: > > We never reached a clear concensus on the issue of stored queries in > CAP. The thread just stopped in mid-January 2003 and I still question > the usefulness of them in CAP. Is what Bruce means, it it does not end until he agrees. There was a debate - two of them over the last two years. > As a refresher for those that may not recall that thread or are new: > > CAP has the ability to store and refer to 'named' queries in the > protocol. However, since there is no ability to wildcard any values in > the query .... Which is irrelevant as there ARE queries that can be saved without wild cards. No place in CAP does it say that you must be able to do stored queries based on time or wild cards. Such as these examples: QUERYID:Common SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED" SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED" QUERYID:STUFF SELECT VEVENT FROM VAGENDA WHERE STATE() = "DELETED" SELECT VTODO FROM VAGENDA WHERE STATE() = "DELETED" QUERYID:Everything SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED" SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED" SELECT VHOURNAL FROM VEGANDA WHERE STATE() = "UNPROCESSED" SELECT X-MY-COMP FROM VEGANDA WHERE STATE() = "UNPROCESSED" QUERYID:MY RIGHTS SELECT VCAR FROM VAGENDA WHERE SELF() IN DENY SELECT VCAR FROM VAGENDA WHERE SELF() IN GRANT QUERYID:MY CALS SELECT CARID FROM VCALSTORE WHERE SELF() in OWNER . . . -- 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 -- 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 --------------ms020209030509010701060501 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwMzIyMDcyNFowIwYJKoZIhvcNAQkEMRYEFGMkHwhR flh/uFr0IjjugX+JzSV2MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGGkAYdyxpzuQcd7XkWOhvIqcOkHvhIm60a5kwTkGRqTqTq82QCn XDH0U4FHwRiWqj/QlQbTH8kLpq91kXh1NYMgQDynh+gxgzJS0aRWlDnhSyE9o/QeslnErb/U Pij4EcPkB6lblppgJBkieErryZrZkzPu3nAP5d1Va52xXpryc8pCpb4e8VVQOp01QIp2N2dk H65LuZD8+whJBfq/SUpgLZtimMkVo2h4GqX1NLSBSqz8y01smurdSlOhZ40wFMlQRZpHCqBo FARtDgLf6sjHZuqKIvBtW+SlfuKdwCd0f5MLF1eSPihgBFTV3b2PMBnXDJmVQHGyeLsHl40C grEAAAAAAAA= --------------ms020209030509010701060501-- From owner-ietf-calendar@mail.imc.org Wed Sep 3 23:33:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00855 for ; Wed, 3 Sep 2003 23:33:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h843FOgc087028 for ; Wed, 3 Sep 2003 20:15:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h843FOLt087027 for ietf-calendar-bks; Wed, 3 Sep 2003 20:15:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h843FNgc087021 for ; Wed, 3 Sep 2003 20:15:23 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175]) by comcast.net (rwcrmhc11) with SMTP id <2003090403152001300bkm2qe> (Authid: TimHare); Thu, 4 Sep 2003 03:15:21 +0000 Message-Id: <5.2.1.1.0.20030903225643.00a161e0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 03 Sep 2003 23:12:42 -0400 To: "ietf-calendar@imc.org" From: Tim Hare Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] In-Reply-To: <3F56661C.5090300@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This may be an implementation question, but I feel it may be germane: How does the "stored" query save anything? It seems to me that in a limited implementation (PDAs were mentioned, but of course that's not the only case, I might want to implement CAP on my Atari 400 or something ) the premium would be on storage space, and you either store the query (memory/disk storage) or you have essentially the same query stored mostly as literals within the program itself because the program has to generate those literals to accomplish the CAP Query anyway. I agree with Doug that there are queries which can be stored without need for wild cards, but I'm not sure I see where the efficiency comes in. Is it intended that the stored queries be on the Calendar Store machine, such that a smaller-footprint client can invoke them just by name, like a remote procedure call of some sort? Tim Hare At 04:07 PM 9/3/03 -0600, you wrote: >(I accidentally sent this to Bruce - I meant to send it to the list) > > >Bruce_Kahn@notesdev.ibm.com wrote: >>We never reached a clear concensus on the issue of stored queries in >>CAP. The thread just stopped in mid-January 2003 and I still question >>the usefulness of them in CAP. > >Is what Bruce means, it it does not end until he agrees. There was >a debate - two of them over the last two years. > >>As a refresher for those that may not recall that thread or are new: >>CAP has the ability to store and refer to 'named' queries in the >>protocol. However, since there is no ability to wildcard any values in >>the query .... > >Which is irrelevant as there ARE queries that can be saved >without wild cards. No place in CAP does it say that >you must be able to do stored queries based on time or wild cards. > > >Such as these examples: > > QUERYID:Common > SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED" > SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED" > > QUERYID:STUFF > SELECT VEVENT FROM VAGENDA WHERE STATE() = "DELETED" > SELECT VTODO FROM VAGENDA WHERE STATE() = "DELETED" > > QUERYID:Everything > SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED" > SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED" > SELECT VHOURNAL FROM VEGANDA WHERE STATE() = "UNPROCESSED" > SELECT X-MY-COMP FROM VEGANDA WHERE STATE() = "UNPROCESSED" > > QUERYID:MY RIGHTS > SELECT VCAR FROM VAGENDA WHERE SELF() IN DENY > SELECT VCAR FROM VAGENDA WHERE SELF() IN GRANT > > QUERYID:MY CALS > SELECT CARID FROM VCALSTORE WHERE SELF() in OWNER > > . > . > . > > >-- > > 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 > >-- > > 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 Thu Sep 4 09:43:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22114 for ; Thu, 4 Sep 2003 09:43:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84DOggc049364 for ; Thu, 4 Sep 2003 06:24:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84DOgPn049363 for ietf-calendar-bks; Thu, 4 Sep 2003 06:24:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84DOfgc049358 for ; Thu, 4 Sep 2003 06:24:42 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F5665DE.1030600@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 8.30 RECUR-ACCEPTED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 09:07:05 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 09:25:43 AM, Serialize complete at 09/04/2003 09:25:43 AM Content-Type: multipart/alternative; boundary="=_alternative 00480CF785256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00480CF785256D97_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 09/03/2003 06:06:22 PM: > > I see that we have a Section 8.30 RECUR-ACCEPTED Property that defined as: > > > > Purpose: This property specifies if the endpoint supports recurring > > instances. > > ... > > Description: Indicates if recurrence rules are supported. If FALSE > > then the endpoint can not process any kind of recurring rules. > > > > The Purpose text talks about general recurrence but the Description text > > talks about recurrence rules. This is a disjoin since: > > > > A) Recurrence also involves RDATEs/EXDATEs and not just RRULEs/EXRULEs and > > 1) It does not say 'RRULE' or 'EXRULE'. Correct. The text under Description says "recurrence rules". This implys RRULEs (iCalendar, Section 4.8.5.4 Recurrence Rule) and thus excludes EXRULES. Im saying that this is a mistake. Not every implementation will support both RRULEs and EXRULEs so the draft needs to be hip to this and not totally ignore both. > 2) Do you have a suggestion as to what it should say? First we need to answer the discrepancy between the Purpose and the Description. Then we will have a better idea of what text to add. In case you missed that point, the Purpose clearly says "supports recurring _instances_" and the Description says "recurrence _rules_ are supported". These are NOT the same. Recurring _instances_ include RDATEs or put another way, repeating instances of any kind. Recurring _rules_ are just RRULEs and NOT RDATEs (or EXRULES or EXDATEs). Unless CAP is going to be indeterminate on the support of RDATEs, EXRULEs and EXDATEs then something needs to be changed. So the question to answer FIRST is "Does RECUR-ACCEPTED refer to all kinds of recurrence or just to recurrence grammars?" From there we can move along to some better text. I for one think that it implys all recurrence but Im sure others may have other ideas. Untill we have concensus on the intent, any proposed text is a waste of time. FYI: Not all implementations support RDATEs but do support RRULEs. If I recall correctly, Outlook does/did not support RDATEs but they do support RRULEs (at least thats what I recall from some testing we did here or at a CalConnect.) so do not assume that every implementation supports every form of repeating instance. 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 00480CF785256D97_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 09/03/2003 06:06:22 PM:
> > I see that we have a Section 8.30 RECUR-ACCEPTED Property that defined as:
> >
> >    Purpose: This property specifies if the endpoint supports recurring
> >   instances.
> > ...
> >    Description: Indicates if recurrence rules are supported.  If FALSE
> >   then the endpoint can not process any kind of recurring rules.
> >
> > The Purpose text talks about general recurrence but the Description text
> > talks about recurrence rules.  This is a disjoin since:
> >
> > A) Recurrence also involves RDATEs/EXDATEs and not just RRULEs/EXRULEs and
>
> 1) It does not say 'RRULE' or 'EXRULE'.
Correct.  The text under Description says "recurrence rules".  This implys RRULEs (iCalendar, Section 4.8.5.4 Recurrence Rule) and thus excludes EXRULES.  Im saying that this is a mistake.  Not every implementation will support both RRULEs and EXRULEs so the draft needs to be hip to this and not totally ignore both.

> 2) Do you have a suggestion as to what it should say?
First we need to answer the discrepancy between the Purpose and the Description.  Then we will have a better idea of what text to add.

In case you missed that point, the Purpose clearly says "supports recurring _instances_" and the Description says "recurrence _rules_ are supported".  These are NOT the same.  Recurring _instances_ include RDATEs or put another way, repeating instances of any kind.  Recurring _rules_ are just RRULEs and NOT RDATEs (or EXRULES or EXDATEs).  

Unless CAP is going to be indeterminate on the support of RDATEs, EXRULEs and EXDATEs then something needs to be changed.  

So the question to answer FIRST is "Does RECUR-ACCEPTED refer to all kinds of recurrence or just to recurrence grammars?"  From there we can move along to some better text.  I for one think that it implys all recurrence but Im sure others may have other ideas.  Untill we have concensus on the intent, any proposed text is a waste of time.

FYI: Not all implementations support RDATEs but do support RRULEs.  If I recall correctly, Outlook does/did not support RDATEs but they do support RRULEs (at least thats what I recall from some testing we did here or at a CalConnect.) so do not assume that every implementation supports every form of repeating instance.

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 00480CF785256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 10:05:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23784 for ; Thu, 4 Sep 2003 10:05:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84DrAgc050706 for ; Thu, 4 Sep 2003 06:53:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84DrAJo050705 for ietf-calendar-bks; Thu, 4 Sep 2003 06:53:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Dr9gc050700 for ; Thu, 4 Sep 2003 06:53:09 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 09:31:09 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 09:53:10 AM, Serialize complete at 09/04/2003 09:53:10 AM Content-Type: multipart/alternative; boundary="=_alternative 004A414685256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004A414685256D97_= Content-Type: text/plain; charset="US-ASCII" In CAP-12-a, under Section 9.6 VQUERY Component is written: Normally "NAME" and "QUERYID" properties are used when looking for a correct stored "VQUERY" component, or when storing a "VQUERY" component. Im curious to know when we decided that the NAME property was to be used for identifying the VQUERY? If its just the "localizable display name" then what use is it in looking for the particular VQUERY? Isn't that the sole role for the QUERYID property? If not, when is NAME _not_ used (since the text says "Normally"...)? Since later text says: For a search, if the "TARGET" property is supplied in a "VQUERY" component, then the CS is to search for the query in the calid supplied by the "TARGET" property value. I suspect that the 1st bit above is just poor phrasing and there is no actual intent of using NAME in some unspecified combination with QUERYID. However I dont want to second guess Dougs intent here. 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 004A414685256D97_= Content-Type: text/html; charset="US-ASCII"
In CAP-12-a, under Section 9.6 VQUERY Component is written:

                                             Normally "NAME" and
  "QUERYID" properties are used when looking for a correct stored
  "VQUERY" component, or when storing a "VQUERY" component.
Im curious to know when we decided that the NAME property was to be used for identifying the VQUERY?  

If its just the "localizable display name" then what use is it in looking for the particular VQUERY?  Isn't that the sole role for the QUERYID property?  If not, when is NAME _not_ used (since the text says "Normally"...)?

Since later text says:

   For a search, if the "TARGET" property is supplied in a "VQUERY"
  component, then the CS is to search for the query in the calid
  supplied by the "TARGET" property value.
I suspect that the 1st bit above is just poor phrasing and there is no actual intent of using NAME in some unspecified combination with QUERYID.  However I dont want to second guess Dougs intent here.  

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 004A414685256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 10:47:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28016 for ; Thu, 4 Sep 2003 10:47:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84EXTgc053659 for ; Thu, 4 Sep 2003 07:33:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84EXTC7053658 for ietf-calendar-bks; Thu, 4 Sep 2003 07:33:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84EXSgc053653 for ; Thu, 4 Sep 2003 07:33:28 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F56661C.5090300@Royer.com> MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 10:29:09 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 10:33:27 AM, Serialize complete at 09/04/2003 10:33:27 AM Content-Type: multipart/alternative; boundary="=_alternative 004F90B585256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004F90B585256D97_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 09/03/2003 06:07:24 PM: > > We never reached a clear concensus on the issue of stored queries in > > CAP. The thread just stopped in mid-January 2003 and I still question > > the usefulness of them in CAP. > > Is what Bruce means, it it does not end until he agrees. There was > a debate - two of them over the last two years. Check the archives and you'll see that its not only I who questioned the usefulness of the feature as we have designed CAP. Go ahead, I'll wait... Recently I asked for examples of where its really useful and really has benefit versus the cost and complexity to CS implementations. Of the 2 people on the list who wanted to keep them (Doug & Andrea), neither responded. Why is that? Instead of showing a benefit for them, you try to deflect the issue now by saying already been covered. In fact, it was not resolved. We debated the initial idea way back when it was proposed as a solution to "thin" clients like PDAs and the like. The idea was to reduce a CUAs need to recraft a common query and just rely on the CS keeping it around. Common activities like checking for alarms, searching for new 'stuff', etc were all proposed as desireable cases that would be used for this feature and there would be lots of saved bandwidth and cycles. In taking a practical look at them in recent drafts I question their actual usefulness given our query lingua. Since there is no way for any client ('fat' or 'thin') to create a stored query that is really beneficial and reusable I question the need to have them as a mandatory CS feature. The query language has NO way for crafting a query thats reusable like "Find me the alarms that go off in the next 15 minutes" or "What entries are on my calendar for today". Thats because we have no concept of being able to wildcards; the query MUST use exact comparisons to _explicit_ values. This hardly makes the stored querys reusable; the CUA will have to update them with new _explicit_ values on some regular basis. Not much savings there that I can see and infact it may be more of a burden (ie: extra network traffic to recreate the stored query) than a benefit. > Which is irrelevant as there ARE queries that can be saved > without wild cards. Yes there are; _any_ query can be stored. However they do NOT fulfull the original intent of the stored query feature nor does storing them in the CS any strong benefit to anyone compared to the cost of implementation. > No place in CAP does it say that > you must be able to do stored queries based on time or wild cards. You are missing the point or trying to deflect it. The intent of stored queries was to make it easier for 'thin' clients to keep smaller footprints by allowing them to not have to (re)craft commonly used queries again and again; they relied on the CS to keep the query and involk it when the CUA needed it. This is a great concept but we failed to design our query language to allow for it to be _actually_ useful. Until now noone has provided any kind of examples that show why we MUST have this as part of ALL CS implemenations. The CAP drafts make an implicit requirement that CS implement stored queries and I think this is wrong to do, especially given the lack of any demonstratable benefit. Now that you've finally got some examples, lets take a look at them to see if they meet the original intent and compare any benefits to the cost of saving queries... > QUERYID:Common > SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED" > SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED" Yes, this is a common kind of query ("Find me 'new stuff'"). However there is nothing complex here that would require any CUA ('fat' or 'thin') to take up that much extra space or cycles to send. It can simply be a hardcoded string that any CUA simply puts into the payload. Of course you can bloat this query out to be explicit for all kinds of components explicitly (and thus miss unprocessed content) or you can take the more compact form and use: SELECT * FROM VEGANDA WHERE STATE() = "UNPROCESSED" The savings in doing this is 51 octets compared to sending just: QUERYID:Common Umm, not any real savings for any kind of CUA that I can see. > QUERYID:STUFF > SELECT VEVENT FROM VAGENDA WHERE STATE() = "DELETED" > SELECT VTODO FROM VAGENDA WHERE STATE() = "DELETED" Is this a common query? Find me the deleted entries? Perhaps if you were building some kind of replication or sync engine on CAP but thats not in CAP 1.0 and the usefulness is quite limitied. Again, you can simplify this down to the more compact form of: SELECT * FROM VAGENDA WHERE STATE() = "DELETED" but so what? This is not really a common action and the savings in storing it is just 47 octets over sending just: QUERYID:STUFF > QUERYID:Everything > SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED" > SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED" > SELECT VHOURNAL FROM VEGANDA WHERE STATE() = "UNPROCESSED" > SELECT X-MY-COMP FROM VEGANDA WHERE STATE() = "UNPROCESSED" Nice bloating of the more normalative case: SELECT * FROM VEGANDA WHERE STATE() = "UNPROCESSED" which you already covered first. Nothing new here. > QUERYID:MY RIGHTS > SELECT VCAR FROM VAGENDA WHERE SELF() IN DENY > SELECT VCAR FROM VAGENDA WHERE SELF() IN GRANT What kind of common action is this? How often does a CUA search for essentially all VCARs where they are either denied or granted some right? VCARs managment is NOT a CAP 1.0 concern (its "Administratin" and thus OOB as many are keen to point out). This is not a commonly performed query that I can see. Hardly a good justification to match the original intent. > QUERYID:MY CALS > SELECT CARID FROM VCALSTORE WHERE SELF() in OWNER This is another common action? Finding all calendars in the store that the CUA is the owner of? Again, this is hardly a commonly performed query and another poor example that does not match the original intent of stored queries. A CUA doesn't often need to check what calendars they own, they should that info already or need to discover it at most once per session. Thats it? I will now amend what I said before about no examples; I finally got 1. It saved my CUA sending ~50ish octets. ~50 octets of what can easily be just a hardcoded string that creates no real burden on any CUA. After all, any CUA that can hold a CAP 1.0 engine should not have to worry about ~50 more bytes... Not many examples of any kind to justify such an implicit CS requirement to me and only 1 was really a commonly performed queries that matches the original intent of the feature. The savings were trival compared to the cost for ALL CS's. Plus there was NOTHING in any of them that required ANY kind of load on the CUA; they could all be resourced strings that just get stuffed into the command and sent! I supported the original intent of stored queries but the current design does not approach the intent we created them with. I still think that implicitly requiring ALL CS's to implement this for such little benefit is a bad idea. I noticed you didnt try to show any queries that did things related to the original intent of the stored query. Nothing about checking for alarm triggers. Nothing about checking for calendar contents for "today" or "tomorrow" or "this week" etc. And why not? Because these more commonly used kinds of queries just cannot be stored and reused without being rewritten on some regular basis. I have a very strong aversion to implicitly mandating unnecessary features in CAP servers, especially when the design does not fulfill the original intent. Why should anyone have to build query storage into their CS when A) it does not fulfill the original intent of the feature, B) there is nothing in CAP about how a CS can reject stored queries yet still say they support VQUERYs that are not stored C) there is nothing in CAP about the CUAs or CSs responsibility for maintenance and cleanup of any stored VQUERY The single common example provided compared to all the ones we originally thought of shows exactly how little benefit there is. A few octets that can be a hardcoded string is hardly compelling reason to keep this feature in CAP 1.0. Why as a CS implementor do I need to design in some query storage mechanism because we left in a worthwhile feature that we failed to adequately design for in our query language? I should have the ability to reject query storage attempt or any attempt to refer to a non-stored query but theres nothing in CAP that allows me to do this nor is there anything about how a CUA can or should deal with a CS that tries to reject stored queries. While I do support the original intent, I think we lost sight of the goal and missed the mark on this feature somewhere along the way. As such lets simplify an already complex draft and remove the highly doubious requirement/feature. 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 004F90B585256D97_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 09/03/2003 06:07:24 PM:
> > We never reached a clear concensus on the issue of stored queries in
> > CAP.  The thread just stopped in mid-January 2003 and I still question
> > the usefulness of them in CAP.
>
> Is what Bruce means, it it does not end until he agrees. There was
> a debate - two of them over the last two years.
Check the archives and you'll see that its not only I who questioned the usefulness of the feature as we have designed CAP.    Go ahead, I'll wait...

Recently I asked for examples of where its really useful and really has benefit versus the cost and complexity to CS implementations.  Of the 2 people on the list who wanted to keep them (Doug & Andrea), neither responded.  Why is that?  Instead of showing a benefit for them, you try to deflect the issue now by saying already been covered.  In fact, it was not resolved.

We debated the initial idea way back when it was proposed as a solution to "thin" clients like PDAs and the like.  The idea was to reduce a CUAs need to recraft a common query and just rely on the CS keeping it around.  Common activities like checking for alarms, searching for new 'stuff', etc were all proposed as desireable cases that would be used for this feature and there would be lots of saved bandwidth and cycles.  

In taking a practical look at them in recent drafts I question their actual usefulness given our query lingua.

Since there is no way for any client ('fat' or 'thin') to create a stored query that is really beneficial and reusable I question the need to have them as a mandatory CS feature.  The query language has NO way for crafting a query thats reusable like "Find me the alarms that go off in the next 15 minutes" or "What entries are on my calendar for today".  Thats because we have no concept of being able to wildcards; the query MUST use exact comparisons to _explicit_ values.  

This hardly makes the stored querys reusable; the CUA will have to update them with new _explicit_ values on some regular basis.  Not much savings there that I can see and infact it may be more of a burden (ie: extra network traffic to recreate the stored query) than a benefit.

> Which is irrelevant as there ARE queries that can be saved
> without wild cards.

Yes there are; _any_ query can be stored.  However they do NOT fulfull the original intent of the stored query feature nor does storing them in the CS any strong benefit to anyone compared to the cost of implementation.

>                      No place in CAP does it say that
> you must be able to do stored queries based on time or wild cards.
You are missing the point or trying to deflect it.

The intent of stored queries was to make it easier for 'thin' clients to keep smaller footprints by allowing them to not have to (re)craft commonly used queries again and again; they relied on the CS to keep the query and involk it when the CUA needed it.  This is a great concept but we failed to design our query language to allow for it to be _actually_ useful.

Until now noone has provided any kind of examples that show why we MUST have this as part of ALL CS implemenations.  The CAP drafts make an implicit requirement that CS implement stored queries and I think this is wrong to do, especially given the lack of any demonstratable benefit.

Now that you've finally got some examples, lets take a look at them to see if they meet the original intent and compare any benefits to the cost of saving queries...

>    QUERYID:Common
>    SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED"
>    SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED"
Yes, this is a common kind of query ("Find me 'new stuff'").  

However there is nothing complex here that would require any CUA ('fat' or 'thin') to take up that much extra space or cycles to send.  It can simply be a hardcoded string that any CUA simply puts into the payload.  Of course you can bloat this query out to be explicit for all kinds of components explicitly (and thus miss unprocessed content) or you can take the more compact form and use:

SELECT * FROM VEGANDA WHERE STATE() = "UNPROCESSED"

The savings in doing this is 51 octets compared to sending just:

QUERYID:Common

Umm, not any real savings for any kind of CUA that I can see.

>    QUERYID:STUFF
>    SELECT VEVENT FROM VAGENDA WHERE STATE() = "DELETED"
>    SELECT VTODO FROM VAGENDA WHERE STATE() = "DELETED"
Is this a common query?  Find me the deleted entries?  

Perhaps if you were building some kind of replication or sync engine on CAP but thats not in CAP 1.0 and the usefulness is quite limitied.  Again, you can simplify this down to the more compact form of:

SELECT * FROM VAGENDA WHERE STATE() = "DELETED"

but so what?  This is not really a common action and the savings in storing it is just 47 octets over sending just:

QUERYID:STUFF

>    QUERYID:Everything
>    SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED"
>    SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED"
>    SELECT VHOURNAL FROM VEGANDA WHERE STATE() = "UNPROCESSED"
>    SELECT X-MY-COMP FROM VEGANDA WHERE STATE() = "UNPROCESSED"
Nice bloating of the more normalative case:

SELECT * FROM VEGANDA WHERE STATE() = "UNPROCESSED"

which you already covered first.  Nothing new here.

>    QUERYID:MY RIGHTS
>    SELECT VCAR FROM VAGENDA WHERE SELF() IN DENY
>    SELECT VCAR FROM VAGENDA WHERE SELF() IN GRANT
What kind of common action is this?  How often does a CUA search for essentially all VCARs where they are either denied or granted some right?  VCARs managment is NOT a CAP 1.0 concern (its "Administratin" and thus OOB as many are keen to point out).

This is not a commonly performed query that I can see.  Hardly a good justification to match the original intent.

>    QUERYID:MY CALS
>    SELECT CARID FROM VCALSTORE WHERE SELF() in OWNER
This is another common action?  Finding all calendars in the store that the CUA is the owner of?  Again, this is hardly a commonly performed query and another poor example that does not match the original intent of stored queries.  A CUA doesn't often need to check what calendars they own, they should that info already or need to discover it at most once per session.

Thats it?  I will now amend what I said before about no examples; I finally got 1.  It saved my CUA sending ~50ish octets.  ~50 octets of what can easily be just a hardcoded string that creates no real burden on any CUA.  After all, any CUA that can hold a CAP 1.0 engine should not have to worry about ~50 more bytes...

Not many examples of any kind to justify such an implicit CS requirement to me and only 1 was really a commonly performed queries that matches the original intent of the feature.  The savings were trival compared to the cost for ALL CS's.  Plus there was NOTHING in any of them that required ANY kind of load on the CUA; they could all be resourced strings that just get stuffed into the command and sent!

I supported the original intent of stored queries but the current design does not approach the intent we created them with.  I still think that implicitly requiring ALL CS's to implement this for such little benefit is a bad idea.

I noticed you didnt try to show any queries that did things related to the original intent of the stored query.  Nothing about checking for alarm triggers.  Nothing about checking for calendar contents for "today" or "tomorrow" or "this week" etc.  And why not?  Because these more commonly used kinds of queries just cannot be stored and reused without being rewritten on some regular basis.  

I have a very strong aversion to implicitly mandating unnecessary features in CAP servers, especially when the design does not fulfill the original intent.  Why should anyone have to build query storage into their CS when

A) it does not fulfill the original intent of the feature,
B) there is nothing in CAP about how a CS can reject stored queries yet still say they support VQUERYs that are not stored
C) there is nothing in CAP about the CUAs or CSs responsibility for maintenance and cleanup of any stored VQUERY

The single common example provided compared to all the ones we originally thought of shows exactly how little benefit there is.  A few octets that can be a hardcoded string is hardly compelling reason to keep this feature in CAP 1.0.

Why as a CS implementor do I need to design in some query storage mechanism because we left in a worthwhile feature that we failed to adequately design for in our query language?  I should have the ability to reject query storage attempt or any attempt to refer to a non-stored query but theres nothing in CAP that allows me to do this nor is there anything about how a CUA can or should deal with a CS that tries to reject stored queries.  

While I do support the original intent, I think we lost sight of the goal and missed the mark on this feature somewhere along the way.  As such lets simplify an already complex draft and remove the highly doubious requirement/feature.

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 004F90B585256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 11:20:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01819 for ; Thu, 4 Sep 2003 11:20:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84F7ggc057022 for ; Thu, 4 Sep 2003 08:07:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84F7gRQ057020 for ietf-calendar-bks; Thu, 4 Sep 2003 08:07:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84F7fgc057011 for ; Thu, 4 Sep 2003 08:07:41 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <5.2.1.1.0.20030903225643.00a161e0@mail.comcast.net> To: ietf-calendar@imc.org Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 11:05:45 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 11:07:38 AM, Serialize complete at 09/04/2003 11:07:38 AM Content-Type: multipart/alternative; boundary="=_alternative 0052EA7E85256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0052EA7E85256D97_= Content-Type: text/plain; charset="US-ASCII" Tim wrote on 09/03/2003 11:12:42 PM: > I agree with Doug that > there are queries which can be stored without need for wild cards, but I'm > not sure I see where the efficiency comes in. I think we all agree that not all stored querys need to use wildcards. If we consider the original intent of the feature, the current design misses the mark and the efficiency for other cases is somewhat tenuous. > Is it intended that the > stored queries be on the Calendar Store machine, such that a > smaller-footprint client can invoke them just by name, like a remote > procedure call of some sort? The original intent was to provide a means for clients to save on space and cycles by not having to recraft commonly used queries and resend them. Queries like "What alarms trigger in the next 10 minutes?" or "Is there anything new for me to look at" or "What entries are on my calendar for this morning/today?", etc. Its possible to craft and store uncommon or infrequently used queries and save them away either locally or on the CS. However making every CS support this feature that does not fulfill the original intent is something I have a concern about. CAP implcitly mandates every CS support stored queries: there is nothing in CAP about how a CS can not support stored queries or how a CUA detects this. This is another mistake that CAP needs to correct. However being a proponent of KISS, I think the better solution is to remove the feature from CAP 1.0 altogether since it fails to meets it original intent and creates an implicit onus on CS's that is not clear no optional. 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 0052EA7E85256D97_= Content-Type: text/html; charset="US-ASCII"
Tim wrote on 09/03/2003 11:12:42 PM:
>                                                   I agree with Doug that
> there are queries which can be stored without need for  wild cards, but I'm
> not sure I see where the efficiency comes in.

I think we all agree that not all stored querys need to use wildcards.  

If we consider the original intent of the feature, the current design misses the mark and the efficiency for other cases is somewhat tenuous.

>                                               Is it intended that the
> stored queries be on the Calendar Store machine, such that a
> smaller-footprint client can invoke them just by name, like a remote
> procedure call of some sort?
The original intent was to provide a means for clients to save on space and cycles by not having to recraft commonly used queries and resend them.  Queries like "What alarms trigger in the next 10 minutes?" or "Is there anything new for me to look at" or "What entries are on my calendar for this morning/today?", etc.

Its possible to craft and store uncommon or infrequently used queries and save them away either locally or on the CS.   However making every CS support this feature that does not fulfill the original intent is something I have a concern about.  

CAP implcitly mandates every CS support stored queries: there is nothing in CAP about how a CS can not support stored queries or how a CUA detects this.  This is another mistake that CAP needs to correct.  However being a proponent of KISS, I think the better solution is to remove the feature from CAP 1.0 altogether since it fails to meets it original intent and creates an implicit onus on CS's that is not clear no optional.

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 0052EA7E85256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 11:23:41 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02004 for ; Thu, 4 Sep 2003 11:23:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84FBTgc057596 for ; Thu, 4 Sep 2003 08:11:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84FBTTF057594 for ietf-calendar-bks; Thu, 4 Sep 2003 08:11:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84FBRgc057584 for ; Thu, 4 Sep 2003 08:11:27 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84FBPS5000553 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 08:11:27 -0700 Message-ID: <3F575618.3010002@Royer.com> Date: Thu, 04 Sep 2003 09:11:20 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 8.30 RECUR-ACCEPTED References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010106040404080209010605" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010106040404080209010605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 09/03/2003 06:06:22 PM: > > > I see that we have a Section 8.30 RECUR-ACCEPTED Property that > defined as: > > > > > > Purpose: This property specifies if the endpoint supports recurring > > > instances. > > > ... > > > Description: Indicates if recurrence rules are supported. If FALSE > > > then the endpoint can not process any kind of recurring rules. > > > > > > The Purpose text talks about general recurrence but the Description > text > > > talks about recurrence rules. This is a disjoin since: > > > > > > A) Recurrence also involves RDATEs/EXDATEs and not just > RRULEs/EXRULEs and > > > > 1) It does not say 'RRULE' or 'EXRULE'. > > Correct. The text under Description says "recurrence rules". This > implys RRULEs (iCalendar, Section 4.8.5.4 Recurrence Rule) and thus > excludes EXRULES. Why do you fell that EXRULES are excluded? Where does it say that? > Im saying that this is a mistake. Not every > implementation will support both RRULEs and EXRULEs so the draft needs > to be hip to this and not totally ignore both. Again - do you have a suggestion? > > 2) Do you have a suggestion as to what it should say? > > First we need to answer the discrepancy between the Purpose and the > Description. Then we will have a better idea of what text to add. Again - do you have a suggestion? -- 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 --------------ms010106040404080209010605 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE1MTEyMFowIwYJKoZIhvcNAQkEMRYEFClHInol BZpz3+WJMFQK1trcK9ROMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAG2qX5V8mxbMq3qcTCQOUiz1pRY7MtxrT+g2zTG+/due8iXmfPht Gu+G2CqcQPMZKaZtPDEqWiZNXkZJ7rhTSDOZ7GgN8My3Q6ljjrBHJ3XlrC++AkqsZGhyhr00 5TzM373QfDrxB/+Yg9bAEJ26HRMa4M39m6irwhWYi/rSsxLCkFk/e07k8+J2tFTUXPoG7Tb2 FXA+8vBxFDSP4rk2CceVKSZt2kwFFOfeSzmtlIJBAW8wR3Q0GMRr4zd9/Kr3TfrR0jVKsii8 04pmRPCKZqxMjW50oyF7FXdbswUvRYjKRohVHNbY+IxhaHP24Nsu9HftBTegSCnOkaxJRUBU CvEAAAAAAAA= --------------ms010106040404080209010605-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 11:26:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02208 for ; Thu, 4 Sep 2003 11:26:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84F9Jgc057255 for ; Thu, 4 Sep 2003 08:09:19 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84F9Jv8057254 for ietf-calendar-bks; Thu, 4 Sep 2003 08:09:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84F9Hgc057247 for ; Thu, 4 Sep 2003 08:09:17 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84F9GS5000528 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 08:09:18 -0700 Message-ID: <3F575596.5070004@Royer.com> Date: Thu, 04 Sep 2003 09:09:10 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: <5.2.1.1.0.20030903225643.00a161e0@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20030903225643.00a161e0@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040700010804000900040005" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040700010804000900040005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > > This may be an implementation question, but I feel it may be germane: > > How does the "stored" query save anything? It seems to me that in a > limited implementation (PDAs were mentioned, but of course that's not > the only case, I might want to implement CAP on my Atari 400 or > something ) the premium would be on storage space, and you either store > the query (memory/disk storage) or you have essentially the same query > stored mostly as literals within the program itself because the program > has to generate those literals to accomplish the CAP Query anyway. I > agree with Doug that there are queries which can be stored without need > for wild cards, but I'm not sure I see where the efficiency comes in. > Is it intended that the stored queries be on the Calendar Store machine, > such that a smaller-footprint client can invoke them just by name, like > a remote procedure call of some sort? Yes. -- 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 --------------ms040700010804000900040005 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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA5MDQxNTA5MTBaMCMGCSqGSIb3DQEJBDEWBBTg XkWFfFEx+2W2/eqL51o8p7UGvzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQDC3ty32DmE7h640jdNac0yc31FUHuO0dSnMKGlb59CJ1si ZeaU6S4yAsCOMvbWCblam+ixmKwxkixI5IR2+Xi/vfFhoij97cEf7gU4oJq2TTlkze11ZnWZ VoOZxvwulCETJLnpGSrB0GlUOmkYTEqaqBzW6eRBiX2ApRLkQmZ2RAvnuv5AhxWIet7RTUV9 xWirC352ZfO07/DjknTs9MVWV7TSwWRYtOVzALsey787iY0HxYEKVdJDM5TYBVWveWmTa01i BikK73D/rApOOTU2tRehfR6GF7h0L3x1S94cG+PvbDNgydi/6RX6OOcgPH5N/7hy0KwsTfcn Ao7RtHVIAAAAAAAA --------------ms040700010804000900040005-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 11:34:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02796 for ; Thu, 4 Sep 2003 11:34:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84FMhgc059402 for ; Thu, 4 Sep 2003 08:22:43 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84FMh6d059401 for ietf-calendar-bks; Thu, 4 Sep 2003 08:22:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84FMfgc059394 for ; Thu, 4 Sep 2003 08:22:41 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84FMeS5000682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 08:22:41 -0700 Message-ID: <3F5758BB.7070206@Royer.com> Date: Thu, 04 Sep 2003 09:22:35 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050503010901050004040802" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050503010901050004040802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 09/03/2003 06:07:24 PM: > > > We never reached a clear concensus on the issue of stored queries in > > > CAP. The thread just stopped in mid-January 2003 and I still question > > > the usefulness of them in CAP. > > > > Is what Bruce means, it it does not end until he agrees. There was > > a debate - two of them over the last two years. > > Check the archives and you'll see that its not only I who questioned the > usefulness of the feature as we have designed CAP. Go ahead, I'll > wait... That is what you said last time, so keep searching the archives for the 1st time you brought this up. > Recently I asked for examples of where its really useful and really has > benefit versus the cost and complexity to CS implementations. Of the 2 > people on the list who wanted to keep them (Doug & Andrea), neither > responded. Why is that? Because we had replied the previous year to your same claim. Go ahead and search the archives... There was nothing new to reply to. Same question, same answer. -- 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 --------------ms050503010901050004040802 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE1MjIzNVowIwYJKoZIhvcNAQkEMRYEFOl7xdfq 7fvYBmqhzYPbtf/NCWzzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBACetROXc5UkVEUCr7HkiERDwb+Z3e9wZiyQNn2KTUf9W4kmeWpqY 3+Vw7v4aT2PRK5PN3izByE8AFnh+PWy8mdEpcoOEtVE9JvwzkiveQPbNT2TrmQkeNEElSwD1 6ZdZDDghx3FdIXI08xlywGhh5g9fwUOTzXMgJoUI4fkD6uI9wdo0hfq8+XkMAtFSoLUE2hUI IpAox/iLkYSPKyB0eNC6NkPV0AWr/gHc5DzDFyD5huW1TzdKBeysd2ItHkvUvidmfYz9JBI2 8wOIgTnM3zq5T9EbJ2ALrX3YApSaM4kimnPrZh5ObDvQzw0BeLrECLQL5NTIZitxSa4eA8WC KicAAAAAAAA= --------------ms050503010901050004040802-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 11:36:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02922 for ; Thu, 4 Sep 2003 11:36:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84FJIgc058880 for ; Thu, 4 Sep 2003 08:19:18 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84FJIjg058879 for ietf-calendar-bks; Thu, 4 Sep 2003 08:19:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84FJHgc058871 for ; Thu, 4 Sep 2003 08:19:17 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84FJFS5000635 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 08:19:16 -0700 Message-ID: <3F5757ED.2050706@Royer.com> Date: Thu, 04 Sep 2003 09:19:09 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040703020306030302040104" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040703020306030302040104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In CAP-12-a, under Section 9.6 VQUERY Component is written: > > Normally "NAME" and > "QUERYID" properties are used when looking for a correct stored > "VQUERY" component, or when storing a "VQUERY" component. > > Im curious to know when we decided that the NAME property was to be used > for identifying the VQUERY? Check the archives, I think the requirement came from CS&T and there were no objections. > If its just the "localizable display name" then what use is it in > looking for the particular VQUERY? Isn't that the sole role for the > QUERYID property? If not, when is NAME _not_ used (since the text says > "Normally"...)? Correct. They wanted a localizable display name. Not everyone has to support just one locale at a time. > Since later text says: > > For a search, if the "TARGET" property is supplied in a "VQUERY" > component, then the CS is to search for the query in the calid > supplied by the "TARGET" property value. > > I suspect that the 1st bit above is just poor phrasing and there is no > actual intent of using NAME in some unspecified combination with > QUERYID. However I dont want to second guess Dougs intent here. I did not write that text. I'll change it to remove NAME: The "QUERYID" property specifies the local identifier for a stored "VQUERY" component. The "NAME" property specifies a localizable display name of a stored "VQUERY" component. Normally the "QUERYID" property is used when looking for a correct stored "VQUERY" component, or when storing a "VQUERY" component. TARGET is used so that you can use stored QUERIES that are not in the current CMD/TARGET, such as when you have access to more than one calendar. -- 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 --------------ms040703020306030302040104 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE1MTkwOVowIwYJKoZIhvcNAQkEMRYEFIp4N+hm mm9Qmw2OMF51zJNHaES7MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAA2x6lQOM7HYeXuz5U9p0eP790SILfaZoTKDtB32G68T/+QJP2Bb seNHo9+oBKdW6pWHGmt8R/KhLJdfPdg6ECLewvg9fR964t7eVVFoEE8I9/9SFf2o8305DCs4 vf57J9lh2biU3fTA3WQtUXXzu88NEcuhUp7Bc7lHbHVd3JYAgr6CrGncdIhBrmo2PKXPCIQG YMTibuG8TWvOIsu2qH4JhTHqdUeOMI2SUJHH7/UE0ouYwzHieBCstcNKKCriw+ntOdmIc2G+ 5D0C7oeXkxajWfZ9Di3uXxOTWoftFewzZV+PPSn3UBfL6yaBPwekfekjbhl5pti69Aub+tpN g7MAAAAAAAA= --------------ms040703020306030302040104-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 11:50:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03760 for ; Thu, 4 Sep 2003 11:50:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84FUCgc060902 for ; Thu, 4 Sep 2003 08:30:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84FUCMH060901 for ietf-calendar-bks; Thu, 4 Sep 2003 08:30:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84FU0gc060871 for ; Thu, 4 Sep 2003 08:30:11 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F50FFA4.9050107@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 11:28:50 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 11:30:07 AM, Serialize complete at 09/04/2003 11:30:07 AM Content-Type: multipart/related; boundary="=_related 0055075D85256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_related 0055075D85256D97_= Content-Type: multipart/alternative; boundary="=_alternative 0055075D85256D97_=" --=_alternative 0055075D85256D97_= Content-Type: text/plain; charset="ISO-2022-JP" Doug wrote on 08/30/2003 03:48:52 PM: > I have placed the latest edit of CAP for your review at: > > http://inet-consulting.com/draft-ietf-calsch-cap-12-a.txt Since the editor is busy revising CAP and reshashing some iCalendar issues I thought Id take a shot at doing the DIFFs between CAP-10-17-FEB-03 and CAP-12-A. Once I did I think I know why Doug was reticent to do it for the WG. Here is a windiff view of the changes: with CAP-10-17-FEB-03 being the red and CAP-12-A being the yellow. This is a LOT of changes. According to diff, there were 707 changes. This includes 1 very big change for the TOC and ~140 changes for the headers/footers. That leaves ~565 changes between CAP-10 and CAP-12-a. In looking a bit closer I see that CAP-12a is ~7 pages shorter than CAP-10. I also see some new sections in the TOC so Im very curious to know where all the changes came from? I dont recall seeing much WG traffic related to CAP issues lately and I certainly dont recall any WG discussion on some of the bigger issues (at least to the point of concensus). Did I miss something or are these just changes created by the editors for WG review?? Some of the changes are pure whitespace changes. The first content diff was: =========================================================================== ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 23 Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 23 Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Since this is IETF boilerplate I dont know why any change, let alone spacing, happened. We already know that there are problems with the XML->HTML/text converter and so Im more than a bit concerned that there are changes that creep (additions or omissions) that should not. One of the other changes Im leary of was the change in the footers: =========================================================================== ************************ e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 1174 Royer, Babics, Hill, Mansour Expires May 4, 2003 [Page 21] ? Internet-Draft Calendar Access Protocol (CAP) November 2002 ****************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 1117 Royer, et al. Expires February 28, 2004 [Page 20] ? Internet-Draft Calendar Access Protocol (CAP) August 2003 The list of editors was replaced by just the current editor name and "et al." Im not sure that the new format is correct given that Dougs only been the editor for a couple revisions compared to others who have been involved longer or on more versions of the draft but I could be wrong. It just looks like an attempt to give Doug more prominence than the other editors given that the format only just changed before a push for Last Call. Has anyone else been able to get a more accurate picture of what changed than just using diffs? I for one am more than a little leary of changes between the drafts since there are known problems in the XML converter tool, there are seemingly unnecessary changes in whitespace/biolerplate, there are new sections to the draft yet the draft is ~7 pages _shorter_, that CAP-12 and 12-a came out so quickly after CAP-11 and we have not really discussed CAP that much recently. Doug: Since you should have an accurate idea of what changed thats more reflective of substantive changes, can you please provide the list with that so we can feel better about the more recent drafts and we can foucs on them rather than playing Hunt the Snipe? 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 0055075D85256D97_= Content-Type: text/html; charset="ISO-2022-JP"
Doug wrote on 08/30/2003 03:48:52 PM:
> I have placed the latest edit of CAP for your review at:
>
>    http://inet-consulting.com/draft-ietf-calsch-cap-12-a.txt
Since the editor is busy revising CAP and reshashing some iCalendar issues I thought Id take a shot at doing the DIFFs between CAP-10-17-FEB-03 and CAP-12-A.  Once I did I think I know why Doug was reticent to do it for the WG.  

Here is a windiff view of the changes:


with CAP-10-17-FEB-03 being the red and CAP-12-A being the yellow.  This is a LOT of changes.  According to diff, there were 707 changes.  This includes 1 very big change for the TOC and ~140 changes for the headers/footers.  That leaves ~565 changes between CAP-10 and CAP-12-a.

In looking a bit closer I see that CAP-12a is ~7 pages shorter than CAP-10.  I also see some new sections in the TOC so Im very curious to know where all the changes came from?  I dont recall seeing much WG traffic related to CAP issues lately and I certainly dont recall any WG discussion on some of the bigger issues (at least to the point of concensus).  Did I miss something or are these just changes created by the editors for WG review??

Some of the changes are pure whitespace changes.  The first content diff was:
===========================================================================
************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 23
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 23
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

Since this is IETF boilerplate I dont know why any change, let alone spacing, happened.  We already know that there are problems with the XML->HTML/text converter and so Im more than a bit concerned that there are changes that creep (additions or omissions) that should not.

One of the other changes Im leary of was the change in the footers:

===========================================================================
************************ e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 1174
Royer, Babics, Hill, Mansour    Expires May 4, 2003            [Page 21]
♀
Internet-Draft       Calendar Access Protocol (CAP)        November 2002
****************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 1117

Royer, et al.          Expires February 28, 2004               [Page 20]
♀
Internet-Draft       Calendar Access Protocol (CAP)          August 2003

The list of editors was replaced by just the current editor name and "et al."  Im not sure that the new format is correct given that Dougs only been the editor for a couple revisions compared to others who have been involved longer or on more versions of the draft but I could be wrong.  It just looks like an attempt to give Doug more prominence than the other editors given that the format only just changed before a push for Last Call.

Has anyone else been able to get a more accurate picture of what changed than just using diffs?  I for one am more than a little leary of changes between the drafts since there are known problems in the XML converter tool, there are seemingly unnecessary changes in whitespace/biolerplate, there are new sections to the draft yet the draft is ~7 pages _shorter_, that CAP-12 and 12-a came out so quickly after CAP-11 and we have not really discussed CAP that much recently.

Doug: Since you should have an accurate idea of what changed thats more reflective of substantive changes, can you please provide the  list with that so we can feel better about the more recent drafts and we can foucs on them rather than playing Hunt the Snipe?

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 0055075D85256D97_=-- --=_related 0055075D85256D97_= Content-Type: image/gif Content-ID: <_1_079569FC079566400055075685256D97> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhUwDQA+cAAAAAAP////gAAPj4AMDAwICAgNDQyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAUwDQA0AI/wAJCBxI sKDBgwgTKlzIsGCAhxAjSgwAoKLFixgpYtzIsaNHjxNDitT40eLIkyhJlgSQ8uRKky9jyjTZUqRM lTNzdqxpMyZOnUBp8pR4c2hKlkWNQkyq1OZPkE0fCphKtarVqBGRany6E6vVr1WHaq1IESdXjlgD gF07cixSsnDNMlV6021ZuG/fbtU712jRjHhJ3uWL1yfWunsJJ+YruK9Yn4HzLoZJ+ezGtHUBK45M 2DFPxJoHX/xpuWvUzKI7cx5cevRhyIvlpnY7M+1asA9XM85bOCdm2Js1uyZq+DTkyrzJ5hacm+WA 59CjS//9cjbLpWWbE2+d0evtq9ivX/+fqLt3Sdvfw5IXLlkyd6FNMxdOzLy53uwoxzdNr351VuSs ASDdgNFRtxJ+SwXW2G7JfWTgeQB2xppo7+lHV0tj0bfbU9Y56B1/Auy11WwiNuhZTUmZqNKKQcFH F3AZXgahgAQS+KCDvJEmY1z35XcjVNXxWJ+JpsV3HGXt4cfeiRgedxeLyTVmX3HxYbhch6NtKB6V SoE41ZRmSRkXlh5G5WWIPCYZ4JLVHWaleAFWWKFyxgW53I6AaVjba0HOiKR7e9Z5YJbIdXffmD5+ yJ92hNo12Vs12sjngWKeVaJ2kQ74Y1ftZZmdebRRKuh5LC4oJJwiHrUpWqB+Sp+Sc1r/6JdhUSo3 3k7jZTrdpH4ieNmTndKo63Or4gkTo8Bip9Kw0BXLnpjdJRgjl7P2iSBxOaLFLLGKpvdosp7aGquz jYqL1p3mbTsAeiDalyqgDT6pqpuqTkskZ6GSOqqH96YZ7Jzk/tkouI76Rq+P/26GrFbqBowvwebG Gm2V9VrnKr9y8oojxJ1qByyTR9G6sVYUknnuviAda2uad5oMFcq4tkwTnP0KO6zDW6Ibb8wZw8yq y55yLKqRbaYsr1356kv0oAqSLOOENQ+3NKnTVkpzqfP6/GuSMaZ2NMj5Fdd1uCuXSO1QZzKqctX+ 0ukSZm9+fWmeQSeqtaEaQnvso0q//2hn0HR7HbXUF2btWs7BjhkoxYmurfCWifddLaW9XYzkgj1P PbLOgvOdeZdemvpp2yTKGpLpn9EqM+bZBgX3vI/jaO/QflOe9Mfgjtvtd1P++XHSYLt0JOZzF7p4 7fqeqiPZAGsMpOB0C/e5UWnzrZqEBt99uMpmMwjptjirbazVGjV88NuO0wZl5VlrnrK9BMemU/jM Mb89oVY6j+vMoVq2YvvIk13uQrOj6YnlTQJrG76y5779ySZc0Dve5Ki2s/UN7mUNZJX3xtci1KFI dZtbifm0xz/f1cx6GCwcwko1I4m5yC9xOyGoXHe+tsjFeC8ZIePeBqXlnYtwTtHfD/939jMc0m6C sksg6ch2Np5Ub4bdY1vw2nIkI0oRaEB8TJ8qpzwuNu80CORecC7HwAA+T30qytGI7JbBrU3mgV30 YFZe1zj7OW1sX2zjs7I1wLqlJX+NI54Cr/VHtIVugKQppCLlGJ7bKfKREUnbxCDJk4ZY8pKYzCRC tMi0DrYofJ7sIChDSUMSuu2REuSkn0hZRhgCsJAkYyPo2gXJC56Seoe80PWaWJPqIYxlMzyiIWkZ nigu0JaMDJu1gsO6G/KySctk5jGBVyQzcip2x3QhKG/4rfI8M2RbNI+enDnFnhRtg6VBYTWRCCSk cdGdebSmBsU5H39JbJRme6NpdCj/zwLqRjbSegg/cUlLBVpIKAct5+mqOEdUXcmbwnTiIXv0n3li MYsSJSaYjLfG0QxUlfzKprQOd9FkCi+a2DqU6GymK3YtaqQRqyedbIlPCvluo/MToj/n0zubItOk I3nirUwov3vu7jZ606cFU5m6ohXVWGwqkx7x17py/Y+mOiWg/ZIlv28qc1Brelcw48lOTq2JifA0 KVDNCdaxaumhCl3P39YWP658tKm24yrN3sdUFOUPVbUpV0Q/eM79OW5BdyVsJ6N6OdYktiVP9Gn0 PIbMUdYTd9KMK1H++rubqsaAGV2U0UbEvdF5lYeBXJ6rJmTawUKzrSrt0V5LOVUx/4qLKx3tneQO WLE0LsynjwVnJx+q15ZNKbhfbWEPU6rENpkpdLdMnwavJMuyWvRdy4XXaYM60VbNVretHOZLSQrM IvYVkOhbKgTj6NzaGtSe8KtsVgfGIPK9N4UEFa3F2Ga58wqXgt38WuRc+8rTec1UBOzsbkPrrd89 sI+ENPB8pZuh+DkNtIqFkIPJC16ygvSMYiViMKWqQh7OFoql9W9yk0jN2+6SwCvma55sykKKIPek bZUZGnPnYbwmr3V9VF6BfSzAsRFRZjem4t96ujcxliXJbO1VbItHYRK7coWIHDBc29vPwPFxOEyE 8kKXCSYaUzXC5KlpnC7bP81WlP9yqr1jY1WMYykjWEpndTNMMZbg9bnwlh+OmZC6WVU9Uze9pPWm erlsXTzlWaYKZnSgh8ih9SJ4u1Fm8Zcl+8kJl21unuORmNPcWwXD8cX4nfTTUF26n651zHmlqmBb nGoiv6+zzRTjqCUiVEffj9brVDXeTsW+a0ra1oa1b5ubG2xk/7DGxBbYrt9MtSjqttWYDklkZ71E bdYwiFw7sictm0B1lvTVcoVzhCpNm2nv+dbu9CKzrSxsq9rbhxjd7FHZcmfDdsTd4DXrvVpTH9S6 F3JanedFAC4nhe/J0A13ddnC+5kw/qVWaqXfiC8t4GNnWNNktLQaq1vvkNcKs7z/YfhfHhyZU3v8 tXYuLz1JwnCh6inko+uxX+sFvM51rebQPXllQkzxj7dTrEJDMyX1/cspd2zpV0a0QaH+x4yTiOq1 dBLWh6LJrnv962APu9i7XnJAwzLb6V7lgmG9dpjT++wv/y/IWRn3GPub7mhn7tzx/naj353vbZe7 jAEfeLufLOt5p3bfwQhx+RC+8Aa3IeHRO8uXolLnkM1l1c/t0gYzftHN7qXm/VpfOnNXo2HL54hD n3nUp7ljMq/7SXzZ0OKFtSJAJybSupo302faaOVlXbwT/26BZzatRXe7jMep6NVPstGGyizvf4rP f5553ofvsh0lC0fMp8TmsA93/2JUXkVZ33yatfa7wgnNfPmaMnLGxF7jndRySEsbfJ7evawLxfn8 6wx7+kR9/hdvldZ78xdO9GR9cEF+KFV/h+Vq2+SAHHcZDBhr52cxEVGBGlYeHLIeGhhSBjgzxVR8 2Qd95hcv/zFHJPgr7xdptbdGCYJhyvd3L3hb5wdjdSZAZSYrVkR8UjFRq4UtzlRSGsdWZ5UauWd5 KyNTLBNwi/d9uURfKAh66TeD02VEW0ZaMih4DuQfI0VlPqgWQacg76Y2RtWCMNhDg+R++zF6gmRB uTVkoldQ67ZqjXSAsGWGoQFc+IeGpiZbARiGkhSA4qM3eEhBFWZmAyZ7SqZu3/+FVs5XgmUXS591 PX9GR+lFRkr1b33Yhu1CgJAIVU+IEpJ0O39nER94dGwSZ95neBykXgWodCqIhjL0gCv4fOLlLYLl c1qYfFBIh6tIiZeGg40oZQNjWueGixXXWzs2jIojiEBYYQnIP62YgyBmcnS1hIwYRHYTimt2MZRn gj14YeR4J0moi96lUgqWiv7Gi/FXjTYEO6DWWlIYhqDBOSZDhSzoieMFjo53iGVyYig2jpK4jIHk a9HmjKz3i6J1ioEoi8rSgprmZ6wVeeLofDeHLk5YkHPYkNjWizkDjyKxbVUFNXu1ha4YPXZYemRo kZP4VO+kelYnkUa2PRvme2z/x2esiDilRXLOtjXSw30bIodWuFNyA0H9tY05CW88KYLflYbceHAx CCCWQ11YRYszpj5KQlvaR5UnCZK/Roy/Zxq7GHC+0ngxZIM/U4gA+TI9dyvuQifseDIF1CFTiZNp x2JJKYxXhZY8B18aqR/cVoVc6HA+JVfqRJgpeYKmY1sYcY6840FeJoqQd3oeWXw6ApZiqW3dxX/1 RSGQiVRZ2YGGCI10+H+Ko5Cm2Y9eWT+nuJCLKTBVyWrO0YldyV4uQ2NEWZgsuIjpw1U+qX47tYHY qJQT0WuC1kX9R5OrFkepMpdQxUL192iVOZZFpIZW02Th+JIPWDBdI5IStkIr/3kps6FynGVyekWZ sGmNgvZU9Ig3uxmbxLZm7RlLLvmT0lNudbiR+1hikoeaiYRHLJUpmBiPA/edTdOWyUZf/mhcMymV K1k1QrOZpCaeQnk1DWKepXaE5OgvGnqQRxN/jLWexchnkLNfDlednPmJOpaH8hKcRRktaORrLWqc TJeJsBFkNqp4TGlRJ4l9ytiR6Ghp2XlfJDqSY6idTUmeD3qbArpSWWaPcYNZ9oWaO3qLJKVURQps +Raj19eLFhZpijl7nclj9melo8iez0Z0bBYn8Xmfm1WT2bilKlqhUuc9AMqlQbqdr9dMVPpO9ggc EJYvyYhuegd8nPOWJXSlP/9YUGZmiFsWqOfEoX0pomMajxYKOE5JRtC5Rzs4qFe5Qwb6qd1TKZ1q VYEpfHq6p7w5bLfHXu4Bo63KYWmFjD0Jp166qWoSnRSFqfyoi2/IM50mkRxTMpXIpzuHZYlzlOrJ kbmqjbmWogp6nU55mFFyquuWaO91hlK5OuhnpGlaotcYe93WpFGHqRGyfqjmrLNKjRt0ZOVjmxeJ OBx6b74onyd6pgJ6r2ranLmmiAIIRqX2VqtKoYdqbE86MtPqTzrqr3h5sNRKnQ6YU1gZl7KpQdg6 U4BqiUDape3KhNIpbn5ZRyyHc7GKqx+LcFW2rA/Lo+2YgHf2P7KKr4/mcxv/a7Au+2zlGrMee2hO WqqAWWiSulglOTsFa6g5O5zaNXz8yao062R21LH9Oa+J6q5GC555yVdhOpj8apkNxl9h2W7yyp3A 9IfreqnW6UbL9rItG5GZ2JeQqJrsSrNJl47expwBFopdm7bRl6KJObQttEsRNHIo+7S/abQjOrf9 mnA3mK4DGikF6hTNubGFirRYmq522WLIurnFhHFCO6y/yjtmC657u5SvibgmtLB9+2WTN4BSxLCg +7MhK7WPWyPVl04Sp7jianxcuz8ZK0PsFrtUm7jV8buZKa1yxqgZM25/67SFO6H9IrdHarqGyWwL 07MQabjy4XJ1CrFAOXCh/+ZQz7u7yFuPsIqzl+tWSpRzLxSeEOqwtiWx03ucY7hUQcatPzuxV3S0 Ziec+SlyHNu/s9itrJtnh/mm5PuK2KS33RtJ0Yh8Jtu07WuQOGrAKrmcBFyapGOpusu31/e/7FuR vpq/9vt0qIu21Pu9aBWlE3yj/im5tQpq+LN16cu6h3K1NOzC4AZtLpjDKZxg+4q9W4caE5dIPmy4 yBImR/ysGKrES+y/6yXET6zDEua8U+zBjXXFEmEAXNzFXvzFYBzGYjzGZFzGZvzFY5fGarzGbNzG bvzGX1cAcjzHdFzHdnzHeJzHerzHfFzHZPt4DVzDf0ZKnSe6UIyKY0vBkv8HeJyrvYCMwll7uo8s wCk7r4C7d5NMyXS7dKrbu5NMP/hJse+byR28opZXS8ZLyvPrvcT7yKCMeMr7j6qsyYvrya7surMs xT9sy4BMbrlsuRJMy0kLFJHrvouUvcg8wlF5zOaai4Z8zChJpq73G9Hstc9cdZHYwq13ym5CzPuG G3BztlPrzEj1eaRrxUg6zcwov6VMv+r8n+SKvo3KzakXfLUrKc/1znEazxBHe5KLcvqIzqbseQYW fmsSmvzWp/oqzgLtzvSsfwmXzcKczqcM0cLHwePMYKJr0Z5JuxO9y5v6qmPEhrJrz7DXuJDMylGc kSbdydk4RtRZzVgMsxz/yISXrLU1LX9Yq9Iv3X7RetNdKH2p27bBzJMhGMBAbV5HDbSlG8lXiKfr K9HAvLxQPXNS/dFO7bCq2tNEHXHW6rnf2s48rY0jfXxJTZk+DVHyHHFYmE1S7csYl9Zd7Xjc5NZv 7bp1HWdXPdUXZ4CqercQ6tegyMtYPdYLjFv6G8hFfb12vbIpPcxRbNcyedYqKX8xedc0Wa8LhNEN bdiBiWJHHcsis4ueKb26nNVLUteAqjt4C8R5O9cwstRg7dI13VUJZLyCbcM0kcoyObtuk8oQXG4S gdtlTZqQfdqendZGHIO8rYAiaFwBANyOO1PQbWOJfMgLLTXwkSvXzcT0/0k4bpNQok1m+0hX/0Hc y82XKQjbhbXdsCKYDK3NlTwxF2aV8Y3cx81TDrrPKP3YggyXIbkdoILQ4ByiTm3a+P3fQVhRLL3T +Z2IKUWpmB3YaYfYrqm8/rzaScXa7/uFRKWxuNfdDEnQUog7OEXZv3bRCEWVM1vL6AlFFlvUfA0j lmilaOrfi93REY6htI18O/66a03EvTrDYb3KD048Hv6IE07Cp8SgO9bjaUjkpROvzFLI5SyEMfWZ zazRV35tKEeGXe1LgKPZ4SHdWiJ+ogHciQaTVbuaX6vkjhLQYn3kTWzeFtzIz8vjh5W5Mg3S5lJ6 QsnhJQ1kifrl4w1bsf8abp0h3VADLf2G5wk8mW1uin2O2sxz4qBI5TeD15+9f5Vr5QnN59OIyFX+ bVUMpTfrzVgpp9KFv/mFjl+9RFz56htt28Dm4BABfsfbyordcBK+R7RbzAqt6PoJ4cpMtuQUNUTo f3LONS86vjNN7PgmjVuO3bODb9gV3SLe4re+fTIO17MLnEhB4F8xgVD7O809nC/qm0b+3/kp7oSd 4PM8pIq+lfdX6pnt7La6li0e6eSl5W6l7fhOwM3YXO8ZrtEOMeZ+R5Xu2Qg62+IjpQNr2Vrls8s8 vBYM7Dc+5277n4Nbtskb5KNNJO4ovsceylYLv/Udqkyuif86GGaOZ/7/wb+F7cCf6Ll/+hPkDh5b tfLlm9HW7ujSGL7NPY8Cye5Aj+cQDVg+pOkthde7l4+qnsHFpZfsLSpyxtZQ3qF0PbJSZ5bqes+a 8s3lvpdpRJAcv9g2rolF3u4WX9BN75gILt+kmKS8Goj9bPep+5DIPOMIyKtz1vB0zraB39S8pveA /5U7HxbAXvgqu9alGNx/TlmQnvDx1TRrvuzEevbeiS7p7mc3jOmQH3QlTK8Th+KL6uSZXu3ezfYS mJpbX7LWJ+N+P1xVRmW4nuOcZtWPH+QxhNjBnftiyKIGzfAM7PZ9j6LPGCYkPbz3Y9sGzvrz3Sqb SFzpDlEAbfiDH/p2/2isle/n1/5PrMXy5/rPa56aJpkbi08VTrha6ojBLwz3TyM39h7iA5+/iuFg Bx/mnYnmZg8QAAIIDFDQ4MGCBBEuZJgQwEOIESMOHDhR4MOEBi9KrBhgwEeQIUU2JIlQYcmLGTFi pOhQYkqNL2WeLNlQwE2cOXWqrEiQpcyMDnvOnFgTpdGWHFsOhbiUIlGiSElCVbqSJdOiSX1SzSrV JNeVPV1a3Bq2qUi0Ib0ypNlwK9awKq2eTFt37cK2bGNWDZqyadC6ae8i1Fk459i4TxUrZAz272DE UJkmlfv3p1awkPdy7Wh1sdahmzNrhjtT6MbJcxurpkq6NNDOnxefbP8KMTBa147feq6Nd+5r2JoN D3f5NPHm2LqvQtaNNejX3sqVam5eO6/YjTNvjyQ93LBYti+Nc1Tu2nvhjr6jmz4+1fz5w8uxdwb6 s3l3+DjTh/bLP3320YTL7ya4Uluvsu3UIq06spLzyyfwEgQpN8ecg7DBsSJrbcEK/6ssq/6kk+8u BhmzsDLgNhRwwPnEu5A1Ed9j8TXKLNNOwgFkzM/AGu2z8D7qKnRRLuNOLI/DzFB7sUj2UpyOOSEf Wy8qADsMcjTexqsvOye7GgxIF6n0b0S9FkSqLBgtYlJLzpBs0yzJAJzNSiiT5K8+7Kxzyj03W1MS z+hapPPLKEsb77P/QI26Tqr7mgz0T4pwzLHPOMnjMsQHNYyKUirjzBNRmGpa9MwoVWPSrDWBrJMz GJMDFVVFKcSywEtBs29QEjsk71RbFfMIR1lZrRXO03yVLtgNLw3RVTZxXavRKmcztkvTOHU0tdDm FJFMr0bViNdhMcvT2W4L/XNZWkM9ysxYQZ1WMmq5ZVTXNbXdFbV2qTvzQ57Yw3Rfa2F71FBUCZJU R/gclFPP2HwVNTeA0bSuqGWrhPfKNud0DtFmVVzVz44LdndPtyCO1eKBd4Pw4IDDNBVdLmV7uGVL jeyX2SMxTnZLdy+M19uaBiRQzcsyfVVVQpOsWNqjc/4Y3qXxhWnL/wCf3jRqn9msiGWdoSYyy0O3 lZfUAB/cLeSJM2ZuX0yLTvFnoFESEtxmCQZY35M9NDttosmdV+mb+675Z2QvfpHv36a+e+28Nab6 Xb+RElqAfitVvL98GZ8Z5SY5RjpXLOc2lvNNu+6UdA9PVZdPvB9GHfNz0RaPZrLE7BnWmVfcMdmj 7b0YssnT9TzlyBUtVWofGb616sGCF5m355/iGnihAy82ZczUTvrNylnjGO7CS8/U0svhHtt4O8sS 1OfamSeR7dOqUnLMz9cKnj5ih23b/Wfhl3P9MWkqOFZzVMGWB7bVlYx2E+sZ/XgyvS/5r1ha8hz4 FhiXimHvXPzrVv/Eege7+QEAgqDj3t5uF6IRPote9JGN2Xz3u+2p6GU1YiHpSkdAnukphDrsTeZi CDVifYpvkQLWBUOoLXvJboA/vNrw4DQlpzGxWlOL3b0sszgpCgxFKKOgEr1EQhmGDVsUE+ASwegp SOnvMvjT3vvylr/2/WdvHmte9QwIPRM9sXi5W5cJ1fe1cbVRhbNSU7bGp0c6nvFqPWyQC62SwnIp jYq3QmKabpjFIaGpL36cYyL71zgy3ilc8QrfFK/IxjSW0YyDFFYeHfnKY7HLdUuqYt2iqMhqSQt6 lYxl647SNjZmD3EwxCWgXhYzPJGsTKa7ViP5Rcb6RZJVwTxcuHr/icMwbWxhGLRkLrEpvwwm7kO3 ZKWfwlkrLxKznF7zI3g2eE1M8kVr4nTZHuVWNh6lEYocZJT/GEhLK0bzb61E5ztRac+pmOtdFLSh IKXJu1OSL52XvMv9YGVJu/mwmJkMnPdq9ysJlTKZ/+qmqTT6yc3Fb5+Ja+gXUbouOe6QpT3kYzyJ VkOLCRGebnRdDV01xK0VkZkCy1I9o3fSh6Kxipx7oTo7+MZ3HrOTDh0oyFqVthYRTpa/POg2/7fT dYqJo098FRY3eq8fvdJ8j/lm+9p5zpa61CsWVdb1mopQtxwvgFNlIVKrCsQj7k9sbLUpFCtIvpLO zpfuCexdHwTJ/7+ejml4XClVzaqXqP1IYQKVXPXkmCor9gSyZCuh78boVqdGNpd6NJJX+Ulaq/KS rIld5VN76lrBUdayRqGrsg70TxEKta02oiwq8UdKI4btpv6KK2HP2siFpXWzu61pya4arZmSc652 jK5XFaZMvIjUqAbtplaHWs+m2k27qn1cTjNJ29pKxXlRza5yX8tbz45PiLQy73B1e1zETvR8opob c9XY1+qG1ZSs9S0P8RoeScZxSji9bFKbuFx65tSvsLWcbxkazNGir5WivJ1jFetfTTZYdRKj7j3f 9M/9UuwhIQ5afu1Lt8HGLaGAY3Aw1zpgmHKVeAwdpictPMUPB/82jhsWsTmV28X3Plg90/ytKKl2 XwKHzoBJRGyLd1xa1rY2Rvhh0fOKLFUvK/C2WOPhp5ic5RdDOaCINDJ7Z8fJKKM2tRy+MJfd21zn KtiYaepYINO8zD46uMd6pqig7zzPP2OFxi528ul0+GOTrfm0W2ZYgrc7o9/Ouct15rOBUdtV+Ab6 yEQ17P4wTeYdrZjBWI2bjvMaYZ3SaKqNXnU2uys7AdsawlSes5XXmulEyxS9Epn0l3emX2Mypdm3 JiiRZxjfgwh7yjtDm5XFJl6+lHfXMxZuYd2G3QkPFty5NfafwdprcAJK14DWNnRKKOEf89rONcO3 ore1bgdPl9H/nG1yh0Er1jGfV6K57TDB4VzpleYb2wXv8+ssjeUgM7ayDP93ciN+5W8nt9vEnvaw IcrUizs849Z9G70x7mzADlPiE394w1M9alJTfME4JzS5Q+rxQTOaiD9XOHR5vvNDb7tSqH6xyln3 yzMDZ4Ke3vdHuVhAegPcow2Od3/NzWJduRzIME952F9ddOIOnOvgNYnWVYbyzXr9ucClUVcHUnKl l525Y2R7tt1u6IUrWcr2hvh7kxxUoqN45B7t1ZspHfPAa9Dp1DZnDvdqNKp3FtQp/+zN653t4+HW iXK3H3eBO+TfOJ7sBo77IU38pK+nNXr/xDth8jtEkqL75Tax//G1fVpX1VN+6b5ecRczr/OgZ9C4 Zz5xBNuF1qJiuMJVTztovR3svxcVp3QPbuJjz2m+yqn2oE+fg64P/OOnv0fbZ6kwk054dq6P3Q1T /+otj2ZHSq/cPBVyJ/dr/uBjiN4qtF/DnPoTvkU6PzcbN5p7vAsLvF7xi/ETDXbKs8Nar+nzO7d6 Mr15N/kyPdc7G1cLwLwztbf6INeANxlLNxGcjBT8QFDzqZ+6kxe0Lag7PMH6vOxTq5/Clxq0Qcaa wRz8wdijwabRwRqsteJIno0hwiLMrOZzQhU8kA5UNSnUvFhjwii8QiBUILjiwr+7HtgDQ/7jE0Qi wxRsFK1BQ0RkM0MXZMM2ZLkxhMMntEI6dLQAu8MXZBA9LAkD+ENADERBHERCLERDPERETERBLABG bERHfERIjERJnERKrERLfMSAAAA7 --=_related 0055075D85256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 12:05:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04602 for ; Thu, 4 Sep 2003 12:05:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Fntgc063763 for ; Thu, 4 Sep 2003 08:49:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Fntqv063762 for ietf-calendar-bks; Thu, 4 Sep 2003 08:49:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Fnrgc063753 for ; Thu, 4 Sep 2003 08:49:53 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84FnpS5000972 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 08:49:52 -0700 Message-ID: <3F575F1A.5040301@Royer.com> Date: Thu, 04 Sep 2003 09:49:46 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030000080605020809030407" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030000080605020809030407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 09/03/2003 06:07:24 PM: > > > We never reached a clear concensus on the issue of stored queries in > > > CAP. The thread just stopped in mid-January 2003 and I still question > > > the usefulness of them in CAP. > > > > Is what Bruce means, it it does not end until he agrees. There was > > a debate - two of them over the last two years. > > Since there is no way for any client ('fat' or 'thin') to create a > stored query that is really beneficial and reusable Your opinions presumes you speak for everyone, and you do not. If you do not find them useful, then speak for yourself. > I question the need > to have them as a mandatory CS feature. The query language has NO way > for crafting a query thats reusable like "Find me the alarms that go off > in the next 15 minutes" or "What entries are on my calendar for today". > Thats because we have no concept of being able to wildcards; the query > MUST use exact comparisons to _explicit_ values. You also have never proposed a solution to your need that you describe above. Those that did propose a solution got the text in CAP. That is the way it works. > This hardly makes the stored querys reusable; the CUA will have to > update them with new _explicit_ values on some regular basis. Explain how *ANY* of the queries I sent need to be updated on a regular basis. > > Which is irrelevant as there ARE queries that can be saved > > without wild cards. > > Yes there are; _any_ query can be stored. However they do NOT fulfull > the original intent of the stored query feature nor does storing them in > the CS any strong benefit to anyone compared to the cost of implementation. You can also store bogus VEVENTs that still fit the ABNF grammar, So what's your point? Do you want to propose that we add text saying "do not do something unless it is useful"? > > No place in CAP does it say that > > you must be able to do stored queries based on time or wild cards. > > You are missing the point or trying to deflect it. No, your missing the point, it was debated, added, text changed, and no one saw that there was a need to add grammar to do the things that you keep saying would make it useful. If you have a proposal - make it. > The intent of stored queries was to make it easier for 'thin' clients to > keep smaller footprints by allowing them to not have to (re)craft > commonly used queries again and again; they relied on the CS to keep the > query and involk it when the CUA needed it. This is a great concept but > we failed to design our query language to allow for it to be _actually_ > useful. You keep (re)stating the obvious - however I find the queries useful as did CS&T. So did John. Currently a CS has to CREATE, MODIFY, MOVE, SEARCH, and DELETE components. VQUERY is just another component. And QUERYID is a way to say: Go SEARCH for a known component (a VQUERY) and store the results in in the CUA Now send that same component back to the CS and get the results and store in the CUA. Your calculations (omitted) failed to calculate the fetching of the same query that you then send back to the CS. Looks beneficial and efficient to me to just say: Go to QUERYID and store the results in a the CUA Remember Cell phones and PDAs do not have a user interface that allows the user to customize the queries. It gives the PDA and Cell phone companies the ability to modify the result sets. Plus there is NO requirement that the contents of QUERYID be static, they could be dynamic. > Until now noone has provided any kind of examples that show why we MUST > have this as part of ALL CS implemenations. The CAP drafts make an > implicit requirement that CS implement stored queries and I think this > is wrong to do, especially given the lack of any demonstratable benefit. Something was demonstrated you comment on it below. > Now that you've finally got some examples, lets take a look at them to > see if they meet the original intent and compare any benefits to the > cost of saving queries... > > > QUERYID:Common > > SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED" > > SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED" > > Yes, this is a common kind of query ("Find me 'new stuff'"). > > However there is nothing complex here that would require any CUA ('fat' > or 'thin') to take up that much extra space or cycles to send. It allows the Cell phone and PDA to have a GUI-CUA that runs on a full computer to specify what you get back when you say 'Common'. Such as VEVENT only, or VTODO only, or whatever. The PDA and Cell phones are not going to have that ability. Stored queries allows a 2nd-CUA to specify the query restrictions for GUI-challanged CUAs. And if you search the archives you will find that we specifically stated at the time we were doing the requirements for iCAL that not all CUAs will have a user interface. They can be hardware or software that responds to data in the CS. Stored queries allows their search results to be configured for them. If you also add the fact that the contents of a stored query can change from time to time, plus the CUA-BOTs that we talked about, you now have a fully configurable searches. Not all CUA's are computer based GUIs with user interfaces and lots of memory and processing power. -- 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 --------------ms030000080605020809030407 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE1NDk0NlowIwYJKoZIhvcNAQkEMRYEFIiioi+u vtNqEWr0/zdnV/0OGmM2MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADoNyK71BaKGs4LjDxS+UfV6Lhu4dARmnhy1HKyyuG71jXOHo4pw NfcH1WeeJA/flJLL7avB94iWk2djGFXT4AVYikCIkcFBvAn4nI+r9ntKPDySmuMHo0Amj7Xm 152uWxYXQYRNWYZ1n6aR+GrgXZE7mdQpUSzmGzd9Ak9zVXpMoUb1VXjh76gwkZJnvqex9dJ6 15xh/Hh41EwPSKlsHumKvz6TRZo+TexmhK/BcWR14nBh5FY/yu6/DjkKU2Xd/j2y+ybcMZFf qH0Qs4X+vj0rclC1kcEcF/9xy27BXPKgoaPSLqBTCMuFB4DHaezWpd+gzouCFhxRlQQ+MiNw 7tIAAAAAAAA= --------------ms030000080605020809030407-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 12:10:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04834 for ; Thu, 4 Sep 2003 12:10:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Fwfgc064390 for ; Thu, 4 Sep 2003 08:58:41 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84FwfQI064389 for ietf-calendar-bks; Thu, 4 Sep 2003 08:58:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Fwegc064381 for ; Thu, 4 Sep 2003 08:58:40 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84FwdS5001077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 08:58:40 -0700 Message-ID: <3F576129.4050107@Royer.com> Date: Thu, 04 Sep 2003 09:58:33 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060007070202000806080109" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060007070202000806080109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Tim wrote on 09/03/2003 11:12:42 PM: > > I agree with Doug that > > there are queries which can be stored without need for wild cards, > but I'm > > not sure I see where the efficiency comes in. > > I think we all agree that not all stored querys need to use wildcards. > > If we consider the original intent of the feature, the current design > misses the mark and the efficiency for other cases is somewhat tenuous. If you feel that is true, please post the 'original intent' as posted to the WG. > > Is it intended that the > > stored queries be on the Calendar Store machine, such that a > > smaller-footprint client can invoke them just by name, like a remote > > procedure call of some sort? > > The original intent was to provide a means for clients to save on space > and cycles by not having to recraft commonly used queries and resend > them. And it does save both bandwidth and octets especially when you consider the 2 sets of QUERY/FETCH required without them. > Queries like "What alarms trigger in the next 10 minutes?" or "Is > there anything new for me to look at" or "What entries are on my > calendar for this morning/today?", etc. If you feel that is a requirement, then submit a proposal. > Its possible to craft and store uncommon or infrequently used queries > and save them away either locally or on the CS. However making every > CS support this feature that does not fulfill the original intent is > something I have a concern about. You keep claiming the 'original intent' - yet my search of the archives show that you did not attend the meetings where that was designed or proposed. You simply do not want them which is a fair statement. But you were not part of the 'original' design so you really are just making up claims that have no foundation. > CAP implcitly mandates every CS support stored queries: there is nothing > in CAP about how a CS can not support stored queries or how a CUA > detects this. Bruce you have been on IETF mailing lists for a long time. You know how it works. Complaining without submitting a proposal is something that almost never works. If you want to have the ability to say get me the alarms over the next 10 minutes - submit a proposal, else - there is nothing to add. -- 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 --------------ms060007070202000806080109 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE1NTgzM1owIwYJKoZIhvcNAQkEMRYEFE9gDxMz yjmSmQbBejgOWHpbhlvtMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBACn7MojLYd8T62r84KpEKEmvy+8zx8Ai4QZeTzH1WMlHSxD0/ECL EdVkjVOp9rTrbzcSD3uVOv2XtUFhp2m8+Qb9KkGr2Z3hA+IPZ4KX67lqzl2mLbB+g8xzatDk BnH9m7+ft2atrGMvCDjo/BW2rFMx7GcPtNSmws3Bb7vfwdDzfq/YhCQd6XW7KN/WTe1bnNXP AQH7BkuLCY1rH4Vh64ELwc3xd3yg6CGdvcEn8zrLmYD0GGoWQ6WVIG5Yko0/i3GBwc6eDrUk 66rncTMUfk4BkNd0JOMRWz/LyQj1d6XzgutpJeAwfLZjdwY98MFC3WOqwFMMj2ZP+cz1Ia0d +2YAAAAAAAA= --------------ms060007070202000806080109-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 12:13:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04941 for ; Thu, 4 Sep 2003 12:13:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Fwqgc064403 for ; Thu, 4 Sep 2003 08:58:52 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Fwq7T064402 for ietf-calendar-bks; Thu, 4 Sep 2003 08:58:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Fwpgc064395 for ; Thu, 4 Sep 2003 08:58:52 -0700 (PDT) (envelope-from acampi@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 210) id 2979B15529; Thu, 4 Sep 2003 17:58:47 +0200 (CEST) Date: Thu, 4 Sep 2003 17:58:47 +0200 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] Message-ID: <20030904155847.GL55532@inet.it> References: <3F56661C.5090300@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.4i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Sep 04, 2003 at 10:29:09AM -0400, Bruce_Kahn@notesdev.ibm.com wrote: > Recently I asked for examples of where its really useful and really has > benefit versus the cost and complexity to CS implementations. Of the 2 > people on the list who wanted to keep them (Doug & Andrea), neither > responded. Why is that? Instead of showing a benefit for them, you try > to deflect the issue now by saying already been covered. In fact, it was > not resolved. Just to clarify my personal position: I am in a release frenzy right now, so I have almost 0 time to read the list. This subject however caught my attention just because I took part in the discussion before. Without checking at the archives, the last time this came up I was left with the impression that the best way forward would be to remove stored queries from this draft and prepare a followup draft that addressed the exact same points that you are bringing up. In particular, I definitely agree that if stored queries can only represent shortcuts for queries we can specify in CAP they're not much use, as Doug's trivial examples perfectly showed. So bottomline is: don't keep them on the account of me wanting them in, at this point I'm absolutely against them (as currently specified). 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 Sep 4 12:57:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07288 for ; Thu, 4 Sep 2003 12:57:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84GfFgc066406 for ; Thu, 4 Sep 2003 09:41:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84GfF1E066405 for ietf-calendar-bks; Thu, 4 Sep 2003 09:41:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84GfDgc066399 for ; Thu, 4 Sep 2003 09:41:13 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84GfCS5001604 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 09:41:13 -0700 Message-ID: <3F576B23.3010704@Royer.com> Date: Thu, 04 Sep 2003 10:41:07 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080609060906060100060109" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080609060906060100060109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 08/30/2003 03:48:52 PM: > > I have placed the latest edit of CAP for your review at: > > > > http://inet-consulting.com/draft-ietf-calsch-cap-12-a.txt > > Since the editor is busy revising CAP and reshashing some iCalendar > issues I thought Id take a shot at doing the DIFFs between > CAP-10-17-FEB-03 and CAP-12-A. Once I did I think I know why Doug was > reticent to do it for the WG. Thanks for finally agreeing that you could indeed help and that your repeated claims that you did not have time or ability to do your own diff were just silly. > Here is a windiff view of the changes: > > > In looking a bit closer I see that CAP-12a is ~7 pages shorter than > CAP-10. I also see some new sections in the TOC so Im very curious to > know where all the changes came from? I dont recall seeing much WG > traffic related to CAP issues lately and I certainly dont recall any WG > discussion on some of the bigger issues (at least to the point of > concensus). Did I miss something or are these just changes created by > the editors for WG review?? Burce you have a bad habit of declaring abusive conclusions and not without yourself doing the work to see if it is true. If you have specific issues - post them so they can be fixed, backed up, or removed. So far there have been no issues in this email that effect the CAP protocol at all. If you do not want to do that work, then please stop your unfounded whining claims. > Some of the changes are pure whitespace changes. The first content diff > was: > =========================================================================== > ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 23 > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 23 > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Since this is IETF boilerplate I dont know why any change, let alone > spacing, happened. We already know that there are problems with the > XML->HTML/text converter and so Im more than a bit concerned that there > are changes that creep (additions or omissions) that should not. Please read the IETF INSTRUCTIONS TO AUTHORS - I simply followed the instructions. Read the formatting requirements as to page width. And make a guess as to how things are being reformatted. Hyphenation is NO longer allowed at the end of a line. Do you feel this is one of those additions or omissions that should not happen? I mean the horrible example you site above has no technical meaning to the CAP protocol. Double spaces after a period are not longer allowed. Do you feel the missing single spaces are of such technical merit that it changes the meaning of CAP to the point that you want to declare on the WG list that I have been creeping things into and out of CAP as you have claimed in your comment about those changes above? *********************************************************** -- AND so as there will be NO more shocking claims, the release process -- will result in MANY formatting changes before RFC status. *********************************************************** > One of the other changes Im leary of was the change in the footers: Please read the IETF INSTRUCTIONS TO AUTHORS - I simply followed the instructions. And it is a NEW requirement from the IETF. The new XML2RFC tool just enforces it now. The hack to add the other authors to the footer was *mine* - the IETF rejected it. I did talk to Pat about this -months- ago and she was aware of this NON-TECHNICAL issue. I *did* talk to Steve about this when he first noticed. Did you bother to find out before declaring on this this it was horrible change? > The list of editors was replaced by just the current editor name and "et > al." Im not sure that the new format is correct given that Dougs only > been the editor for a couple revisions compared to others who have been > involved longer or on more versions of the draft but I could be wrong. > It just looks like an attempt to give Doug more prominence than the > other editors given that the format only just changed before a push for > Last Call. Bruce - your simply being a whiner - you insult me and yet in the same paragraph declare '..but I could be wrong. ...' Well - you are wrong. Please read the IETF INSTRUCTIONS TO AUTHORS. And as to longer - you do not have a clue. I was part of the few that started CAP prior to Dallas and you really need to get your facts correct before you start to embarrass yourself farther. I was one of the original authors and did much of the work as did others. The IETF made that an RFC rule - not me. If you have an issue or problem - state it. Please keep your insults to yourself. > Has anyone else been able to get a more accurate picture of what changed > than just using diffs? I for one am more than a little leary of changes > between the drafts since there are known problems in the XML converter > tool, there are seemingly unnecessary changes in whitespace/biolerplate, Please read the IETF INSTRUCTIONS TO AUTHORS, when you do you will understand that these NON-TECHNICAL changes are MANDATED by the IETF as formatting requirements for submission to the last call process. > there are new sections to the draft yet the draft is ~7 pages _shorter_, > that CAP-12 and 12-a came out so quickly after CAP-11 and we have not > really discussed CAP that much recently. And -b will come out this weekend with this weeks WG fixes as discussed on this WG list. > Doug: Since you should have an accurate idea of what changed thats more > reflective of substantive changes, can you please provide the list with > that so we can feel better about the more recent drafts and we can foucs > on them rather than playing Hunt the Snipe? No, as it is time for a snipe hunt. Diffs mean that people do not read the entire text in context. It is time to read the entirety of CAP in context so we can go to WG last call. Overlall 11 or 12-a have not had that many technical issues. My issue list had ZERO items on it when 12-a came out. We are getting close to last call. -- 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 --------------ms080609060906060100060109 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE2NDEwN1owIwYJKoZIhvcNAQkEMRYEFO4RYQkm abUzaQv0dqQwmTkTumSLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBALfU7DkVK6rar6TWx6ASbR8x9kWk4sDIj2dnPWgx7Ca4f/ylqPRC 69x4RjCGK0OaCdjLgD9JObZ24q3+MxxTF6yt+s4cs3H/00Bj/DO2mLkV7PH3a0R4Y8xWoZNY X5ukPikrlkEmWzJMsSo+O8dITiZN7aTH2hSwX41+Bk2Ehhh2wtDneibEXb76eA0ZJjn8HbU3 qJXe3oWC9f3DwVfN1g3MZfaIRf+LJuhyModCOAyPPy01/98+Mk8XW9NXC0uBwtIB/WmA5xso u6juoJtQEJaNJHp2hUMy4/M3sZ0w9G4qk9Di8n+dF5kBNz5qu4etXlDAUfnp53GB/DObpoZa QYYAAAAAAAA= --------------ms080609060906060100060109-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 12:57:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07308 for ; Thu, 4 Sep 2003 12:57:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84GjWgc066808 for ; Thu, 4 Sep 2003 09:45:32 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84GjWHK066807 for ietf-calendar-bks; Thu, 4 Sep 2003 09:45:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84GjVgc066801 for ; Thu, 4 Sep 2003 09:45:31 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84GjUS5001650 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 09:45:31 -0700 Message-ID: <3F576C25.9080206@Royer.com> Date: Thu, 04 Sep 2003 10:45:25 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: <3F56661C.5090300@Royer.com> <20030904155847.GL55532@inet.it> In-Reply-To: <20030904155847.GL55532@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020308090005030306080702" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020308090005030306080702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > On Thu, Sep 04, 2003 at 10:29:09AM -0400, Bruce_Kahn@notesdev.ibm.com wrote: > >>Recently I asked for examples of where its really useful and really has >>benefit versus the cost and complexity to CS implementations. Of the 2 >>people on the list who wanted to keep them (Doug & Andrea), neither >>responded. Why is that? Instead of showing a benefit for them, you try >>to deflect the issue now by saying already been covered. In fact, it was >>not resolved. > > > Just to clarify my personal position: I am in a release frenzy right now, > so I have almost 0 time to read the list. This subject however caught > my attention just because I took part in the discussion before. What about the round trip time to go fetch the VQUERY manually, then re-submit it as a query? That save bandwidth and octets for slow and memory limited devices. -- 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 --------------ms020308090005030306080702 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE2NDUyNVowIwYJKoZIhvcNAQkEMRYEFLvHml20 gR0y5gZ01EwV7ZXhyUvLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGDXfz0go1XjhqL1hHz5am575+QSiyaoKgx6C/dwGkYpid8rYPiZ E7GTEaFIXFl8VvtFP2Vz+kl3y7VEhpdDSLkp+KFFUsWCWnOQxeJygF9OHBEiGHvNRs8FVkTL bh2AIfT/5iILabUMx+CTfsqB3N+aGxBuooLuMRGy2nBrX293OlR5tQryMGsuz3CjkBuR+Zhq uCf7aXMP+6XfLXQd5HnTm9ay1V4uM2hJzlMcIKX5mMBD75YErojyv17dcVOsNio5XEWUXrUv zRpGF846D4NVZ7cdbREu4n7AsPzkS3z9OUFATbZdtQmohdP6s0yr94eyauIeiu3UBbY7e2VJ NI0AAAAAAAA= --------------ms020308090005030306080702-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 13:02:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07521 for ; Thu, 4 Sep 2003 13:02:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Gnsgc067629 for ; Thu, 4 Sep 2003 09:49:54 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84GnsES067627 for ietf-calendar-bks; Thu, 4 Sep 2003 09:49:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Gnpgc067573 for ; Thu, 4 Sep 2003 09:49:51 -0700 (PDT) (envelope-from pregen@egenconsulting.com) Subject: Re: CAP-12 - interm version 'A' To: Bruce_Kahn@notesdev.ibm.com Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Thu, 4 Sep 2003 12:49:44 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 12:49:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=Big5 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id h84Gnrgc067620 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Bruce, thanks for taking the trouble to do the diff. And, thank you for sending me a copy of the entire diff document. I've put it out on the following link so people can read it - I understand it was too big to go through the email engine at imc.org. I don't have a problem hosting it on my site. The link is http://www.egenconsulting.com/ietf/Diff-10-12a.txt I agree that if there are so many changes/differences, if they are not white space changes, we need to know what they are. We know there should be quite a few, but it is always a good idea to post some sort of short summary when a document changes that dramatically. In fact, several months ago Doug brought up exactly this issue regarding changes made to CAP after we put in the BEEP work. Knowing that, I am sure Doug will respond appropriately. In one of your comments below, you said Doug changed the footer to be Royer, et al. In searching through IETF archives of RFC's and drafts, it appears there is a precedent for doing that when there are more names than will fit on one footer line. I'm not sure that's the case on this draft, but I leave that up to the other authors to "yell and scream" if their names only appear at the top of the draft and not on every line. Either way is "Ok" according to the RFC that details how to set up RFC's. As for the boiler plate changes, I think a boiler plate is supposed to be just that - I am not sure we have much leverage to change things. However, I must admit I don't know if the boiler plate has recently changed. I will be looking into that as we speak. And finally, I'm not sure your "colors" came across. For security reasons I have turned off allowing HTML in incoming emails and other's may have as well. Bruce said: Doug wrote on 08/30/2003 03:48:52 PM: > I have placed the latest edit of CAP for your review at: > > ? ?http://inet-consulting.com/draft-ietf-calsch-cap-12-a.txt Since the editor is busy revising CAP and reshashing some iCalendar issues I thought Id take a shot at doing the DIFFs between CAP-10-17-FEB-03 and CAP-12-A. ?Once I did I think I know why Doug was reticent to do it for the WG. Here is a windiff view of the changes: with CAP-10-17-FEB-03 being the red and CAP-12-A being the yellow. ?This is a LOT of changes. ?According to diff, there were 707 changes. ?This includes 1 very big change for the TOC and ~140 changes for the headers/footers. ?That leaves ~565 changes between CAP-10 and CAP-12-a. In looking a bit closer I see that CAP-12a is ~7 pages shorter than CAP-10. ?I also see some new sections in the TOC so Im very curious to know where all the changes came from? ?I dont recall seeing much WG traffic related to CAP issues lately and I certainly dont recall any WG discussion on some of the bigger issues (at least to the point of concensus). ?Did I miss something or are these just changes created by the editors for WG review?? Some of the changes are pure whitespace changes. ?The first content diff was: =========================================================================== ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 23 ? ?Task Force (IETF), its areas, and its working groups. ?Note that ? ?other groups may also distribute working documents as Internet- ? ?Drafts. ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 23 ? ?Task Force (IETF), its areas, and its working groups. Note that other ? ?groups may also distribute working documents as Internet-Drafts. Since this is IETF boilerplate I dont know why any change, let alone spacing, happened. ?We already know that there are problems with the XML->HTML/text converter and so Im more than a bit concerned that there are changes that creep (additions or omissions) that should not. One of the other changes Im leary of was the change in the footers: =========================================================================== ************************ e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 1174 Royer, Babics, Hill, Mansour ? ?Expires May 4, 2003 ? ? ? ? ? ?[Page 21] ¡ð Internet-Draft ? ? ? Calendar Access Protocol (CAP) ? ? ? ?November 2002 ****************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 1117 Royer, et al. ? ? ? ? ?Expires February 28, 2004 ? ? ? ? ? ? ? [Page 20] ¡ð Internet-Draft ? ? ? Calendar Access Protocol (CAP) ? ? ? ? ?August 2003 The list of editors was replaced by just the current editor name and "et al." ?Im not sure that the new format is correct given that Dougs only been the editor for a couple revisions compared to others who have been involved longer or on more versions of the draft but I could be wrong. ?It just looks like an attempt to give Doug more prominence than the other editors given that the format only just changed before a push for Last Call. Has anyone else been able to get a more accurate picture of what changed than just using diffs? ?I for one am more than a little leary of changes between the drafts since there are known problems in the XML converter tool, there are seemingly unnecessary changes in whitespace/biolerplate, there are new sections to the draft yet the draft is ~7 pages _shorter_, that CAP-12 and 12-a came out so quickly after CAP-11 and we have not really discussed CAP that much recently. Doug: Since you should have an accurate idea of what changed thats more reflective of substantive changes, can you please provide the ?list with that so we can feel better about the more recent drafts and we can foucs on them rather than playing Hunt the Snipe? Bruce From owner-ietf-calendar@mail.imc.org Thu Sep 4 13:18:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08401 for ; Thu, 4 Sep 2003 13:18:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84H1Agc068406 for ; Thu, 4 Sep 2003 10:01:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84H1A5D068405 for ietf-calendar-bks; Thu, 4 Sep 2003 10:01:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84H19gc068399 for ; Thu, 4 Sep 2003 10:01:09 -0700 (PDT) (envelope-from bernard.desruisseaux@oracle.com) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail1.oracle.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h84H15us000861 for ; Thu, 4 Sep 2003 10:01:05 -0700 (PDT) Received: from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h84H0tZ10421 for ; Thu, 4 Sep 2003 11:00:56 -0600 (MDT) Received: from oracle.com (c-1782.ca.oracle.com [144.23.213.225]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h84H0qZ10264 for ; Thu, 4 Sep 2003 11:00:52 -0600 (MDT) Message-ID: <3F576F09.6060706@oracle.com> Date: Thu, 04 Sep 2003 12:57:45 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME References: <3F5757ED.2050706@Royer.com> In-Reply-To: <3F5757ED.2050706@Royer.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 Doug Royer wrote: > > > Bruce_Kahn@notesdev.ibm.com wrote: > >> >> In CAP-12-a, under Section 9.6 VQUERY Component is written: >> >> Normally "NAME" and >> "QUERYID" properties are used when looking for a correct stored >> "VQUERY" component, or when storing a "VQUERY" component. >> >> Im curious to know when we decided that the NAME property was to be >> used for identifying the VQUERY? > > > Check the archives, I think the requirement came from CS&T and > there were no objections. In February 2002, Steltor (formerly CS&T, and now Oracle) proposed to rename the property QUERYNAME to QUERYID and to add a new property NAME to specify a localizable display name. VQUERY components should be referred to with their unique QUERYID not their NAME which may not be unique. Cheers, Bernard > >> If its just the "localizable display name" then what use is it in >> looking for the particular VQUERY? Isn't that the sole role for the >> QUERYID property? If not, when is NAME _not_ used (since the text >> says "Normally"...)? > > > Correct. They wanted a localizable display name. Not everyone has > to support just one locale at a time. > >> Since later text says: >> >> For a search, if the "TARGET" property is supplied in a "VQUERY" >> component, then the CS is to search for the query in the calid >> supplied by the "TARGET" property value. >> >> I suspect that the 1st bit above is just poor phrasing and there is no >> actual intent of using NAME in some unspecified combination with >> QUERYID. However I dont want to second guess Dougs intent here. > > > I did not write that text. I'll change it to remove NAME: > > The "QUERYID" property specifies the local identifier for > a stored "VQUERY" component. The "NAME" property specifies > a localizable display name of a stored "VQUERY" component. > Normally the "QUERYID" property is used when looking for a correct > stored "VQUERY" component, or when storing a "VQUERY" component. > > TARGET is used so that you can use stored QUERIES that are not in > the current CMD/TARGET, such as when you have access to more than > one calendar. > From owner-ietf-calendar@mail.imc.org Thu Sep 4 13:22:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08673 for ; Thu, 4 Sep 2003 13:22:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HB2gc016931 for ; Thu, 4 Sep 2003 10:11:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84HB27c016930 for ietf-calendar-bks; Thu, 4 Sep 2003 10:11:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HAqgc015946 for ; Thu, 4 Sep 2003 10:10:52 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F575618.3010002@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 8.30 RECUR-ACCEPTED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 12:10:03 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 01:12:10 PM, Serialize complete at 09/04/2003 01:12:10 PM Content-Type: multipart/alternative; boundary="=_alternative 00598FCB85256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00598FCB85256D97_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 09/04/2003 11:11:20 AM: > > Correct. The text under Description says "recurrence rules". This > > implys RRULEs (iCalendar, Section 4.8.5.4 Recurrence Rule) and thus > > excludes EXRULES. > > Why do you fell that EXRULES are excluded? Where does it say > that? Because the text says "recurrence rules" and not "recurrence and exclusion rules". An EXRULE is an _exclusion_ rule, RRULE is a _recurrence_ rule. Both are examples of properties that use the recurrence rule grammar. CAP is unclear on which its referring to and some could incorrectly infer the wrong choice from what we intended (more easily than misunderstanding the meaning of "original"). If you do not understand the difference then perhaps we need to get someone to help co-edit CAP who does. > > > 2) Do you have a suggestion as to what it should say? > > > > First we need to answer the discrepancy between the Purpose and the > > Description. Then we will have a better idea of what text to add. > > Again - do you have a suggestion? Doug seems to have a perchant for missing points. I just told you my suggestion: we need to answer the discrepancy between Purpose and Description. Is the purpose of RECUR-ACCEPTED to be all different kinds of recurrence or just recurrence rules (RRULEs)? I suspect the Purpose is accurate and Description is just poorly phrased but thats just me. Anyone think that the Description is correct and that Purpose is poorly phrased? 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 00598FCB85256D97_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 09/04/2003 11:11:20 AM:
> > Correct.  The text under Description says "recurrence rules".  This
> > implys RRULEs (iCalendar, Section 4.8.5.4 Recurrence Rule) and thus
> > excludes EXRULES.
>
> Why do you fell that EXRULES are excluded? Where does it say
> that?
Because the text says "recurrence rules" and not "recurrence and exclusion rules".  An EXRULE is an _exclusion_ rule, RRULE is a _recurrence_ rule.  Both are examples of properties that use the recurrence rule grammar.  CAP is unclear on which its referring to and some could incorrectly infer the wrong choice from what we intended (more easily than misunderstanding the meaning of "original").  If you do not understand the difference then perhaps we need to get someone to help co-edit CAP who  does.

> >  > 2) Do you have a suggestion as to what it should say?
> >
> > First we need to answer the discrepancy between the Purpose and the
> > Description.  Then we will have a better idea of what text to add.
>
> Again - do you have a suggestion?
Doug seems to have a perchant for missing points.  I just told you my suggestion: we need to answer the discrepancy between Purpose and Description.

Is the purpose of RECUR-ACCEPTED to be all different kinds of recurrence or just recurrence rules (RRULEs)?  I suspect the Purpose is accurate and Description is just poorly phrased but thats just me.   Anyone think that the Description is correct and that Purpose is poorly phrased?

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 00598FCB85256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 13:24:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08811 for ; Thu, 4 Sep 2003 13:24:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HArgc016223 for ; Thu, 4 Sep 2003 10:10:53 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84HArSo016222 for ietf-calendar-bks; Thu, 4 Sep 2003 10:10:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HAqgc015945 for ; Thu, 4 Sep 2003 10:10:52 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F5758BB.7070206@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 12:16:44 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 01:12:10 PM, Serialize complete at 09/04/2003 01:12:10 PM Content-Type: multipart/alternative; boundary="=_alternative 005A2CAF85256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A2CAF85256D97_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 09/04/2003 11:22:35 AM: > There was nothing new to reply to. Same > question, same answer. Actually its more like same question, same non-answer. Everyone from 2 of the other editors to Andrea question the usefulness of this feature in CAP 1.0 given our inability to achieve the original intent. You seem to be the only one steadfastly opposed to removing it from 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... Warning: Dates in Calendar are closer than they appear. --=_alternative 005A2CAF85256D97_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 09/04/2003 11:22:35 AM:
>                           There was nothing new to reply to. Same
> question, same answer.
Actually its more like same question, same non-answer.  

Everyone from 2 of the other editors to Andrea question the usefulness of this feature in CAP 1.0 given our inability to achieve the original intent.  You seem to be the only one steadfastly opposed to removing it from 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...
Warning: Dates in Calendar are closer than they appear. --=_alternative 005A2CAF85256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 13:24:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08814 for ; Thu, 4 Sep 2003 13:24:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HAsgc016244 for ; Thu, 4 Sep 2003 10:10:54 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84HAr5X016238 for ietf-calendar-bks; Thu, 4 Sep 2003 10:10:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HAqgd015945 for ; Thu, 4 Sep 2003 10:10:53 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F5757ED.2050706@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 12:45:19 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 01:12:11 PM, Serialize complete at 09/04/2003 01:12:11 PM Content-Type: multipart/alternative; boundary="=_alternative 005CCAB385256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CCAB385256D97_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Doug replied on 09/04/2003 11:19:09 AM: > > In CAP-12-a, under Section 9.6 VQUERY Component is written: > >=20 > > Normally "NAME" and > > "QUERYID" properties are used when looking for a correct stored > > "VQUERY" component, or when storing a "VQUERY" component. > >=20 > > Im curious to know when we decided that the NAME property was to be=20 used=20 > > for identifying the VQUERY?=20 >=20 > Check the archives, I think the requirement came from CS&T and > there were no objections. What permutations of search do I use? Using NAME and QUERY and some other = values do not help since I get TONS of unrelated matches. You seem to=20 recall it so how about at least a Subject I can use? The idea is interesting but there are LOTS of unanswered questions=20 involved in using localized strings for identification. The NAME is there = as a friendly/display name for the QUERY ("What the hell does=20 QUERYID:Fizbin32 do??" vs "Ah, QUERYID:Fizbin32 is displayed w/the=20 'NAME:F=EDnd all calendars that Andr=E8 owns'.") and not as part of searchi= ng=20 for it. Even if it was suggested, there is NO prose in CAP =5Fnow=5F for when NAME = is=20 used, how it is to be used or when it is NOT used in conjunction with=20 QUERYID in a VQUERY. If (and thats a big if) the WG decides to use NAME=20 in addition to QUERYID as part of VQUERY location then issues like dealing = with specifying localization code pages used, etc need to be answered.=20 I hope George or any of the former CS&T/Steltor folks can chime in here=20 and help us out here since they are credited w/the proposal. > Correct. They wanted a localizable display name. Not everyone has > to support just one locale at a time. The abilty to have > 1 NAME property per component is understandable but=20 its not relevant to the need to finding a particular query.=20 I can have multiple queries all with NAME:Widget but each MUST have a=20 different QUERYID per VAGENDA. Since QUERYIDs are unique per VAGENDA and=20 NAMEs are not, what good is searching on both QUERYID and NAME?? None=20 really since the NAME is only intended for display purposes rather than=20 actual identification. > I did not write that text. I'll change it to remove NAME: >=20 > The "QUERYID" property specifies the local identifier for > a stored "VQUERY" component. The "NAME" property specifies > a localizable display name of a stored "VQUERY" component. > Normally the "QUERYID" property is used when looking for a correct > stored "VQUERY" component, or when storing a "VQUERY" component. >=20 > TARGET is used so that you can use stored QUERIES that are not in > the current CMD/TARGET, such as when you have access to more than > one calendar. Thank you. Also, strike the word "Normally" from the last sentence too.=20 Otherwise you imply there is a 'non-normal' case but you never say what it = is. After all, how would you identify a particular stored query w/o a=20 QUERYID? Bruce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Kahn INet:=20 Bruce=5FKahn@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 005CCAB385256D97_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Doug replied on 09/04/2003 11:19:09 AM:
> > In CAP-12-a, under Section 9.6 VQUERY Component is written:
> >
> >                                              Normally "NAME" and
> >   "QUERYID" properties are used when looking for a correct stored
> >   "VQUERY" component, or when storing a "VQUE= RY" component.
> >
> > Im curious to know when we decided that the NAME property was to be used
> > for identifying the VQUERY?  
>
> Check the archives, I think the requirement came from CS&T and
> there were no objections.
What permutations of search do I use?  Using NAME and QUERY and some other values do not help since I get TONS of unrelated matches.  You seem to recall it so how about at least a Subject I can use?

The idea is interesting but there are LOTS of unanswered questions involved in using localized strings for identi= fication.  The NAME is there as a friendly/display name for the QUERY ("What the hell does QUERYID:Fizbin32 do??" vs "Ah, QUERYID:Fizbin32 is displayed w/the 'NAME:F=EDnd all calendars that Andr=E8 owns'.") and not as part of searching for it.

Even if it was suggested, there is NO prose in CAP =5Fnow=5F for when NAME is used, how it is to be used or when it is NOT used in conjunction with QUERYID in a VQUERY.  If (and thats a big if) the WG decides to use NAME in addition to QUERYID as part of VQUERY location then issues like dealing with specifying localization code pages used, etc need to be answered.  

I hope George or any of the former C= S&T/Steltor folks can chime in here and help us out here since they are credited w/the proposal.

> Correct. They wanted a localizable display name. Not everyone has
> to support just one locale at a time.
The abilty to have > 1 NAME prope= rty per component is understandable but its not relevant to the need to finding a particular query.  

I can have multiple queries all with NAME:Widget but each MUST have a different QUERYID per VAGENDA.  Since QUERYIDs are unique per VAGENDA and NAMEs are not, what good is searching on both QUERYID and NAME??  None really since the NAME is only intended for display purposes rather than actual identification.

> I did not write that text. I'll change it to remove NAME:
>
>   The "QUERYID" property specifies the local identifier for
>   a stored "VQUERY" component. The "NAME" property specifies
>   a localizable display name of a stored "VQUERY" compo= nent.
>   Normally the "QUERYID" property is used when looking for a correct
>   stored "VQUERY" component, or when storing a "VQ= UERY" component.
>
> TARGET is used so that you can use stored QUERIES that are not in
> the current CMD/TARGET, such as when you have access to more than
> one calendar.
Thank you.  Also, strike the wo= rd "Normally" from the last sentence too.  Otherwise you imply there is a 'non-normal' case but you never say what it is.  After all, how would you identify a particular stored query w/o a QUERYID?

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                                INet: Bruce=5FKahn@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 005CCAB385256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 13:44:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09731 for ; Thu, 4 Sep 2003 13:44:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HQ6gc030279 for ; Thu, 4 Sep 2003 10:26:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84HQ69c030278 for ietf-calendar-bks; Thu, 4 Sep 2003 10:26:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HQ5gc030273 for ; Thu, 4 Sep 2003 10:26:05 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84HPqS5002249 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 10:26:03 -0700 Message-ID: <3F577593.9070008@Royer.com> Date: Thu, 04 Sep 2003 11:25:39 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030402090307060003040105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030402090307060003040105 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > Bruce, thanks for taking the trouble to do the diff. And, thank you for > sending me a copy of the entire diff document. I've put it out on the > following link so people can read it - I understand it was too big to go > through the email engine at imc.org. I don't have a problem hosting it on > my site. The link is http://www.egenconsulting.com/ietf/Diff-10-12a.txt Thanks. > In one of your comments below, you said Doug changed the footer to be > Royer, et al. In searching through IETF archives of RFC's and drafts, it > appears there is a precedent for doing that when there are more names than > will fit on one footer line. I'm not sure that's the case on this draft, > but I leave that up to the other authors to "yell and scream" if their > names only appear at the top of the draft and not on every line. Either > way is "Ok" according to the RFC that details how to set up RFC's. The tool takes them out, I plan to manually hack them back in for the final RFC - and thanks for your support! > As for the boiler plate changes, I think a boiler plate is supposed to be > just that - I am not sure we have much leverage to change things. However, > I must admit I don't know if the boiler plate has recently changed. I will > be looking into that as we speak. See my other post on the above issue. Hint - compare the text and not the formatting of the text. NOTHING CHANGED except the formatting as mandated by the IETF. > And finally, I'm not sure your "colors" came across. For security reasons > I have turned off allowing HTML in incoming emails and other's may have as > well. What Bruce posted came to me as a LARGE JPG looking object that was unreadable. I assumed it was an error. Perhaps it requires a vendor specific tool that I did not have to view. AND - Bruce's diff - as I can see it from your web page (thanks again), is a diff from (-10) to (-12a) (not from -11 to -12a and not a diff of -10 to -11). So PLEASE BE SURE the issue was not already covered before posting !!! And many of the bugs/fixes where covered in the few bugs filed (of which had many entries): I track many of the issues with the MOZILLA/BUGZILLA tool: http://INET-Consulting.com/bugzilla IETF Drafts and RFCs / draft-ietf-calsch-cap > Bruce said: > > Doug wrote on 08/30/2003 03:48:52 PM: > >>I have placed the latest edit of CAP for your review at: >> >>? ?http://inet-consulting.com/draft-ietf-calsch-cap-12-a.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 --------------ms030402090307060003040105 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE3MjU0MFowIwYJKoZIhvcNAQkEMRYEFLAJ4d6b S4/+5mORuj9OqqCnWvBRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGY80cXOsNiJfKWCNxWvUHJmh0kUc0ofmu34K+tcvcRPFxssurW4 b26Fjzp0523ZuBjsDhE1vjaem8OikaWTuIaOWq9PhAxZBQWJpUgR266UBqziCSnHG0xc4hHD ZIdEUZUibwGjjgnL6m8Wh1gdkgehnKRI9YyWcuST4Pa4nJSCFHSW4ganOS6lz2BZjmKMvqHu L7u6hgrX9clImnglhSGOnplrQD8uS4N5H0+QEyp/IM+kVeRteZQDn2aADjETvCyyry1ba++i 9YpwU3WEv7ot/uhCaktAYsumcUbv35xH6SVQ3DDpi4hb0VcO0W+3Mml+WdzcyATZzH9/YuCZ +AIAAAAAAAA= --------------ms030402090307060003040105-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 13:53:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10398 for ; Thu, 4 Sep 2003 13:53:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Hbfgc030894 for ; Thu, 4 Sep 2003 10:37:41 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84HbfHp030893 for ietf-calendar-bks; Thu, 4 Sep 2003 10:37:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Hbdgc030887 for ; Thu, 4 Sep 2003 10:37:40 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84HbSS5002385 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 10:37:38 -0700 Message-ID: <3F577851.3080608@Royer.com> Date: Thu, 04 Sep 2003 11:37:21 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090702060504010707030707" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090702060504010707030707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 09/04/2003 11:19:09 AM: > > > In CAP-12-a, under Section 9.6 VQUERY Component is written: > > > > > > Normally "NAME" and > > > "QUERYID" properties are used when looking for a correct stored > > > "VQUERY" component, or when storing a "VQUERY" component. > > > > > > Im curious to know when we decided that the NAME property was to be > used > > > for identifying the VQUERY? > > > > Check the archives, I think the requirement came from CS&T and > > there were no objections. > > What permutations of search do I use? I do not find it odd that you can only seem to find opinions that aggree with yours. -- 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 --------------ms090702060504010707030707 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE3MzcyMVowIwYJKoZIhvcNAQkEMRYEFNw+NGdJ Gpk+lzurdW76WssuJN5BMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEszhvfgG0T6VqvQu1Z7vHqDgjNLSFt8Il7CkffRX/WSoo7Xmp9D /G2+D1nTro26gHHGfcHhzZMRPK3JId4Vy06fWWYm6zm3comeJsV4bJw52wahOk8VDdyi47m+ xwEz+XGVcnFgU+T3+U/PoG6/F8tgyrKtIXfZQsSXy/DykEhKoOW8sEcLHBRlpilqvfFhe+ZJ yRFHT/7Zz7Ab+88rViN3dd+0pKJL4TDAv1+qPhOwuxmwP/SNUq5sGWBk96b42tBrhh3g+atg Y+v20KYJxiDJO2M+28j2pxkCq2kU4PF6LkoRICSJMW7yDKPYg5ndmCel0R2T3aKgp/UXLgLu yFkAAAAAAAA= --------------ms090702060504010707030707-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 13:55:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10460 for ; Thu, 4 Sep 2003 13:55:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HgPgc031114 for ; Thu, 4 Sep 2003 10:42:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84HgPKq031113 for ietf-calendar-bks; Thu, 4 Sep 2003 10:42:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HgLgc031107 for ; Thu, 4 Sep 2003 10:42:23 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84HgHS5002446 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 10:42:21 -0700 Message-ID: <3F577974.8060706@Royer.com> Date: Thu, 04 Sep 2003 11:42:12 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000605010304040705050105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000605010304040705050105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 09/04/2003 11:22:35 AM: > > There was nothing new to reply to. Same > > question, same answer. > > Actually its more like same question, same non-answer. > > Everyone from 2 of the other editors to Andrea question the usefulness > of this feature in CAP 1.0 given our inability to achieve the original > intent. You seem to be the only one steadfastly opposed to removing it > from CAP. Bruce - 4 people replied today - two said yes (me and it looks as if Bernard by replying is saying yes, you said no, and Andrea said no). Bernard proposed the NAME/QUERYID change - do you want us to think that that means 'NO' to stored queries? And you just posted TODAY - so don't you feel just a little bit embarrassed that you declare 'Everyone from 2 of the other editors...' question ... it? And you have failed to find *anything* that supports your assertion of the 'original intent'. -- 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 --------------ms000605010304040705050105 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE3NDIxMlowIwYJKoZIhvcNAQkEMRYEFLwZ60Pj NokZ2TUJ+Boao7LO9d7tMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAF851n4jwgOj3DfDCHIoRpvVUHnaimtkL3GUdPDWAZ4EtEK6WTs8 y3FnXBxzA9jtdHJQ+95h2OjOc6W5rFVmXFOaFzuvdu9PgR6Y5MZMLajFYDXjc/zNrBNM2BAi sfwCtliW6AtWjlCNKtCVXW7cjyL5g4XBRsK2eEp8w5e68hqo4+Lw2HhTjiru6bG52eSgHkWy wx0sf21M0qYzTaBV9Wlsacz9Y57Z4daRiVyNqoPMj8nDJK/AgT//SQMXZ+ONL8l9Rg4ZMr1x J6izgMludACLciG3in+oLDKZ6x5NOEQd3WwzgpNTqMBXXXPo60InnUVE/HY8CJPgSdc/Oz4Y dvMAAAAAAAA= --------------ms000605010304040705050105-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 13:56:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10534 for ; Thu, 4 Sep 2003 13:56:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Hfogc031094 for ; Thu, 4 Sep 2003 10:41:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Hfo67031093 for ietf-calendar-bks; Thu, 4 Sep 2003 10:41:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Hflgc031067 for ; Thu, 4 Sep 2003 10:41:47 -0700 (PDT) (envelope-from pregen@egenconsulting.com) Subject: Re: CAP-12 - interm version 'A' To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Thu, 4 Sep 2003 13:41:46 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 01:41:49 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBE704DFCFFF508f9e8a93df938690918c0ABBE704DFCFFF50" Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=0ABBE704DFCFFF508f9e8a93df938690918c0ABBE704DFCFFF50 Content-type: text/plain; charset=US-ASCII Doug, thanks for responding so quickly to Bruce's note. However, I am concerned about the tone of the note - we need more productive responses to questions and not challenges and verbal abuse. I have just sent out a note that says we do indeed need to know what changes our in our recent draft. That's typical for an editor to post summaries to a list when changes are made. What we see from you are lots of line noise - but when you post a draft - very little comments regarding what went into the drafts as text and changes. On 8/18 you sent out a note pointing up to Bugzilla (http://INET-Consulting.com/bugzilla). That's a great start - this is a good place to track draft changes. However, your bugzilla report only shows typo changes. That does not account for a reduction of 7 pages nor new sections found by Bruce when he ran the windiff. If there are new sections or reductions, shouldn't they be in the bugzilla report as well? I believe that's one of the reasons we are struggling to get this draft to last call - every time someone challenges one of your ideas, you bombast them with a verbal harrange such that only those with skins of steel will continue the dialog. That is not what an editor should do. An editor should put into the draft what the list feels should be there. And, it is the chairs responsibility to call concensus on items and ensure that they make it to the list. I will stand up and take responsibility for not doing that more proactively. However, I spent an entire weekend going through all the recent emails so that I can post my own "summary" of recent items showing what I see are "for/against" types of responses. I will be curious to see if my summary of comments matches your summary of changes to the CAP draft. If they do, I will be pleased and comfortable that we have done the right things. If they do not, we need to take steps to get that rectified. Therefore, we do need a summary from you, the current editor, of changes you have made to the most recent draft that you submitted. I appreciate your hard work on this draft - I want to come to last call - but only with a draft that everyone on this list (who is interested) agrees with. Doug Royer To: "ietf-calendar@imc.org" Sent by: cc: owner-ietf-calendar@m Subject: Re: CAP-12 - interm version 'A' ail.imc.org 09/04/2003 12:41 PM Please respond to "ietf-calendar@imc.or g" Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 08/30/2003 03:48:52 PM: > > I have placed the latest edit of CAP for your review at: > > > > http://inet-consulting.com/draft-ietf-calsch-cap-12-a.txt > > Since the editor is busy revising CAP and reshashing some iCalendar > issues I thought Id take a shot at doing the DIFFs between > CAP-10-17-FEB-03 and CAP-12-A. Once I did I think I know why Doug was > reticent to do it for the WG. Thanks for finally agreeing that you could indeed help and that your repeated claims that you did not have time or ability to do your own diff were just silly. > Here is a windiff view of the changes: > > > In looking a bit closer I see that CAP-12a is ~7 pages shorter than > CAP-10. I also see some new sections in the TOC so Im very curious to > know where all the changes came from? I dont recall seeing much WG > traffic related to CAP issues lately and I certainly dont recall any WG > discussion on some of the bigger issues (at least to the point of > concensus). Did I miss something or are these just changes created by > the editors for WG review?? Burce you have a bad habit of declaring abusive conclusions and not without yourself doing the work to see if it is true. If you have specific issues - post them so they can be fixed, backed up, or removed. So far there have been no issues in this email that effect the CAP protocol at all. If you do not want to do that work, then please stop your unfounded whining claims. > Some of the changes are pure whitespace changes. The first content diff > was: > =========================================================================== > ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 23 > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 23 > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Since this is IETF boilerplate I dont know why any change, let alone > spacing, happened. We already know that there are problems with the > XML->HTML/text converter and so Im more than a bit concerned that there > are changes that creep (additions or omissions) that should not. Please read the IETF INSTRUCTIONS TO AUTHORS - I simply followed the instructions. Read the formatting requirements as to page width. And make a guess as to how things are being reformatted. Hyphenation is NO longer allowed at the end of a line. Do you feel this is one of those additions or omissions that should not happen? I mean the horrible example you site above has no technical meaning to the CAP protocol. Double spaces after a period are not longer allowed. Do you feel the missing single spaces are of such technical merit that it changes the meaning of CAP to the point that you want to declare on the WG list that I have been creeping things into and out of CAP as you have claimed in your comment about those changes above? *********************************************************** -- AND so as there will be NO more shocking claims, the release process -- will result in MANY formatting changes before RFC status. *********************************************************** > One of the other changes Im leary of was the change in the footers: Please read the IETF INSTRUCTIONS TO AUTHORS - I simply followed the instructions. And it is a NEW requirement from the IETF. The new XML2RFC tool just enforces it now. The hack to add the other authors to the footer was *mine* - the IETF rejected it. I did talk to Pat about this -months- ago and she was aware of this NON-TECHNICAL issue. I *did* talk to Steve about this when he first noticed. Did you bother to find out before declaring on this this it was horrible change? > The list of editors was replaced by just the current editor name and "et > al." Im not sure that the new format is correct given that Dougs only > been the editor for a couple revisions compared to others who have been > involved longer or on more versions of the draft but I could be wrong. > It just looks like an attempt to give Doug more prominence than the > other editors given that the format only just changed before a push for > Last Call. Bruce - your simply being a whiner - you insult me and yet in the same paragraph declare '..but I could be wrong. ...' Well - you are wrong. Please read the IETF INSTRUCTIONS TO AUTHORS. And as to longer - you do not have a clue. I was part of the few that started CAP prior to Dallas and you really need to get your facts correct before you start to embarrass yourself farther. I was one of the original authors and did much of the work as did others. The IETF made that an RFC rule - not me. If you have an issue or problem - state it. Please keep your insults to yourself. > Has anyone else been able to get a more accurate picture of what changed > than just using diffs? I for one am more than a little leary of changes > between the drafts since there are known problems in the XML converter > tool, there are seemingly unnecessary changes in whitespace/biolerplate, Please read the IETF INSTRUCTIONS TO AUTHORS, when you do you will understand that these NON-TECHNICAL changes are MANDATED by the IETF as formatting requirements for submission to the last call process. > there are new sections to the draft yet the draft is ~7 pages _shorter_, > that CAP-12 and 12-a came out so quickly after CAP-11 and we have not > really discussed CAP that much recently. And -b will come out this weekend with this weeks WG fixes as discussed on this WG list. > Doug: Since you should have an accurate idea of what changed thats more > reflective of substantive changes, can you please provide the list with > that so we can feel better about the more recent drafts and we can foucs > on them rather than playing Hunt the Snipe? No, as it is time for a snipe hunt. Diffs mean that people do not read the entire text in context. It is time to read the entirety of CAP in context so we can go to WG last call. Overlall 11 or 12-a have not had that many technical issues. My issue list had ZERO items on it when 12-a came out. We are getting close to last call. -- 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 (See attached file: smime.p7s) --0__=0ABBE704DFCFFF508f9e8a93df938690918c0ABBE704DFCFFF50 Content-type: application/octet-stream; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCCA2Iw ggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVow gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkg UmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1 YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2ok kuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAE QDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5j cmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5v RUs4oLje6VNkIbzkTCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrT ssSr51a+i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkg UmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1 YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMw OTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2Vydmlj ZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQp Z2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV 5umSqlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcU KdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZ AgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGO MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYw FRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVu Y2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNan VdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kz UOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZI hvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1 bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3ll ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2r KbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/ Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSg LmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46Pbzk gCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApu lYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsG AQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBi eSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4Aw MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5 gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZN FuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSmAgEBMIHhMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE2NDEwN1owIwYJ KoZIhvcNAQkEMRYEFO4RYQkmabUzaQv0dqQwmTkTumSLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJp U2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBAQUABIIB ALfU7DkVK6rar6TWx6ASbR8x9kWk4sDIj2dnPWgx7Ca4f/ylqPRC69x4RjCGK0OaCdjLgD9JObZ2 4q3+MxxTF6yt+s4cs3H/00Bj/DO2mLkV7PH3a0R4Y8xWoZNYX5ukPikrlkEmWzJMsSo+O8dITiZN 7aTH2hSwX41+Bk2Ehhh2wtDneibEXb76eA0ZJjn8HbU3qJXe3oWC9f3DwVfN1g3MZfaIRf+LJuhy ModCOAyPPy01/98+Mk8XW9NXC0uBwtIB/WmA5xsou6juoJtQEJaNJHp2hUMy4/M3sZ0w9G4qk9Di 8n+dF5kBNz5qu4etXlDAUfnp53GB/DObpoZaQYYAAAAAAAA= --0__=0ABBE704DFCFFF508f9e8a93df938690918c0ABBE704DFCFFF50-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 14:01:41 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10873 for ; Thu, 4 Sep 2003 14:01:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HdAgc030949 for ; Thu, 4 Sep 2003 10:39:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84HdA0T030948 for ietf-calendar-bks; Thu, 4 Sep 2003 10:39:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Hd8gc030942 for ; Thu, 4 Sep 2003 10:39:08 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84HclS5002398 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 10:39:08 -0700 Message-ID: <3F5778A2.8070807@Royer.com> Date: Thu, 04 Sep 2003 11:38:42 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: Re: [Fwd: Re: CAP-12-a: Stored queries still?]] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050904020507010201000907" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050904020507010201000907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > On Thu, Sep 04, 2003 at 10:29:09AM -0400, Bruce_Kahn@notesdev.ibm.com wrote: > >>Recently I asked for examples of where its really useful and really has >>benefit versus the cost and complexity to CS implementations. Of the 2 >>people on the list who wanted to keep them (Doug & Andrea), neither >>responded. Why is that? Instead of showing a benefit for them, you try >>to deflect the issue now by saying already been covered. In fact, it was >>not resolved. > > > Just to clarify my personal position: I am in a release frenzy right now, > so I have almost 0 time to read the list. This subject however caught > my attention just because I took part in the discussion before. What about the round trip time to go fetch the VQUERY manually, then re-submit it as a query? That saves bandwidth and octets for ALL devices and help slow and memory limited devices. -- 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 --------------ms050904020507010201000907 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE3Mzg0MlowIwYJKoZIhvcNAQkEMRYEFIZgHPSc CiBaRXz495q5sq38J+U/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIvJG0IaIzAQZwFYSmF3swLF1sB0Og/BWvfVFFgocKF+jKN6UUtb Nd8GRBoBNg+e1GZqK23e0op8txqWbD0waahRWzGXPC1IsqaA/RkUZVJ7WM1wVRDc8pn/7ulF D09pZr0ZETyUrjLXPn/GN5hzeXNvfjQdMjJRRcEsqlu585M4AAQx1MKKG3lHWZDg6MynTqnS brTERqgU94pExoSz3XyXJ+asrrDiNjpjJg8gjRzOC0iiws/RtpnJowDnV2WNlBC75KXC0d+7 Rp0gPtTvE1eAhRC12FPmCEdzfME/GRypgDvbTU+sKQdaMOYIYxIKHJlMj5ORh8bYZ9ylBOTf TF8AAAAAAAA= --------------ms050904020507010201000907-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 14:07:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11208 for ; Thu, 4 Sep 2003 14:07:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Hplgc031577 for ; Thu, 4 Sep 2003 10:51:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Hpl3M031576 for ietf-calendar-bks; Thu, 4 Sep 2003 10:51:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Hpjgc031570 for ; Thu, 4 Sep 2003 10:51:45 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84HpfS5002555 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 10:51:44 -0700 Message-ID: <3F577BA7.2030100@Royer.com> Date: Thu, 04 Sep 2003 11:51:35 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080004030700020405030901" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080004030700020405030901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Bruce_Kahn@notesdev.ibm.com wrote: > The idea is interesting but there are LOTS of unanswered questions=20 > involved in using localized strings for identification. The NAME is=20 > there as a friendly/display name for the QUERY ("What the hell does=20 > QUERYID:Fizbin32 do??" vs "Ah, QUERYID:Fizbin32 is displayed w/the=20 > 'NAME:F=EDnd all calendars that Andr=E8 owns'.") and not as part of=20 > searching for it. (1) Bruce - please read all of CAP - not just the diffs. (2) You can search for any component by ANY property value. Are you proposing that we limit searching of VQUERYs to be less than other components? > Even if it was suggested, there is NO prose in CAP _now_ for when NAME= > is used, how it is to be used or when it is NOT used in conjunction > with QUERYID in a VQUERY. If (and thats a big if) the WG decides to > use NAME in addition to QUERYID as part of VQUERY location then issues= > like dealing with specifying localization code pages used, etc need to= > be answered. (1) Did you bother to read section 8.23? (2) You can search for any component by ANY property value. Are you proposing that we limit searching of VQUERYs to be less than other components? By your removal and (so far) non responsiveness to your incorrect octet count conclusion, are you agreeing that it does indeed save one round trip and twice the stored VQUERY size in OCTETS at a minimum now so it is in fact 'efficient'? Plus we use UID to uniqly identify several components. We use CSID to uniquly identify one type of component. We have a VQUERY component - are you proposing we have no unique way to store/fetch/modify/delete them? --=20 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 --------------ms080004030700020405030901 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE3NTEzNVowIwYJKoZIhvcNAQkEMRYEFNn8qMFV tn/DGVnnDocjV/0+5InDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAKGWgFceBdDe6LfqaSlQhXI3bxaHCeGEpWh1W5HcFC8Q5YNd+vhi lXnCR8UkmiNFEanU7Ozf7kBe17uA3g2d/2AUrMgbz/AiKnkfeWTeElyY/Anu/psI1lnehgzk EbD4jqBZ8uO7G8lrJsjgKPkMXtgrS5JbD6EgXoEdc+s4AUvHlDKMLpql+Lptk6Iq/HI9jyJf xZiP/fnC7fM4CpzUUatKdnlh4YdfmsCJ4wy5Vtj6rXk4DyEgv1hozKayp9B3osH85wqBPBuU b8rKsF/72y23Uuqzr/C1vkHS/wvEk3Lo++sBYjLXNfNgfbASNSt4FbArbTfVS+cpP1u3aEs9 HdMAAAAAAAA= --------------ms080004030700020405030901-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 14:13:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11441 for ; Thu, 4 Sep 2003 14:13:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Hx8gc032083 for ; Thu, 4 Sep 2003 10:59:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Hx82Y032082 for ietf-calendar-bks; Thu, 4 Sep 2003 10:59:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Hx6gc032071 for ; Thu, 4 Sep 2003 10:59:07 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84HwrS5002628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 10:58:59 -0700 Message-ID: <3F577D57.3030303@Royer.com> Date: Thu, 04 Sep 2003 11:58:47 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030802080501070504040007" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030802080501070504040007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > I did not write that text. I'll change it to remove NAME: > > > > The "QUERYID" property specifies the local identifier for > > a stored "VQUERY" component. The "NAME" property specifies > > a localizable display name of a stored "VQUERY" component. > > Normally the "QUERYID" property is used when looking for a correct > > stored "VQUERY" component, or when storing a "VQUERY" component. > > > > TARGET is used so that you can use stored QUERIES that are not in > > the current CMD/TARGET, such as when you have access to more than > > one calendar. > > Thank you. Also, strike the word "Normally" from the last sentence too. > Otherwise you imply there is a 'non-normal' case but you never say what > it is. After all, how would you identify a particular stored query w/o > a QUERYID? Identify != 'looking for' as the following is as valid: SELECT VQUERY FROM VAGENDA WHERE 'some ... locale string' IN NAME as: SELECT VQUERY FROM VAGENDA WHERE QUERYID = '123' VQUERY is a component searchable like any other. -- 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 --------------ms030802080501070504040007 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE3NTg0N1owIwYJKoZIhvcNAQkEMRYEFMUuF86j jTelgfrsw8gH4MirughcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADiwT/aFA7GRHfQcClyHtw0g5FsZEWIMumoLWHHeJb72uErfg/cU stJ7btGfoJ/8l1Cn/jMqjHlBbRm0s33nrnkIpMtaZY70zbGmZp9hrCBVR4B2ybmRAn6ak9Oy hLb0Rz/hi44CG9mocD9y1KnRleiIk5uT0x2OIKlJdZZu06Spqx5Y3RB0L1wsFxxMQXWr5nhf v4SkiAp+8pHkD2Ywgh8lFJFBnKALB8+esC0ZIExmc0k0VQjf7FTMbfkMeoMNlbMt3xR1el83 igpDEj4Y1lo/WnALqnG58VaTubLpi9mwMVW57Y7rKYl80GKlsVPtb/3IMr2ObVu/QPOJY6kv MZQAAAAAAAA= --------------ms030802080501070504040007-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 14:15:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11567 for ; Thu, 4 Sep 2003 14:15:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84I1Mgc032254 for ; Thu, 4 Sep 2003 11:01:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84I1MZa032253 for ietf-calendar-bks; Thu, 4 Sep 2003 11:01:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84I1Kgc032248 for ; Thu, 4 Sep 2003 11:01:20 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84I1AS5002698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 11:01:15 -0700 Message-ID: <3F577DDD.6090606@Royer.com> Date: Thu, 04 Sep 2003 12:01:01 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 8.30 RECUR-ACCEPTED References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080509050502020305010409" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080509050502020305010409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > Doug seems to have a perchant for missing points. I just told you my > suggestion: we need to answer the discrepancy between Purpose and > Description. So you are proposing we change the text to: "we need to answer the discrepancy between Purpose and Description." No. So - do you have a proposal? -- 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 --------------ms080509050502020305010409 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE4MDEwMVowIwYJKoZIhvcNAQkEMRYEFJw4ZQon iUVTcd1RUPXj3xwIb56xMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADjL3lci3K+JlZ+Roq81MaqiAEZbJJfguaJrHvGaCGLpb3rqt0mw rBluLXEmvTQ5JSFS8eujpaHCeYFHq/WfOR1QvhDJF1c6VNkMpVHybFcoFKPmJaSc8qEwMiSI OJYhdUr7NCx1WXzKSw65X6Ry5zclditkrRkxXP0Ia97liH62+T8lFu6DbkKnoikKdGGmyXwY 6CIpQIdIIUp9DusiN0RgJ/8BBMBeIOqLv5ouRaSin/zOXJ03KerGhXCc8BSKN7TXUp/wySKU hyxE+iDj7OF2vfY6xWWDtMDOZz69JiucMsh5NW7s6ww6DJwKn/3P0YIcs707LN8uRqiknL6d HusAAAAAAAA= --------------ms080509050502020305010409-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 15:09:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15824 for ; Thu, 4 Sep 2003 15:09:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84InNgc036959 for ; Thu, 4 Sep 2003 11:49:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84InN3W036958 for ietf-calendar-bks; Thu, 4 Sep 2003 11:49:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84InMgc036953 for ; Thu, 4 Sep 2003 11:49:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84InJS5003487 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 11:49:22 -0700 Message-ID: <3F578929.9050600@Royer.com> Date: Thu, 04 Sep 2003 12:49:13 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020506090708020400080506" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020506090708020400080506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > Doug, thanks for responding so quickly to Bruce's note. However, I am > concerned about the tone of the note - we need more productive responses to > questions and not challenges and verbal abuse. Then please stop Bruce from his unfounded insults and claims. That email he sent out did NOT include ANY comments on the protocol and made unsubstantiated claims as to my motives. It is politics and I am going to respond. > That's typical for an editor to post summaries to a list when > changes are made. It is not typical, I am on several ietf mailing lists, and it is DARN RARE. (see end of this post for more on this topic). >.. believe that's one of the reasons we are struggling to get this draft to > last call - every time someone challenges one of your ideas, you bombast > them with a verbal harrange such that only those with skins of steel will > continue the dialog. STOP DECLARING THAT EVERYTHING IS *MY* IDEA we had this talk at the SF IETF meeting and I told you and Ned in San Francisco that I was going to oppose ANY AND ALL changes to CAP so that we can get it out. You *BOTH* supported me in the FACE to FACE meeting. Ned told us that the only way to finish CAP was to not let ANY more changes to CAP be done without an *OVERWELMING* request to change AND you made that announcement in the SF meeting. Ned told you and I both that is what needed to be done, else they were going to close down the WG. As a result we took out sort (and something else?). I simply have been doing what YOU and NED asked me to do - to STOP ALL CHANGES without an *OVERWELMING* request to change. I told you both the techniques I would use and we ALL agreed it was needed. I told you thatthose that delcare a problem without posting any facts are were going to get bambarded by email from me to ether post the issue or stop claiming there is one. People keep claiming there 'are technical issues', you keep saying you think there are issues with CAP. Bruces email claimed motive but failed to support his claims. Your a chair - post the technical issues. I *WILL* continue to respond to insults and unfounded claims about my motives. And I hope that the senders of that noise do not like my response to their insults. Bruce has a bad habit of declaring what he fears as my motive, then for some reason feels that it is not an insult to say "or I may be mistaken" as if that justifies the insult. Go re-read Bruces email and tell me if he has posted even ONE post that backs up (some in recent posts); (a) ...I certainly dont recall any WG discussion on some of the bigger issues ... (b) ...Im more than a bit concerned that there are changes that creep (additions or omissions) that should not. ... (c) One of the other changes Im leary of was the change in the footers: It just looks like an attempt to give Doug more prominence ... Now do YOU honestly see ANY details in his post to substantiate his assertions? I see him as claiming injury or my motive, without ANY facts or substantive facts to back up his posts. I think it is just politics and I am going to call him on those claims when he makes them. In (a) he does not point out what he is talking about. But he has asserted there are 'bigger issues'. In (b) he claims that things are creeping in (or out). Yet the example he sites is THE SAME TEXT reformatted. In (c) he claims my motive. Then discards it as an insult by saying "..but I could be wrong". What was the point of posting his fear about my motive? Why not a question like you asked when it first came up? > However, I spent an entire weekend going through all the recent emails so > that I can post my own "summary" of recent items showing what I see are > "for/against" types of responses. I will be curious to see if my summary > of comments matches your summary of changes to the CAP draft. If they do, > I will be pleased and comfortable that we have done the right things. If > they do not, we need to take steps to get that rectified. I have no problem with constructive feedback. I do have a problem with comments about my motives. Also - the RECURRECE-ID issue is not a CAP issue. > Therefore, we do need a summary from you, the current editor, of changes > you have made to the most recent draft that you submitted. I appreciate > your hard work on this draft - I want to come to last call - but only with > a draft that everyone on this list (who is interested) agrees with. I kept no summary. I simply printed out the -10 version of the draft, looked at the date, started looking in the WG archive from a month or so before -10 released and started using a markup pen to the printed version as I read each post. The result was edited into -11. And -12-a is simply typos as posted to this list or logged by others into the bugtrack system I posted. The only other things that changed were formatting issues and fixes as a result in a bug in xml2rfc that for some reason left out about 3 sentences and did some odd formatting. Bruce found one of them, no one had noticed the other two. These kinds of rabble rousing claims about motive and secret changes have been made since -00 of CAP. Yet NO post or private email found them substantive. This is part of the IETF process. When I want to see what changed - I do a diff. 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 --------------ms020506090708020400080506 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE4NDkxM1owIwYJKoZIhvcNAQkEMRYEFMgl7hac TzwJVF5Gz0rUa3zbE5mcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAAW5fxbC1qtom+BNz+xgVba8H5u4Vl6DmpRi0zp7MbvlVWmJ8ih4 SdPRNQbA+brR05A0OdC8emAf3VO5FxhfIPDg5xyixG7y0EosQfutwxU4DOVl5QooINgwyxwl u/3UnC4jO/CcJm+nkZkG8xWxwKHy5bFypVJnkFcao8kRgTvrJfb9RpEk/fjW3CX+HYuZKLnP gFPv7jOzFnd9C8ch/iPVAnPKawcbZnQmS46d5urFbaFYA/wAeK5PczDCPZWbVKC8YaW/GEjT PDWOcJCnBc1GssbEXAMObqr0t3JFZL109Z6SJJsErjfNOtVSpKYb4M6c5lbqLFVSxQ9xpZll EUAAAAAAAAA= --------------ms020506090708020400080506-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 15:12:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16131 for ; Thu, 4 Sep 2003 15:12:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84IwEgc037255 for ; Thu, 4 Sep 2003 11:58:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84IwEQh037254 for ietf-calendar-bks; Thu, 4 Sep 2003 11:58:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84IwDgc037249 for ; Thu, 4 Sep 2003 11:58:13 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F576129.4050107@Royer.com> To: ietf-calendar@imc.org Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 14:52:56 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 02:59:26 PM, Serialize complete at 09/04/2003 02:59:26 PM Content-Type: multipart/alternative; boundary="=_alternative 0067B70C85256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067B70C85256D97_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 09/04/2003 11:58:33 AM: > > The original intent was to provide a means for clients to save on space > > and cycles by not having to recraft commonly used queries and resend > > them. > > And it does save both bandwidth and octets especially when you consider > the 2 sets of QUERY/FETCH required without them. Err, I think you are mistaken in how non-stored queries work. The CUA does NOT first retrieve them from the CS (1 trip on the wire) and then resend them to CS in a command (1 trip on the wire). The CUA simply crafts the query locally using whatever inputs it needs/has and sends it. Just the 1 trip I described, not the 2 you seem to think. For those frequently used querys like "What events are on my calendar for XXX" or "What alarms trigger in the next 15 minutes" the CUA simply does a Cscanf() of the correct inputs (XXX or the current date/time) into a loaded query and then sends it. Again, there is no 2 trips across the wire for the query. Even for the stored query case, unless you count the initial storage case, there is only 1 trip across the wire for the query. Subsequent uses simply send QUERYID:Foo in the command and the CS goes to find it and then uses it (assuming it can find it and the CU has the ability to read it). There are undiscussed issues related to stored queries such as: 1: Failure to find a particular QUERYID in a given TARGET, 2: The ability to specify multiple TARGETs in a VQUERY (ie: Do ALL TARGETs have to have the QUERYID in it or just one or is it something else?) 3: How are failures to find/use the QUERYID distinguishded from other command failures (ie: The SEARCH failed because you cant see/find/use the QUERYID in a TARGET vs the SEARCH failed because you cant access the TARGET vs the SEARCH failed because you only can read stored queries but not other data in a TARGET vs...?) All of these undiscussed issues contribute to the proposal that we pull stored queries from CAP 1.0 and defer it to a later draft when they can all be covered. Especially since the feature as it currently exists does not fulfill our original intent. > Complaining without submitting a proposal is something > that almost never works. Likewise, rehashing an issue whose overwhelming data is against you wont change things. > If you want to have the ability to say > get me the alarms over the next 10 minutes - submit a proposal, > else - there is nothing to add. Perhaps you should read the acutal postings before you just fire back responses. Since you keep overlooking it perhaps Ill just make that the body of all repsonses from now on out until you see it (I dont hold my breath for accepting it). In the mean time, I repropose that all references to stored queries be removed from CAP 1.0 and the feature be left for a followon draft when it can be accurately and properly done. 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... Warning: Dates in Calendar are closer than they appear. --=_alternative 0067B70C85256D97_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 09/04/2003 11:58:33 AM:
> > The original intent was to provide a means for clients to save on space
> > and cycles by not having to recraft commonly used queries and resend
> > them.
>
> And it does save both bandwidth and octets especially when you consider
> the 2 sets of QUERY/FETCH required without them.
Err, I think you are mistaken in how non-stored queries work.  

The CUA does NOT first retrieve them from the CS (1 trip on the wire) and then resend them to CS in a command (1 trip on the wire).   The CUA simply crafts the query locally using whatever inputs it needs/has and sends it.  Just the 1 trip I described, not the 2 you seem to think.

For those frequently used querys like "What events are on my calendar for XXX" or "What alarms trigger in the next 15 minutes" the CUA simply does a Cscanf() of the correct inputs (XXX or the current date/time) into a loaded query and then sends it.   Again, there is no 2 trips across the wire for the query.

Even for the stored query case, unless you count the initial storage case, there is only 1 trip across the wire for the query.  Subsequent uses simply send QUERYID:Foo in the command and the CS goes to find it and then uses it (assuming it can find it and the CU has the ability to read it).

There are undiscussed issues related to stored queries such as:

1: Failure to find a particular QUERYID in a given TARGET,
2: The ability to specify multiple TARGETs in a VQUERY (ie: Do ALL TARGETs have to have the QUERYID in it or just one or is it something else?)
3: How are failures to find/use the QUERYID distinguishded from other command failures (ie: The SEARCH failed because you cant see/find/use the QUERYID in a TARGET vs the SEARCH failed because you cant access the TARGET vs the SEARCH failed because you only can read stored queries but not other data in a TARGET vs...?)

All of these undiscussed issues contribute to the proposal that we pull stored queries from CAP 1.0 and defer it to a later draft when they can all be covered.  Especially since the feature as it currently exists does not fulfill our original intent.

>              Complaining without submitting a proposal is something
> that almost never works.

Likewise, rehashing an issue whose overwhelming data is against you wont change things.

>                           If you want to have the ability to say
> get me the alarms over the next 10 minutes - submit a proposal,
> else - there is nothing to add.
Perhaps you should read the acutal postings before you just fire back responses.  Since you keep overlooking it perhaps Ill just make that the body of all repsonses from now on out until you see it (I dont hold my breath for accepting it).  

In the mean time, I repropose that all references to stored queries be removed from CAP 1.0 and the feature be left for a followon draft when it can be accurately and properly done.

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...
Warning: Dates in Calendar are closer than they appear.

--=_alternative 0067B70C85256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 15:14:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16381 for ; Thu, 4 Sep 2003 15:13:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Iw8gc037244 for ; Thu, 4 Sep 2003 11:58:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Iw8BR037243 for ietf-calendar-bks; Thu, 4 Sep 2003 11:58:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Iw7gc037238 for ; Thu, 4 Sep 2003 11:58:07 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F575F1A.5040301@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 14:30:35 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 02:59:20 PM, Serialize complete at 09/04/2003 02:59:20 PM Content-Type: multipart/alternative; boundary="=_alternative 0065AB4485256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065AB4485256D97_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 09/04/2003 11:49:46 AM: > > Since there is no way for any client ('fat' or 'thin') to create a > > stored query that is really beneficial and reusable > > Your opinions presumes you speak for everyone, and you do not. > If you do not find them useful, then speak for yourself. I'm not the only one who have questioned this dubious feature. At the last IETF I was at everyone there questioned it for the exact reasons I described. Had stored queries been able to achieve the original intent I would not question them in CAP 1.0 but they do not remotely approach solving the original intent and they put an implicit burden on ALL CSs so I question their inclusion. I can see their use for non-wildcarded cases but they do not fulfill our original intent for the feature. Because of this and because of the extra load it places on every CS (since there is NO way under CAP-12-a to opt out of it) I concur with Andrea in that it should be removed and left until a later draft. Since Doug seems to be proficient at extra drafts perhaps he can flesh one out that will achieve the original intent... > You also have never proposed a solution to your need that you describe > above. Those that did propose a solution got the text in CAP. That > is the way it works. I proposed that all references to stored queries be removed from CAP 1.0. Or perhaps you missed that in nearly all my other postings on the subject. > So what's your point? Do you want to propose that we add text > saying "do not do something unless it is useful"? Perhaps I should propose we get a co-editor who will pay attention to postings on issues w/o trying to ignore or deflect them in an attempt to get CAP 1.0 out the door ASAP. Proposal: We remove any and all references to stored queries in CAP 1.0. Anyone interested in extending CAP such that the original intent of stored queries is achieved can do so in a later draft. > > The intent of stored queries was to make it easier for 'thin' clients to > > keep smaller footprints by allowing them to not have to (re)craft > > commonly used queries again and again; they relied on the CS to keep the > > query and involk it when the CUA needed it. This is a great concept but > > we failed to design our query language to allow for it to be _actually_ > > useful. > > You keep (re)stating the obvious - however I find the queries useful > as did CS&T. So did John. If its obvious then why is it such a big deal to get it removed? At the last IETF I was at with the Steltor folks they all questioned the usefulness of stored queries given our query language. So did Steve Mansour. That's 2 of the co-editors of CAP. Sure, stored queries can be used but none has been able to show that we are able to achieve the original intent to any real degree (1 example for ~50 octets is hardly any benefit). Given the cost of implementation vs the degree of inability to achieve the intent of the feature I propose (in case you missed it before) that we remove all references to stored queries from CAP 1.0 and leave it to a later draft to add the feature properly. > Your calculations (omitted) failed to calculate the fetching > of the same query that you then send back to the CS. Oh, so you think that the CUA is always going to retrieve the VQUERY from the CS and then resend it back to the CS on any of those commands?!? Why? If the CUA knows it wants to find all unprocessed entries it can use a hardcoded query and just send it; there's no need to go find it and then resend it. There's never been any implicit or explicit need for the CUA to first find the query in the CS and then use it. My CUA should be able to craft and send queries just fine w/o expecting to get them from the CS. After all, just how would your CUA be able to "Find the query that retrieves all entries on my calendar for XXX" where XXX is some arbitrary date/time value? The CUA should have no problem calculating the XXX value based on some UI inputs (ie: the current date being displayed) and filling in the blank before sending the query. Unless of course you never wrote code that used Cscanf() before... > Looks beneficial and efficient to me to just say: Saving ~50 octets is hardly efficient when you factor in that the CS has to always be able to support stored queries and that the original intent for stored queries is unreachable given our current model/design (with 1 exception). > Remember Cell phones and PDAs do not have a user interface that allows > the user to customize the queries. It gives the PDA and Cell phone > companies the ability to modify the result sets. Huh? My cell phone has a built in calendar. From there I can pick the day to see entries on. That's all that the CU needs to do to get data; the underlying CAP engine does the rest. (Are you expecting CUs to be doing query crafting manually instead of letting the CUA do it?? I don't want to be beta testing your CUA if that's true...) If it had a CAP engine, it would have NO way to access any kind of stored query on my CS to get the events for "Today" or the day I pick at random! None. The CAP engine in my cell phone MUST craft up the query with the "WHERE DTSTART<=[the selected day] AND DTEND>=[the selected day]" and send it. There is NO way around it and that's exactly why the stored query feature in CAP 1.0 fails to meet the original intent. "[T]he ability to modify the result set" is totally unrelated to the issue of query storage! Post processing of any kind is not relevant to the issue of using stored queries or queries within the command. > Plus there is NO requirement that the contents of QUERYID be > static, they could be dynamic. Umm, is this germane? I'm not sure what you are referring to so I cant respond. > Something was demonstrated you comment on it below. Your 4 examples were unremarkable and uncompelling. You duplicated 1 and the other 2 were not related to the intent of the feature. Of the sole releveant example the only savings was ~50 octets. To me, 50 octets is not that compelling given its only for 1 example and there are NO other examples that fulfill the original intent. All the other examples you provided were not typical common or frequently used queries and as such are hardly compelling incentive to keep the feature in (unless you've got code that already does it and don't want to tie it off until a later draft.) > It allows the Cell phone and PDA to have a GUI-CUA that runs on > a full computer to specify what you get back when you say 'Common'. > Such as VEVENT only, or VTODO only, or whatever. The PDA and > Cell phones are not going to have that ability. There is no great need for some fancy GUI on thin clients Doug. My LG 610 has a built in calendar that allows me to create entries on it and have alarms set, etc. I press 1 button to get the current month and then use my arrow buttons to pick a day. From there any entries I have for that day appear. I can also create new entries or remove those that are there (or update them w/alarms). If I were to try and use CAP to get data from my calendar then the phone MUST craft a query like "QUERY:SELECT VEVENT FROM VAGENDA WHERE DTSTART<=[date I selected] AND DTEND>=[date I selected]" where the date values are based on the day I selected via arrow buttons. The CAP engine simply takes the date I picked and then Cscanf()'s it into the query and sends it. No big GUI needs. No benefit to using a stored query since it cannot wildcard the selected date into the query. Just a simple Cscanf() into a buffer and then send it. Originally we had envisioned being able to say "QUERYID:Todays_events" and the CS would be able to find them for my cell phone, no need for it to craft the QUERY. However we failed to make the query language robust (or flexible) enough to convey wildcarded or fixed semantics (ie: "Today"). As such the thin clients have no way to get the benefit we intended and the CS implementations are implicitly mandated to support stored queries. > Stored queries allows their search results > to be configured for them. Where do you come up with this stuff? Referencing a stored query has NOTHING to do with any kind of results processing. A stored query was intended as a means to minimize the CUAs need to send the frequently used querys in a command; the query was already on the CS so it could be just referenced by QUERYID and the CS would find and use it instead of parse the command for the query and perform it. > Not all CUA's are computer based GUIs with user interfaces and lots > of memory and processing power. Umm, ~50 octets is hardly that big an impact if the 'thin' client expects to be able to hold any amount of possible calendar data returned on the search. After all we dont have a way to throttle off the SEARCH command results when too much data is returned short of shutting the BEEP channel. So again I propose that we remove all references to stored queries in CAP 1.0 and anyone interested in extending CAP such that the original intent of stored queries is achieved can do so in a later 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 0065AB4485256D97_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 09/04/2003 11:49:46 AM:
> > Since there is no way for any client ('fat' or 'thin') to create a
> > stored query that is really beneficial and reusable
>
> Your opinions presumes you speak for everyone, and you do not.
> If you do not find them useful, then speak for yourself.
I'm not the only one who have questioned this dubious feature.  At the last IETF I was at everyone there questioned it for the exact reasons I described.

Had stored queries been able to achieve the original intent I would not question them in CAP 1.0 but they do not remotely approach solving the original intent and they put an implicit burden on ALL CSs so I question their inclusion.

I can see their use for non-wildcarded cases but they do not fulfill our original intent for the feature.  Because of this and because of the extra load it places on every CS (since there is NO way under CAP-12-a to opt out of it) I concur with Andrea in that it should be removed and left until a later draft.  

Since Doug seems to be proficient at extra drafts perhaps he can flesh one out that will achieve the original intent...

> You also have never proposed a solution to your need that you describe
> above. Those that did propose a solution got the text in CAP. That
> is the way it works.
I proposed that all references to stored queries be removed from CAP 1.0.  Or perhaps you missed that in nearly all my other postings on the subject.  

> So what's your point? Do you want to propose that we add text
> saying "do not do something unless it is useful"?
<FRUSTRATION SHOW=ON>
Perhaps I should propose we get a co-editor who will pay attention to postings on issues w/o trying to ignore or deflect them in an attempt to get CAP 1.0 out the door ASAP.
</FRUSTRATION>

Proposal: We remove any and all references to stored queries in CAP 1.0.  Anyone interested in extending CAP such that the original intent of stored queries is achieved can do so in a later draft.

> > The intent of stored queries was to make it easier for 'thin' clients to
> > keep smaller footprints by allowing them to not have to (re)craft
> > commonly used queries again and again; they relied on the CS to keep the
> > query and involk it when the CUA needed it.  This is a great concept but
> > we failed to design our query language to allow for it to be _actually_
> > useful.
>
> You keep (re)stating the obvious - however I find the queries useful
> as did CS&T. So did John.
If its obvious then why is it such a big deal to get it removed?

At the last IETF I was at with the Steltor folks they all questioned the usefulness of stored queries given our query language.  So did Steve Mansour.  That's 2 of the co-editors of CAP.  Sure, stored queries can be used but none has been able to show that we are able to achieve the original intent to any real degree (1 example for ~50 octets is hardly any benefit).

Given the cost of implementation vs the degree of inability to achieve the intent of the feature I propose (in case you missed it before) that we remove all references to stored queries from CAP 1.0 and leave it to a later draft to add the feature properly.

> Your calculations (omitted) failed to calculate the fetching
> of the same query that you then send back to the CS.
Oh, so you think that the CUA is always going to retrieve the VQUERY from the CS and then resend it back to the CS on any of those commands?!?  Why?  If the CUA knows it wants to find all unprocessed entries it can use a hardcoded query and just send it; there's no need to go find it and then resend it.

There's never been any implicit or explicit need for the CUA to first find the query in the CS and then use it.  My CUA should be able to craft and send queries just fine w/o expecting to get them from the CS.  After all, just how would your CUA be able to "Find the query that retrieves all entries on my calendar for XXX" where XXX is some arbitrary date/time value?  The CUA should have no problem calculating the XXX value based on some UI inputs (ie: the current date being displayed) and filling in the blank before sending the query.  Unless of course you never wrote code that used Cscanf() before...

> Looks beneficial and efficient to me to just say:
Saving ~50 octets is hardly efficient when you factor in that the CS has to always be able to support stored queries and that the original intent for stored queries is unreachable given our current model/design (with 1 exception).

> Remember Cell phones and PDAs do not have a user interface that allows
> the user to customize the queries. It gives the PDA and Cell phone
> companies the ability to modify the result sets.
Huh?  My cell phone has a built in calendar.  From there I can pick the day to see entries on.  That's all that the CU needs to do to get data; the underlying CAP engine does the rest.  (Are you expecting CUs to be doing query crafting manually instead of letting the CUA do it?? I don't want to be beta testing your CUA if that's true...)

If it had a CAP engine, it would have NO way to access any kind of stored query on my CS to get the events for "Today" or the day I pick at random!  None.  The CAP engine in my cell phone MUST craft up the query with the "WHERE DTSTART<=[the selected day] AND DTEND>=[the selected day]" and send it.  There is NO way around it and that's exactly why the stored query feature in CAP 1.0 fails to meet the original intent.  

"[T]he ability to modify the result set" is totally unrelated to the issue of query storage!  Post processing of any kind is not relevant to the issue of using stored queries or queries within the command.

> Plus there is NO requirement that the contents of QUERYID be
> static, they could be dynamic.  

Umm, is this germane?  I'm not sure what you are referring to so I cant respond.  

> Something was demonstrated you comment on it below.
Your 4 examples were unremarkable and uncompelling.  You duplicated 1 and the other 2 were not related to the intent of the feature.  

Of the sole releveant example the only savings was ~50 octets.  To me, 50 octets is not that compelling given its only for 1 example and there are NO other examples that fulfill the original intent.  All the other examples you provided were not typical common or frequently used queries and as such are hardly compelling incentive to keep the feature in (unless you've got code that already does it and don't want to tie it off until a later draft.)

> It allows the Cell phone and PDA to have a GUI-CUA that runs on
> a full computer to specify what you get back when you say 'Common'.
> Such as VEVENT only, or VTODO only, or whatever. The PDA and
> Cell phones are not going to have that ability.
There is no great need for some fancy GUI on thin clients Doug.  My LG 610 has a built in calendar that allows me to create entries on it and have alarms set, etc.  I press 1 button to get the current month and then use my arrow buttons to pick a day.  From there any entries I have for that day appear.  I can also create new entries or remove those that are there (or update them w/alarms).

If I were to try and use CAP to get data from my calendar then the phone MUST craft a query like "QUERY:SELECT VEVENT FROM VAGENDA WHERE DTSTART<=[date I selected] AND DTEND>=[date I selected]" where the date values are based on the day I selected via arrow buttons.  The CAP engine simply takes the date I picked and then Cscanf()'s it into the query and sends it.  No big GUI needs.  No benefit to using a stored query since it cannot wildcard the selected date into the query.  Just a simple Cscanf() into a buffer and then send it.

Originally we had envisioned being able to say "QUERYID:Todays_events" and the CS would be able to find them for my cell phone, no need for it to craft the QUERY.  However we failed to make the query language robust (or flexible) enough to convey wildcarded or fixed semantics (ie: "Today").  As such the thin clients have no way to get the benefit we intended and the CS implementations are implicitly mandated to support stored queries.  

>                               Stored queries allows their search results
> to be configured for them.

Where do you come up with this stuff?  Referencing a stored query has NOTHING to do with any kind of results processing.

A stored query was intended as a means to minimize the CUAs need to send the frequently used querys in a command; the query was already on the CS so it could be just referenced by QUERYID and the CS would find and use it instead of parse the command for the query and perform it.

> Not all CUA's are computer based GUIs with user interfaces and lots
> of memory and processing power.
Umm, ~50 octets is hardly that big an impact if the 'thin' client expects to be able to hold any amount of possible calendar data returned on the search.  After all we dont have a way to throttle off the SEARCH command results when too much data is returned short of shutting the BEEP channel.

So again I propose that we remove all references to stored queries in CAP 1.0 and anyone interested in extending CAP such that the original intent of stored queries is achieved can do so in a later 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 0065AB4485256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 15:21:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17129 for ; Thu, 4 Sep 2003 15:21:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84J2Ygc037463 for ; Thu, 4 Sep 2003 12:02:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84J2YBC037462 for ietf-calendar-bks; Thu, 4 Sep 2003 12:02:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84J2Xgc037457 for ; Thu, 4 Sep 2003 12:02:33 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: Re: CAP-12 - interm version 'A' MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 15:00:35 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 03:03:46 PM, Serialize complete at 09/04/2003 03:03:46 PM Content-Type: multipart/alternative; boundary="=_alternative 00686A4A85256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00686A4A85256D97_= Content-Type: text/plain; charset="US-ASCII" Pat replied on 09/04/2003 12:49:44 PM: > As for the boiler plate changes, I think a boiler plate is supposed to be > just that - I am not sure we have much leverage to change things. Perhaps I was not clear when I described the change. It was not the change like the year in the copyright, it was whitespace changes like: =========================================================================== ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 23 Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 23 Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. =========================================================================== ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 29 time. It is inappropriate to use Internet-Drafts as reference ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 28 time. It is inappropriate to use Internet-Drafts as reference Notice that just the whitespace changed in a couple sentences (2 spaces down to 1 space). This isn't an IETF change that I can verify in other recent drafts. I suspect its likely related to the XML converter that Doug uses; the one that lost at least 3-4 blocks of text in the past. I dont get warm fuzzys about doing diffs if stuff that should not change does, it makes weeding the wheat from the chaff very very tedious. 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 00686A4A85256D97_= Content-Type: text/html; charset="US-ASCII"
Pat replied on 09/04/2003 12:49:44 PM:
> As for the boiler plate changes, I think a boiler plate is supposed to be
> just that - I am not sure we have much leverage to change things.

Perhaps I was not clear when I described the change.  It was not the change like the year in the copyright, it was whitespace changes like:

===========================================================================
************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 23
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 23
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.
===========================================================================
************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 29
   time.  It is inappropriate to use Internet-Drafts as reference
******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 28
   time. It is inappropriate to use Internet-Drafts as reference

Notice that just the whitespace changed in a couple sentences (2 spaces down to 1 space).  This isn't an IETF change that I can verify in other recent drafts.  

I suspect its likely related to the XML converter that Doug uses; the one that lost at least 3-4 blocks of text in the past.  I dont get warm fuzzys about doing diffs if stuff that should not change does, it makes weeding the wheat from the chaff very very tedious.

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 00686A4A85256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 15:31:55 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17717 for ; Thu, 4 Sep 2003 15:31:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JIXgc038730 for ; Thu, 4 Sep 2003 12:18:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84JIXnA038729 for ietf-calendar-bks; Thu, 4 Sep 2003 12:18:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JIWgc038723 for ; Thu, 4 Sep 2003 12:18:32 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84JIUS5003891 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 12:18:33 -0700 Message-ID: <3F579001.1020109@Royer.com> Date: Thu, 04 Sep 2003 13:18:25 -0600 From: Doug Royer Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070005060702090304030909" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070005060702090304030909 Content-Type: multipart/mixed; boundary="------------010704000704020306000301" This is a multi-part message in MIME format. --------------010704000704020306000301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is an attempt to start documenting all of the RECURRENCE-ID issues. In -00 I did not represent the 'FIXED' camp very well as I do not fully understand it and so it is missing examples. I hope this will evolve into a document that describes ways that different models will interact and how to make them interact in useful ways. I also hope this will evolve into how to migrate to some workable common usage. As it states in the first part of the draft, I expect it to get blasted. But the intent is to gather information so that things can be documented and resolutions found. -------- Original Message -------- Subject: I-D ACTION:draft-royer-rid-ical-00.txt Date: Thu, 04 Sep 2003 10:39:08 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RECURRENCE-ID in iCal Author(s) : D. Royer Filename : draft-royer-rid-ical-00.txt Pages : 10 Date : 2003-9-4 The initial version of this draft are going to be controversial. The idea is to develope ways to make the various ways of using the [iCAL] and [iTIP] 'RECURRENCE-ID' property work between vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-rid-ical-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-rid-ical-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-rid-ical-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- 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 --------------010704000704020306000301 Content-Type: Message/External-body; name="draft-royer-rid-ical-00.txt" Content-Disposition: inline; filename="draft-royer-rid-ical-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-9-4095506.I-D@ietf.org> --------------010704000704020306000301-- --------------ms070005060702090304030909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE5MTgyNVowIwYJKoZIhvcNAQkEMRYEFEHy7uzB CaIIGgJ85rnrutxGiYhVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIaLBLwHFJwSLMc9vfA7TvM/JjaBhcxXRL5LkvSH0p2Fb4JeoiwN 2UC73TbHy9NSqdUv0VyKGV4kYL2q3+VGr+e7zcmDYNlNuNI2YduAMYPjkByj2EjXITkepm2Q dW1VaqYqf+yAmFRNWK2yT8MP5zwouu/eZsVddNo5KLjqYTLys7GFsEzGVJhwSM1HXSb2oS0r edZQtV52T2Z8ZE1YLaR1pQVrzZdsnV0WXwtol0CIiKnuITUACKFGFdPQPa8vj66FWuOzxiHC zNd5+h+Vi3bmyko+A6QBH5V3tc1fu7C7TPdmNULuNtqZPEf2SHZ3Fo2di+A3uaOTRvOX4iTX SzQAAAAAAAA= --------------ms070005060702090304030909-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 15:37:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17941 for ; Thu, 4 Sep 2003 15:37:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JI5gc038664 for ; Thu, 4 Sep 2003 12:18:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84JI5xI038663 for ietf-calendar-bks; Thu, 4 Sep 2003 12:18:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JI3gc038654 for ; Thu, 4 Sep 2003 12:18:03 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84JI3S5003885 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 12:18:04 -0700 Message-ID: <3F578FE5.2050305@Royer.com> Date: Thu, 04 Sep 2003 13:17:57 -0600 From: Doug Royer Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070706010400030403060805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070706010400030403060805 Content-Type: multipart/mixed; boundary="------------080908000401070005090208" This is a multi-part message in MIME format. --------------080908000401070005090208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is an attempt to start documenting all of the RECURRENCE-ID issues. In -00 I did not represent the 'FIXED' camp very well as I do not fully understand it and so it is missing examples. I hope this will evolve into a document that describes ways that different models will interact and how to make them interact in useful ways. I also hope this will evolve into how to migrate to some workable common usage. As it states in the first part of the draft, I expect it to get blasted. But the intent is to gather information so that it can be documented. -------- Original Message -------- Subject: I-D ACTION:draft-royer-rid-ical-00.txt Date: Thu, 04 Sep 2003 10:39:08 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RECURRENCE-ID in iCal Author(s) : D. Royer Filename : draft-royer-rid-ical-00.txt Pages : 10 Date : 2003-9-4 The initial version of this draft are going to be controversial. The idea is to develope ways to make the various ways of using the [iCAL] and [iTIP] 'RECURRENCE-ID' property work between vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-rid-ical-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-rid-ical-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-rid-ical-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- 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 --------------080908000401070005090208 Content-Type: Message/External-body; name="draft-royer-rid-ical-00.txt" Content-Disposition: inline; filename="draft-royer-rid-ical-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-9-4095506.I-D@ietf.org> --------------080908000401070005090208-- --------------ms070706010400030403060805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE5MTc1N1owIwYJKoZIhvcNAQkEMRYEFD1I756g Wu3pC7KCFajDG6vEC83YMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGyCNn727DdZosX8TbjlgFNJ7iIwaaQa1vpFoPYeeHpPz4XSlEYY Ndnjln+23/qlXELMwCs8gSYwQFxWAQ1DNdUkanVlCz0N1LXyazN3kjAJFoDeXtQgw2xCuGia zAGOed5xltaGF5mjj3a77qpFWMiDKip7MMG7Tw/BmayOZGrEGQfQ7tjpLp8cJpQRj9GbPLnA Fg9DOqMLCHHWkirlgqcY021gEq838DcPcidD3KIZnLIFZbDGnkmv+0DECLnoKXrK/zWFTmY1 Z16gNicNlMqk8xKGDS1XoykBJ3ycts/jYoCaRy+reGC7dM5td4rZc/5J61vGPtCcjNMbj31g z9AAAAAAAAA= --------------ms070706010400030403060805-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 15:40:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18140 for ; Thu, 4 Sep 2003 15:40:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JMKgc039381 for ; Thu, 4 Sep 2003 12:22:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84JMKWm039380 for ietf-calendar-bks; Thu, 4 Sep 2003 12:22:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JMIgc039365 for ; Thu, 4 Sep 2003 12:22:19 -0700 (PDT) (envelope-from pregen@egenconsulting.com) Subject: Re: CAP-12 - interm version 'A' To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Thu, 4 Sep 2003 15:22:12 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 03:22:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h84JMJgc039369 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hm, that makes a difference. I guess I need to ask the RFC guys if what we are doing is cool. Bruce_Kahn@notesdev.i bm.com To: pregen@egenconsulting.com Sent by: cc: ietf-calendar@imc.org owner-ietf-calendar@m Subject: Re: CAP-12 - interm version 'A' ail.imc.org 09/04/2003 03:00 PM Pat replied on 09/04/2003 12:49:44 PM: > As for the boiler plate changes, I think a boiler plate is supposed to be > just that - I am not sure we have much leverage to change things. Perhaps I was not clear when I described the change.  It was not the change like the year in the copyright, it was whitespace changes like: =========================================================================== ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 23    Task Force (IETF), its areas, and its working groups.  Note that    other groups may also distribute working documents as Internet-    Drafts. ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 23    Task Force (IETF), its areas, and its working groups. Note that other    groups may also distribute working documents as Internet-Drafts. =========================================================================== ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 29    time.  It is inappropriate to use Internet-Drafts as reference ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 28    time. It is inappropriate to use Internet-Drafts as reference Notice that just the whitespace changed in a couple sentences (2 spaces down to 1 space).  This isn't an IETF change that I can verify in other recent drafts. I suspect its likely related to the XML converter that Doug uses; the one that lost at least 3-4 blocks of text in the past.  I dont get warm fuzzys about doing diffs if stuff that should not change does, it makes weeding the wheat from the chaff very very tedious. 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 Thu Sep 4 15:57:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18996 for ; Thu, 4 Sep 2003 15:57:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JjTgc042952 for ; Thu, 4 Sep 2003 12:45:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84JjTmE042951 for ietf-calendar-bks; Thu, 4 Sep 2003 12:45:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JjSgc042944 for ; Thu, 4 Sep 2003 12:45:28 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F576C25.9080206@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 15:38:32 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 03:46:39 PM, Serialize complete at 09/04/2003 03:46:39 PM Content-Type: multipart/alternative; boundary="=_alternative 006BE39185256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006BE39185256D97_= Content-Type: text/plain; charset="US-ASCII" Doug pondered on 09/04/2003 12:45:25 PM: > What about the round trip time to go fetch the VQUERY manually, > then re-submit it as a query? That save bandwidth and octets > for slow and memory limited devices. Umm, there is NO roundtrip to get the query string and then resending it to the CS. The CUA simply does (psuedocode below): LoadString( (bCheckingEvents) ? QUERY_NEW_EVENTS : QUERY_NEW_TASKS, Buffer ); Cscanf( Buffer, DateToGetEntriesFor ); SendQUERY( Buffer ); to query the CS for the new events or todos. Im not sure why you'd think you have to query the CS for the query and then resend it, you'd just be crafting the query in the CUA and just sending them. Nobody has said anything about loading the query from the CS just to resend it back on the 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 006BE39185256D97_= Content-Type: text/html; charset="US-ASCII"
Doug pondered on 09/04/2003 12:45:25 PM:
> What about the round trip time to go fetch the VQUERY manually,
> then re-submit it as a query? That save bandwidth and octets
> for slow and memory limited devices.
Umm, there is NO roundtrip to get the query string and then resending it to the CS.  The CUA simply does (psuedocode below):

        LoadString( (bCheckingEvents) ? QUERY_NEW_EVENTS : QUERY_NEW_TASKS, Buffer );
        Cscanf( Buffer, DateToGetEntriesFor );
        SendQUERY( Buffer );

to query the CS for the new events or todos.

Im not sure why you'd think you have to query the CS for the query and then resend it, you'd just be crafting the query in the CUA and just sending them.   Nobody has said anything about loading the query from the CS just to resend it back on the 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 006BE39185256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 15:58:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19015 for ; Thu, 4 Sep 2003 15:58:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JjPgc042933 for ; Thu, 4 Sep 2003 12:45:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84JjP2c042932 for ietf-calendar-bks; Thu, 4 Sep 2003 12:45:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JjOgc042923 for ; Thu, 4 Sep 2003 12:45:24 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F576B23.3010704@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 15:29:35 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 03:46:35 PM, Serialize complete at 09/04/2003 03:46:35 PM Content-Type: multipart/alternative; boundary="=_alternative 006B11E985256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B11E985256D97_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 09/04/2003 12:41:07 PM: > Thanks for finally agreeing that you could indeed help and that > your repeated claims that you did not have time or ability to do > your own diff were just silly. In WGs its typically the job of the editor to post a summary of the changes between versions of a draft; not the job of each individual reader in the group to go and try and figure it out. As my diff showed, I see why you were reluctant to post them. They are >500K in size (after I removed many of the header/footer/TOC reports even!)! Now to be fair about it, several of the changes appear to just be simple whitespace changes (or the TOC/header/footer changes) but still a diff is not that useful if every reader has to start from scratch or separate whitespace changes from real changes. Why there appear to be so many simple whitespace changs (for the worse mind you) I dont know but I suspect the XML converter. Given its history of not accuratly converting content to HTML/TEXT you can understand why I dont have a warm fuzzy feeling about accuratly finding the changs you've made to CAP-12. In any case, instead of making everyone in the list wade thru all the diffs to find changes I think it would be more constructive if you could post a summary of the changes. You've done this before on other drafts (or was it earlier CAP ones, I dont recall) so you know whats involved. Plus you are the only one who knows what actual changs got made vs diff blithly reports as a change but isnt really content related. 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 006B11E985256D97_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 09/04/2003 12:41:07 PM:
> Thanks for finally agreeing that you could indeed help and that
> your repeated claims that you did not have time or ability to do
> your own diff were just silly.
In WGs its typically the job of the editor to post a summary of the changes between versions of a draft; not the job of each individual reader in the group to go and try and figure it out.

As my diff showed, I see why you were reluctant to post them.  They are >500K in size (after I removed many of the header/footer/TOC reports even!)!  Now to be fair about it, several of the changes appear to just be simple whitespace changes (or the TOC/header/footer changes) but still a diff is not that useful if every reader has to start from scratch or separate whitespace changes from real changes.

Why there appear to be so many simple whitespace changs (for the worse mind you) I dont know but I suspect the XML converter.  Given its history of not accuratly converting content to HTML/TEXT  you can understand why I dont have a warm fuzzy feeling about accuratly finding the changs you've made to CAP-12.

In any case, instead of making everyone in the list wade thru all the diffs to find changes I think it would be more constructive if you could post a summary of the changes.  You've done this before on other drafts (or was it earlier CAP ones, I dont recall) so you know whats involved.  Plus you are the only one who knows what actual changs got made vs diff blithly reports as a change but isnt really content related.

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 006B11E985256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 16:04:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19336 for ; Thu, 4 Sep 2003 16:04:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Jm7gc043105 for ; Thu, 4 Sep 2003 12:48:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Jm6ob043104 for ietf-calendar-bks; Thu, 4 Sep 2003 12:48:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Jm5gc043099 for ; Thu, 4 Sep 2003 12:48:05 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84Jm4S5004349 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 12:48:06 -0700 Message-ID: <3F5796EF.9060908@Royer.com> Date: Thu, 04 Sep 2003 13:47:59 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070101060704090304030705" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070101060704090304030705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 09/04/2003 11:58:33 AM: > > > The original intent was to provide a means for clients to save on > space > > > and cycles by not having to recraft commonly used queries and resend > > > them. > > > > And it does save both bandwidth and octets especially when you consider > > the 2 sets of QUERY/FETCH required without them. > > Err, I think you are mistaken in how non-stored queries work. > > The CUA does NOT first retrieve them from the CS (1 trip on the wire) > and then resend them to CS in a command (1 trip on the wire). The CUA > simply crafts the query locally using whatever inputs it needs/has and > sends it. Just the 1 trip I described, not the 2 you seem to think. My point exactly. If I want the query named XXX and we do not support VQUERY with QUERYID, then the CUA MUST do that 2 round trips. > For those frequently used querys like "What events are on my calendar > for XXX" or "What alarms trigger in the next 15 minutes" the CUA simply > does a Cscanf() of the correct inputs (XXX or the current date/time) > into a loaded query and then sends it. Again, there is no 2 trips > across the wire for the query. NO ONE has proposed such a thing - who cares? > There are undiscussed issues related to stored queries such as: > > 1: Failure to find a particular QUERYID in a given TARGET, Why do you feel that would be any different to a query for a UID that did not exist? Its the component-ID tag. No such distinction exists. If you qury for a UID that does not exist in the named TARGET - you get an error. If you qury for a QUIERYID that does not exist in the named TARGET - you get an error. If you qury for ANY property that does not exist in the named TARGET - you get an error - even when it is not a VQUERY. Not an issue. > 2: The ability to specify multiple TARGETs in a VQUERY (ie: Do ALL > TARGETs have to have the QUERYID in it or just one or is it something > else?) Not sure which TARGET you mean: If you are talking about the TARGET in the VQUERY, then there is no difference to manually sending the same VQUERY even when it is not stored. Not an issue, So why do you feel it is different if it is stored or not? If you are talking about the TARGET at the CMD level, then there is no difference to manually sending the same VQUERY even when it is not stored. Not an issue. So why do you feel it is different if it is stored or not? > 3: How are failures to find/use the QUERYID distinguishded from other > command failures (ie: The SEARCH failed because you cant see/find/use > the QUERYID in a TARGET vs the SEARCH failed because you cant access the > TARGET vs the SEARCH failed because you only can read stored queries but > not other data in a TARGET vs...?) As you can send the EXACT same query manually, why do you feel that it would be any different? > All of these undiscussed issues contribute to the proposal that we pull > stored queries from CAP 1.0 and defer it to a later draft when they can > all be covered. Especially since the feature as it currently exists > does not fulfill our original intent. All of your assertions above are unfounded and unsubstantiated. They are not real problems. They have nothing to do with the text in CAP. Those problems do not exist in any way that is different from non-stored queries. > -- 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 --------------ms070101060704090304030705 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE5NDc1OVowIwYJKoZIhvcNAQkEMRYEFCaR7ph1 CRiJXI1z+XX0zdRUFqqbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAENgQ30+C0vno3eczve1ZO2zS6TIf7nXLfgx3ksJsNvCHmW0GhxS hkfSV+ljwFfSv1qKG1rOMEyAdIaE5iT1z5lQyz4hlp6FAW6vUkq7U6lcrGZzT7mUT2PsMe3S 2Fl9VKI8G6q1qoVydIHRzMwmARDZsofPYixHC6NIUrTGmqjqAxYvkr64aZuLRINEYB9NYLUb 0KY1gATVWqktLDTbkA7ygkvOq7JkS3LwN580qZlg+lRTwqQtnSj2xVuirFztwD0lIRazevrr jvQd9Eyx3b7zwtEVGt426UTzaBSp69i4UNFE3torKN/cjDmzwTaq+NwWymI54uFr9PuIotWW hhoAAAAAAAA= --------------ms070101060704090304030705-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 16:10:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19619 for ; Thu, 4 Sep 2003 16:10:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JsNgc043885 for ; Thu, 4 Sep 2003 12:54:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84JsN8U043884 for ietf-calendar-bks; Thu, 4 Sep 2003 12:54:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JsLgc043878 for ; Thu, 4 Sep 2003 12:54:21 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84JsJS5004456 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 12:54:22 -0700 Message-ID: <3F579866.1050902@Royer.com> Date: Thu, 04 Sep 2003 13:54:14 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050600030306000401000101" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050600030306000401000101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Pat replied on 09/04/2003 12:49:44 PM: > > As for the boiler plate changes, I think a boiler plate is supposed to be > > just that - I am not sure we have much leverage to change things. > > Perhaps I was not clear when I described the change. It was not the > change like the year in the copyright, it was whitespace changes like: > > =========================================================================== > ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 23 > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 23 > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > =========================================================================== > ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 29 > time. It is inappropriate to use Internet-Drafts as reference > ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 28 > time. It is inappropriate to use Internet-Drafts as reference > > Notice that just the whitespace changed in a couple sentences (2 spaces > down to 1 space). This isn't an IETF change that I can verify in other > recent drafts. > > I suspect its likely related to the XML converter that Doug uses; the > one that lost at least 3-4 blocks of text in the past. I dont get warm > fuzzys about doing diffs if stuff that should not change does, it makes > weeding the wheat from the chaff very very tedious. No, the instructions say: Use single spaced text within a paragraph, and one blank line between paragraphs. I have been told that also means you can not have two spaces after a period using the new interpretations. And yes, it is a pain as I have to compare what I change to look for typos myself in the editing process. And if you did not notice my note: -->>>>>>> There are going to be more formatting changes to come. Because the RFC editors take the ENTIRE file and reformat it using their tools. Feed it back, loop, repeat until everyone is happy. -- 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 --------------ms050600030306000401000101 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE5NTQxNFowIwYJKoZIhvcNAQkEMRYEFNLU0IDb vBE0KBWA0yKzKt0Sa88uMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAMA7FTfPYc7QBvDMKeakd6yGa9kbHAKUKy1g0ax1gwzrjTxBZYgG 4LKzRGaAEfiVqzmg2Rx+gtZoHXlhWugnuzkBG/8FXa37iA+ksDTaACXZOByaQhG4ntSPFl6k sEzqmw3kpAbt9bxwRaAhmOsl5cpX+lDYYl00Z0/F4ZQO/ZldrxhzwscpM5xLupMjSLu3JzEl NDBT761AnC0aaEzbqmtGwYdH84X7EVPrDuDeB/f+woexqGGZtLjAHL9wDnwuoo4N/EKu/vK5 +B5bvegClyxKAb4JasaflkZIAFGH2F5/CgINdQNHLng6hEWVBS7LCUW3lAMlGhgOaXW+ZhER 2eQAAAAAAAA= --------------ms050600030306000401000101-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 16:20:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20108 for ; Thu, 4 Sep 2003 16:20:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84K6kgc044511 for ; Thu, 4 Sep 2003 13:06:46 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84K6jus044510 for ietf-calendar-bks; Thu, 4 Sep 2003 13:06:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84K6igc044501 for ; Thu, 4 Sep 2003 13:06:44 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84K6iS5004651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 13:06:45 -0700 Message-ID: <3F579B4E.1090108@Royer.com> Date: Thu, 04 Sep 2003 14:06:38 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000107070107050301040501" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000107070107050301040501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug pondered on 09/04/2003 12:45:25 PM: > > What about the round trip time to go fetch the VQUERY manually, > > then re-submit it as a query? That save bandwidth and octets > > for slow and memory limited devices. > > Umm, there is NO roundtrip to get the query string and then resending it > to the CS. The CUA simply does (psuedocode below): Not a clue what you sent below was. > LoadString( (bCheckingEvents) ? QUERY_NEW_EVENTS : > QUERY_NEW_TASKS, Buffer ); > Cscanf( Buffer, DateToGetEntriesFor ); > SendQUERY( Buffer ); > > to query the CS for the new events or todos. > > Im not sure why you'd think you have to query the CS for the query and > then resend it, you'd just be crafting the query in the CUA and just > sending them. Nobody has said anything about loading the query from > the CS just to resend it back on the command... Okay - I want to do what is stored in a component with a QUERYID tag of 'XXX' as set by my configureation tool on my cell phone. Please show me the VQUERY component that your CUA will send. Your going to have to (1) fetch XXX, then (2) submit it. That is 2 round trips. -- 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 --------------ms000107070107050301040501 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDIwMDYzOFowIwYJKoZIhvcNAQkEMRYEFCcFM47t czpxNk0x1SPNPJhDfyJfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAB7yhWhKZXl0dC52XjhxAIosxpiJ7DhVD7r+GxlOEuEP8whT3f2O /eWA34kJ3RXWre4T37OfA9fzdPMLIXR4SQuEJX12saajPNL37x2p61SHbyoEnckqjKXIa0JW 075NczMIY5xuWM7YegbXobOaBqNvh180evkLnqhjNyrYlfJE81+6rfxTX29TE+nHid6EF9jb /2XowHGC8yMpiu5F+mbl7gpKs7/NjblfwOCzvKdkn0Vm1e8ei0F51UHuYZQ/IwexEIVB8AVw tKr0Are+46ge/FmuSxDgso6ENmHPRhFgWOC2wzJfdB/zNVJoujwS6Ec8OInH0U3nbuUZyHPb Nc4AAAAAAAA= --------------ms000107070107050301040501-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 16:24:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20228 for ; Thu, 4 Sep 2003 16:24:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84K4Cgc044347 for ; Thu, 4 Sep 2003 13:04:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84K4Ciu044346 for ietf-calendar-bks; Thu, 4 Sep 2003 13:04:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84K4Agc044341 for ; Thu, 4 Sep 2003 13:04:11 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84K49S5004616 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 13:04:11 -0700 Message-ID: <3F579AB4.1000900@Royer.com> Date: Thu, 04 Sep 2003 14:04:04 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050609050403010702020302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050609050403010702020302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug responded on 09/04/2003 11:49:46 AM: > > > Since there is no way for any client ('fat' or 'thin') to create a > > > stored query that is really beneficial and reusable > > > > Your opinions presumes you speak for everyone, and you do not. > > If you do not find them useful, then speak for yourself. > > I'm not the only one who have questioned this dubious feature. At the > last IETF I was at everyone there questioned it for the exact reasons I > described. I made no such claim. You clamed that only I supported it - not true. > Had stored queries been able to achieve the original intent I would not > question them in CAP 1.0 but they do not remotely approach solving the > original intent and they put an implicit burden on ALL CSs so I question > their inclusion. And what was the original intent? > > I proposed that all references to stored queries be removed from CAP > 1.0. Or perhaps you missed that in nearly all my other postings on the > subject. > > > So what's your point? Do you want to propose that we add text > > saying "do not do something unless it is useful"? > > Perhaps I should propose we get a co-editor who will pay attention to > postings on issues w/o trying to ignore or deflect them in an attempt to > get CAP 1.0 out the door ASAP. > Hint: A proposal suggests something, it is not a question :-) > Proposal: We remove any and all references to stored queries in CAP 1.0. > Anyone interested in extending CAP such that the original intent of > stored queries is achieved can do so in a later draft. Thanks for a proposal. Did you notice that I was not the only one that objects to it being removed - today? Why do you want VQUERY to be the ONLY component that can not be fetched or stored? > > > Your calculations (omitted) failed to calculate the fetching > > of the same query that you then send back to the CS. > > Oh, so you think that the CUA is always going to retrieve the VQUERY > from the CS and then resend it back to the CS on any of those > commands?!? Why? Because cell and small devices do not have a GUI to configure what they want in the response. > > Remember Cell phones and PDAs do not have a user interface that allows > > the user to customize the queries. It gives the PDA and Cell phone > > companies the ability to modify the result sets. > > Huh? My cell phone has a built in calendar. From there I can pick the > day to see entries on. That's all that the CU needs to do to get data; Yes, but what data is to be included? That is NOT configurable by your cell phone. Stored queries allow a 2nd CUA to store queries that can be used by the non-CUI CUAs. There has not been a requirement that the same CUA store and fetch the same queries. -- 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 --------------ms050609050403010702020302 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDIwMDQwNFowIwYJKoZIhvcNAQkEMRYEFKNiC6qS aT1adnhzgoLqT8k1XK61MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJrWk8F0HtUK8pJ+U8TKekrKADXspUgx3iPLpoaOV5K21rlPNF23 1LZFES7VUTBBou3zM/Ahazoe8ItXVkxZp8HUE94/Tzry9j3CEvuQlzUvExeFeoFSqJutoKAq woW20ca5OBFL3NgASlWJyw/mpw9tgKn3BLSw/i54giVohFvKV254LAK1iWasOJ0EbnzBGL1H 1l6i4/GiNmdtMdsjShYx+5FfhdSL4rB1ZdR3hGTAR5ZJduhQ34VNTzCNULPTkwaIXdjPFdJp EK65CrCVPWadMIhNCEUZgj7quCj9RmasKTt2JyYMA7In21JqL8Cvlj9vLo7dk7WBz9Thf6Fd McAAAAAAAAA= --------------ms050609050403010702020302-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 16:28:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20476 for ; Thu, 4 Sep 2003 16:28:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KAdgc044644 for ; Thu, 4 Sep 2003 13:10:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84KAdhl044643 for ietf-calendar-bks; Thu, 4 Sep 2003 13:10:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KAbgc044638 for ; Thu, 4 Sep 2003 13:10:38 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84KAaS5004708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 13:10:38 -0700 Message-ID: <3F579C36.1040706@Royer.com> Date: Thu, 04 Sep 2003 14:10:30 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050609020100090403040801" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050609020100090403040801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 09/04/2003 12:41:07 PM: > > Thanks for finally agreeing that you could indeed help and that > > your repeated claims that you did not have time or ability to do > > your own diff were just silly. > > In WGs its typically the job of the editor to post a summary of the > changes between versions of a draft; not the job of each individual > reader in the group to go and try and figure it out. No mater how many times you ask for it, no such beast exists as I used a markup pen and wrote on paper until the final edit. I am reluctant to ship the DIFFS as they are being taken out of context. Now that you have generated one, did it take that long? And it is the job of those that wish to post constructive criticism to read the draft, understand the text in context, and then post. -- 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 --------------ms050609020100090403040801 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDIwMTAzMVowIwYJKoZIhvcNAQkEMRYEFPgQNZh4 2Sfnwb0A18nuB6eskTjuMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAFnIB/Hsw8oLJF5XTdeoWdeAkWFFaxf6IdS7xnAwrCZBx7ipWdw8 77WUxW1rbsdg0zxZfRGQeiL2v1wr6ElrEWQqUUmFq2drQttDl2QpdNTbp0JG52Ii/YiTLYhf 5Rph1XwbMjwS9Ee4MfFfmZkMn0JM5gG5iLoYfbNEruXfnCymZgsiRrfVObIdkgLnnFi6hxac /OtksimnPKrX6UgV+gCg45rRQ6UM/DH26gQD1AdtR7K5GjEPUVyqO/hsid5JnJjcAOxr0p4s K6D8/K83lQfNvgl84eeO4tC/PNRMswov9UavcRO+KNOwGhNfPOO0Qzhn+wv5KLFiE0U5+CYy OKkAAAAAAAA= --------------ms050609020100090403040801-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 16:46:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21301 for ; Thu, 4 Sep 2003 16:46:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KTVgc045370 for ; Thu, 4 Sep 2003 13:29:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84KTVYq045369 for ietf-calendar-bks; Thu, 4 Sep 2003 13:29:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KTUgc045364 for ; Thu, 4 Sep 2003 13:29:30 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F577593.9070008@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 16:28:23 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 04:30:39 PM, Serialize complete at 09/04/2003 04:30:39 PM Content-Type: multipart/alternative; boundary="=_alternative 0070740485256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0070740485256D97_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 09/04/2003 01:25:39 PM: > See my other post on the above issue. Hint - compare the text > and not the formatting of the text. NOTHING CHANGED except > the formatting as mandated by the IETF. Somehow I dont think the IETF mandated you remove a space or two from the biolerplate or from some random sentences in the drafts. Im not hand comparing the 140+ page drafts to find content differences just because your tool mangles whitespace! Im using diff and windiff (a GUI diff for those w/Windows) and relying on them to do the right thing just like the WG relys on the editor to provide drafts that do not contain undiscussed changes. > What Bruce posted came to me as a LARGE JPG looking object that was > unreadable. I assumed it was an error. Perhaps it requires a vendor > specific tool that I did not have to view. Actually its the graphical differences that windiff uses in conjuction with displaying content. For those of us w/Windows its a handy way to judge overall changes; the less color you see, the less changes there were. As I said before, diff (not some custom tool) reported 707 differences and windiff shows it graphically (as well as side by side but I didnt include that). > And many of the bugs/fixes where covered in the few bugs filed > (of which had many entries): > > I track many of the issues with the MOZILLA/BUGZILLA tool: Umm, I just checked that bugzilla and it doesnt have lots of comments or issues listed that were raised here nor does it have several of the OOB typos/fixes I sent you over the past year or so. I saw George Barnes postings (2) and a couple questions by Satay (2) and some non-CAP related posts (Bugs 26-28). I do not see any of the comments / issues such as stored queries, scoping of searches, busytime searches, etc. that were raised in the past few months. In addition, discussion of issues is done on the list and typically its the editors job to track raised issues to ensure they get addressed; not the WG's job to use a tool like bugzilla to report and track them. If you want to make use it to track issues, great. But I thinks its unreasonable to expect those that raise issues on the list to also have to put them into your bugzilla in order for them to be addressed. 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 0070740485256D97_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 09/04/2003 01:25:39 PM:
> See my other post on the above issue. Hint - compare the text
> and not the formatting of the text. NOTHING CHANGED except
> the formatting as mandated by the IETF.
Somehow I dont think the IETF mandated you remove a space or two from the biolerplate or from some random sentences in the drafts.

Im not hand comparing the 140+ page drafts to find content differences just because your tool mangles whitespace!  Im using diff and windiff (a GUI diff for those w/Windows) and relying on them to do the right thing just like the WG relys on the editor to provide drafts that do not contain undiscussed changes.

> What Bruce posted came to me as a LARGE JPG looking object that was
> unreadable. I assumed it was an error. Perhaps it requires a vendor
> specific tool that I did not have to view.
Actually its the graphical differences that windiff uses in conjuction with displaying content.  For those of us w/Windows its a handy way to judge overall changes; the less color you see, the less changes there were.  

As I said before, diff (not some custom tool) reported 707 differences and windiff shows it graphically (as well as side by side but I didnt include that).  

> And many of the bugs/fixes where covered in the few bugs filed
> (of which had many entries):
>
> I track many of the issues with the MOZILLA/BUGZILLA tool:
Umm, I just checked that bugzilla and it doesnt have lots of comments or issues listed that were raised here nor does it have several of the OOB typos/fixes I sent you over the past year or so.  I saw George Barnes postings (2) and a couple questions by Satay (2) and some non-CAP related posts (Bugs 26-28).

I do not see any of the comments / issues such as stored queries, scoping of searches, busytime searches, etc. that were raised in the past few months.  

In addition, discussion of issues is done on the list and typically its the editors job to track raised issues to ensure they get addressed; not the WG's job to use a tool like bugzilla to report and track them.  If you want to make use it to track issues, great.  But I thinks its unreasonable to expect those that raise issues on the list to also have to put them into your bugzilla in order for them to be addressed.

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 0070740485256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 16:51:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21539 for ; Thu, 4 Sep 2003 16:51:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KQSgc045226 for ; Thu, 4 Sep 2003 13:26:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84KQSr6045225 for ietf-calendar-bks; Thu, 4 Sep 2003 13:26:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KQPgc045219 for ; Thu, 4 Sep 2003 13:26:25 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19v0gz-00032F-00 for ; Thu, 04 Sep 2003 22:26:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19v0gy-000325-00 for ; Thu, 04 Sep 2003 22:26:56 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19v0gT-0001cz-00 for ; Thu, 04 Sep 2003 22:26:25 +0200 From: "Michael Fair" Subject: Re: I-D ACTION:draft-royer-rid-ical-00.txt] Date: Thu, 4 Sep 2003 13:26:20 -0700 Lines: 168 Message-ID: References: <3F578FE5.2050305@Royer.com> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since the "changing recurrence id" model is not consistent with neither iCal, nor the goals of iTIP in a message lossy environment, since it can get itself into an infinite loop if trying to interoperate with a fixed-id ORGANIZER (unavoidable), and since the only reason this document even exists is because Doug (after some hundreds of messages) still hasn't been able understand a fixed-id model (by his own admission) I see no purpose in making anything interoperable between the two as such interoperability is both unwarranted and untennable. Further, I see no benefit to this since only two people have expressed a desire to implement a changing recurrence-id model and the rest of the WG seems to have aligned on a fixed ID model. Not to forget that all existing major implementations use the fixed ID model. So strange that given the years of his participation Doug still doesn't understand a fixed ID model. We have yet to here Pat's declaration on this and until we hear that she says they should interoperate, pursuing such interoperability will be a waste of time. The draft also talks about the various invite models, and cites there is no proof about problems with his model for delegations/forwarding (despite at least 5 repitions of such proof) and then holds firm to his idea no one needs to have the same version of the same UID becuase of his false understanding that it only needs to be internally unique to the recipient. These two concepts of only internal uniqueness and delegation/forwarding are directly contradictory and only Doug seems to fail to understand this. Further his ignorance of the proof he cites as missing gives me no confidence in his abilities to compose this summary, even if it were needed, which at this time it isn't. Lastly, his document makes no attempt to address how each camp has declared how recoveries from missed or missequenced messages are made which is a critical link to understanding the various strengths and weaknesses of each model. I fear that any attempt to organize such thoughts, especially since I'm being ignored by the author, will unnecesarily exclude me from fully participating in the discussion, and further, given that the author has yet to understand both models fully given the hundreds of messages already posted, gives me no hope that trying to summarize it in a draft written by the same author is going to make one bit of a difference in this argument over how it should be done. Pat has already said that she is going to post a summary of the hundreds of messages, it's a shame that Doug couldn't wait for her to do that. I do believe that a draft going into more detail about dealing with recurring events, or text intended to replace/augment the current sections of iCal/iTIP to better define how to deal with recurring events is certainly warranted. Such text should not try to include both models, including both models just makes it more complicated to implement for no significant benefit to either the existing CUAs (which will now be incompatible no matter what we do) nor future CUAs (which will have added complexity for no good reason). -- Michael -- "Doug Royer" wrote in message news:3F578FE5.2050305@Royer.com... > > This is an attempt to start documenting all of the RECURRENCE-ID issues. > In -00 I did not represent the 'FIXED' camp very well as I do > not fully understand it and so it is missing examples. > > I hope this will evolve into a document that describes ways > that different models will interact and how to make them > interact in useful ways. I also hope this will evolve > into how to migrate to some workable common usage. > > As it states in the first part of the draft, I expect it > to get blasted. But the intent is to gather information > so that it can be documented. > > > -------- Original Message -------- > Subject: I-D ACTION:draft-royer-rid-ical-00.txt > Date: Thu, 04 Sep 2003 10:39:08 -0400 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : RECURRENCE-ID in iCal > Author(s) : D. Royer > Filename : draft-royer-rid-ical-00.txt > Pages : 10 > Date : 2003-9-4 > > The initial version of this draft are going to be controversial. The > idea is to develope ways to make the various ways of using the [iCAL] > and [iTIP] 'RECURRENCE-ID' property work between vendors. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-royer-rid-ical-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-royer-rid-ical-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-royer-rid-ical-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > -- > > 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 Thu Sep 4 16:51:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21556 for ; Thu, 4 Sep 2003 16:51:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KYvgc045595 for ; Thu, 4 Sep 2003 13:34:57 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84KYvmL045594 for ietf-calendar-bks; Thu, 4 Sep 2003 13:34:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KYugc045588 for ; Thu, 4 Sep 2003 13:34:56 -0700 (PDT) (envelope-from bernard.desruisseaux@oracle.com) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail2.oracle.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h84KYrfp005734 for ; Thu, 4 Sep 2003 13:34:53 -0700 (PDT) Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h84KYo407645 for ; Thu, 4 Sep 2003 14:34:51 -0600 (MDT) Received: from oracle.com (c-1782.ca.oracle.com [144.23.213.225]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h84KYn407600 for ; Thu, 4 Sep 2003 14:34:49 -0600 (MDT) Message-ID: <3F57A12E.1000308@oracle.com> Date: Thu, 04 Sep 2003 16:31:42 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: <3F577974.8060706@Royer.com> In-Reply-To: <3F577974.8060706@Royer.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 Doug Royer wrote: > > > Bruce_Kahn@notesdev.ibm.com wrote: > >> >> Doug wrote on 09/04/2003 11:22:35 AM: >> > There was nothing new to reply to. Same >> > question, same answer. >> >> Actually its more like same question, same non-answer. >> Everyone from 2 of the other editors to Andrea question the usefulness >> of this feature in CAP 1.0 given our inability to achieve the original >> intent. You seem to be the only one steadfastly opposed to removing >> it from CAP. > > > Bruce - 4 people replied today - two said yes (me and it looks as if > Bernard by replying is saying yes, you said no, and Andrea > said no). Bernard proposed the NAME/QUERYID change - do you want > us to think that that means 'NO' to stored queries? My reply was simply clarifying that if CAP were to support stored VQUERY components, one should use the QUERYID property, and not the NAME property, when making reference to stored VQUERY components. As for where I stand with the stored VQUERY issue, like Bruce and Andrea, I don't see a real benefit from using stored VQUERY as they are currently specified, and as such I would remove all references to them in CAP 1.0. Cheers, Bernard > > And you just posted TODAY - so don't you feel just a little > bit embarrassed that you declare 'Everyone from 2 of the other > editors...' question ... it? > > And you have failed to find *anything* that supports your > assertion of the 'original intent'. > From owner-ietf-calendar@mail.imc.org Thu Sep 4 16:55:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21726 for ; Thu, 4 Sep 2003 16:55:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KeYgc045847 for ; Thu, 4 Sep 2003 13:40:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84KeYCN045846 for ietf-calendar-bks; Thu, 4 Sep 2003 13:40:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KeTgc045829 for ; Thu, 4 Sep 2003 13:40:29 -0700 (PDT) (envelope-from pregen@egenconsulting.com) Subject: Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt] To: Doug Royer Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Thu, 4 Sep 2003 16:40:30 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 04:40:31 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBE704DFFF71678f9e8a93df938690918c0ABBE704DFFF7167" Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=0ABBE704DFFF71678f9e8a93df938690918c0ABBE704DFFF7167 Content-type: text/plain; charset=US-ASCII Doug, from what I read on Frank and Derik's replies and on other peoples comments on the list, I see a pattern evolving. People are coding their applications using more of a fixed model. Why do we have to have a complicated draft when all we need to do is remove the one sentence in 3.7.1, change examples to reflect that change and resubmit the draft. So, my question to everyone on the list that has been active on the Recurrence-ID issue - does this sound like too simplistic an approach? Am I missing something. The arguments seem to lean towards Bruce's comments and attempt at a model. His borad summary ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer To: "ietf-calendar@imc.org" , Sent by: "ietf-calendar@imc.org" owner-ietf-calendar@m cc: ail.imc.org Subject: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt] 09/04/2003 03:17 PM This is an attempt to start documenting all of the RECURRENCE-ID issues. In -00 I did not represent the 'FIXED' camp very well as I do not fully understand it and so it is missing examples. I hope this will evolve into a document that describes ways that different models will interact and how to make them interact in useful ways. I also hope this will evolve into how to migrate to some workable common usage. As it states in the first part of the draft, I expect it to get blasted. But the intent is to gather information so that it can be documented. -------- Original Message -------- Subject: I-D ACTION:draft-royer-rid-ical-00.txt Date: Thu, 04 Sep 2003 10:39:08 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RECURRENCE-ID in iCal Author(s) : D. Royer Filename : draft-royer-rid-ical-00.txt Pages : 10 Date : 2003-9-4 The initial version of this draft are going to be controversial. The idea is to develope ways to make the various ways of using the [iCAL] and [iTIP] 'RECURRENCE-ID' property work between vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-rid-ical-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-rid-ical-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-rid-ical-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- 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 (See attached file: draft-royer-rid-ical-00.txt) (See attached file: smime.p7s) --0__=0ABBE704DFFF71678f9e8a93df938690918c0ABBE704DFFF7167 Content-type: application/octet-stream; name="draft-royer-rid-ical-00.txt" Content-Disposition: attachment; filename="draft-royer-rid-ical-00.txt" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOgk8MjAwMy05LTQwOTU1MDYuSS1E QGlldGYub3JnPg0KDQoNCg== --0__=0ABBE704DFFF71678f9e8a93df938690918c0ABBE704DFFF7167 Content-type: application/octet-stream; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCCA2Iw ggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVow gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkg UmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1 YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2ok kuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAE QDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5j cmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5v RUs4oLje6VNkIbzkTCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jY UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrT ssSr51a+i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkg UmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1 YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMw OTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2Vydmlj ZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQp Z2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV 5umSqlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcU KdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZ AgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGO MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYw FRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVu Y2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNan VdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kz UOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZI hvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1 bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3ll ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2r KbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/ Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSg LmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46Pbzk gCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApu lYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsG AQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBi eSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4Aw MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5 gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZN FuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSmAgEBMIHhMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDE5MTc1N1owIwYJ KoZIhvcNAQkEMRYEFD1I756gWu3pC7KCFajDG6vEC83YMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJp U2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBAQUABIIB AGyCNn727DdZosX8TbjlgFNJ7iIwaaQa1vpFoPYeeHpPz4XSlEYYNdnjln+23/qlXELMwCs8gSYw QFxWAQ1DNdUkanVlCz0N1LXyazN3kjAJFoDeXtQgw2xCuGiazAGOed5xltaGF5mjj3a77qpFWMiD Kip7MMG7Tw/BmayOZGrEGQfQ7tjpLp8cJpQRj9GbPLnAFg9DOqMLCHHWkirlgqcY021gEq838DcP cidD3KIZnLIFZbDGnkmv+0DECLnoKXrK/zWFTmY1Z16gNicNlMqk8xKGDS1XoykBJ3ycts/jYoCa Ry+reGC7dM5td4rZc/5J61vGPtCcjNMbj31gz9AAAAAAAAA= --0__=0ABBE704DFFF71678f9e8a93df938690918c0ABBE704DFFF7167-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 17:11:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22720 for ; Thu, 4 Sep 2003 17:11:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KmMgc046165 for ; Thu, 4 Sep 2003 13:48:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84KmM7J046164 for ietf-calendar-bks; Thu, 4 Sep 2003 13:48:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KmLgc046159 for ; Thu, 4 Sep 2003 13:48:21 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84KmKS5005289 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 13:48:22 -0700 Message-ID: <3F57A50F.70002@Royer.com> Date: Thu, 04 Sep 2003 14:48:15 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080602000703060208040306" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080602000703060208040306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > > > > Doug, from what I read on Frank and Derik's replies and on other peoples > comments on the list, I see a pattern evolving. People are coding their > applications using more of a fixed model. Why do we have to have a > complicated draft when all we need to do is remove the one sentence in > 3.7.1, change examples to reflect that change and resubmit the draft. > > So, my question to everyone on the list that has been active on the > Recurrence-ID issue - does this sound like too simplistic an approach? Am > I missing something. The arguments seem to lean towards Bruce's comments > and attempt at a model. His borad summary When you read what I put in the draft, not all of the 'fixed' camp agree on all of the details. And they are NOT compatible with each other. I have a list that I am not confident to send out yet as I re-read the examples sent. It looks as if there are 4 distinct models and not 2. This list will be included in the next rev of that draft. Its not as simple as 'fixed' vs. 'non-fixed' which is one of the points of the draft. -- 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 --------------ms080602000703060208040306 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDIwNDgxNVowIwYJKoZIhvcNAQkEMRYEFBlcKdM5 +5tsdxK6dehz764aF7doMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADRoRWPhURkJMskEIOG8ppBDrTyL40b8RHEuwJqBKAZETeYpjZR0 pAti9+QGWkiYtrhVISaeT8CM+PfzW45AsbjSBmk7V50Dqo4rIDUzBMtwLkomqjYtRAtE/Kv2 v7psu0t8f0emQnQUhDatzauDxQ2E8Uixa+2MsTeYzN93wajIAu6Jac7PGO+29oE/wfbQnVAj lsR5DDHwkC1kpGU5qnJ8lw0uvJ1Goa+cw8WZMuOlLhV9H0ZzX9EmdYKltpaBL/Rm1gZy/Fqk 8YfZtCQWTM+D+DjiYtsnnvvR6C803x3s/CkShv6HkiYLilpDhJG/ZAwap316Cl8hi/4YGI9j 0IgAAAAAAAA= --------------ms080602000703060208040306-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 17:19:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23266 for ; Thu, 4 Sep 2003 17:19:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84L32gc047584 for ; Thu, 4 Sep 2003 14:03:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84L31kK047582 for ietf-calendar-bks; Thu, 4 Sep 2003 14:03:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84L30gc047568 for ; Thu, 4 Sep 2003 14:03:00 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: To: michael@daclubhouse.net Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: I-D ACTION:draft-royer-rid-ical-00.txt] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 4 Sep 2003 17:00:47 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 05:04:08 PM, Serialize complete at 09/04/2003 05:04:08 PM Content-Type: multipart/alternative; boundary="=_alternative 0072E04485256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072E04485256D97_= Content-Type: text/plain; charset="US-ASCII" Just for the record I agree with Michael Fairs assessment. "Michael Fair" Sent by: owner-ietf-calendar@mail.imc.org 09/04/2003 04:26 PM To ietf-calendar@imc.org cc Subject Re: I-D ACTION:draft-royer-rid-ical-00.txt] Since the "changing recurrence id" model is not consistent with neither iCal, nor the goals of iTIP in a message lossy environment, since it can get itself into an infinite loop if trying to interoperate with a fixed-id ORGANIZER (unavoidable), and since the only reason this document even exists is because Doug (after some hundreds of messages) still hasn't been able understand a fixed-id model (by his own admission) I see no purpose in making anything interoperable between the two as such interoperability is both unwarranted and untennable. Further, I see no benefit to this since only two people have expressed a desire to implement a changing recurrence-id model and the rest of the WG seems to have aligned on a fixed ID model. Not to forget that all existing major implementations use the fixed ID model. So strange that given the years of his participation Doug still doesn't understand a fixed ID model. We have yet to here Pat's declaration on this and until we hear that she says they should interoperate, pursuing such interoperability will be a waste of time. The draft also talks about the various invite models, and cites there is no proof about problems with his model for delegations/forwarding (despite at least 5 repitions of such proof) and then holds firm to his idea no one needs to have the same version of the same UID becuase of his false understanding that it only needs to be internally unique to the recipient. These two concepts of only internal uniqueness and delegation/forwarding are directly contradictory and only Doug seems to fail to understand this. Further his ignorance of the proof he cites as missing gives me no confidence in his abilities to compose this summary, even if it were needed, which at this time it isn't. Lastly, his document makes no attempt to address how each camp has declared how recoveries from missed or missequenced messages are made which is a critical link to understanding the various strengths and weaknesses of each model. I fear that any attempt to organize such thoughts, especially since I'm being ignored by the author, will unnecesarily exclude me from fully participating in the discussion, and further, given that the author has yet to understand both models fully given the hundreds of messages already posted, gives me no hope that trying to summarize it in a draft written by the same author is going to make one bit of a difference in this argument over how it should be done. Pat has already said that she is going to post a summary of the hundreds of messages, it's a shame that Doug couldn't wait for her to do that. I do believe that a draft going into more detail about dealing with recurring events, or text intended to replace/augment the current sections of iCal/iTIP to better define how to deal with recurring events is certainly warranted. Such text should not try to include both models, including both models just makes it more complicated to implement for no significant benefit to either the existing CUAs (which will now be incompatible no matter what we do) nor future CUAs (which will have added complexity for no good reason). -- Michael -- "Doug Royer" wrote in message news:3F578FE5.2050305@Royer.com... > > This is an attempt to start documenting all of the RECURRENCE-ID issues. > In -00 I did not represent the 'FIXED' camp very well as I do > not fully understand it and so it is missing examples. > > I hope this will evolve into a document that describes ways > that different models will interact and how to make them > interact in useful ways. I also hope this will evolve > into how to migrate to some workable common usage. > > As it states in the first part of the draft, I expect it > to get blasted. But the intent is to gather information > so that it can be documented. > > > -------- Original Message -------- > Subject: I-D ACTION:draft-royer-rid-ical-00.txt > Date: Thu, 04 Sep 2003 10:39:08 -0400 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : RECURRENCE-ID in iCal > Author(s) : D. Royer > Filename : draft-royer-rid-ical-00.txt > Pages : 10 > Date : 2003-9-4 > > The initial version of this draft are going to be controversial. The > idea is to develope ways to make the various ways of using the [iCAL] > and [iTIP] 'RECURRENCE-ID' property work between vendors. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-royer-rid-ical-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-royer-rid-ical-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-royer-rid-ical-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > -- > > 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 > --=_alternative 0072E04485256D97_= Content-Type: text/html; charset="US-ASCII"
Just for the record I agree with Michael Fairs assessment.



"Michael Fair" <michael@daclubhouse.net>
Sent by: owner-ietf-calendar@mail.imc.org

09/04/2003 04:26 PM

To
ietf-calendar@imc.org
cc
Subject
Re: I-D ACTION:draft-royer-rid-ical-00.txt]







Since the "changing recurrence id" model is not
consistent with neither iCal, nor the goals of
iTIP in a message lossy environment, since it can
get itself into an infinite loop if trying to
interoperate with a fixed-id ORGANIZER (unavoidable),
and since the only reason this document even exists
is because Doug (after some hundreds of messages)
still hasn't been able understand a fixed-id model
(by his own admission) I see no purpose in making
anything interoperable between the two as such
interoperability is both unwarranted and untennable.

Further, I see no benefit to this since only two
people have expressed a desire to implement a
changing recurrence-id model and the rest of the WG
seems to have aligned on a fixed ID model.  Not to
forget that all existing major implementations use
the fixed ID model.  So strange that given the years
of his participation Doug still doesn't understand a
fixed ID model.

We have yet to here Pat's declaration on this and
until we hear that she says they should interoperate,
pursuing such interoperability will be a waste of time.

The draft also talks about the various invite models,
and cites there is no proof about problems with his model
for delegations/forwarding (despite at least 5 repitions
of such proof) and then holds firm to his idea no one
needs to have the same version of the same UID becuase
of his false understanding that it only needs to be
internally unique to the recipient.  These two
concepts of only internal uniqueness and
delegation/forwarding are directly contradictory and
only Doug seems to fail to understand this.
Further his ignorance of the proof he cites as
missing gives me no confidence in his abilities
to compose this summary, even if it were needed,
which at this time it isn't.


Lastly, his document makes no attempt to address how
each camp has declared how recoveries from missed
or missequenced messages are made which is a critical
link to understanding the various strengths and
weaknesses of each model.


I fear that any attempt to organize such thoughts,
especially since I'm being ignored by the author,
will unnecesarily exclude me from fully participating
in the discussion, and further, given that the author
has yet to understand both models fully given the
hundreds of messages already posted, gives me no hope
that trying to summarize it in a draft written by the
same author is going to make one bit of a difference
in this argument over how it should be done.

Pat has already said that she is going to post a
summary of the hundreds of messages, it's a shame
that Doug couldn't wait for her to do that.


I do believe that a draft going into more detail about
dealing with recurring events, or text intended to
replace/augment the current sections of iCal/iTIP to
better define how to deal with recurring events is
certainly warranted.  Such text should not try to
include both models, including both models just makes
it more complicated to implement for no significant
benefit to either the existing CUAs (which will now
be incompatible no matter what we do) nor future CUAs
(which will have added complexity for no good reason).

-- Michael --

"Doug Royer" <Doug@royer.com> wrote in message
news:3F578FE5.2050305@Royer.com...
>
> This is an attempt to start documenting all of the RECURRENCE-ID issues.
> In -00 I did not represent the 'FIXED' camp very well as I do
> not fully understand it and so it is missing examples.
>
> I hope this will evolve into a document that describes ways
> that different models will interact and how to make them
> interact in useful ways. I also hope this will evolve
> into how to migrate to some workable common usage.
>
> As it states in the first part of the draft, I expect it
> to get blasted. But the intent is to gather information
> so that it can be documented.
>
>
> -------- Original Message --------
> Subject: I-D ACTION:draft-royer-rid-ical-00.txt
> Date: Thu, 04 Sep 2003 10:39:08 -0400
> From: Internet-Drafts@ietf.org
> Reply-To: Internet-Drafts@ietf.org
> To: IETF-Announce: ;
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : RECURRENCE-ID in iCal
> Author(s) : D. Royer
> Filename : draft-royer-rid-ical-00.txt
> Pages : 10
> Date : 2003-9-4
>
> The initial version of this draft are going to be controversial.  The
> idea is to develope ways to make the various ways of using the [iCAL]
> and [iTIP] 'RECURRENCE-ID' property work between vendors.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-royer-rid-ical-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-royer-rid-ical-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-royer-rid-ical-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> --
>
>   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
>
--=_alternative 0072E04485256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 17:26:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23735 for ; Thu, 4 Sep 2003 17:26:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84L8Ngc047984 for ; Thu, 4 Sep 2003 14:08:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84L8NBE047983 for ietf-calendar-bks; Thu, 4 Sep 2003 14:08:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84L8Lgc047977 for ; Thu, 4 Sep 2003 14:08:21 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84L8LS5005547 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 14:08:22 -0700 Message-ID: <3F57A9C0.8060606@Royer.com> Date: Thu, 04 Sep 2003 15:08:16 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070205080803010609070203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070205080803010609070203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 09/04/2003 01:25:39 PM: > > See my other post on the above issue. Hint - compare the text > > and not the formatting of the text. NOTHING CHANGED except > > the formatting as mandated by the IETF. > > Somehow I dont think the IETF mandated you remove a space or two from > the biolerplate or from some random sentences in the drafts. Did you bother to see if what you just sent is true? There was a debate on another WG list about the usage of two spaces after a period. The IETF editors wanted exactly one space and not two. > > > > I track many of the issues with the MOZILLA/BUGZILLA tool: > > Umm, I just checked that bugzilla and it doesnt have lots of comments or > issues listed that were raised here nor does it have several of the OOB > typos/fixes I sent you over the past year or so. I saw George Barnes > postings (2) and a couple questions by Satay (2) and some non-CAP > related posts (Bugs 26-28). It is where I asked this WG list to file 'typos'. And I have closed 2 bugs where people filed technical issues telling them it is the wrong forum. Those few bugs had over 100 typos, grammar, ... type bugs. > I do not see any of the comments / issues such as stored queries, > scoping of searches, busytime searches, etc. that were raised in the > past few months. That is because they are where they belong - on the mailing list. > In addition, discussion of issues is done on the list and typically its > the editors job to track raised issues to ensure they get addressed; not > the WG's job to use a tool like bugzilla to report and track them. > If you want to make use it to track issues, great. But I thinks its > unreasonable to expect those that raise issues on the list to also have > to put them into your bugzilla in order for them to be addressed. Bruce - you have complained about every list I have ever submitted. Text - you wanted words changed to fit what you wanted, html - you did not like the colors and column names chosen and now bugzilla. Oh well.. -- 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 --------------ms070205080803010609070203 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDIxMDgxNlowIwYJKoZIhvcNAQkEMRYEFKg2FR+h tD+R4D2u14yCpxKm8goxMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIEPlfEJZ0JEsdUdbRe0PfkuRacD0ayHYyWzezQdEKJoazrpCPN9 shhVbhia0MZdmRsZMlUgu8aYXKxXhXRCEHgYkBBb7xYoeJ+yvy2WguYkIInbCcBUZenCatgD 7M3mmsxWuuC8uipaZfBRHsKLoA8Xm78jroKuuEDPrEI3IByBD081JbHjndK97XxEirCaZTiO fBVYtOyu9cHO30l7fWWAvKv4di0y/oZ3gsNkK4koCkA+tHxkO2VdJ9ovPIyBJ/OKyGS+klG4 dX/TNhl7zHYRTMl7QuNNYWq2Yt37zJ9qalI7G9b5umKXNfBFOrGlgBAtgXiGi7sXmYpnKU5U +XcAAAAAAAA= --------------ms070205080803010609070203-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 17:39:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24258 for ; Thu, 4 Sep 2003 17:39:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84LK9gc049967 for ; Thu, 4 Sep 2003 14:20:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84LK9xu049966 for ietf-calendar-bks; Thu, 4 Sep 2003 14:20:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84LK8gc049961 for ; Thu, 4 Sep 2003 14:20:08 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84LK8S5005768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 14:20:09 -0700 Message-ID: <3F57AC82.6050907@Royer.com> Date: Thu, 04 Sep 2003 15:20:02 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080706050302070108020907" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080706050302070108020907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > I do not see any of the comments / issues such as stored queries, > scoping of searches, busytime searches, etc. that were raised in the > past few months. There was busytime searches fix it was bug #30. And I close the bugs as I fix them, I just closed the last of the CAP bugs. You can open closed bugs. And I agree not that many were filed. I just started using the tool a month or so ago just after (or before) -11 was released. Nothing before that is included. -- 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 --------------ms080706050302070108020907 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDIxMjAwMlowIwYJKoZIhvcNAQkEMRYEFCMzm/F0 oVpZ64rbkbj1+mCu+YzSMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIjFhgVbdytOErBPkZGp63Rlp3VbnjwZq0WAfT0MApNyX2kqWPaj BNKOoDHbC6zodcied8V55Z3ua2+yqrF4T0YcH+pzf5gc7E459GXIjo8RWVup6DAFbkzJKb9I l3vs0X/An0+uJC/HbY0W2B6b6jVRvkZUe7JIbA/OrkqeEFNBJrbrL58Ztov3cgDFeCOGOS+i 639hFAQr1HKC1L8iocTkGO5QxWJkxJhxvWdxruKdNVS2H1tr9yttTyolwHm9k6pMCKl4H1wX vEz2SGues3XBWa5tIGiqnickXSWfRPxsn3D0UqRMYlYFDQTGzMZlJf/THaXQUDR4cfUL0TVm FSoAAAAAAAA= --------------ms080706050302070108020907-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 17:42:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24459 for ; Thu, 4 Sep 2003 17:42:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84LT6gc050411 for ; Thu, 4 Sep 2003 14:29:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84LT6v5050410 for ietf-calendar-bks; Thu, 4 Sep 2003 14:29:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84LT3gc050397 for ; Thu, 4 Sep 2003 14:29:06 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F577974.8060706@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 17:28:56 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 05:30:11 PM, Serialize complete at 09/04/2003 05:30:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0075FF2285256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075FF2285256D97_= Content-Type: text/plain; charset="US-ASCII" Doug wished on 09/04/2003 01:42:12 PM: > Bruce - 4 people replied today - two said yes (me and it looks as if > Bernard by replying is saying yes, you said no, and Andrea > said no). Umm, you better actually read what Bernard wrote. He said: In February 2002, Steltor (formerly CS&T, and now Oracle) proposed to rename the property QUERYNAME to QUERYID and to add a new property NAME to specify a localizable display name. VQUERY components should be referred to with their unique QUERYID not their NAME which may not be unique. Thats not an endorsement of stored queries. He's merely giving history to their contribution that you referenced. > Bernard proposed the NAME/QUERYID change - do you want > us to think that that means 'NO' to stored queries? You are incorrectly trying to link what Bernard clarified to a my issue of stored queries. You should be thinking of the other issue I raised: the incorrect inclusion of NAME in the searching for a stored query. The latter is related to the former but goes away if the former is removed as Ive proposed. > And you just posted TODAY - so don't you feel just a little > bit embarrassed that you declare 'Everyone from 2 of the other > editors...' question ... it? If you are trying to bait me into something it wont work. The issue was raised at the San Diego IETF (I think) and nobody there could find a compelling reason to keep them given the limitation of our query language (which I believe you proposed be simplified under the Subject "I MOVE we simplify the query language." back in early 2002). The plain fact of the matter is that stored queries failed to meet our original intent because the query language cannot support what we thought we could design. Because of this and because of several unspecified/unanswer related issues I agree w/Andrea that it should be removed from CAP and left for a later draft to properly design and specify. > And you have failed to find *anything* that supports your > assertion of the 'original intent'. Are you now saying that the original intent of stored queries was NOT for thin clients? Gee, you previously confirmed what I said when you wrote: > The original intent was to provide a means for clients to save on space > and cycles by not having to recraft commonly used queries and resend > them. And it does save both bandwidth and octets especially when you consider the 2 sets of QUERY/FETCH required without them. but I guess you will say I misquoted you. The motivation has it roots as far back as 1998 when Surendra Reddy mentioned it in the context of Simple Internet Calendar Access Protocol. Its also been discussed in the context of the original intent often in other discussions over the past couple of years. In fact, a scan of my archive reveals that this kind of issue was at least partly recognized by John Stracke back in March 2003 when he replied to you with: Besides, as things stand, a stored query would be useless for "today's alarms", or "today's events", because the query language has no term for "today". Your attempts to question the original intent aside (hey, theres that pesky word 'original' again. I wonder...) I am still proposing that we simplify CAP by removing stored queries and that they be deferred to a later draft where all issues can be properly delt with. We simplified the query lingua to speed up CAP but as a side effect we gutted the stored queries ability to fulfill our original intent. We should further simplify CAP and remove all references to stored queries for CAP 1.0. 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 0075FF2285256D97_= Content-Type: text/html; charset="US-ASCII"
Doug wished on 09/04/2003 01:42:12 PM:
> Bruce - 4 people replied today - two said yes (me and it looks as if
> Bernard by replying is saying yes, you said no, and Andrea
> said no).

Umm, you better actually read what Bernard wrote.  He said:

In February 2002, Steltor (formerly CS&T, and now Oracle) proposed
to rename the property QUERYNAME to QUERYID and to add a new property
NAME to specify a localizable display name.

VQUERY components should be referred to with their unique QUERYID not
their NAME which may not be unique.

Thats not an endorsement of stored queries.  He's merely giving history to their contribution that you referenced.

>           Bernard proposed the NAME/QUERYID change - do you want
> us to think that that means 'NO' to stored queries?
You are incorrectly trying to link what Bernard clarified to a my issue of stored queries.  You should be thinking of the other issue I raised: the incorrect inclusion of NAME in the searching for a stored query.  The latter is related to the former but goes away if the former is removed as Ive proposed.

> And you just posted TODAY - so don't you feel just a little
> bit embarrassed that you declare 'Everyone from 2 of the other
> editors...' question ... it?
If you are trying to bait me into something it wont work.  The issue was raised at the San Diego IETF (I think) and nobody there could find a compelling reason to keep them given the limitation of our query language (which I believe you proposed be simplified under the Subject "I MOVE we simplify the query language." back in early 2002).  

The plain fact of the matter is that stored queries failed to meet our original intent because the query language cannot support what we thought we could design.  Because of this and because of several unspecified/unanswer related issues I agree w/Andrea that it should be removed from CAP and left for a later draft to properly design and specify.

> And you have failed to find *anything* that supports your
> assertion of the 'original intent'.
Are you now saying that the original intent of stored queries was NOT for thin clients?  Gee, you previously confirmed what I said when you wrote:

> The original intent was to provide a means for clients to save on space
> and cycles by not having to recraft commonly used queries and resend
> them.

And it does save both bandwidth and octets especially when you consider
the 2 sets of QUERY/FETCH required without them.

but I guess you will say I misquoted you.

The motivation has it roots as far back as 1998 when Surendra Reddy mentioned it in the context of Simple Internet Calendar Access Protocol.  Its also been discussed in the context of the original intent often in other discussions over the past couple of years.  

In fact, a scan of my archive reveals that this kind of issue was at least partly recognized by John Stracke back in March 2003 when he replied to you with:

Besides, as things stand, a stored query would be useless for "today's
alarms", or "today's events", because the query language has no term for
"today".

Your attempts to question the original intent aside (hey, theres that pesky word 'original' again.  I wonder...) I am still proposing that we simplify CAP by removing stored queries and that they be deferred to a later draft where all issues can be properly delt with.

We simplified the query lingua to speed up CAP but as a side effect we gutted the stored queries ability to fulfill our original intent.  We should further simplify CAP and remove all references to stored queries for CAP 1.0.

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 0075FF2285256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 17:58:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25311 for ; Thu, 4 Sep 2003 17:58:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Le4gc052383 for ; Thu, 4 Sep 2003 14:40:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Le4q3052382 for ietf-calendar-bks; Thu, 4 Sep 2003 14:40:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Le3gc052373 for ; Thu, 4 Sep 2003 14:40:03 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84Le2S5005980 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 14:40:03 -0700 Message-ID: <3F57B12C.7040709@Royer.com> Date: Thu, 04 Sep 2003 15:39:56 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: I-D ACTION:draft-royer-rid-ical-00.txt] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050004000403010406020108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050004000403010406020108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Just for the record I agree with Michael Fairs assessment. Have you looked closly at the examples and comments by those in the 'fixed' camp? They are not all compatible with each other. Plus the draft throws in the how to invite to a single instance issue - which seems related but ether model can do or not do that independent of fixed or not-fixed. And there is also the CANCEL issue with respect to instances - not everyone agrees yet. And again this seems to be independent of fixed vs non-fixed. And not everyone agrees that SEQUENCE:0 plus X updates is the same object as a full replacement sent as SEQUENCE:X (or would that be X+1). And again this seems to be independent of fixed vs non-fixed. Not everyone agrees that you can send unique objects to unique ATTENDEES. And again this seems to be independent of fixed vs non-fixed. This issue was ignored at iCAL and iTIP time because it was controversial, it still is. As are other issues that relate to RECURRENCE-ID. If nothing else when the draft is done, it will allow the next reader to not have to guess. -- 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 --------------ms050004000403010406020108 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDIxMzk1NlowIwYJKoZIhvcNAQkEMRYEFOUNpmn5 1kP5KEXdQf6nAa4cktqqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAA/cQ2PZJrfmNituQlYbNV/C60jXWFOZEuFYew7m2nqXw5pIjQ30 mexiC3sqNol+gziMt6eSr0Lg6ul72gq5sXiu4ZF+67JXWQ1TnpAhAKmNnGvYEndxaopZtu9S rs6Baqg2pPgoPcFqSg1wx6/xqgczC3qQwZpEQl2feYLM+FbjLKlBIn7G6BkkD7dowjwwKyuM qNq701h3uY9aDirkwZII1ZWgs8RYH6l3bkskxO5lvpLQc11sJOIgSAUUIUAzFs/UOKBy5OqL m+ivMbmnjdjYbrnCVTk3zlKTDS7MihcvmqCUHd+0tBdXq9A/dLT3tH77qILX6HuOVsZg6fsv OdwAAAAAAAA= --------------ms050004000403010406020108-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 18:00:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25408 for ; Thu, 4 Sep 2003 18:00:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84LbJgc051893 for ; Thu, 4 Sep 2003 14:37:19 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84LbJKn051892 for ietf-calendar-bks; Thu, 4 Sep 2003 14:37:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84LbIgc051884 for ; Thu, 4 Sep 2003 14:37:19 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F577851.3080608@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 17:32:08 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 05:38:24 PM, Serialize complete at 09/04/2003 05:38:24 PM Content-Type: multipart/alternative; boundary="=_alternative 00764A3185256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00764A3185256D97_= Content-Type: text/plain; charset="US-ASCII" Doug non-replied on 09/04/2003 01:37:21 PM: > > What permutations of search do I use? > > I do not find it odd that you can only seem to find opinions that > aggree with yours. Im asking you for your search criteria so I can use them to find the posts you were referring to. If you wont provide citations (Dates, Subjects, Posters, actual snippets), the least you can do is provide the search phrases you used. Unless you can't... 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 00764A3185256D97_= Content-Type: text/html; charset="US-ASCII"
Doug non-replied on 09/04/2003 01:37:21 PM:
> > What permutations of search do I use?
>
> I do not find it odd that you can only seem to find opinions that
> aggree with yours.
Im asking you for your search criteria so I can use them to find the posts you were referring to.  If you wont provide citations (Dates, Subjects, Posters, actual snippets), the least you can do is provide the search phrases you used.  Unless you can't...

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 00764A3185256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 18:01:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25503 for ; Thu, 4 Sep 2003 18:01:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Ll0gc053246 for ; Thu, 4 Sep 2003 14:47:00 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Ll0iq053245 for ietf-calendar-bks; Thu, 4 Sep 2003 14:47:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Lkwgc053235 for ; Thu, 4 Sep 2003 14:46:59 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84LkwS5006113 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 14:47:00 -0700 Message-ID: <3F57B2CD.9080009@Royer.com> Date: Thu, 04 Sep 2003 15:46:53 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: [Bug 31] Various typos and slightly more than typos] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020709000805060905000505" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020709000805060905000505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit http://INET-Consulting.com/bugzilla/show_bug.cgi?id=31 gsbarnes@washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From gsbarnes@washington.edu 2003-09-04 14:38 ------- Most of these were fixed in 12a, except 2.1.1 still lists the SEQUENCE property as a parameter 6.1.1.12 still refers to a WHEN clause 7.7 still has a problem with the paragraph 'A CUA adds the "OPTIONS" parameter to the "LOCALIZE" parameter to the "CMD" property when the command needs extra values.' The reference to LOCALIZE does not belong. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. -- 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 --------------ms020709000805060905000505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDIxNDY1M1owIwYJKoZIhvcNAQkEMRYEFONNLlwh 5rZehlw3tQ6Cq9u0/X8bMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGtxzDD9Z+KclSOrTKKFXYRWwgKvUwC6nGjH+WyRatSvgUjTfWI8 pyb3sa2cuSOrd88HAis9xoU4MxKdFoNiOcoHthGTEby6QJfrc2lxoFfA6AEMfi0BugYQ8/vy xaD8HMeMhVnfOj3M58jYbdmE4mYtGDgG2bs+Zn8YZ7ff02dfCoO8JPuC5AzdfkyTbuuyIPR+ qzgEidSc+wkBuDpbUX8j6m25rRNSUiIsy4rbhiDpSS/pTQYTizPqx5RYSNKgSGP/Z3H4cKAc bD6FjpDlypnif6RCog5SnwJ3XyGQjrEeqAElYnCldzw+AIuhIyp6YKiWUO0whEpOTr7u0RBT 8MQAAAAAAAA= --------------ms020709000805060905000505-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 18:15:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27210 for ; Thu, 4 Sep 2003 18:15:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Lx0gc054296 for ; Thu, 4 Sep 2003 14:59:00 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84Lx0Jf054295 for ietf-calendar-bks; Thu, 4 Sep 2003 14:59:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Lwwgc054289 for ; Thu, 4 Sep 2003 14:58:58 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h84LwuS5006243 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 14:58:59 -0700 Message-ID: <3F57B59A.5040908@Royer.com> Date: Thu, 04 Sep 2003 15:58:50 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010105070408030200070109" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010105070408030200070109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Are you now saying that the original intent of stored queries was NOT > for thin clients? Gee, you previously confirmed what I said when you > wrote: So rather than define what you are talking about, you show some history that has nothing to do with the question. And what was the original intent? >> The original intent was to provide a means for clients to save on space >> and cycles by not having to recraft commonly used queries and resend >> them. >> >> And it does save both bandwidth and octets especially when you consider >> the 2 sets of QUERY/FETCH required without them. And it does. And despite your assertion to the contrary, you still forgot to add in the (1) set of octets to get the XXX query definition. -- 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 --------------ms010105070408030200070109 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNDIxNTg1MFowIwYJKoZIhvcNAQkEMRYEFNZd5MR2 aIC9UM+ANFpbS1WizUBqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBALD+YLIvBzJrXH04f778xJWpppKLBrMmE4NGwUrBXmSeBovq/+z5 Pe7ZLIWx4itrXlInTCAC7K/B4oijUbl57AT7wGujHk5i1js8Mw6vEf3IUxA6+cVNhfuAHQ2j UnQqeYRlTyxN7IXbGdV/zReUC7eP55grSnbDZ4V0jFdOZISocgQGwBzdOGcbHvqVxiVGe3tW aqqWhF/mtS37Umr3h7bwjH9/IQhDwJ3FXwQ10NjLupYVAzUKlwA70onagIfwW6HeLXB8SFZu 9Y0NevikXamE0YHTQcGhnczyRv+rAeiGaMF90Zt3J6BDX91JT7uceW57OQfDgXSlggX+LV29 PlAAAAAAAAA= --------------ms010105070408030200070109-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 18:19:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27463 for ; Thu, 4 Sep 2003 18:19:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84M4Kgc054445 for ; Thu, 4 Sep 2003 15:04:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84M4KIb054443 for ietf-calendar-bks; Thu, 4 Sep 2003 15:04:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84M4Igc054438 for ; Thu, 4 Sep 2003 15:04:19 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F577BA7.2030100@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 17:58:03 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 06:05:23 PM, Serialize complete at 09/04/2003 06:05:23 PM Content-Type: multipart/alternative; boundary="=_alternative 0078A9B385256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0078A9B385256D97_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 09/04/2003 01:51:35 PM: > (1) Bruce - please read all of CAP - not just the diffs. Doug - please post a summary of the changes between versions instead of saying "do the diffs yourself" (paraphrased). I did and now you say, go read the drafts!? Sorry but Im NOT going to reread ~140 pages every time a new draft is reissued since by now there should not be lots of changes going in. Its a typical editors task to provide a summary of the changes, not say "do the diffs yourself" (paraphrased; you're welcome by the way) and then complain in the next posting that Im actually doing that. > (2) You can search for any component by ANY property value. > Are you proposing that we limit searching of VQUERYs to > be less than other components? How the heck did you get that from either my proposal to remove all references to stored queries OR to my comment about NAME being incorrectly used in finding the a particular stored query in a particular TARGET? This is totally a nonsequitor. > > Even if it was suggested, there is NO prose in CAP _now_ for when NAME > > is used, how it is to be used or when it is NOT used in conjunction > > with QUERYID in a VQUERY. If (and thats a big if) the WG decides to > > use NAME in addition to QUERYID as part of VQUERY location then issues > > like dealing with specifying localization code pages used, etc need to > > be answered. > > (1) Did you bother to read section 8.23? In fact I did. Section 8.23 NAME Property says NOTHING about using NAME as part of any criteria for identifying queries. Actually it does not matter now that you've said you will revise the questionable text in Section 9.6 VQUERY Component it doesn't really matter but Im still interested in what I missed. > (2) You can search for any component by ANY property value. > Are you proposing that we limit searching of VQUERYs to > be less than other components? Ahh, I think I see now; you have confused SEARCHing with the act of finding a particular stored query in a particular TARGET that I cited and have been referring to. I have been referring to the questionable text in Section 9.6 VQUERY Component that said that "NAME" was used "when looking for a correct stored "VQUERY" component" and you have incorrectly extended this to all SEARCHing based on the NAME property. > By your removal and (so far) non responsiveness to your incorrect > octet count conclusion, are you agreeing that it does indeed save > one round trip and twice the stored VQUERY size in OCTETS > at a minimum now so it is in fact 'efficient'? I have NO clue where you got the idea in your head that the CUA is going to have to retrieve a query string from the CS only to stuff it into a command buffer and then send it back to the CS. Perhaps the same place you got your definition of the word original. Ive already explained several times that this is incorrect on your part and Ive even given pseudocode on how the CUA does it all itself. Beyond that, I cannot do more. I would still appreciate an explaination of why you think the CUA MUST load the query string from the CS in the first place? Is that how you prototyped it? Or is there just some other nuance of phrasing Im not getting? Arnaud, can you help me out here? 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 0078A9B385256D97_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 09/04/2003 01:51:35 PM:
> (1) Bruce - please read all of CAP - not just the diffs.
Doug - please post a summary of the changes between versions instead of saying "do the diffs yourself" (paraphrased).  I did and now you say, go read the drafts!?  Sorry but Im NOT going to reread ~140 pages every time a new draft is reissued since by now there should not be lots of changes going in.

Its a typical editors task to provide a summary of the changes, not say "do the diffs yourself" (paraphrased; you're welcome by the way) and then complain in the next posting that Im actually doing that.

> (2) You can search for any component by ANY property value.
>      Are you proposing that we limit searching of VQUERYs to
>      be less than other components?
How the heck did you get that from either my proposal to remove all references to stored queries OR to my comment about NAME being incorrectly used in finding the a particular stored query in a particular TARGET?  This is totally a nonsequitor.

>  > Even if it was suggested, there is NO prose in CAP _now_ for when NAME
>  > is used, how it is to be used or when it is NOT used in conjunction
>  > with QUERYID in a VQUERY.  If (and thats a big if) the WG decides to
>  > use NAME in addition to QUERYID as part of VQUERY location then issues
>  > like dealing with specifying localization code pages used, etc need to
>  > be answered.
>
> (1) Did you bother to read section 8.23?
In fact I did.  Section 8.23 NAME Property says NOTHING about using NAME as part of any criteria for identifying queries.

Actually it does not matter now that you've said you will revise the questionable text in Section 9.6 VQUERY Component it doesn't really matter but Im still interested in what I missed.

> (2) You can search for any component by ANY property value.
>      Are you proposing that we limit searching of VQUERYs to
>      be less than other components?
Ahh, I think I see now; you have confused SEARCHing with the act of finding a particular stored query in a particular TARGET that I cited and have been referring to.  

I have been referring to the questionable text in Section 9.6 VQUERY Component that said that "NAME" was used "when looking for a correct stored "VQUERY" component" and you have incorrectly extended this to all SEARCHing based on the NAME property.  

> By your removal and (so far) non responsiveness to your incorrect
> octet count conclusion, are you agreeing that it does indeed save
> one round trip and twice the stored VQUERY size in OCTETS
> at a minimum now so it is in fact 'efficient'?
I have NO clue where you got the idea in your head that the CUA is going to have to retrieve a query string from the CS only to stuff it into a command buffer and then send it back to the CS.  Perhaps the same place you got your definition of the word original.

Ive already explained several times that this is incorrect on your part and Ive even given pseudocode on how the CUA does it all itself.  Beyond that, I cannot do more.  

I would still appreciate an explaination of why you think the CUA MUST load the query string from the CS in the first place?  Is that how you prototyped it?  Or is there just some other nuance of phrasing Im not getting?   Arnaud, can you help me out here?

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 0078A9B385256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 18:46:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29008 for ; Thu, 4 Sep 2003 18:45:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MSjgc055571 for ; Thu, 4 Sep 2003 15:28:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84MSjbL055570 for ietf-calendar-bks; Thu, 4 Sep 2003 15:28:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MSfgc055565 for ; Thu, 4 Sep 2003 15:28:43 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19v2bJ-0004EC-00 for ; Fri, 05 Sep 2003 00:29:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19v2bI-0004Ds-00 for ; Fri, 05 Sep 2003 00:29:12 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19v2an-0004c9-00 for ; Fri, 05 Sep 2003 00:28:41 +0200 From: "Michael Fair" Subject: Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt] Date: Thu, 4 Sep 2003 15:28:40 -0700 Lines: 140 Message-ID: References: <3F57A50F.70002@Royer.com> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Doug, from what I read on Frank and Derik's replies and on other peoples > > comments on the list, I see a pattern evolving. People are coding their > > applications using more of a fixed model. Why do we have to have a > > complicated draft when all we need to do is remove the one sentence in > > 3.7.1, change examples to reflect that change and resubmit the draft. > > > > So, my question to everyone on the list that has been active on the > > Recurrence-ID issue - does this sound like too simplistic an approach? > > Am I missing something. The arguments seem to lean towards Bruce's > > comments and attempt at a model. That is certainly a step in the right direction and would clear up the blatant conflicts. However there are other areas too. Off the top of my head: "Bad Recurrence-ID" needs to be expanded to include a fourth possibility; that it has never seen neither the base UID nor the RECURRENCE-ID before. The "may be" in "so that each instance may be both sequence and versioned" needs to be changed to "is" I don't recall the section offhand. This needs to make it explcit that the SEQUENCE value for each instance is tracked independently and that they do not share a common SEQUENCE counter. Somehow it needs to be made clear that every relevant reference to "UID" throughout the document really means something more along the lines of "primary key" which could include UID, RECURRENCE-ID, and RANGE to accurately identify which events are being referred to. Much of the confusion here has been as a result of interpretting "UID" to not mean all of those. Any place where dealing with recurring instances (or sets of them via RANGE) is not appropriate should be explicitly mentioned that such use is inappropriate. I cannot think of any such cases at the moment. Making it clear that when canceling an event for a particular user the SEQUENCE value should not be incremented (or at least more discussion on what it should do). I'm sure there are others. If there is a new list thread started after some definite declaration that the changing recurrence-id model is dead and should be eliminated from iTIP and perhaps we should look at making iCal even more clear I'll be happy to provide more direct textual recommendations with section numbers. Of course these are just my initial thoughts and I'd be happy to hear others either confirm, disagree, or add to these. > I have a list that I am not confident to send out yet as I re-read > the examples sent. It looks as if there are 4 distinct models and > not 2. This list will be included in the next rev of that draft. > > Its not as simple as 'fixed' vs. 'non-fixed' which is one of the > points of the draft. At one point in time it appeared as if there was more than 1 fixed-id model. But I think that the split perceived was actaully a consequence of limiting the scope of the conversation in attempt to create clarity since it was getting harder and harder to put together sentences that Doug would understand. Doug's two fixed-id models as hes explained so far are thus: 1) A recurrence-id is created at the time the instance is first born into existence and is fixed from then on forever regardless of any other changes to the event. 2) A recurrence-id is fixed from the last "rescheduling" of the base event. Rescheduling means a SEQUENCE bump with the UID and no RECURRENCE-ID (in many cases the recurrence-ids actually stay the same, but not all). "Add" is officially a rescheduling, but it has no destructive powers over any existing RECURRENCE-ID. It's not entirely clear to me at this time if canceling an instance (and I mean truly canceling it) is a rescheduling of the base event or an update to just the instances involved. I leave this to someone else with more clarity on this issue to clarify for us. Model (1) has been obsolete since Derik and Frank's post and I'm not event clear that it was ever believed that model (1) was ever the totality of how to deal with recurring events. I'm fairly confident that regardless of what might have been flying around at the beginning of the conversations, the fixed-id camp has all come to using model (2). There was a time in the conversation when the discussion was explicitly trying to exclude reschedules of the base event from the conversation. When such an exclusion is made, recurrence-ids are indeed permanently fixed from SEQUENCE:0 and model (1) is actually the truth in that context. Doug never seemed to grasp this part of the conversation. Doug also hasn't understood per instance sequence numbers, or at least has never been able to represent the model accurately to demonsrate any sort of competence in using it, and as a result he may be seeing more models than we've actually been talking about. I can absolutely gaurantee that Doug's list is obsolete regardless of what's on it. There are not 4 models flying around. He's just seeing 4 models. What Doug also might have on his list came from differences in opinion about how rescheduling all instances would have occured. After hashing it out, we discovered that there are two ways to reschedule every instance in a series, and we initially were talking about our respective methods which caused confusion. One way is to reschedule the entire series, the other is to provide the first RECURRENCE-ID in the series and use the RANGE:THISANDFUTURE. These two methods result in slightly different objects on the calendar though the displayed results to the CU are the same. That has since been resolved and we are in agreement that each of us was always saying the right thing given their view. -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Sep 4 18:47:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29068 for ; Thu, 4 Sep 2003 18:47:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MZKgc056179 for ; Thu, 4 Sep 2003 15:35:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84MZKHR056177 for ietf-calendar-bks; Thu, 4 Sep 2003 15:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MZJgc056166 for ; Thu, 4 Sep 2003 15:35:19 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F577DDD.6090606@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 8.30 RECUR-ACCEPTED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 18:29:55 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 06:36:22 PM, Serialize complete at 09/04/2003 06:36:22 PM Content-Type: multipart/alternative; boundary="=_alternative 007B949385256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B949385256D97_= Content-Type: text/plain; charset="US-ASCII" Doug quiped on 09/04/2003 02:01:01 PM: > So you are proposing we change the text to: > > "we need to answer the discrepancy between Purpose and > Description." > > No. Correct: No. Im not sure if I should propose getting a co-editor or not since you seem to have a knack for missing points. I propose that the WG decide if the intent of the RECUR-ACCEPTED property is correctly defined as (A) "This property specifies if the endpoint supports recurring instances." (any kind of recurrence) or as (B) "This property specifies if the endpoint supports recurring rules." (RRULEs only) I suggest (A) is correct and (B) is incorrect. If we opt for (A) then Description needs to be changed to be: Description: Indicates if recurrence instances are supported. If FALSE then the endpoint can not process any kind of recurring rules. If we opt for (B) then Description is ok and Purpose needs to be changed to: Purpose: This property specifies if the endpoint supports recurring rules. No matter if we choose (A) or (B), the property is incomplete in that it is unable to convey the ability/inability for a CS to deal with RDATEs, EXRULEs and EXDATEs. As noted earlier, not all engines that support RRULEs support RDATEs and supporing RRULEs/RDATEs is orthogonal to supporting EXRULEs/EXDATEs. As such CAP needs some way for this ability/inability to be conveyed clearly for each kind of recurrence/exclusion. Depending on how we resolve (A)/(B) above, I can better propose how to fix the other bits. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 007B949385256D97_= Content-Type: text/html; charset="US-ASCII"
Doug quiped on 09/04/2003 02:01:01 PM:
> So you are proposing we change the text to:
>
>    "we need to answer the discrepancy between Purpose and
>    Description."
>
> No.
Correct: No.  Im not sure if I should propose getting a co-editor or not since you seem to have a knack for missing points.

I propose that the WG decide if the intent of the RECUR-ACCEPTED property is correctly defined as (A) "This property specifies if the endpoint supports recurring instances." (any kind of recurrence) or as (B) "This property specifies if the endpoint supports recurring rules." (RRULEs only)

I suggest (A) is correct and (B) is incorrect.  If we opt for (A) then Description needs to be changed to be:

   Description: Indicates if recurrence instances are supported. If FALSE
  then the endpoint can not process any kind of recurring rules.

If we opt for (B) then Description is ok and Purpose needs to be changed to:

   Purpose: This property specifies if the endpoint supports recurring
  rules.

No matter if we choose (A) or (B), the property is incomplete in that it is unable to convey the ability/inability for a CS to deal with RDATEs, EXRULEs and EXDATEs.  

As noted earlier, not all engines that support RRULEs support RDATEs and supporing RRULEs/RDATEs is orthogonal to supporting EXRULEs/EXDATEs.   As such CAP needs some way for this ability/inability to be conveyed clearly for each kind of recurrence/exclusion.  Depending on how we resolve (A)/(B) above, I can better propose how to fix the other bits.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 007B949385256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 18:52:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29292 for ; Thu, 4 Sep 2003 18:52:57 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MZKgc056178 for ; Thu, 4 Sep 2003 15:35:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84MZK8H056173 for ietf-calendar-bks; Thu, 4 Sep 2003 15:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MZJgc056167 for ; Thu, 4 Sep 2003 15:35:19 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F577D57.3030303@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 18:13:08 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 06:36:22 PM, Serialize complete at 09/04/2003 06:36:22 PM Content-Type: multipart/alternative; boundary="=_alternative 007A0B2F85256D97_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007A0B2F85256D97_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 09/04/2003 01:58:47 PM: > Identify != 'looking for' as the following is as valid: > > SELECT VQUERY FROM VAGENDA WHERE 'some ... locale string' IN NAME > > as: > > SELECT VQUERY FROM VAGENDA WHERE QUERYID = '123' > > VQUERY is a component searchable like any other. You are once again confusing SEARCHing for VQUERYs with using "looking for" VQUERYs to use in a command. The former is above, the latter is: BEGIN:VQUERY TARGET:cap:FrodosCalendar QUERYID:EventsInTheShire END:VQUERY where whatever command is told to use the query identified by QUERYID:EventsInTheShire in VAGENDA FrodosCalendar rather than another TARGETed VAGENDA to find the entries that are to be processed by the command. At least thats what I take from: For a search, if the "TARGET" property is supplied in a "VQUERY" component, then the CS is to search for the query in the CALID supplied by the "TARGET" property value. I did not take "a search" above to be "a SEARCH" as in a SEARCH command. I took this to be "Use the QUERYID value to find the desired actual query in the specified TARGET" rather than limiting it to an actual SEARCH or SELECT as you suggest. Is this not consistant with the comments in the ABNF for VQUERY: ; 'queryid' is OPTIONAL but MUST NOT occur ; more than once. If the "TARGET" property ; is supplied then the "QUERYID" property ; MUST BE supplied. and the text: ...looking for a correct stored "VQUERY" component... If not then the comments and the prose under 9.6 need to be better phrased to reflect the correct intent. In addition, if the intent of "For a search" was to imply a SEARCH command then I have to ask why the same "find the query" logic is not applicable to other commands like DELETE or MOVE? 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 007A0B2F85256D97_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 09/04/2003 01:58:47 PM:
> Identify != 'looking for' as the following is as valid:
>
>    SELECT VQUERY FROM VAGENDA WHERE 'some ... locale string' IN NAME
>
> as:
>
>    SELECT VQUERY FROM VAGENDA WHERE QUERYID = '123'
>
> VQUERY is a component searchable like any other.
You are once again confusing SEARCHing for VQUERYs with using "looking for" VQUERYs to use in a command.  The former is above, the latter is:

BEGIN:VQUERY
TARGET:cap:FrodosCalendar
QUERYID:EventsInTheShire
END:VQUERY

where whatever command is told to use the query identified by QUERYID:EventsInTheShire in VAGENDA FrodosCalendar rather than another TARGETed VAGENDA to find the entries that are to be processed by the command.  At least thats what I take from:

   For a search, if the "TARGET" property is supplied in a "VQUERY"
  component, then the CS is to search for the query in the CALID
  supplied by the "TARGET" property value.
I did not take "a search" above to be "a SEARCH" as in a SEARCH command.  I took this to be "Use the QUERYID value to find the desired actual query in the specified TARGET" rather than limiting it to an actual SEARCH or SELECT as you suggest.  Is this not consistant with the comments in the ABNF for VQUERY:

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

and the text:

                                        ...looking for a correct stored
  "VQUERY" component...

If not then the comments and the prose under 9.6 need to be better phrased to reflect the correct intent.

In addition, if the intent of "For a search" was to imply a SEARCH command then I have to ask why the same "find the query" logic is not applicable to other commands like DELETE or MOVE?

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 007A0B2F85256D97_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 21:00:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06486 for ; Thu, 4 Sep 2003 21:00:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h850Xdgc062019 for ; Thu, 4 Sep 2003 17:33:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h850XdKq062018 for ietf-calendar-bks; Thu, 4 Sep 2003 17:33:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h850Xcgc062013 for ; Thu, 4 Sep 2003 17:33:38 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h850XZS5007874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 17:33:38 -0700 Message-ID: <3F57D9DA.6000908@Royer.com> Date: Thu, 04 Sep 2003 18:33:30 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060909010105070805050308" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060909010105070805050308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > (2) You can search for any component by ANY property value. > > Are you proposing that we limit searching of VQUERYs to > > be less than other components? > > How the heck did you get that from either my proposal to remove all > references to stored queries OR to my comment about NAME being > incorrectly used in finding the a particular stored query in a > particular TARGET? This is totally a nonsequitor. So you want to not be able to store some types components. But other type components you want to be able to save. Correct? The 'NAME' issue I think we resolved. -- 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 --------------ms060909010105070805050308 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNTAwMzMzMFowIwYJKoZIhvcNAQkEMRYEFHl5aKYJ MBUd7doIHtGXe9G5/HgQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAKu3yHP1+iFto+F8BgBXRALBcDoYPeQvydBSEftKcdoEEd6XmWjS lgHxJhrjNE98V5x5pk2I96i3cGmJqdnoBcZZoSlOGCEheFne+M6MDVuLAAf33CIOmP4oGoXJ bGjVX8avbW5VnGbd//J3YHhROOA3KAK0izJO08XWXK3FNBKAJop9SzDA55DRCqCcnMkv03Jz 3Jgl+4kB8HB4SfqHCb5P4/+VCuzMITkjoJgKP1457yHHUrJbJkO3Tcc7RplMf1dzvqiH0OD+ LN9rNlCvGX0OqvGzts3mXHxYilOie6/R9AFKxuB5e5GWak7QmlXXP5zKwIkYFbhPeK3JZC99 crkAAAAAAAA= --------------ms060909010105070805050308-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 21:09:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06983 for ; Thu, 4 Sep 2003 21:09:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h850jogc062488 for ; Thu, 4 Sep 2003 17:45:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h850joRU062487 for ietf-calendar-bks; Thu, 4 Sep 2003 17:45:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h850jmgc062482 for ; Thu, 4 Sep 2003 17:45:48 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h850jiS5008022 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 17:45:48 -0700 Message-ID: <3F57DCB3.1020402@Royer.com> Date: Thu, 04 Sep 2003 18:45:39 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000807070402070109000905" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000807070402070109000905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > You are once again confusing SEARCHing for VQUERYs with using "looking > for" VQUERYs to use in a command. The former is above, the latter is: Sorry, now I understand - yes I agree, 'Normally' gone. -- 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 --------------ms000807070402070109000905 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNTAwNDUzOVowIwYJKoZIhvcNAQkEMRYEFM/VFz1p MZnHU3ScsO/coOhgGiYuMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAC79pAxrsF7cZWI8a4XUX6sOPDRvsHISpxiBxsBtOOgDQWNC1/JA Xhf4AyGh/3GyWc64drrH+7omThMJqXIhqF64p2uQ3hTWPO0+oJH4Kchxp+XmZ47UZOeqVttY S2V2ZD+Jwo5E4V1JCzP5cyxMExO2FQMbFfqthPXcxzi2o36f3CLHt+dZBsXb6/B86bg0h+IC t46U7N30ECfHPpPKnj8hBS8KNUB4BILG48rrnc0VY+kUF3VQP3fPi558Q6sA+qMlmRQyAoGO VnB68tDfHrdhDg/rOGaC67X/Bm3A/SrfkaQFyihzQusGIJplYGmXKkMgxa65FbCSKxDh4wPX oKEAAAAAAAA= --------------ms000807070402070109000905-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 21:16:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07402 for ; Thu, 4 Sep 2003 21:16:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h850xLgc063018 for ; Thu, 4 Sep 2003 17:59:21 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h850xLVk063017 for ietf-calendar-bks; Thu, 4 Sep 2003 17:59:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h850xKgc063012 for ; Thu, 4 Sep 2003 17:59:20 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F578929.9050600@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 4 Sep 2003 20:53:17 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/04/2003 09:00:37 PM, Serialize complete at 09/04/2003 09:00:37 PM Content-Type: multipart/alternative; boundary="=_alternative 0004DEB385256D98_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0004DEB385256D98_= Content-Type: text/plain; charset="US-ASCII" Doug fired back on 09/04/2003 02:49:13 PM: > > That's typical for an editor to post summaries to a list when > > changes are made. > > It is not typical, I am on several ietf mailing lists, and it > is DARN RARE. (see end of this post for more on this topic). Not its not and you've done it before on other drafts we've worked here on so dont act as if the request is totally out of left field and new to you. > I told you and Ned in San Francisco that > I was going to oppose ANY AND ALL changes to CAP so that we can get it out. If you are simply opposing any and all proposals made to fix CAP in an effort to get it shipped rather than actually considering them then there is something very wrong here. I seriously seriously doubt that the ADs or the co-chairs just want to pass a draft thats got identifiable problems that are fixable just to get the draft done and the group closed down. If progress is being made then I suspect they would give us a chance to fix things before pulling the plug. If CAP was just going to be pushed out in its current form then what need did the ADs/co-chairs have of an editor? None really. They could have just issued it and been done with it. Why ask you to be the editor if there was going to be no further changes at all? If CAP 1.0 goes out as it, it will have plenty of known flaws or shortcomings that will result in indeterminate behaviour in several cases. This is NOT the way to get CAP 1.0 adopted in products. Im not as concerned about fixing each and every gramatical error as I am in making sure that the larger design issues get addressed first. If you're not sure what Im referring to, read on... > I told you thatthose that delcare a problem without posting any > facts are were going to get bambarded by email from me to ether > post the issue or stop claiming there is one. Ive posted an issue. Several in fact. Ive even posted ideas for WG discussion on solving them. Instead of looking at them you've tried to use email flooding and digression to disusade WG discussion. I seriously doubt this is what Pat/Ned or anyone else expected or wanted. I would be willing to be that they really wanted to disuade any new features unless there was a large outcry for them and that fixes were not part of the prohibition. > People keep claiming there 'are technical issues', you keep saying you > think there are issues with CAP. Bruces email claimed motive > but failed to support his claims. Ive questioned your recent reluctance to do things you've done before as editor and the changes I found in comparing 2 versions of CAP. Given what I found I dont think that my suspicions are necessarily unfounded. They may be incorrect but NOT unfounded. However if you want to know why I question your motives read on still... > Go re-read Bruces email and tell me if he has posted even ONE post > that backs up (some in recent posts); > > (a) ...I certainly dont recall any WG discussion on some of the bigger > issues ... Please point to the WG thread(s) where we discussed and resolved the issue of scoping on SEARCH? Please point to the WG thread(s) where we discussed and resolved the issue of busytime querying and maintenance? (For which I twice posted a proposed solution but you have refused to acknowledge it let alone discuss it.) Please point to the WG thread(s) where we resolved the issue of stored queries? (For which Andrea and I have proposed a solution as well.) We've had CAP-11, CAP-12 and CAP-12-a in very quick succession over the span of a couple months. Why so many revisions if we didn't discuss/resolve the issues raised in the months just prior to them? Even if the pageful of grammar/typos in your Bugzilla were factored in that does not account for 3 revisions in such a short a span of time. > (b) ...Im more than a bit concerned that there are changes that creep > (additions or omissions) that should not. ... diff reports 707 changes between CAP-10 and CAP-12-a. Not some custom tool; generic diff. If I remove the TOC (1 big difference) and the ~140 headers/footers that leaves ~565 other changes of _some_ kind. If we were not discussing CAP issues over the past month or two, just where did all these changes come from? Some are pure whitespace but others are NOT. Either there were LOTS and LOTS of typos or grammar errors or changs were made. The TOC for CAP-12-a says there are 7 fewer pages. Unless you did some unusual reformatting there is no way typos and small grammar changes can account for this! Combine this with the results from diff and its easy to call changes into question (especially given your reticence to provide a summary of the changes yet you have time to spin out several extra CAP related drafts). Instead of providing a summary of the changes in the drafts you say I should do it. When I do and I question the results you complain that Im not reading the drafts. As editor you should be able to tell us what changes you made using your custom XML based tool rather than making us all try to find them. > (c) One of the other changes Im leary of was the change in the footers: > It just looks like an attempt to give Doug more prominence ... > > Now do YOU honestly see ANY details in his post to substantiate his > assertions? Its hard to see the details if you dont read the posts Doug. The footer change was coincidental with Dougs great desire to go to Last Call and was not something done on ANY previous version of the draft, excluding the CAP-11 I never saw nor can I find the URL for, and was not an unreasonable change to notice or question. After all, it didnt happen on any previous CAP-10 drafts that Doug edited so it looked suspicious... > I kept no summary. I simply printed out the -10 version of the > draft, looked at the date, started looking in the WG archive from a month > or so before -10 released and started using a markup pen to the printed > version as I read each post. The result was edited into -11. Umm, which version of CAP-10 was this? We had several in Dec/Jan/Feb. You clearly missed the issue of stored queries that was in active discussion in Nov/Dec 2002 under the thread "What good are stored VQUERYs?" of which you were a participant even. You also missed the scoping issue from the thread "How do you get the METHOD property on a SEARCH" in April 2003. You also did not cover the issue of busy time creation/searching/updating that I raised under "CAP & busytime?" in March 2003 and "CAP / Busytime Restart" in April 2003. Oh yeah, if that went into CAP-11 then what was the need for a CAP-12 and CAP-12-a so soon after CAP-11?? > The only other things that changed were formatting issues and fixes > as a result in a bug in xml2rfc that for some reason left out > about 3 sentences and did some odd formatting. Then why are there so many whitespace changes unrelated to anything else? The boilerplate text alone had more than just 1 change in whitespace: =========================================================================== ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 29 time. It is inappropriate to use Internet-Drafts as reference ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 28 time. It is inappropriate to use Internet-Drafts as reference =========================================================================== ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 51 (CALSCH) Working Group. More information about the IETF CALSCH ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 59 (CALSCH) Working Group. More information about the IETF CALSCH =========================================================================== ************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 63 www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the ******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 62 www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the There are plenty of other non-typo changes to be found by diff too. Either they came from the Dougs fingers or from his non-standard XML tool thats admittedly munges content. Either way, there is no simple way to not see them using the diff tool that Doug suggested we use. So, if you only did typo changes an other minor grammar changes then why is CAP-12-a 7 pages shorter but ~2K larger?? 7 pages/~2K is a LOT for no acutal substance changes no matter how you cut it. You want facts Ill give you some to consider in questioning Dougs motives: 1: Doug has not been shy about his desire to get CAP to Last Call. Even though he's "on several ietf mailing lists" he seemed to think making Last Call was his perogative rather than the chairs. 2: Doug has consistanly refused to provide a change list for CAP-11, CAP-12 or CAP-12-a unlike previous iterations or drafts where hes done exactly that. 3: The sheer volume of changes between CAP-10-17-FEB-03 and CAP-12-a is astounding. Over 500K edited down to remove the TOC and many headers/footers. 707 changed blocks of text (TOC and headers/footers included) Thats much more than typical for supposedly typos and grammar changes. 4: There are 7 fewer pages in CAP-12-a than CAP-10-17-FEB-03. Again thats much more than would be reasonably expected for typos and grammar changes alone. 5: Dougs been the editor for a while now and only for CAP-12-a do I see that the footers changed to be "et al." instead of the list of editors. Unless your XML tool changed and automagically rewrites footer content I have to doubt that it was a tool bug. It could be that Doug forgot to make the change this time and he made it in previous versions but he didnt say that so I wont assume that to his benefit. 6: None of the CAP-10 drafts Doug put out had the seemingly minor changes in them between versions (ie: no whitespace changes). 7: Instead of engaging in constructive dialog about issues in CAP, Doug has chosen to ignore postings by those not afraid of him (ie: Michael Fair) or try to digress the thread off topic (ie: my postings) All of these put together I think show why I raised the question of motivation. Only Doug can say with 100% certainty what his motives are, I have to rely on what I observe. The observed 7 facts above (plus other OOB info) are why I questioned him. If Im totally off base then I appologize but from what I've observed (see above) I'd have to say that Dougs motives dont look all that pure. Couple that with your admitted intent to "to oppose ANY AND ALL changes to CAP so that we can get it out" and the questioning now appears even less unwaranted. > These kinds of rabble rousing claims about motive and secret > changes have been made since -00 of CAP. Yet NO post or private > email found them substantive. Umm, I havent questioned you or any editor since CAP-00 (until now). I don't recall anyone else doing it either. Now you are just being paranoid Doug. There is no way any email (public or private) will be able to prove or disprove your motives since we are not inside your head. However, it is possible to observe a pattern of behaviour and from there deduce motives or at least potential motives. If you combine the facts above like I did then you should be able to see that they collectively paint a questionable picture. To test this out I asked 7 random folks here to read the list above and asked them for their impression of the person described. Each and every one came to the same conclusion that I did. > When I want to see what changed - I do a diff. Since you know you didnt make that ~700 changes (right??) you should be somewhat curious why there were so many differences. Well, you _should_ have been curious... Given that CAP-10-17-Feb-03 was ~242K and CAP-12-a is ~244K you should have been more than a little curious when the diff is over 500K and reports 707 changes! I certainly am and among them are some that reasonably can call your motives into question. 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 0004DEB385256D98_= Content-Type: text/html; charset="US-ASCII"
Doug fired back on 09/04/2003 02:49:13 PM:
>  > That's typical for an editor to post summaries to a list when
>  > changes are made.
>
> It is not typical, I am on several ietf mailing lists, and it
> is DARN RARE. (see end of this post for more on this topic).
Not its not and you've done it before on other drafts we've worked here on so dont act as if the request is totally out of left field and new to you.

>                         I told you and Ned in San Francisco that
> I was going to oppose ANY AND ALL changes to CAP so that we can get it out.
If you are simply opposing any and all proposals made to fix CAP in an effort to get it shipped rather than actually considering them then there is something very wrong here.  

I seriously seriously doubt that the ADs or the co-chairs just want to pass a draft thats got identifiable problems that are fixable just to get the draft done and the group closed down.  If progress is being made then I suspect they would give us a chance to fix things before pulling the plug.

If CAP was just going to be pushed out in its current form then what need did the ADs/co-chairs have of an editor?  None really.  They could have just issued it and been done with it.   Why ask you to be the editor if there was going to be no further changes at all?

If CAP 1.0 goes out as it, it will have plenty of known flaws or shortcomings that will result in indeterminate behaviour in several cases.  This is NOT the way to get CAP 1.0 adopted in products.  Im not as concerned about fixing each and every gramatical error as I am in making sure that the larger design issues get addressed first.  If you're not sure what Im referring to, read on...

> I told you thatthose that delcare a problem without posting any
> facts are were going to get bambarded by email from me to ether
> post the issue or stop claiming there is one.
Ive posted an issue.  Several in fact.  Ive even posted ideas for WG discussion on solving them.

Instead of looking at them you've tried to use email flooding and digression to disusade WG discussion.  I seriously doubt this is what Pat/Ned or anyone else expected or wanted.  I would be willing to be that they really wanted to disuade any new features unless there was a large outcry for them and that fixes were not part of the prohibition.

> People keep claiming there 'are technical issues', you keep saying you
> think there are issues with CAP. Bruces email claimed motive
> but failed to support his claims.

Ive questioned your recent reluctance to do things you've done before as editor and the changes I found in comparing 2 versions of CAP.  Given what I found I dont think that my suspicions are necessarily unfounded.  They may be incorrect but NOT unfounded.

However if you want to know why I question your motives read on still...

> Go re-read Bruces email and tell me if he has posted even ONE post
> that backs up (some in recent posts);
>
> (a)   ...I certainly dont recall any WG discussion on some of the bigger
>       issues ...
Please point to the WG thread(s) where we discussed and resolved the issue of scoping on SEARCH?

Please point to the WG thread(s) where we discussed and resolved the issue of busytime querying and maintenance?  (For which I twice posted a proposed solution but you have refused to acknowledge it let alone discuss it.)

Please point to the WG thread(s) where we resolved the issue of stored queries?  (For which Andrea and I have proposed a solution as well.)

We've had CAP-11, CAP-12 and CAP-12-a in very quick succession over the span of a couple months.  Why so many revisions if we didn't discuss/resolve the issues raised in the months just prior to them?  Even if the pageful of grammar/typos in your Bugzilla were factored in  that does not account for 3 revisions in such a short a span of time.

> (b)   ...Im more than a bit concerned that there are changes that creep
>      (additions or omissions) that should not. ...
diff reports 707 changes between CAP-10 and CAP-12-a.  Not some custom tool; generic diff.  If I remove the TOC (1 big difference) and the ~140 headers/footers that leaves ~565 other changes of _some_ kind.  If we were not discussing CAP issues over the past month or two, just where did all these changes come from?  Some are pure whitespace but others are NOT.  Either there were LOTS and LOTS of typos or grammar errors or changs were made.

The TOC for CAP-12-a says there are 7 fewer pages.  Unless you did some unusual reformatting there is no way typos and small grammar changes can account for this!  Combine this with the results from diff and its easy to call changes into question (especially given your reticence to provide a summary of the changes yet you have time to spin out several extra CAP related drafts).

Instead of providing a summary of the changes in the drafts you say I should do it.  When I do and I question the results you complain that Im not reading the drafts.  As editor you should be able to tell us what changes you made using your custom XML based tool rather than making us all try to find them.

> (c)   One of the other changes Im leary of was the change in the footers:
>        It just looks like an attempt to give Doug more prominence ...
>
> Now do YOU honestly see ANY details in his post to substantiate his
> assertions?

Its hard to see the details if you dont read the posts Doug.

The footer change was coincidental with Dougs great desire to go to Last Call and was not something done on ANY previous version of the draft, excluding the CAP-11 I never saw nor can I find the URL for, and was not an unreasonable change to notice or question.  After all, it didnt happen on any previous CAP-10 drafts that Doug edited so it looked suspicious...

> I kept no summary. I simply printed out the -10 version of the
> draft, looked at the date, started looking in the WG archive from a month
> or so before -10 released and started using a markup pen to the printed
> version as I read each post. The result was edited into -11.
Umm, which version of CAP-10 was this?  We had several in Dec/Jan/Feb.  

You clearly missed the issue of stored queries that was in active discussion in Nov/Dec 2002 under the thread "What good are stored VQUERYs?" of which you were a participant even.

You also missed the scoping issue from the thread "How do you get the METHOD property on a SEARCH" in April 2003.

You also did not cover the issue of busy time creation/searching/updating that I raised under "CAP & busytime?" in March 2003 and "CAP / Busytime Restart" in April 2003.

Oh yeah, if that went into CAP-11 then what was the need for a CAP-12 and CAP-12-a so soon after CAP-11??

> The only other things that changed were formatting issues and fixes
> as a result in a bug in xml2rfc that for some reason left out
> about 3 sentences and did some odd formatting.

Then why are there so many whitespace changes unrelated to anything else?  The boilerplate text alone had more than just 1 change in whitespace:

===========================================================================
************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 29
   time.  It is inappropriate to use Internet-Drafts as reference
******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 28
   time. It is inappropriate to use Internet-Drafts as reference
===========================================================================
******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 51
   (CALSCH) Working Group.  More information about the IETF CALSCH
******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 59
   (CALSCH) Working Group. More information about the IETF CALSCH
===========================================================================
************************** e:\draft-ietf-calsch-cap-10-17Feb03.txt, Line 63
   www.ietf.org/html.charters/calsch-charter.html [1].  Refer to the
******************************** e:\draft-ietf-calsch-cap-12-a.txt, Line 62
   www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the

There are plenty of other non-typo changes to be found by diff too.  Either they came from the Dougs fingers or from his non-standard XML tool thats admittedly munges content.  Either way, there is no simple way to not see them using the diff tool that Doug suggested we use.

So, if you only did typo changes an other minor grammar changes then why is CAP-12-a 7 pages shorter but ~2K larger??  7 pages/~2K is a LOT for no acutal substance changes no matter how you cut it.

You want facts Ill give you some to consider in questioning Dougs motives:

1: Doug has not been shy about his desire to get CAP to Last Call.  Even though he's "on several ietf mailing lists" he seemed to think making Last Call was his perogative rather than the chairs.
2: Doug has consistanly refused to provide a change list for CAP-11, CAP-12 or CAP-12-a unlike previous iterations or drafts where hes done exactly that.
3: The sheer volume of changes between CAP-10-17-FEB-03 and CAP-12-a is astounding.  Over 500K edited down to remove the TOC and many headers/footers.  707 changed blocks of text (TOC and headers/footers included)  Thats much more than typical for supposedly typos and grammar changes.
4: There are 7 fewer pages in CAP-12-a than CAP-10-17-FEB-03.  Again thats much more than would be reasonably expected for typos and grammar changes alone.
5: Dougs been the editor for a while now and only for CAP-12-a do I see that the footers changed to be "et al." instead of the list of editors.  Unless your XML tool changed and automagically rewrites footer content I have to doubt that it was a tool bug.  It could be that Doug forgot to make the change this time and he made it in previous versions but he didnt say that so I wont assume that to his benefit.
6: None of the CAP-10 drafts Doug put out had the seemingly minor changes in them between versions (ie: no whitespace changes).
7: Instead of engaging in constructive dialog about issues in CAP, Doug has chosen to ignore postings by those not afraid of him (ie: Michael Fair) or try to digress the thread off topic (ie: my postings)

All of these put together I think show why I raised the question of motivation.  Only Doug can say with 100% certainty what his motives are, I have to rely on what I observe.  The observed 7 facts above (plus other OOB info) are why I questioned him.  

If Im totally off base then I appologize but from what I've observed (see above) I'd have to say that Dougs motives dont look all that pure.  Couple that with your admitted intent to "to oppose ANY AND ALL changes to CAP so that we can get it out" and the questioning now appears even less unwaranted.

> These kinds of rabble rousing claims about motive and secret
> changes have been made since -00 of CAP. Yet NO post or private
> email found them substantive.

Umm, I havent questioned you or any editor since CAP-00 (until now).  I don't recall anyone else doing it either.  Now you are just being paranoid Doug.

There is no way any email (public or private) will be able to prove or disprove your motives since we are not inside your head.  

However, it is possible to observe a pattern of behaviour and from there deduce motives or at least potential motives.  If you combine the facts above like I did then you should be able to see that they collectively paint a questionable picture.  To test this out I asked 7 random folks here to read the list above and asked them for their impression of the person described.  Each and every one came to the same conclusion that I did.

> When I want to see what changed - I do a diff.
Since you know you didnt make that ~700 changes (right??) you should be somewhat curious why there were so many differences.  Well, you _should_ have been curious...

Given that CAP-10-17-Feb-03 was ~242K and CAP-12-a is ~244K you should have been more than a little curious when the diff is over 500K and reports 707 changes!  I certainly am and among them are some that reasonably can call your motives into question.

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 0004DEB385256D98_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 22:02:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10462 for ; Thu, 4 Sep 2003 22:02:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h851iCgc064540 for ; Thu, 4 Sep 2003 18:44:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h851iCIQ064539 for ietf-calendar-bks; Thu, 4 Sep 2003 18:44:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h851iBgc064533 for ; Thu, 4 Sep 2003 18:44:11 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h851iBS5008603 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 18:44:12 -0700 Message-ID: <3F57EA66.6030904@Royer.com> Date: Thu, 04 Sep 2003 19:44:06 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010405040001000900000209" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010405040001000900000209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > Not its not and you've done it before on other drafts we've worked here > on so dont act as if the request is totally out of left field and new to > you. > > > I told you and Ned in San Francisco that > > I was going to oppose ANY AND ALL changes to CAP so that we can get > it out. > > If you are simply opposing any and all proposals made to fix CAP in an > effort to get it shipped rather than actually considering them then > there is something very wrong here. Removal of something that has been in CAP for YEARS is not a typo. You have no right to assert that I have not considered them. > > If CAP 1.0 goes out as it, it will have plenty of known flaws or > shortcomings that will result in indeterminate behaviour in several > cases. So you have pointed out one case and some typos since -11, stored queries that you want removed. You did not site it as busted. Your assertion is that it does not meet what you (and others) feel was what ever the original needs were. The typos are getting fixed and the word smithing as you called it are being done because of thousands WG and private emails. And I do not place those in the same category as issues that will "result in indeterminate behavior". If you have a list of bugs, compatibility issues - please post it. Without such an issue list - your claims are just bits of noise. If you have proposals - make them. Many have made proposals that are in CAP. They have proposed solutions, text, and ABNF. That is helpful. Simply declaring there are un-named issues is not helpful. -- 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 --------------ms010405040001000900000209 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNTAxNDQwNlowIwYJKoZIhvcNAQkEMRYEFD53C9DE +sUI3G1C4Wvkhqv6EXsnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAHEcCkmuQWTZ7dLWN8mJ7aDtZ3ejXcIlTSeiKEARsmWUfk2QdfC9 BveX7OszugclE040jKceUFtGOqmgPkV2dqJl+FKiZYM2mWTx/zLJg17mdlm4koJj7imwu0g7 8HynRdG2li8pDkSU7Jzh54V6XbxHezdQs/wJwDbiG7ybxEXfxDR7TkWBsz7dHNyNONVjYR9z YAG63eD2C4wik26GSGr5GXiqzAXMsYdNu9ahgT/Igtf7Pj4bAll9tCCrYYU77zMh2C8s+hRo /O6pOb/2GujW0frRlJyc/1XV4iv87qIkIk8B2xs25OWvp8XBA2uUkZJmhsKJNmb03zeTWPae nN8AAAAAAAA= --------------ms010405040001000900000209-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 22:17:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11381 for ; Thu, 4 Sep 2003 22:17:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h851xngc065004 for ; Thu, 4 Sep 2003 18:59:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h851xnBF065003 for ietf-calendar-bks; Thu, 4 Sep 2003 18:59:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h851xlgc064998 for ; Thu, 4 Sep 2003 18:59:48 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h851xmS5008744 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 18:59:49 -0700 Message-ID: <3F57EE0E.2030909@Royer.com> Date: Thu, 04 Sep 2003 19:59:42 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000105050503020101030007" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000105050503020101030007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > Go re-read Bruces email and tell me if he has posted even ONE post > > that backs up (some in recent posts); > > > > (a) ...I certainly dont recall any WG discussion on some of the bigger > > issues ... > > Please point to the WG thread(s) where we discussed and resolved the > issue of scoping on SEARCH? Go re-read my post (a) was not about SEARCH. It was was in response to the text you sent. Your mis quoting me again. > > (b) ...Im more than a bit concerned that there are changes that creep > > (additions or omissions) that should not. ... > > diff reports 707 changes between CAP-10 and CAP-12-a. Not some custom > tool; generic diff. If I remove the TOC (1 big difference) and the ~140 > headers/footers that leaves ~565 other changes of _some_ kind. If we > were not discussing CAP issues over the past month or two, just where > did all these changes come from? Some are pure whitespace but others > are NOT. Either there were LOTS and LOTS of typos or grammar errors or > changs were made. Your own assertions above conclude that you still do not know. Why are you posting there is a problem and in the same post declaring you did not know if there is a problem - whitespace inside of paragraphs? There are lots of changes because there were lots of changes including formatting of the text. > The TOC for CAP-12-a says there are 7 fewer pages. Unless you did some > unusual reformatting there is no way typos and small grammar changes can > account for this! Combine this with the results from diff and its easy > to call changes into question (especially given your reticence to > provide a summary of the changes yet you have time to spin out several > extra CAP related drafts). The 7 pages concerned me also. So looking at YOUR diff that Pat has hosted. I found the answer in less than a minute. Your questions are answered in your own diff. > > > (c) One of the other changes Im leary of was the change in the footers: > > It just looks like an attempt to give Doug more prominence ... > > > > Now do YOU honestly see ANY details in his post to substantiate his > > assertions? > > Its hard to see the details if you dont read the posts Doug. Is this really one of the "issues" that you fell is going to make CAP ship before it is ready? > > Umm, which version of CAP-10 was this? We had several in Dec/Jan/Feb. > You clearly missed the issue of stored queries that was in active > discussion in Nov/Dec 2002 under the thread "What good are stored > VQUERYs?" of which you were a participant even. And no consensus was called. > You also missed the scoping issue from the thread "How do you get the > METHOD property on a SEARCH" in April 2003. It was covered on the WG list. If you do not like what it does, do you have a proposal? > You also did not cover the issue of busy time > creation/searching/updating that I raised under "CAP & busytime?" in > March 2003 and "CAP / Busytime Restart" in April 2003. Did it reach consensus? I did not see it called. > Oh yeah, if that went into CAP-11 then what was the need for a CAP-12 > and CAP-12-a so soon after CAP-11?? To post the changes so people could see what changed. > > The only other things that changed were formatting issues and fixes > > as a result in a bug in xml2rfc that for some reason left out > > about 3 sentences and did some odd formatting. > > Then why are there so many whitespace changes unrelated to anything > else? The boilerplate text alone had more than just 1 change in > whitespace: As covered in the previous email. Please read the instructions to RFC authors and RFC 2223. > There are plenty of other non-typo changes to be found by diff too. > Either they came from the Dougs fingers or from his non-standard XML > tool thats admittedly munges content. Either way, there is no simple > way to not see them using the diff tool that Doug suggested we use. > > So, if you only did typo changes an other minor grammar changes then why > is CAP-12-a 7 pages shorter but ~2K larger?? 7 pages/~2K is a LOT for > no acutal substance changes no matter how you cut it. Look in your diff - you initiated the change on this WG list that resulted in most of that 7 pages missing. > You want facts Ill give you some to consider in questioning Dougs motives: > (Your non-productive comments and personal opinions deleted. And I did not sort through them to see if there was anything useful). -- 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 --------------ms000105050503020101030007 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNTAxNTk0MlowIwYJKoZIhvcNAQkEMRYEFDvGP7m/ rcQCx6FLBdK/JAw+KJISMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAFOo0RIfSNHjN9c5grBkw8BYmFmeYzLo9/T5lZtQzVZDR7g4poRD S+eqIWNTUPQd6+Usfx7VAMklFQr9GyoqyHpg6SpIFrj6qHC9elOHzvTMy+AV8o5vrPA6wIvu 3Y8z/HWm1qlmqBzBkiqEQYQDeo3WNJztq9l7HywGS1mda5rnQFE01O3qvlpoxquUswRuhKP6 ea+RqTOaHoIMnyoUA1hWgki4i5Mf0hN5hkTVnaXjhlUtaraGrwMb3JQBGE3LPdR7P57efld3 UQdLO+TnC9SkiJs03jgv9auRgSRSKVehv9K0+bnyqwGkXDGFMdkNCMwIXG5ku+yv1vUspWoI AiwAAAAAAAA= --------------ms000105050503020101030007-- From owner-ietf-calendar@mail.imc.org Thu Sep 4 22:44:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12754 for ; Thu, 4 Sep 2003 22:44:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h852Rcgc065944 for ; Thu, 4 Sep 2003 19:27:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h852RcNV065943 for ietf-calendar-bks; Thu, 4 Sep 2003 19:27:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h852Rbgc065938 for ; Thu, 4 Sep 2003 19:27:37 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h852RcS5009100 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Sep 2003 19:27:39 -0700 Message-ID: <3F57F494.8090605@Royer.com> Date: Thu, 04 Sep 2003 20:27:32 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080403050906070301090006" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080403050906070301090006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > These kinds of rabble rousing claims about motive and secret > > changes have been made since -00 of CAP. Yet NO post or private > > email found them substantive. > > Umm, I havent questioned you or any editor since CAP-00 (until now). I > don't recall anyone else doing it either. Now you are just being > paranoid Doug. Bruce as far as I can tell you are the only one to have made claims that the editors have a motive to sneak in changes in each and every release/version of CAP, iTIP, iMIP, and iCAL. Your feed back is *very* useful. But your assertions of negative motives is at the best, not helpfull. -- 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 --------------ms080403050906070301090006 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkwNTAyMjczMlowIwYJKoZIhvcNAQkEMRYEFL0AD7jK +pJsqG7DHBAv/6f4Bkq2MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEVbuanlzSI13eUx1pHpqlNvIpSttN3mY1mW4HvZMywLfIpv0Nrw aDzaccHNHzFcOOLZ3v/R8A1sTsQ0MWcR7f8Ad6jvI7htxX478dPKaikZb+h0E9qdWXuGoEFA /C7yCCS+xy9/xlm9YtfVSjFokXs/V9vt5FP6UgavBlEn0oeK6GFX8xWZY/pT5abBiMa+v1QF WSJFNYh54Rp4bPEbuAjpqq3sz0HBr6iAaoFin0Nf0Z0aH0rWIlakfXNMpc6e0rwlyl8wVJK7 YiDkpb/2Y7CTEceRpZ2RFGIjUvc6a3WDw5ugE4Dot186v4NB11AjUI61d0/a9vntGStWJRNv HMYAAAAAAAA= --------------ms080403050906070301090006-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 06:56:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13889 for ; Fri, 5 Sep 2003 06:56:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Ad1gc014673 for ; Fri, 5 Sep 2003 03:39:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85Ad1nL014672 for ietf-calendar-bks; Fri, 5 Sep 2003 03:39:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Acxgc014643 for ; Fri, 5 Sep 2003 03:39:00 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175]) by comcast.net (sccrmhc13) with SMTP id <20030905103854016006g5k6e> (Authid: TimHare); Fri, 5 Sep 2003 10:38:54 +0000 Message-Id: <5.2.1.1.0.20030905062303.00a19370@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 05 Sep 2003 06:36:15 -0400 To: "ietf-calendar@imc.org" From: Tim Hare Subject: re: stored queries In-Reply-To: <3F57F494.8090605@Royer.com> References: Mime-Version: 1.0 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 may be muddying the water here, I am about to leave on un-connected travel, so I hate to start a discussion since I don't have time to search RFC2445 for details until Monday, but this occurred to me this morning and so I submit it to the group. RFC2445 allows for x-comp and iana-comp in 4.6. This allows any CS / CUA that wants to to support stored queries as x-comp members within the CS unless I'm overlooking something else (see above for time shortage). I propose that we drop all stored query items from CAP (and for that matter iTIP / iMIP and any other CUA protocols). Any implementation which wants to do so can support them via the x-comp facility. It looks to me as though you can still search for the objects with VQUERY. The X- stands for 'experimental', so this would allow us to wait until some "real world" experience has developed around stored queries before we make it a non-experimental part of the RFC; it also removes the burden (from us) of figuring out the CAP handling of such items in detail, moving the CAP closer to being done. Tim Hare interested bystander, non-inc. From owner-ietf-calendar@mail.imc.org Fri Sep 5 14:43:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11773 for ; Fri, 5 Sep 2003 14:43:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IJogc055492 for ; Fri, 5 Sep 2003 11:19:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85IJock055491 for ietf-calendar-bks; Fri, 5 Sep 2003 11:19:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IJngc055486 for ; Fri, 5 Sep 2003 11:19:49 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F5796EF.9060908@Royer.com> To: ietf-calendar@imc.org Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 5 Sep 2003 14:18:49 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 02:21:11 PM, Serialize complete at 09/05/2003 02:21:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0064911F85256D98_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064911F85256D98_= Content-Type: text/plain; charset="US-ASCII" Doug wondered on 09/04/2003 03:47:59 PM: > > For those frequently used querys like "What events are on my calendar > > for XXX" or "What alarms trigger in the next 15 minutes" the CUA simply > > does a Cscanf() of the correct inputs (XXX or the current date/time) > > into a loaded query and then sends it. Again, there is no 2 trips > > across the wire for the query. > > NO ONE has proposed such a thing - who cares? You have when you keep saying "2 trips on the wire" (paraphrased). However I think you are misunderstanding something here: removing stored queries entirely means the CUA wont try to use them (trip 1), fail and then craft its own query (trip 2). The CUA simply crafts the query and sends it (1 trip). > > 1: Failure to find a particular QUERYID in a given TARGET, > > Why do you feel that would be any different to a query for a UID > that did not exist? Its the component-ID tag. No such distinction > exists. Because there is a definite difference between "I cant find the query you wanted me to use to find those VEVENTS" and "I cant find those VEVENTS". Both are errors but dealing with them is different. See the difference now? > > 2: The ability to specify multiple TARGETs in a VQUERY (ie: Do ALL > > TARGETs have to have the QUERYID in it or just one or is it something > > else?) > > Not sure which TARGET you mean: Clearly not (or is this another tactic?). In a VQUERY there can be one (or multiple) TARGET properties to tell the CS where to go look for the QUERYID (go recheck the ABNF in 9.6 if not with me still) It is unspecified how a CS deals with finding/selecting/using the QUERYID in multiple TARGETs (those TARGETs you can put inside the VQUERY, not out side it at the command level). Does it use the first one it finds only? All of them? All the CU has access to? Does any failure to find the QUERYID in any/all/some TARGET mean the command should be rejected or attempted anyway? Etc... > > 3: How are failures to find/use the QUERYID distinguishded from other > > command failures (ie: The SEARCH failed because you cant see/find/use > > the QUERYID in a TARGET vs the SEARCH failed because you cant access the > > TARGET vs the SEARCH failed because you only can read stored queries but > > not other data in a TARGET vs...?) > > As you can send the EXACT same query manually, why do you feel that > it would be any different? You really do not understand some of this stuff, or at least are trying to appear not to. Ill give you the benefit of the doubt and say that it was not clearly phrased on my part. In the stored query case the CUA is expecting the CS to do some kind of query lookup internally (based on QUERYIDs and TARGETs), use that to find the proper data set for the command to work on and return the results. In the CUA query generated case, the CUA does not expect the CS to have to go find and them craft some query to use for the command; it generates the exact query it wanted to use. There is no needing for the CS to go get the query or parts of it from any other place in the CS so there are no problems like VCARs or non-existant QUERYIDs. In the former case there is potential for the CS to fail to find/craft the query that the CUA was expecting since there are things like VCARs, etc that now come into play for getting the query data separate from the data set the query is to work on. As such, the the CUA may not get the same results they expect because the effective query used by the CS may not be exactly what they intended. Couple with this the fact that there is no way for the CUA to distinguish between "I was unable to craft the query you requested to perform the command you sent" from "I was unable perform the command you sent' (see top) then it should be clear now that there is added complexity in using or relying on stored queries that is not currently clearly described in CAP. > All of your assertions above are unfounded and unsubstantiated. If you stil think so then perhaps we need to get an someone here who sees the difference described above and can see the issues when they are presented. > They have nothing to do with the text in CAP. Err, part of the issue is precisely that: there is NO text in CAP to deal with these things. This is yet another reason why stored queries need to be removed. All aspects of their use has not been fully designed or dealt with in CAP. > Those problems do not exist in any way that is different from non-stored > queries. Actually they do not. Go recheck the part related to issue 3 again... So, my proposal is still on the table: We remove all references to stored queries in CAP 1.0 and defer them to a followon draft when they can be properly designed to meet our original intent. So far the only disagreement on this proposal is yours. Anyone else? 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 0064911F85256D98_= Content-Type: text/html; charset="US-ASCII"
Doug wondered on 09/04/2003 03:47:59 PM:
> > For those frequently used querys like "What events are on my calendar
> > for XXX" or "What alarms trigger in the next 15 minutes" the CUA simply
> > does a Cscanf() of the correct inputs (XXX or the current date/time)
> > into a loaded query and then sends it.   Again, there is no 2 trips
> > across the wire for the query.
>
> NO ONE has proposed such a thing - who cares?
You have when you keep saying "2 trips on the wire" (paraphrased).  However I think you are misunderstanding something here: removing stored queries entirely means the CUA wont try to use them (trip 1), fail and then craft its own query (trip 2).  The CUA simply crafts the query and sends it (1 trip).

> > 1: Failure to find a particular QUERYID in a given TARGET,
>
> Why do you feel that would be any different to a query for a UID
> that did not exist? Its the component-ID tag. No such distinction
> exists.
Because there is a definite difference between "I cant find the query you wanted me to use to find those VEVENTS" and "I cant find those VEVENTS".  Both are errors but dealing with them is different.  See the difference now?

> > 2: The ability to specify multiple TARGETs in a VQUERY (ie: Do ALL
> > TARGETs have to have the QUERYID in it or just one or is it something
> > else?)
>
> Not sure which TARGET you mean:
Clearly not (or is this another tactic?).  In a VQUERY there can be one (or multiple) TARGET properties to tell the CS where to go look for the QUERYID (go recheck the ABNF in 9.6 if not with me still)

It is unspecified how a CS deals with finding/selecting/using the QUERYID in multiple TARGETs (those TARGETs you can put inside the VQUERY, not out side it at the command level).  Does it use the first one it finds only? All of them? All the CU has access to? Does any failure to find the QUERYID in any/all/some TARGET mean the command should be rejected or attempted anyway? Etc...

> > 3: How are failures to find/use the QUERYID distinguishded from other
> > command failures (ie: The SEARCH failed because you cant see/find/use
> > the QUERYID in a TARGET vs the SEARCH failed because you cant access the
> > TARGET vs the SEARCH failed because you only can read stored queries but
> > not other data in a TARGET vs...?)
>
> As you can send the EXACT same query manually, why do you feel that
> it would be any different?
You really do not understand some of this stuff, or at least are trying to appear not to.  Ill give you the benefit of the doubt and say that it was not clearly phrased on my part.

In the stored query case the CUA is expecting the CS to do some kind of query lookup internally (based on QUERYIDs and TARGETs), use that to find the proper data set for the command to work on and return the results.

In the CUA query generated case, the CUA does not expect the CS to have to go find and them craft some query to use for the command; it generates the exact query it wanted to use.  There is no needing for the CS to go get the query or parts of it from any other place in the CS so there are no problems like VCARs or non-existant QUERYIDs.

In the former case there is potential for the CS to fail to find/craft the query that the CUA was expecting since there are things like VCARs, etc that now come into play for getting the query data separate from the data set the query is to work on.  As such, the the CUA may not get the same results they expect because the effective query used by the CS may not be exactly what they intended.

Couple with this the fact that there is no way for the CUA to distinguish between "I was unable to craft the query you requested to perform the command you sent" from "I was unable perform the command you sent' (see top) then it should be clear now that there is added complexity in using or relying on stored queries that is not currently clearly described in CAP.

> All of your assertions above are unfounded and unsubstantiated.
If you stil think so then perhaps we need to get an someone here who sees the difference described above and can see the issues when they are presented.

>                             They have nothing to do with the text in CAP.
Err, part of the issue is precisely that: there is NO text in CAP to deal with these things.  This is yet another reason why stored queries need to be removed.  All aspects of their use has not been fully designed or dealt with in CAP.

> Those problems do not exist in any way that is different from non-stored
> queries.
Actually they do not.  Go recheck the part related to issue 3 again...

So, my proposal is still on the table: We remove all references to stored queries in CAP 1.0 and defer them to a followon draft when they can be properly designed to meet our original intent.

So far the only disagreement on this proposal is yours.  Anyone else?

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 0064911F85256D98_=-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 14:55:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12217 for ; Fri, 5 Sep 2003 14:55:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Id8gc056360 for ; Fri, 5 Sep 2003 11:39:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85Id8KG056359 for ietf-calendar-bks; Fri, 5 Sep 2003 11:39:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Id8gc056348 for ; Fri, 5 Sep 2003 11:39:08 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F579866.1050902@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12 - interm version 'A' MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 5 Sep 2003 14:37:37 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 02:40:29 PM, Serialize complete at 09/05/2003 02:40:29 PM Content-Type: multipart/alternative; boundary="=_alternative 006649B785256D98_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006649B785256D98_= Content-Type: text/plain; charset="US-ASCII" Doug noted on 09/04/2003 03:54:14 PM: > No, the instructions say: > > Use single spaced text within a paragraph, and one blank line > between paragraphs. > > I have been told that also means you can not have two spaces after a > period using the new interpretations. Then how come not all text was changed like this? I think you misundertood the text above from RFC 2223. I think they are talking about not using LWSP to format text inside of paragraphs, not actually formatting them using normal English punctionation and spacing rules. After all, _that_ RFC uses 2 spaces after a period... Also, I just checked the currenty RFC guidelines doc at ftp://ftp.ietf.org/ietf/1id-guidelines.txt and it has no such text. This is the direct link off the RFC Editors site and its dated 5-Sep-2002 (well after RFC 2223, Oct 1997). I found the boilerplate and it clearly shows 2 spaces so unless they forgot to update the guidelines the RFC Editors site (a possibility) then you got incorrect instructions. Heres the current boilerplate I found: The following verbatim statement must follow the optional opening sentence: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." I also looked at "Instructions to Request for Comments (RFC) Authors" ( draft-rfc-editor-rfc2223bis-06.txt, Obsoletes RFC 2223, ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt ) and it definitely contradicts the sentence you cited: (7) Spaces at the End of a Sentence When a sentence ended by a period is immediately followed by another sentence, there should be two blank spaces after the period. This rule provides clarity when an RFC is displayed or printed with a fixed-width font. So Im guessing you just misunderstood the intent of that single line in RFC 2223. Can we get a 12-b with the normal 2 spaces back (so there will be far fewer LWSP diffs!)?? 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 006649B785256D98_= Content-Type: text/html; charset="US-ASCII"
Doug noted on 09/04/2003 03:54:14 PM:
> No, the instructions say:
>
>        Use single spaced text within a paragraph, and one blank line
>        between paragraphs.
>
> I have been told that also means you can not have two spaces after a
> period using the new interpretations.
Then how come not all text was changed like this?  

I think you misundertood the text above from RFC 2223.  I think they are talking about not using LWSP to format text inside of paragraphs, not actually formatting them using normal English punctionation and spacing rules.  After all, _that_ RFC uses 2 spaces after a period...

Also, I just checked the currenty RFC guidelines doc at ftp://ftp.ietf.org/ietf/1id-guidelines.txt and it has no such text.  This is the direct link off the RFC Editors site and its dated 5-Sep-2002 (well after RFC 2223, Oct 1997).  I found the boilerplate and it clearly shows 2 spaces so unless they forgot to update the guidelines the RFC Editors site (a possibility) then you got incorrect instructions.  Heres the current boilerplate I found:

The following verbatim statement must follow the optional opening
sentence:

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
    Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-
    Drafts as reference material or to cite them other than as
    "work in progress."

I also looked at "Instructions to Request for Comments (RFC) Authors" (draft-rfc-editor-rfc2223bis-06.txt, Obsoletes RFC 2223, ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt ) and it definitely contradicts the sentence you cited:

       (7) Spaces at the End of a Sentence

          When a sentence ended by a period is immediately followed by
          another sentence, there should be two blank spaces after the
          period.  This rule provides clarity when an RFC is displayed
          or printed with a fixed-width font.

So Im guessing you just misunderstood the intent of that single line in RFC 2223.  Can we get a 12-b with the normal 2 spaces back (so there will be far fewer LWSP diffs!)??

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 006649B785256D98_=-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 14:57:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12274 for ; Fri, 5 Sep 2003 14:57:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IhWgc056581 for ; Fri, 5 Sep 2003 11:43:32 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85IhW3f056580 for ietf-calendar-bks; Fri, 5 Sep 2003 11:43:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IhWgc056564 for ; Fri, 5 Sep 2003 11:43:32 -0700 (PDT) (envelope-from george.babics@oracle.com) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail3.oracle.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h85IhS0o026995 for ; Fri, 5 Sep 2003 11:43:28 -0700 (PDT) Received: from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h85IhRZ06375 for ; Fri, 5 Sep 2003 12:43:27 -0600 (MDT) Received: from oracle.com (c-0000.ca.oracle.com [144.23.213.222]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h85IhQZ06346 for ; Fri, 5 Sep 2003 12:43:26 -0600 (MDT) Message-ID: <3F58D895.4010202@oracle.com> Date: Fri, 05 Sep 2003 14:40:21 -0400 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: <3F575F1A.5040301@Royer.com> In-Reply-To: <3F575F1A.5040301@Royer.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 Doug Royer wrote: > > ... > >> The intent of stored queries was to make it easier for 'thin' clients >> to keep smaller footprints by allowing them to not have to (re)craft >> commonly used queries again and again; they relied on the CS to keep >> the query and involk it when the CUA needed it. This is a great >> concept but we failed to design our query language to allow for it to >> be _actually_ useful. > > > You keep (re)stating the obvious - however I find the queries useful > as did CS&T. So did John. > ... Oracle (formerly Steltor, which used to be CS&T) does not find them useful. I had a quick look at the archives and I believe that John also did not think that they were needed. George From owner-ietf-calendar@mail.imc.org Fri Sep 5 15:06:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13008 for ; Fri, 5 Sep 2003 15:06:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Io1gc056917 for ; Fri, 5 Sep 2003 11:50:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85Io04X056916 for ietf-calendar-bks; Fri, 5 Sep 2003 11:50:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Io0gc056905 for ; Fri, 5 Sep 2003 11:50:00 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F579B4E.1090108@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 5 Sep 2003 14:44:37 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 02:51:20 PM, Serialize complete at 09/05/2003 02:51:20 PM Content-Type: multipart/alternative; boundary="=_alternative 0066EE0685256D98_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066EE0685256D98_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 09/04/2003 04:06:38 PM: > Okay - I want to do what is stored in a component with > a QUERYID tag of 'XXX' as set by my configureation tool > on my cell phone. Err, QUERYID is only on queries to identify them. Its not specified to be on other components so you must be still thinking of stored queries. If we dont have stored queries then you wont be looking for it in the CS, the CUA will be the one generating it as it needs it using something akin to my pseudocode from before. Hence, no 2 trips... > Please show me the VQUERY component that your CUA will send. Go recheck that psuedocode. The CUA crafts the proper query itself and sends it. There is NO way around it if the CUA wants to find "Any alarms that trigger in the next 15 minutes", etc. > Your going to have to (1) fetch XXX, then (2) submit it. > That is 2 round trips. Slowly in... Slowly out... The does NOT do attempt to go find any stored query in the CS using QUERYID:XXX, pull it down and then resend it. You are missing the entire proposal. There are no more stored queries. This means then that the CUA simply generates the correct query (since the CS cant do it anyway!) and sends it. That means 1 trip, not 2. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 0066EE0685256D98_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 09/04/2003 04:06:38 PM:
> Okay - I want to do what is stored in a component with
> a QUERYID tag of 'XXX' as set by my configureation tool
> on my cell phone.
Err, QUERYID is only on queries to identify them.  Its not specified to be on other components so you must be still thinking of stored queries.  If we dont have stored queries then you wont be looking for it in the CS, the CUA will be the one generating it as it needs it using something akin to my pseudocode from before.  Hence, no 2 trips...

> Please show me the VQUERY component that your CUA will send.
Go recheck that psuedocode.  The CUA crafts the proper query itself and sends it.  There is NO way around it if the CUA wants to find "Any alarms that trigger in the next 15 minutes", etc.

> Your going to have to (1) fetch XXX, then (2) submit it.
> That is 2 round trips.
Slowly in... Slowly out...

The does NOT do attempt to go find any stored query in the CS using QUERYID:XXX, pull it down and then resend it.  You are missing the entire proposal.  There are no more stored queries.  This means then that the CUA simply generates the correct query (since the CS cant do it anyway!) and sends it.  That means 1 trip, not 2.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 0066EE0685256D98_=-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 15:15:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14040 for ; Fri, 5 Sep 2003 15:15:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85J1Ngc057476 for ; Fri, 5 Sep 2003 12:01:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85J1NnS057475 for ietf-calendar-bks; Fri, 5 Sep 2003 12:01:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85J1Mgc057468 for ; Fri, 5 Sep 2003 12:01:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h85J1LS5019399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 5 Sep 2003 12:01:23 -0700 Message-ID: <3F58DD7C.1090108@Royer.com> Date: Fri, 05 Sep 2003 13:01:16 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: stored queries References: <5.2.1.1.0.20030905062303.00a19370@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20030905062303.00a19370@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040102060206030303010505" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040102060206030303010505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit There are really (3) issues: (A) Can you store a VQUERY in CAP? (B) Can you fetch a VQUERY in CAP? (C) Can you tell a CS to auto-execute a stored query? Others? Everyone knows my opinion on these three, yours? Tim Hare wrote: > > I may be muddying the water here, I am about to leave on un-connected > travel, so I hate to start a discussion since I don't have time to > search RFC2445 for details until Monday, but this occurred to me this > morning and so I submit it to the group. > > RFC2445 allows for x-comp and iana-comp in 4.6. This allows any CS / > CUA that wants to to support stored queries as x-comp members within the > CS unless I'm overlooking something else (see above for time shortage). > > I propose that we drop all stored query items from CAP (and for that > matter iTIP / iMIP and any other CUA protocols). Any implementation > which wants to do so can support them via the x-comp facility. It looks > to me as though you can still search for the objects with VQUERY. > > The X- stands for 'experimental', so this would allow us to wait until > some "real world" experience has developed around stored queries before > we make it a non-experimental part of the RFC; it also removes the > burden (from us) of figuring out the CAP handling of such items in > detail, moving the CAP closer to being done. > > Tim Hare > interested bystander, non-inc. > -- 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 --------------ms040102060206030303010505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTA1MTkwMTE2WjAjBgkqhkiG9w0BCQQxFgQUCmVspBXLzlxItk2H/TLk qi5EgcUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEArON7Sj9xBac213rMM4uPzdx/mMLM2r6oUxO0O+X/7jp698Z6S2pZ2AexyPIljphd o+4bTjNdSF9kDLdGu1Opk4oDGuYTT5Rfhezhh+3sUIjvD55upll1Ap1gQRvacj8TmDvARisA EkNIIlGsrOUQIuDG9N0YOQK6nBVk7wIv47S+UbxLcqGwFkSWb6xDkobA519OWlkfa4MiR+E7 Le42clSX1PONw6bLC2Xu5wTYsMzbwTbvgAbuF+YR715CxgesBgguUHhqCfJdarGiMWd2YIvs xBleDANPReO0WJCd7YN+Vl2NuQWhvY/kYZPHrWxSMUefEq3VcT6HdRSMp98e2wAAAAAAAA== --------------ms040102060206030303010505-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 15:15:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14092 for ; Fri, 5 Sep 2003 15:15:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Iw8gc057285 for ; Fri, 5 Sep 2003 11:58:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85Iw80l057284 for ietf-calendar-bks; Fri, 5 Sep 2003 11:58:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Iw7gc057278 for ; Fri, 5 Sep 2003 11:58:07 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: "Michael Fair" Cc: ietf-calendar@imc.org Subject: Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 5 Sep 2003 14:55:18 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 02:59:27 PM, Serialize complete at 09/05/2003 02:59:27 PM Content-Type: multipart/alternative; boundary="=_alternative 0067E88085256D98_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067E88085256D98_= Content-Type: text/plain; charset="US-ASCII" Michael replied on 09/04/2003 06:28:40 PM: > "Bad Recurrence-ID" needs to be expanded to include a fourth > possibility; that it has never seen neither the base UID nor > the RECURRENCE-ID before. Isn't that already covered by: If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. (factoring in Section 2.1.5 says that UID / RECURRENCE-ID are used in place of UID when dealing with recurring instances per Section 2.1.5)? > Somehow it needs to be made clear that every relevant reference > to "UID" throughout the document really means something more > along the lines of "primary key" which could include UID, > RECURRENCE-ID, and RANGE to accurately identify which events > are being referred to. Much of the confusion here has been > as a result of interpretting "UID" to not mean all of those. Ok, so some text added to 2.1.5 to this effect (expanding on bullet 1's meaning) would be useful? > Making it clear that when canceling an event for a particular > user the SEQUENCE value should not be incremented (or at least > more discussion on what it should do). While this is a good change, exactly how to do it is another matter. The problem is that this change is that it will effect all implementations already out there that follow that text from Section 2.1.4. Just making the change could mean interoperability issues w/existing implementations and no way to detect 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 0067E88085256D98_= Content-Type: text/html; charset="US-ASCII"
Michael replied on 09/04/2003 06:28:40 PM:
> "Bad Recurrence-ID" needs to be expanded to include a fourth
> possibility; that it has never seen neither the base UID nor
> the RECURRENCE-ID before.
Isn't that already covered by:

                                 If the "UID" property value in
  the "REQUEST" is not found on the recipient's calendar, then the
  "REQUEST" is for a new "VEVENT" calendar component.

(factoring in Section 2.1.5 says that UID / RECURRENCE-ID are used in place of UID when dealing with recurring instances per Section 2.1.5)?  

> Somehow it needs to be made clear that every relevant reference
> to "UID" throughout the document really means something more
> along the lines of "primary key" which could include UID,
> RECURRENCE-ID, and RANGE to accurately identify which events
> are being referred to.  Much of the confusion here has been
> as a result of interpretting "UID" to not mean all of those.
Ok, so some text added to 2.1.5 to this effect (expanding on bullet 1's meaning) would be useful?  

> Making it clear that when canceling an event for a particular
> user the SEQUENCE value should not be incremented (or at least
> more discussion on what it should do).
While this is a good change, exactly how to do it is another matter.  The problem is that this change is that it will effect all implementations already out there that follow that text from Section 2.1.4.  Just making the change could mean interoperability issues w/existing implementations and no way to detect 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 0067E88085256D98_=-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 15:17:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14224 for ; Fri, 5 Sep 2003 15:17:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85J2Qgc057526 for ; Fri, 5 Sep 2003 12:02:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85J2Qtj057525 for ietf-calendar-bks; Fri, 5 Sep 2003 12:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85J2Ogc057517 for ; Fri, 5 Sep 2003 12:02:24 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h85J2OS5019409 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 5 Sep 2003 12:02:25 -0700 Message-ID: <3F58DDBA.3060309@Royer.com> Date: Fri, 05 Sep 2003 13:02:18 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: Re: CAP-12-a: Stored queries still?] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020800040709080207000908" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020800040709080207000908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wondered on 09/04/2003 03:47:59 PM: > > > For those frequently used querys like "What events are on my calendar > > > for XXX" or "What alarms trigger in the next 15 minutes" the CUA > simply > > > does a Cscanf() of the correct inputs (XXX or the current date/time) > > > into a loaded query and then sends it. Again, there is no 2 trips > > > across the wire for the query. > > > > NO ONE has proposed such a thing - who cares? > > You have when you keep saying "2 trips on the wire" (paraphrased). > However I think you are misunderstanding something here: removing > stored queries entirely means the CUA wont try to use them (trip 1), > fail and then craft its own query (trip 2). The CUA simply crafts the > query and sends it (1 trip). And you keep failing to reply to the example - why? -- 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 --------------ms020800040709080207000908 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTA1MTkwMjE4WjAjBgkqhkiG9w0BCQQxFgQUH4Xb0FQhjn2hPN6KHDTw KHEn33MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAT7cn6LODMvGQpOdffqqzPSPZ5Vx2i+I3p6rWikh9t1JZrTocmgx5J5X67ETIgmjL OIHR44Go28l9g0o9c7PyAeTKNikc/jcvRNKDOsKbOEjRouTu+mxkWWtoaupjKwCxaKTtaZNY dVtQNt+9sZoHjDvxQBoCk733OdQKXBubljAQQ+Hq2XNvgtXU7nhOO2sq91M21FBlRWDZXYjI z/9wBMVLroBlkKIkHQJLVrozkzq3v+Owf2Xf2xea5sxBiQY5nJGl/jha8+rhge4+kb9V+xJh M6/pB1BqVJ1w3pYdtHtGOTswr4hIOsp8yyuCgThmz1h3CE7Y+yYihoTJsbeBqAAAAAAAAA== --------------ms020800040709080207000908-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 15:37:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15109 for ; Fri, 5 Sep 2003 15:37:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85JJ8gc058546 for ; Fri, 5 Sep 2003 12:19:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85JJ83t058544 for ietf-calendar-bks; Fri, 5 Sep 2003 12:19:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85JJ8gc058533 for ; Fri, 5 Sep 2003 12:19:08 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F57EA66.6030904@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 5 Sep 2003 15:06:55 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 03:20:27 PM, Serialize complete at 09/05/2003 03:20:27 PM Content-Type: multipart/alternative; boundary="=_alternative 0068F8C385256D98_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068F8C385256D98_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 09/04/2003 09:44:06 PM: > > > I told you and Ned in San Francisco that > > > I was going to oppose ANY AND ALL changes to CAP so that we can get > > it out. > > > > If you are simply opposing any and all proposals made to fix CAP in an > > effort to get it shipped rather than actually considering them then > > there is something very wrong here. > > Removal of something that has been in CAP for YEARS is not a typo. > You have no right to assert that I have not considered them. You practically said as much when you wrote "I was going to oppose ANY AND ALL changes to CAP so that we can get it out.". Thats your direct quote yes? > Your assertion is that it does not meet what you (and others) feel > was what ever the original needs were. If you want to whine and nit pick over the original intent of stored queries then I'll just the attempt. You tacitly agreed to the intent I described in earlier emails and now you are trying to dispute them. Go ahead. If anyone bothers to check previous discussions on stored queries (including the thread of ~Jan/Feb/Mar 2002 where we wanted to simplify the query lingua) they will see you using PDAs and Cell phones as part of the discussion. Stored queries have some use now but they are far short of what we originally intended. The proposal to remove them is still on the table and so far the ONLY objection to it is you; the avowed change opposing editor. > The typos are getting fixed and the word smithing as you called > it are being done because of thousands WG and private emails. Thousands? I somehow doubt it. I know the ones I sent (for CAP-10 mind you) and Ive seen the 2 pages from others in Bugzilla and the list. Are you saying that after 10+ versions (CAP-10 had 4+ versions alone!) we still have "thousands" of typos. Ahh, hehehe. Must be some attempt at levity... > If you have a list of bugs, compatibility issues - please post it. Ive done that 3 times now. If you cant see them then either get glasses or get someone to help you. 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 0068F8C385256D98_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 09/04/2003 09:44:06 PM:
> >  >                         I told you and Ned in San Francisco that
> >  > I was going to oppose ANY AND ALL changes to CAP so that we can get
> > it out.
> >
> > If you are simply opposing any and all proposals made to fix CAP in an
> > effort to get it shipped rather than actually considering them then
> > there is something very wrong here.  
>
> Removal of something that has been in CAP for YEARS is not a typo.
> You have no right to assert that I have not considered them.
You practically said as much when you wrote "I was going to oppose ANY AND ALL changes to CAP so that we can get it out.".  Thats your direct quote yes?

> Your assertion is that it does not meet what you (and others) feel
> was what ever the original needs were.
If you want to whine and nit pick over the original intent of stored queries then I'll just the attempt.  You tacitly agreed to the intent I described in earlier emails and now you are trying to dispute them.  Go ahead.  If anyone bothers to check previous discussions on stored queries (including the thread of ~Jan/Feb/Mar 2002 where we wanted to simplify the query lingua) they will see you using PDAs and Cell phones as part of the discussion.

Stored queries have some use now but they are far short of what we originally intended.  The proposal to remove them is still on the table and so far the ONLY objection to it is you; the avowed change opposing editor.

> The typos are getting fixed and the word smithing as you called
> it are being done because of thousands WG and private emails.
Thousands?  I somehow doubt it.  I know the ones I sent (for CAP-10 mind you) and Ive seen the 2 pages from others in Bugzilla and the list.  Are you saying that after 10+ versions (CAP-10 had 4+ versions alone!) we still have "thousands" of typos.  Ahh, hehehe.  Must be some attempt at levity...

> If you have a list of bugs, compatibility issues - please post it.
Ive done that 3 times now.  If you cant see them then either get glasses or get someone to help you.

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 0068F8C385256D98_=-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 15:53:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15720 for ; Fri, 5 Sep 2003 15:53:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85JXjgc059534 for ; Fri, 5 Sep 2003 12:33:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85JXjMG059533 for ietf-calendar-bks; Fri, 5 Sep 2003 12:33:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85JXigc059519 for ; Fri, 5 Sep 2003 12:33:44 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F57EE0E.2030909@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 5 Sep 2003 15:33:36 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/05/2003 03:35:03 PM, Serialize complete at 09/05/2003 03:35:03 PM Content-Type: multipart/alternative; boundary="=_alternative 006B69E585256D98_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B69E585256D98_= Content-Type: text/plain; charset="US-ASCII" Doug seemed confused on 09/04/2003 09:59:42 PM: > > > Go re-read Bruces email and tell me if he has posted even ONE post > > > that backs up (some in recent posts); > > > > > > (a) ...I certainly dont recall any WG discussion on some of the bigger > > > issues ... > > > > Please point to the WG thread(s) where we discussed and resolved the > > issue of scoping on SEARCH? > > Go re-read my post (a) was not about SEARCH. It was was in response > to the text you sent. Your mis quoting me again. Hello! McFly!! Your (a) was a citation from one of my emails and your charge was I didnt describe "bigger issues" I was referring to. I did that. I listed 3 even (of which you only how include 1)! > > > (b) ...Im more than a bit concerned that there are changes that creep > > > (additions or omissions) that should not. ... > > > > diff reports 707 changes between CAP-10 and CAP-12-a. Not some custom > > tool; generic diff. If I remove the TOC (1 big difference) and the ~140 > > headers/footers that leaves ~565 other changes of _some_ kind. If we > > were not discussing CAP issues over the past month or two, just where > > did all these changes come from? Some are pure whitespace but others > > are NOT. Either there were LOTS and LOTS of typos or grammar errors or > > changs were made. > > Your own assertions above conclude that you still do not know. Why > are you posting there is a problem and in the same post declaring > you did not know if there is a problem - whitespace inside of paragraphs? INCONSISTANT whitespace changes inside the text (contrary to the actual RFC Authors guidelines even!). NOT every sentence after a period was 1 blank instead of 2. So clearly it was not a consitant change done by the tool or the editor. (b) is a concern that there is a problem w/the editor and/or his tools given the inconsistancy of the changes (among other changes) between CAP-10-17-FEB-03 and CAP-12-a. My info about diff (an IETF standard tool) reveals all kinds of changes and with no consistantcy to them. This is cause for concern (plus the fact your XML tool admittedly losses content). If it does not concern you then Id be even more concerned about you being sole editor of CAP now. > There are lots of changes because there were lots of changes including > formatting of the text. Why are you reformatting the draft? It only makes the process of finding changes HARDER, not easier. Is that another goal you have? > > The TOC for CAP-12-a says there are 7 fewer pages. Unless you did some > > unusual reformatting there is no way typos and small grammar changes can > > account for this! Combine this with the results from diff and its easy > > to call changes into question (especially given your reticence to > > provide a summary of the changes yet you have time to spin out several > > extra CAP related drafts). > > The 7 pages concerned me also. So looking at YOUR diff that Pat has hosted. > I found the answer in less than a minute. Your questions are answered > in your own diff. Of course, you say there is an answer but you wont provide it. Typical. You did that for all discussion over the past 4 months. "I dont have to prove anything." (loosely paraphrased). Well in the IETF if you cant back up your statements then but the other folks can then yours dont hold much water... > > Umm, which version of CAP-10 was this? We had several in Dec/Jan/Feb. > > > You clearly missed the issue of stored queries that was in active > > discussion in Nov/Dec 2002 under the thread "What good are stored > > VQUERYs?" of which you were a participant even. > > And no consensus was called. So it is an issue then... Funny, you didnt list that a known one when you tried to go to Last Call over the summer. > > You also missed the scoping issue from the thread "How do you get the > > METHOD property on a SEARCH" in April 2003. > > It was covered on the WG list. If you do not like what it does, > do you have a proposal? It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately. > > You also did not cover the issue of busy time > > creation/searching/updating that I raised under "CAP & busytime?" in > > March 2003 and "CAP / Busytime Restart" in April 2003. > > Did it reach consensus? I did not see it called. I made a proposal and you did not disagree. In fact noone did so I would say that we did reach concensus. Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12. > > Oh yeah, if that went into CAP-11 then what was the need for a CAP-12 > > and CAP-12-a so soon after CAP-11?? > > To post the changes so people could see what changed. Minor typo fixes rarely call for an entirely new version so soon. After all we had 4+ versions of CAP-10 and we've already had 2 versions of CAP-12. > > > The only other things that changed were formatting issues and fixes > > > as a result in a bug in xml2rfc that for some reason left out > > > about 3 sentences and did some odd formatting. > > > > Then why are there so many whitespace changes unrelated to anything > > else? The boilerplate text alone had more than just 1 change in > > whitespace: > > As covered in the previous email. Please read the instructions > to RFC authors and RFC 2223. 2 things: 1: You clearly misunderstood that 1 line in RFC 2223. Had you actually read RFC 2223 you would have seen that _it_ uses 2 spaces after a period so thats not what that 1 sentence meant. Also, the current RFC Authors guidelines clearly has boilerplate in it that has 2 spaces after a period. Furthermore if you read the "Instructions to RFC Authors" ( ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt) from the RFC Editors site you would clearly see: (7) Spaces at the End of a Sentence When a sentence ended by a period is immediately followed by another sentence, there should be two blank spaces after the period. This rule provides clarity when an RFC is displayed or printed with a fixed-width font. 2: Not every sentence in CAP-12-a was changed to have 1 space after the period; only some. This is clear from just just searching for ". " so either you didnt check to see that it got changed uniformly or the changes were dont seemingly at random in an attempt to make finding actual changes harder. Ill give you the benefit of the doubt again and say the former... Now for CAP-12-b please follow the guidelines above and restore the spacing. > > You want facts Ill give you some to consider in questioning Dougs motives: > > > (Your non-productive comments and personal opinions deleted. And I did > not sort through them to see if there was anything useful). Of course not. That would mean you'd have to acutally read the contents of posting of someone who wont back down from you on the list. Given all those separate facts (that you didnt read) its not hard to see why your motives could be called into question. You may not like it but thats just how I interpret the actions I see. 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 006B69E585256D98_= Content-Type: text/html; charset="US-ASCII"
Doug seemed confused on 09/04/2003 09:59:42 PM:
> >  > Go re-read Bruces email and tell me if he has posted even ONE post
> >  > that backs up (some in recent posts);
> >  >
> >  > (a)   ...I certainly dont recall any WG discussion on some of the bigger
> >  >       issues ...
> >
> > Please point to the WG thread(s) where we discussed and resolved the
> > issue of scoping on SEARCH?
>
> Go re-read my post (a) was not about SEARCH. It was was in response
> to the text you sent. Your mis quoting me again.
Hello!  McFly!!  Your (a) was a citation from one of my emails and your charge was I didnt describe "bigger issues" I was referring to.  I did that.  I listed 3 even (of which you only how include 1)!

> >  > (b)   ...Im more than a bit concerned that there are changes that creep
> >  >      (additions or omissions) that should not. ...
> >
> > diff reports 707 changes between CAP-10 and CAP-12-a.  Not some custom
> > tool; generic diff.  If I remove the TOC (1 big difference) and the ~140
> > headers/footers that leaves ~565 other changes of _some_ kind.  If we
> > were not discussing CAP issues over the past month or two, just where
> > did all these changes come from?  Some are pure whitespace but others
> > are NOT.  Either there were LOTS and LOTS of typos or grammar errors or
> > changs were made.
>
> Your own assertions above conclude that you still do not know. Why
> are you posting there is a problem and in the same post declaring
> you did not know if there is a problem - whitespace inside of paragraphs?
INCONSISTANT whitespace changes inside the text (contrary to the actual RFC Authors guidelines even!).  NOT every sentence after a period was 1 blank instead of 2.  So clearly it was not a consitant change done by the tool or the editor.

(b) is a concern that there is a problem w/the editor and/or his tools given the inconsistancy of the changes (among other changes) between CAP-10-17-FEB-03 and CAP-12-a.  My info about diff (an IETF standard tool) reveals all kinds of changes and with no consistantcy to them.  This is cause for concern (plus the fact your XML tool admittedly losses content).  If it does not concern you then Id be even more concerned about you being sole editor of CAP now.

> There are lots of changes because there were lots of changes including
> formatting of the text.
Why are you reformatting the draft?  It only makes the process of finding changes HARDER, not easier.  Is that another goal you have?

> > The TOC for CAP-12-a says there are 7 fewer pages.  Unless you did some
> > unusual reformatting there is no way typos and small grammar changes can
> > account for this!  Combine this with the results from diff and its easy
> > to call changes into question (especially given your reticence to
> > provide a summary of the changes yet you have time to spin out several
> > extra CAP related drafts).
>
> The 7 pages concerned me also. So looking at YOUR diff that Pat has hosted.
> I found the answer in less than a minute. Your questions are answered
> in your own diff.
Of course, you say there is an answer but you wont provide it.  Typical.  You did that for all discussion over the past 4 months.  "I dont have to prove anything." (loosely paraphrased).  Well in the IETF if you cant back up your statements then but the other folks can then yours dont hold much water...

> > Umm, which version of CAP-10 was this?  We had several in Dec/Jan/Feb.  
>
> > You clearly missed the issue of stored queries that was in active
> > discussion in Nov/Dec 2002 under the thread "What good are stored
> > VQUERYs?" of which you were a participant even.
>
> And no consensus was called.
So it is an issue then...  Funny, you didnt list that a known one when you tried to go to Last Call over the summer.

> > You also missed the scoping issue from the thread "How do you get the
> > METHOD property on a SEARCH" in April 2003.
>
> It was covered on the WG list. If you do not like what it does,
> do you have a proposal?
It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately.

> > You also did not cover the issue of busy time
> > creation/searching/updating that I raised under "CAP & busytime?" in
> > March 2003 and "CAP / Busytime Restart" in April 2003.
>
> Did it reach consensus? I did not see it called.
I made a proposal and you did not disagree.  In fact noone did so I would say that we did reach concensus.  Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12.

> > Oh yeah, if that went into CAP-11 then what was the need for a CAP-12
> > and CAP-12-a so soon after CAP-11??
>
> To post the changes so people could see what changed.
Minor typo fixes rarely call for an entirely new version so soon.  After all we had 4+ versions of CAP-10 and we've already had 2 versions of CAP-12.

> >  > The only other things that changed were formatting issues and fixes
> >  > as a result in a bug in xml2rfc that for some reason left out
> >  > about 3 sentences and did some odd formatting.
> >
> > Then why are there so many whitespace changes unrelated to anything
> > else?  The boilerplate text alone had more than just 1 change in
> > whitespace:
>
> As covered in the previous email. Please read the instructions
> to RFC authors and RFC 2223.
2 things:

1: You clearly misunderstood that 1 line in RFC 2223.  Had you actually read RFC 2223 you would have seen that _it_ uses 2 spaces after a period so thats not what that 1 sentence meant.  Also, the current RFC Authors guidelines clearly has boilerplate in it that has 2 spaces after a period.  Furthermore if you read the "Instructions to RFC Authors" (ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt) from the RFC Editors site you would clearly see:

       (7) Spaces at the End of a Sentence

          When a sentence ended by a period is immediately followed by
          another sentence, there should be two blank spaces after the
          period.  This rule provides clarity when an RFC is displayed
          or printed with a fixed-width font.

2: Not every sentence in CAP-12-a was changed to have 1 space after the period; only some.  This is clear from just just searching for ".  " so either you didnt check to see that it got changed uniformly or the changes were dont seemingly at random in an attempt to make finding actual changes harder.  Ill give you the benefit of the doubt again and say the former...  Now for CAP-12-b please follow the guidelines above and restore the spacing.

> > You want facts Ill give you some to consider in questioning Dougs motives:
> >
> (Your non-productive comments and personal opinions deleted. And I did
> not sort through them to see if there was anything useful).
Of course not.  That would mean you'd have to acutally read the contents of posting of someone who wont back down from you on the list.  Given all those separate facts (that you didnt read) its not hard to see why your motives could be called into question.  You may not like it but thats just how I interpret the actions I see.

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 006B69E585256D98_=-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 16:17:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16585 for ; Fri, 5 Sep 2003 16:17:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85K2Kgc060820 for ; Fri, 5 Sep 2003 13:02:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85K2KDK060818 for ietf-calendar-bks; Fri, 5 Sep 2003 13:02:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85K2Jgc060813 for ; Fri, 5 Sep 2003 13:02:19 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h85K2IS5020045 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 5 Sep 2003 13:02:20 -0700 Message-ID: <3F58EBC5.3070000@Royer.com> Date: Fri, 05 Sep 2003 14:02:13 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000907080807020808020602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000907080807020808020602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 09/04/2003 09:44:06 PM: > > > > I told you and Ned in San Francisco that > > > > I was going to oppose ANY AND ALL changes to CAP so that we can get > > > it out. > > > > > > If you are simply opposing any and all proposals made to fix CAP in an > > > effort to get it shipped rather than actually considering them then > > > there is something very wrong here. > > > > Removal of something that has been in CAP for YEARS is not a typo. > > You have no right to assert that I have not considered them. > > You practically said as much when you wrote "I was going to oppose ANY > AND ALL changes to CAP so that we can get it out.". Thats your direct > quote yes? Do you see the word TYPO in that? -- 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 --------------ms000907080807020808020602 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTA1MjAwMjEzWjAjBgkqhkiG9w0BCQQxFgQU+jC46DAOjQX51pN5mbwM Dw+r06kwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEApqCIRvHFSy/NSD8cvlT5nGBqg4m5ibt0l+mLvt5sDNgOVgvvHB0/w8LGKCl0Z3IJ Tr9EgKCiZiq17LghbIUMJgncGRXogcZUwgngGvoSyTG5XTiW4VaTHcK+e0FutJLhQz8LS/u4 c+87oP20Tn+VpuFeImH5Z6fV2R8Dv9sFGVLfqRM5gRhPA7CL47qAaOJLemThjXpkzP+JwC7D PkUJvsz0jzP4dP0Qqnxk/RqBLLvZy5jQUM656BYUI/YIUd9C8BaPOgvCGJhX+Fmlb5HVB4Mi GyzeJ+J8Fm2KF7QFAoZFmsDHYPyF6pa9OFT93JAaIE//osMMXAGhK5UbpQQWcAAAAAAAAA== --------------ms000907080807020808020602-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 16:18:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16685 for ; Fri, 5 Sep 2003 16:18:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85K0Zgc060717 for ; Fri, 5 Sep 2003 13:00:35 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85K0Zmv060716 for ietf-calendar-bks; Fri, 5 Sep 2003 13:00:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85K0Wgc060709 for ; Fri, 5 Sep 2003 13:00:34 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h85K0TS5020009 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 5 Sep 2003 13:00:30 -0700 Message-ID: <3F58EB57.8090904@Royer.com> Date: Fri, 05 Sep 2003 14:00:23 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020406070209000702070202" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020406070209000702070202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug noted on 09/04/2003 03:54:14 PM: > > No, the instructions say: > > > > Use single spaced text within a paragraph, and one blank line > > between paragraphs. > > > > I have been told that also means you can not have two spaces after a > > period using the new interpretations. > > Then how come not all text was changed like this? Not done. > I think you misundertood the text above from RFC 2223. I think they are > talking about not using LWSP to format text inside of paragraphs, not > actually formatting them using normal English punctionation and spacing > rules. After all, _that_ RFC uses 2 spaces after a period... 1) A draft does not obsolete an RFC until it is released. 2) It does look as if that is the new direction. 3) The draft is at -07 (not -06). -- 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 --------------ms020406070209000702070202 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTA1MjAwMDIzWjAjBgkqhkiG9w0BCQQxFgQURfYDz/uyKdlLRCyO+oyO Dez/P40wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAewm0fE4TIdYVBFL8RBfhOCCyZWkxkRCml49U+42ZwvFFXhoV36cHd8p6ctk6fbom g6FcgP9QVDjIUVE4wItaUNo/p2LyC6oWSwq33t3hyUnwCyiEifPnq+Dn3uVpMY90b1dfsiLd l0T6+jgg0Ft9jRRKsDBYalkn0GqbaabksSEHjmanFu0BmbNf10X1X2RUem1w4dzO+o96z4ZB g+769KpN0rHqdIxEwxWFafCSTNUa8wOvHHjDFTmW7tSLvwBiqJN3ad4uqWnVedthZlDx5FzQ HTeuqq/KK9iySKx30ss7DCkIyLz0ppF2pfVTpW7iDAZ+Gb0Fa/oBMGSHDb8PgQAAAAAAAA== --------------ms020406070209000702070202-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 16:18:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16701 for ; Fri, 5 Sep 2003 16:18:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85K4Vgc060956 for ; Fri, 5 Sep 2003 13:04:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85K4VN6060955 for ietf-calendar-bks; Fri, 5 Sep 2003 13:04:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85K4Ugc060949 for ; Fri, 5 Sep 2003 13:04:30 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h85K3tS5020055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 5 Sep 2003 13:03:57 -0700 Message-ID: <3F58EC26.5020703@Royer.com> Date: Fri, 05 Sep 2003 14:03:50 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010804030906020103040504" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010804030906020103040504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug seemed confused on 09/04/2003 09:59:42 PM: > > > > Go re-read Bruces email and tell me if he has posted even ONE post > > > > that backs up (some in recent posts); > > > > > > > > (a) ...I certainly dont recall any WG discussion on some of > the bigger > > > > issues ... > > > > > > Please point to the WG thread(s) where we discussed and resolved the > > > issue of scoping on SEARCH? > > > > Go re-read my post (a) was not about SEARCH. It was was in response > > to the text you sent. Your mis quoting me again. > > Hello! McFly!! I am deleting the rest of your email - unread. Learn manners. -- 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 --------------ms010804030906020103040504 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTA1MjAwMzUwWjAjBgkqhkiG9w0BCQQxFgQU7llG0eL+ggwRVkEvMMG9 1AzgQbgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAZ9MpHfEB7NO2LigMGtQB8kv9ySghQIEKo7ucf/o9lNDt+s4GNcQCGbW97RprblIa 9B6otTd0fIEUsh0xUkZhHfjO/17XQhZm6E7yhed7zlTc1VX/1RbRpzgNO1h+/eIZk5/qdRKG +wRS+gcYDaSiihJjyt8TugtflILqkA7+HeW5gBFO5cTO96uXuCRnBTK3Kzn3aRjGLNrdevGx sA+g+/KBfEUW0W15AEWp7uakrvyybUQNl4j2GL9S9RoIYpNeZhYTzCZNVBNWe3S6Bthjb/0Y yJ0RjHgZNOw8Yr9bxyUNegbOpWo0Y0meXes6hhY9pJMCQzyBWupwXGVJL1m9KgAAAAAAAA== --------------ms010804030906020103040504-- From owner-ietf-calendar@mail.imc.org Fri Sep 5 16:36:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17708 for ; Fri, 5 Sep 2003 16:35:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85KLIgc062164 for ; Fri, 5 Sep 2003 13:21:18 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85KLIgP062163 for ietf-calendar-bks; Fri, 5 Sep 2003 13:21:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85KLFgc062145 for ; Fri, 5 Sep 2003 13:21:15 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19vN5Q-0005n2-00 for ; Fri, 05 Sep 2003 22:21:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19vN5P-0005mu-00 for ; Fri, 05 Sep 2003 22:21:39 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19vN4x-0007jI-00 for ; Fri, 05 Sep 2003 22:21:11 +0200 From: "Michael Fair" Subject: Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt] Date: Fri, 5 Sep 2003 13:21:03 -0700 Lines: 104 Message-ID: References: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > "Bad Recurrence-ID" needs to be expanded to include a fourth > > possibility; that it has never seen neither the base UID nor > > the RECURRENCE-ID before. > > Isn't that already covered by: > > If the "UID" property value in > the "REQUEST" is not found on the recipient's calendar, then the > "REQUEST" is for a new "VEVENT" calendar component. > > (factoring in Section 2.1.5 says that UID / RECURRENCE-ID are used in > place of UID when dealing with recurring instances per Section 2.1.5)? What to do is handled, but it's the actual text of 4.7.2 that bothers me. Section 4.7.2 Bad RECURRENCE-ID says: ... there are three cases in which an instance cannot be found. ... It then talks about finding the "UID" but then either not finding the RID or having problems with the SEQUENCE value. This isn't true. There are four cases. The fourth case being that neither the UID nor the RID have ever been seen before. A simple reference to "Do what 2.1.5 says" would suffice, but the declaration that there are only three cases can be confusing. > > Somehow it needs to be made clear that every relevant reference > > to "UID" throughout the document really means something more > > along the lines of "primary key" which could include UID, > > RECURRENCE-ID, and RANGE to accurately identify which events > > are being referred to. Much of the confusion here has been > > as a result of interpretting "UID" to not mean all of those. > > Ok, so some text added to 2.1.5 to this effect (expanding on bullet 1's > meaning) would be useful? Yes, that would be best, I fear putting it in a different section like Convenentions used in this document would be to easily missed. > > Making it clear that when canceling an event for a particular > > user the SEQUENCE value should not be incremented (or at least > > more discussion on what it should do). > > While this is a good change, exactly how to do it is another matter. The > problem is that this change is that it will effect all implementations > already out there that follow that text from Section 2.1.4. Just making > the change could mean interoperability issues w/existing implementations > and no way to detect it. Well is there any _real_ problem that develops if we do this? There's 4 scenarios I can think of, of which only 2 might be an issue: 1) Old sends a cancel to Old No problem they do what they always did 2) New sends a cancel to New No problem they both expect the new behavior 3) Old sends a cancel to New No problem, SEQUENCE value has been incremented New just prcesses it. If Old wants to reinvite New it will do whatever it has always done in the past when it did such things. 4) New sends a cancel to Old Not sure what happens here since it seems to be implementation specific. I suspect that it will actually still work since DTSTAMP will be greater than what it has, but some CUAs might try to enforce the RFC MUST and ignore a CANCEL if the SEQUENCE isn't greater. I guess the question is are there any CUAs we know of that will fail to CANCEL an event if the SEQUENCE is the same? Assuming that the CUAs will indeed cancel the event, will they reschedule it if they receive a request at the same SEQUENCE but greater DTSTAMP. -------------------------------------- There might be another approach. Rather than try and prevent SEQUENCE from being incremented, define rules for exceptions to invalidating the ATTENDENCE status. For instance, if an update is sent with a greater SEQUENCE and ALL fields except Comments are identical, then no REPLY is required and ORGANIZERS should simply transfer the attendence status. This way, cancelling an ATTENDEE with cause a SEQUENCE bump, and reinviting an ATTENDEE will also cause a SEQUENCE bump, however, those bumps will have no impact on the existing attendees. Old CUAs will simply go through the extra effort of processing the replies and New CUAs might be sent an RSVP=true for the higher SEQUENCE value because it failed to respond. However, in any case, the right things end up on the calendar. -- Michael -- From owner-ietf-calendar@mail.imc.org Sat Sep 6 15:20:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00510 for ; Sat, 6 Sep 2003 15:20:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86Iwpgc075199 for ; Sat, 6 Sep 2003 11:58:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h86Iwp72075198 for ietf-calendar-bks; Sat, 6 Sep 2003 11:58:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86Iwogc075192 for ; Sat, 6 Sep 2003 11:58:50 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h86IwnS5001182 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 6 Sep 2003 11:58:51 -0700 Message-ID: <3F5A2E64.2080505@Royer.com> Date: Sat, 06 Sep 2003 12:58:44 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP-12 - interm version 'B' Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030608070800010302080804" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030608070800010302080804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have placed the latest edit of CAP for your review at: http://inet-consulting.com/draft-ietf-calsch-cap-12-b.txt http://inet-consulting.com/draft-ietf-calsch-cap-12-b.html http://inet-consulting.com/draft-ietf-calsch-cap-12-b.xml This time Greg, I think I got all of your fixes in - 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 --------------ms030608070800010302080804 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTA2MTg1ODQ0WjAjBgkqhkiG9w0BCQQxFgQU8KxPnuAV0z7P/CmrVCfU 53vDPBEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAdDoBDAl+uG7oSjknOBAlGr6f5yn18eLGWdw+tcgDOirjgxMAKZc0WGT0tX8lbDiw CDVqWqLkbP7480jTYKX+RsQovRjYiHV8Sjk7iRPiNy5+Q3fl3TQSPTo6Fxna1vfaUP1qUJwv R/lT/32BrGBWByIWf/HB0i/dXdDS0LJzKIf9uZz4V+Y4CtSBUJ/1XBKG1ay3jc126vdT+Nez krLh79se9VOzPEIB6XtoVAAeFp/MlgPAv6U8O/+kP0ZS/K6ZRYbZA97+Gpd3gzo0N0RZqotH K/VseYiN8yGJlW6Nmmp7FQ+8GM62sNaVfFHOBl2fxmbH0SX0s3vwMZSkwl1V1QAAAAAAAA== --------------ms030608070800010302080804-- From owner-ietf-calendar@mail.imc.org Sat Sep 6 19:55:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13299 for ; Sat, 6 Sep 2003 19:55:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86NbRgc085769 for ; Sat, 6 Sep 2003 16:37:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h86NbRqY085768 for ietf-calendar-bks; Sat, 6 Sep 2003 16:37:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86NbQgc085759 for ; Sat, 6 Sep 2003 16:37:26 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h86NbN3Q011756 for ; Sat, 6 Sep 2003 17:37:23 -0600 (MDT) Message-ID: <3F5A6FB3.D03EB25A@INET-Calendar.net> Date: Sat, 06 Sep 2003 17:37:23 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: [Fwd: CAP-12 - interm version 'A'] Content-Type: multipart/mixed; boundary="------------1DC651776FD24896862C5375" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1DC651776FD24896862C5375 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug seemed confused on 09/04/2003 09:59:42 PM: > > > > Go re-read Bruces email and tell me if he has posted even ONE > post > > > > that backs up (some in recent posts); > > > > > > > > (a) ...I certainly dont recall any WG discussion on some of > the bigger > > > > issues ... > > > > > > Please point to the WG thread(s) where we discussed and resolved > the > > > issue of scoping on SEARCH? > > > > Go re-read my post (a) was not about SEARCH. It was was in response > > to the text you sent. Your mis quoting me again. > > Hello! McFly!! Your (a) was a citation from one of my emails and > your charge was I didnt describe "bigger issues" I was referring to. > I did that. I listed 3 even (of which you only how include 1)! I have seen you LIE on this list many times. At what point will the chair of this working group stop this trouble maker? You ether do not have a clue what he sent or your just lying. You seem to think that just because you post that means consensus and it does not. You got upset because his name is on the footer of the doc and make that a BIG issue. Are you just jealous? You clam that one space and not two is a BIG issue. Do you know how to use a computer and read? Get a life! With the RECURRENCE-ID issue you and Robert have changed your mind several times, yet claim he is the one that is pig headed. Your so arrogant you will not even admit that you changed your mind or opinion and you still slam him with lies and insults. You started the RECURRENCE-ID issue by declaring that it was fixed forever. Now you say it changes with the set, you changed your mind to be mostly compatible with the non-fixed model, admit it and stop slamming him or anyone simply because you changed your mind to agree with them. Your said: > Of course, you say there is an answer but you wont provide it. Typical. You did that for all discussion over the past 4 > months. "I dont have to prove anything." (loosely paraphrased). Well in the IETF if you cant back up your statements then > but the other folks can then yours dont hold much water... Not only was that on a non-CAP topic. IT HAD NOTHING WHAT SO EVER TO DO WITH WHAT HE SENT OR CAP. Is your mail tool busted? Or are you? I looked at your diff and never having seen CAP until -08, I figured it out in a couple of minutes - go hire someone competent if you can figure it out. This is a technical mailing list, not a list of people who subscribed just to hear Bruce demand other do his work. > It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately. Did you bother reading his post? He CAN NOT change such things until the chair calls consensus. Because CAP IS going to ship soon (are you now going to claim I made a last call?) The chair chastised him for making changes, and you chastise him for not making changes some of which only you seem to want. How about thanking him for what seems to be lots of abuse from you and a couple of others that do not seem to know how to act professionally. Or at the very least post your item list (I do not think you have one). Do you have an issue list? Or is there just one item on your issue list that is to slow down CAP until you can ship your product? > I made a proposal and you did not disagree. In fact noone did so I would say that we did reach concensus. > Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12. You did not make a proposal at all. You declared you did not like something. Have you read the real proposals made by many that I read about on the list archive? Yet you are the FIRST to scream when what you want is not in CAP. Or when you want something removed from CAP. There WAS NO CONSENSUS - who do you think you are to demand it change? If you want to know the consensus - ask the chair and don't declare it yourself. I see you post nothing useful most of the time, you RARELY post suggestions or useful comments. Your only contribution to this list seems to be that you have an opinion that you badly document. You claimed that if you just had a diff then things would be wonderful. Then after you had your own diff you scream because you have to read it. Grow up. > Of course not. That would mean you'd have to acutally read the contents of posting of someone who wont back down > from you on the list. Given all those separate facts (that you didnt read) its not hard to see why your motives could be > called into question. You may not like it but thats just how I interpret the actions I see. If I call you an idiot will you listen to me? If I call you a moron will you then help me? If you are incapable of posting technical issues. Why do you bother posting? WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND ABUSE OF OTHERS!! It takes for ever to read the archives and I am finding that a HUGE percentage of Bruce's posts are inflated self ego with no technical contribution, but its lots of text. > 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... --------------1DC651776FD24896862C5375 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3F5A5328.A8975529@INET-Calendar.net> Date: Sat, 06 Sep 2003 15:35:36 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug seemed confused on 09/04/2003 09:59:42 PM: > > > > Go re-read Bruces email and tell me if he has posted even ONE > post > > > > that backs up (some in recent posts); > > > > > > > > (a) ...I certainly dont recall any WG discussion on some of > the bigger > > > > issues ... > > > > > > Please point to the WG thread(s) where we discussed and resolved > the > > > issue of scoping on SEARCH? > > > > Go re-read my post (a) was not about SEARCH. It was was in response > > to the text you sent. Your mis quoting me again. > > Hello! McFly!! Your (a) was a citation from one of my emails and > your charge was I didnt describe "bigger issues" I was referring to. > I did that. I listed 3 even (of which you only how include 1)! I have seen you LIE on this list many times. At what point will the chair of this working group stop this trouble maker? You ether do not have a clue what he sent or your just lying. Are you getting paid to keep CAP from being published? I mean you call everyone names that disagrees with you. Your said: > Of course, you say there is an answer but you wont provide it. Typical. You did that for all discussion over the past 4 > months. "I dont have to prove anything." (loosely paraphrased). Well in the IETF if you cant back up your statements then > but the other folks can then yours dont hold much water... Not only was that on a non-CAP topic - IT HAD NOTHING WHAT SO EVER TO DO WITH WHAT HE SENT IN THE REPLY YOU ARE POSTING TO OR CAP. > It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately. Did you bother reading his post? He CAN NOT change such things until the chair calls consensus. CAP IS going to ship soon. > I made a proposal and you did not disagree. In fact noone did so I would say that we did reach concensus. > Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12. Yet you are the FIRST to scream when what you want is not in CAP. Or when you want something removed from CAP. There WAS NO CONSENSUS - who do you think you are? I see you post nothing useful, you RARELY post suggestions or useful comments. > Of course not. That would mean you'd have to acutally read the contents of posting of someone who wont back down > from you on the list. Given all those separate facts (that you didnt read) its not hard to see why your motives could be > called into question. You may not like it but thats just how I interpret the actions I see. If you are incapable of posting technical issues - why do you bother posting. If I call you an idiot will you listen to me? WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND ABUSE OF OTHERS!! > 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... --------------1DC651776FD24896862C5375-- From owner-ietf-calendar@mail.imc.org Sat Sep 6 22:19:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27126 for ; Sat, 6 Sep 2003 22:19:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8722Igc088910 for ; Sat, 6 Sep 2003 19:02:18 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8722It3088909 for ietf-calendar-bks; Sat, 6 Sep 2003 19:02:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8722Fgc088903 for ; Sat, 6 Sep 2003 19:02:16 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Sat, 6 Sep 2003 22:03:05 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.2CF2|July 23, 2003) at 09/06/2003 10:02:19 PM, Serialize complete at 09/06/2003 10:02:19 PM Content-Type: multipart/alternative; boundary="=_alternative 000B44DB85256D9A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000B44DB85256D9A_= Content-Type: text/plain; charset="us-ascii" Copy to this list ----- Forwarded by Pat R Egen/Egen Consulting/01 on 09/06/2003 22:02 ----- Pat R Egen 09/06/2003 22:02 To: Mark Smith cc: Subject: Re: [Fwd: CAP-12 - interm version 'A'] Actually, Mr. Smith, the chair (me) is really waiting to see when people will get back to the issue at hand - getting CAP out the door. I am also waiting for people to get back to being adults. Occasionally, the chair has to step in and suggest we keep things above board. It that is chastisment, then so be it. Blasts of emails between two or three people is not the answer. Making offensive comments about people also is not the answer, nor appropriate. There is no one person at fault - there are many, including myself for not getting into the middle of some of these discussions and saying - stop the noise and get productive. However, that's not the way the IETF works. The chair is there to call concensus, keep people cool, and push drafts. We are not supposed to interfere or persuade people to move in any particular direction. Therefore, I take great pains to not interfere with dialog.. However, I have to interfere when people write things that are abusive. It is appropriate for the chair to step in when things get out of hand and when trying to reach concensus. It is also the responsibility of the chair to step in and say there may be an issue. I know Bruce - and he does not lie. He gets "enthusiastic" with his replies. As for posting to the list, I happen to know he has been told by his management to reduce the amount of time he spends on items not pertaining to his work. I know he tries to get on the list when he can - he is not supposed to be on this list at all - he still participates anyway because he too wants to see CAP out. He's probably not pleased I am defending him. With regards to his "job on the list" - the only "official" job he has is method reviewer for ical, itip and imip. He's not "officially" responsible for anything pertaining to CAP. He's just trying to make sure it gets done. When we have had meetings at IETF's and have been fortunate that Bruce could attend, he would help us get to an answer on issues. He would hound us until we got there - and sometimes, it was not the direction he was heading - he would find out something should go in another direction. Both Bob and I welcome Bruce's comments - they have usually been germaine. However, in his defense, when someone just doesn't get it, it gets frustrating. And when someone starts making comments like "you lie" on the list, then I have to step in and say "foul, below the belt, keep it nice." So, that being said, can we please move on and get this done. And again, name calling and mud slinging will not be condoned on the list. Mark Smith Sent by: owner-ietf-calendar@mail.imc.org 09/06/2003 19:37 To: ietf-calendar@imc.org cc: Subject: [Fwd: CAP-12 - interm version 'A'] Bruce_Kahn@notesdev.ibm.com wrote: > > Doug seemed confused on 09/04/2003 09:59:42 PM: > > > > Go re-read Bruces email and tell me if he has posted even ONE > post > > > > that backs up (some in recent posts); > > > > > > > > (a) ...I certainly dont recall any WG discussion on some of > the bigger > > > > issues ... > > > > > > Please point to the WG thread(s) where we discussed and resolved > the > > > issue of scoping on SEARCH? > > > > Go re-read my post (a) was not about SEARCH. It was was in response > > to the text you sent. Your mis quoting me again. > > Hello! McFly!! Your (a) was a citation from one of my emails and > your charge was I didnt describe "bigger issues" I was referring to. > I did that. I listed 3 even (of which you only how include 1)! I have seen you LIE on this list many times. At what point will the chair of this working group stop this trouble maker? You ether do not have a clue what he sent or your just lying. You seem to think that just because you post that means consensus and it does not. You got upset because his name is on the footer of the doc and make that a BIG issue. Are you just jealous? You clam that one space and not two is a BIG issue. Do you know how to use a computer and read? Get a life! With the RECURRENCE-ID issue you and Robert have changed your mind several times, yet claim he is the one that is pig headed. Your so arrogant you will not even admit that you changed your mind or opinion and you still slam him with lies and insults. You started the RECURRENCE-ID issue by declaring that it was fixed forever. Now you say it changes with the set, you changed your mind to be mostly compatible with the non-fixed model, admit it and stop slamming him or anyone simply because you changed your mind to agree with them. Your said: > Of course, you say there is an answer but you wont provide it. Typical. You did that for all discussion over the past 4 > months. "I dont have to prove anything." (loosely paraphrased). Well in the IETF if you cant back up your statements then > but the other folks can then yours dont hold much water... Not only was that on a non-CAP topic. IT HAD NOTHING WHAT SO EVER TO DO WITH WHAT HE SENT OR CAP. Is your mail tool busted? Or are you? I looked at your diff and never having seen CAP until -08, I figured it out in a couple of minutes - go hire someone competent if you can figure it out. This is a technical mailing list, not a list of people who subscribed just to hear Bruce demand other do his work. > It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately. Did you bother reading his post? He CAN NOT change such things until the chair calls consensus. Because CAP IS going to ship soon (are you now going to claim I made a last call?) The chair chastised him for making changes, and you chastise him for not making changes some of which only you seem to want. How about thanking him for what seems to be lots of abuse from you and a couple of others that do not seem to know how to act professionally. Or at the very least post your item list (I do not think you have one). Do you have an issue list? Or is there just one item on your issue list that is to slow down CAP until you can ship your product? > I made a proposal and you did not disagree. In fact noone did so I would say that we did reach concensus. > Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12. You did not make a proposal at all. You declared you did not like something. Have you read the real proposals made by many that I read about on the list archive? Yet you are the FIRST to scream when what you want is not in CAP. Or when you want something removed from CAP. There WAS NO CONSENSUS - who do you think you are to demand it change? If you want to know the consensus - ask the chair and don't declare it yourself. I see you post nothing useful most of the time, you RARELY post suggestions or useful comments. Your only contribution to this list seems to be that you have an opinion that you badly document. You claimed that if you just had a diff then things would be wonderful. Then after you had your own diff you scream because you have to read it. Grow up. > Of course not. That would mean you'd have to acutally read the contents of posting of someone who wont back down > from you on the list. Given all those separate facts (that you didnt read) its not hard to see why your motives could be > called into question. You may not like it but thats just how I interpret the actions I see. If I call you an idiot will you listen to me? If I call you a moron will you then help me? If you are incapable of posting technical issues. Why do you bother posting? WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND ABUSE OF OTHERS!! It takes for ever to read the archives and I am finding that a HUGE percentage of Bruce's posts are inflated self ego with no technical contribution, but its lots of text. > 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... Content-Transfer-Encoding: 7bit X-Mozilla-Status2: 00000000 Message-ID: <3F5A5328.A8975529@INET-Calendar.net> Date: Sat, 06 Sep 2003 15:35:36 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: Content-Type: text/plain; charset=us-ascii Bruce_Kahn@notesdev.ibm.com wrote: > > Doug seemed confused on 09/04/2003 09:59:42 PM: > > > > Go re-read Bruces email and tell me if he has posted even ONE > post > > > > that backs up (some in recent posts); > > > > > > > > (a) ...I certainly dont recall any WG discussion on some of > the bigger > > > > issues ... > > > > > > Please point to the WG thread(s) where we discussed and resolved > the > > > issue of scoping on SEARCH? > > > > Go re-read my post (a) was not about SEARCH. It was was in response > > to the text you sent. Your mis quoting me again. > > Hello! McFly!! Your (a) was a citation from one of my emails and > your charge was I didnt describe "bigger issues" I was referring to. > I did that. I listed 3 even (of which you only how include 1)! I have seen you LIE on this list many times. At what point will the chair of this working group stop this trouble maker? You ether do not have a clue what he sent or your just lying. Are you getting paid to keep CAP from being published? I mean you call everyone names that disagrees with you. Your said: > Of course, you say there is an answer but you wont provide it. Typical. You did that for all discussion over the past 4 > months. "I dont have to prove anything." (loosely paraphrased). Well in the IETF if you cant back up your statements then > but the other folks can then yours dont hold much water... Not only was that on a non-CAP topic - IT HAD NOTHING WHAT SO EVER TO DO WITH WHAT HE SENT IN THE REPLY YOU ARE POSTING TO OR CAP. > It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately. Did you bother reading his post? He CAN NOT change such things until the chair calls consensus. CAP IS going to ship soon. > I made a proposal and you did not disagree. In fact noone did so I would say that we did reach concensus. > Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12. Yet you are the FIRST to scream when what you want is not in CAP. Or when you want something removed from CAP. There WAS NO CONSENSUS - who do you think you are? I see you post nothing useful, you RARELY post suggestions or useful comments. > Of course not. That would mean you'd have to acutally read the contents of posting of someone who wont back down > from you on the list. Given all those separate facts (that you didnt read) its not hard to see why your motives could be > called into question. You may not like it but thats just how I interpret the actions I see. If you are incapable of posting technical issues - why do you bother posting. If I call you an idiot will you listen to me? WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND ABUSE OF OTHERS!! > 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 000B44DB85256D9A_= Content-Type: text/html; charset="us-ascii"
Copy to this list
----- Forwarded by Pat R Egen/Egen Consulting/01 on 09/06/2003 22:02 -----
Pat R Egen

09/06/2003 22:02


        To:        Mark Smith <mark@inet-calendar.net>
        cc:        
        Subject:        Re: [Fwd: CAP-12 - interm version 'A']Link




Actually, Mr. Smith, the chair (me) is really waiting to see when people will get back to the issue at hand - getting CAP out the door.  I am also waiting for people to get back to being adults.  Occasionally, the chair has to step in and suggest we keep things above board.  It that is chastisment, then so be it.

Blasts of emails between two or three people is not the answer.  Making offensive comments about people also is not the answer, nor appropriate.  There is no one person at fault - there are many, including myself for not getting into the middle of some of these discussions and saying - stop the noise and get productive.  

However, that's not the way the IETF works.  The chair is there to call concensus, keep people cool, and push drafts.  We are not supposed to interfere or persuade people to move in any particular direction.  Therefore, I take great pains to not interfere with dialog..  However, I have to interfere when people write things that are abusive.  It is appropriate for the chair to step in when things get out of hand and when trying to reach concensus. It is also the responsibility of the chair to step in and say there may be an issue.  I know Bruce - and he does not lie.  He gets "enthusiastic" with his replies.  As for posting to the list, I happen to know he has been told by his management to reduce the amount of time he spends on items not pertaining to his work.  I know he tries to get on the list when he can - he is not supposed to be on this list at all - he still participates anyway because he too wants to see CAP out.!  He's probably not pleased I am defending him.  With regards to his "job on the list"  - the only "official" job he has is method reviewer for ical, itip and imip.  He's not "officially" responsible for anything pertaining to CAP.  He's just trying to make sure it gets done.  When we have had meetings at IETF's and have been fortunate that Bruce could attend, he would help us get to an answer on issues.  He would hound us until we got there - and sometimes, it was not the direction he was heading - he would find out something should go in another direction.  Both Bob and I welcome Bruce's comments - they have usually been germaine.  However, in his defense, when someone just doesn't get it, it gets frustrating.  And when someone starts making comments like "you lie" on the list, then I have to step in and say "foul, below the belt, keep it nice."

So, that being said, can we please move on and get this done.  And again, name calling and mud slinging will not be condoned on the list.

Mark Smith <mark@inet-calendar.net>
Sent by: owner-ietf-calendar@mail.imc.org

09/06/2003 19:37

       
       To:        ietf-calendar@imc.org
       cc:        
       Subject:        [Fwd: CAP-12 - interm version 'A']





Bruce_Kahn@notesdev.ibm.com wrote:
>
> Doug seemed confused on 09/04/2003 09:59:42 PM:
> > >  > Go re-read Bruces email and tell me if he has posted even ONE
> post
> > >  > that backs up (some in recent posts);
> > >  >
> > >  > (a)   ...I certainly dont recall any WG discussion on some of
> the bigger
> > >  >       issues ...
> > >
> > > Please point to the WG thread(s) where we discussed and resolved
> the
> > > issue of scoping on SEARCH?
> >
> > Go re-read my post (a) was not about SEARCH. It was was in response
> > to the text you sent. Your mis quoting me again.
>
> Hello!  McFly!!  Your (a) was a citation from one of my emails and
> your charge was I didnt describe "bigger issues" I was referring to.
>  I did that.  I listed 3 even (of which you only how include 1)!

I have seen you LIE on this list many times. At what point will the
chair of this working group stop this trouble maker?

You ether do not have a clue what he sent or your just lying.

You seem to think that just because you post that means consensus and it
does not.

You got upset because his name is on the footer of the doc and make
that a BIG issue. Are you just jealous?

You clam that one space and not two is a BIG issue. Do you know how to
use a computer and read? Get a life!

With the RECURRENCE-ID issue you and Robert have changed your mind
several times, yet claim
he is the one that is pig headed. Your so arrogant you will not even
admit that
you changed your mind or opinion and you still slam him with lies and
insults.
You started the RECURRENCE-ID issue by declaring that it was fixed
forever.
Now you say it changes with the set, you changed your mind to be mostly
compatible with the non-fixed model, admit it and stop slamming him or
anyone simply because you changed your mind to agree with them.

Your said:

> Of course, you say there is an answer but you wont provide it.  Typical.  You did that for all discussion over the past 4
> months.  "I dont have to prove anything." (loosely paraphrased).  Well in the IETF if you cant back up your statements then
> but the other folks can then yours dont hold much water...

Not only was that on a non-CAP topic. IT HAD NOTHING WHAT SO EVER TO DO
WITH WHAT HE SENT OR CAP. Is your mail tool busted? Or are you?

I looked at your diff and never having seen CAP until -08, I figured
it out in a couple of minutes  - go hire someone competent if you can
figure it out.
This is a technical mailing list, not a list of people who subscribed
just to hear Bruce
demand other do his work.

> It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately.

Did you bother reading his post? He CAN NOT change such things until the
chair calls consensus. Because CAP IS going to ship soon (are you
now going to claim I made a last call?)

The chair chastised him for making changes, and you chastise him for not
making changes
some of which only you seem to want. How about thanking him for what
seems to be lots
of abuse from you and a couple of others that do not seem to know how to
act professionally.
Or at the very least post your item list (I do not think you have one).

Do you have an issue list? Or is there just one item on your issue list
that
is to slow down CAP until you can ship your product?

> I made a proposal and you did not disagree.  In fact noone did so I would say that we did reach concensus.
> Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12.

You did not make a proposal at all. You declared you did not like
something. Have you read
the real proposals made by many that I read about on the list archive?

Yet you are the FIRST to scream when what you want is not in CAP.
Or when you want something removed from CAP.

There WAS NO CONSENSUS - who do you think you are to demand it change?
If you want to know the consensus - ask the chair and don't declare it
yourself.

I see you post nothing useful most of the time, you RARELY post
suggestions
or useful comments. Your only contribution to this list seems to be that
you have an opinion that you badly document.

You claimed that if you just had a diff then things would be wonderful.
Then after you had your own diff you scream because you have to
read it. Grow up.

> Of course not.  That would mean you'd have to acutally read the contents of posting of someone who wont back down
> from you on the list.  Given all those separate facts (that you didnt read) its not hard to see why your motives could be
> called into question.  You may not like it but thats just how I interpret the actions I see.

If I call you an idiot will you listen to me? If  I call you a moron
will you then help me?

If you are incapable of posting technical issues. Why do you bother
posting?

WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND
ABUSE OF OTHERS!! It takes for ever to read the archives and I am
finding that a HUGE percentage of Bruce's posts are inflated self ego
with
no technical contribution, but its lots of text.


> 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...
Content-Transfer-Encoding: 7bit
X-Mozilla-Status2: 00000000
Message-ID: <3F5A5328.A8975529@INET-Calendar.net>
Date: Sat, 06 Sep 2003 15:35:36 -0600
From: Mark Smith <mark@INET-Calendar.net>
X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: CAP-12 - interm version 'A'
References: <OF957761B2.CCC0F26F-ON85256D98.0068FF88-85256D98.006B69EB@notesdev.ibm.com>
Content-Type: text/plain; charset=us-ascii

Bruce_Kahn@notesdev.ibm.com wrote:
>
> Doug seemed confused on 09/04/2003 09:59:42 PM:
> > >  > Go re-read Bruces email and tell me if he has posted even ONE
> post
> > >  > that backs up (some in recent posts);
> > >  >
> > >  > (a)   ...I certainly dont recall any WG discussion on some of
> the bigger
> > >  >       issues ...
> > >
> > > Please point to the WG thread(s) where we discussed and resolved
> the
> > > issue of scoping on SEARCH?
> >
> > Go re-read my post (a) was not about SEARCH. It was was in response
> > to the text you sent. Your mis quoting me again.
>
> Hello!  McFly!!  Your (a) was a citation from one of my emails and
> your charge was I didnt describe "bigger issues" I was referring to.
>  I did that.  I listed 3 even (of which you only how include 1)!

I have seen you LIE on this list many times. At what point will the
chair of this working group stop this trouble maker?

You ether do not have a clue what he sent or your just lying.

Are you getting paid to keep CAP from being published?
I mean you call everyone names that disagrees with you.

Your said:

> Of course, you say there is an answer but you wont provide it.  Typical.  You did that for all discussion over the past 4
> months.  "I dont have to prove anything." (loosely paraphrased).  Well in the IETF if you cant back up your statements then
> but the other folks can then yours dont hold much water...

Not only was that on a non-CAP topic - IT HAD NOTHING WHAT SO EVER TO DO
WITH WHAT HE SENT
IN THE REPLY YOU ARE POSTING TO OR CAP.

> It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately.

Did you bother reading his post? He CAN NOT change such things until the
chair
calls consensus. CAP IS going to ship soon.


> I made a proposal and you did not disagree.  In fact noone did so I would say that we did reach concensus.
> Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12.

Yet you are the FIRST to scream when what you want is not in CAP.
Or when you want something removed from CAP.

There WAS NO CONSENSUS - who do you think you are?

I see you post nothing useful, you RARELY post suggestions or useful
comments.

> Of course not.  That would mean you'd have to acutally read the contents of posting of someone who wont back down
> from you on the list.  Given all those separate facts (that you didnt read) its not hard to see why your motives could be
> called into question.  You may not like it but thats just how I interpret the actions I see.

If you are incapable of posting technical issues - why do you bother
posting.
If I call you an idiot will you listen to me?

WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND
ABUSE OF OTHERS!!


> 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 000B44DB85256D9A_=-- From owner-ietf-calendar@mail.imc.org Sun Sep 7 13:32:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20850 for ; Sun, 7 Sep 2003 13:32:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87Guqgc065771 for ; Sun, 7 Sep 2003 09:56:52 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h87Guq0e065770 for ietf-calendar-bks; Sun, 7 Sep 2003 09:56:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87Gupgc065765 for ; Sun, 7 Sep 2003 09:56:51 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F5A6FB3.D03EB25A@INET-Calendar.net> To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Sun, 7 Sep 2003 12:56:47 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/07/2003 12:56:38 PM, Serialize complete at 09/07/2003 12:56:38 PM Content-Type: multipart/alternative; boundary="=_alternative 005CA71D85256D9A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CA71D85256D9A_= Content-Type: text/plain; charset="US-ASCII" > With the RECURRENCE-ID issue you and Robert have changed your mind > several times, yet claim > he is the one that is pig headed. Your so arrogant you will not even > admit that We did not change are minds. The scope of the original discussion was changing an instance of a repeat set. It was than asked is there ever a case where the recurrence-id's can be reset. The response was, If the CHAIR sends out a REQUEST with no RECURRENCE-ID the REQUEST applies to the entire repeat set. In that case the CHAIR is resetting the RULE/RDATE/EXRULE/EXDATE information for the set and thus resetting the RECURRENCE-ID's for the entire set. The recipient of such a REQUEST must obsolete/delete or move the existing set and accept the new information from the CHAIR. This procedure has been referred to as NUKING the recipients calendar store. Mark Smith Sent by: owner-ietf-calendar@mail.imc.org 09/06/2003 07:37 PM To ietf-calendar@imc.org cc Subject [Fwd: CAP-12 - interm version 'A'] Bruce_Kahn@notesdev.ibm.com wrote: > > Doug seemed confused on 09/04/2003 09:59:42 PM: > > > > Go re-read Bruces email and tell me if he has posted even ONE > post > > > > that backs up (some in recent posts); > > > > > > > > (a) ...I certainly dont recall any WG discussion on some of > the bigger > > > > issues ... > > > > > > Please point to the WG thread(s) where we discussed and resolved > the > > > issue of scoping on SEARCH? > > > > Go re-read my post (a) was not about SEARCH. It was was in response > > to the text you sent. Your mis quoting me again. > > Hello! McFly!! Your (a) was a citation from one of my emails and > your charge was I didnt describe "bigger issues" I was referring to. > I did that. I listed 3 even (of which you only how include 1)! I have seen you LIE on this list many times. At what point will the chair of this working group stop this trouble maker? You ether do not have a clue what he sent or your just lying. You seem to think that just because you post that means consensus and it does not. You got upset because his name is on the footer of the doc and make that a BIG issue. Are you just jealous? You clam that one space and not two is a BIG issue. Do you know how to use a computer and read? Get a life! With the RECURRENCE-ID issue you and Robert have changed your mind several times, yet claim he is the one that is pig headed. Your so arrogant you will not even admit that you changed your mind or opinion and you still slam him with lies and insults. You started the RECURRENCE-ID issue by declaring that it was fixed forever. Now you say it changes with the set, you changed your mind to be mostly compatible with the non-fixed model, admit it and stop slamming him or anyone simply because you changed your mind to agree with them. Your said: > Of course, you say there is an answer but you wont provide it. Typical. You did that for all discussion over the past 4 > months. "I dont have to prove anything." (loosely paraphrased). Well in the IETF if you cant back up your statements then > but the other folks can then yours dont hold much water... Not only was that on a non-CAP topic. IT HAD NOTHING WHAT SO EVER TO DO WITH WHAT HE SENT OR CAP. Is your mail tool busted? Or are you? I looked at your diff and never having seen CAP until -08, I figured it out in a couple of minutes - go hire someone competent if you can figure it out. This is a technical mailing list, not a list of people who subscribed just to hear Bruce demand other do his work. > It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately. Did you bother reading his post? He CAN NOT change such things until the chair calls consensus. Because CAP IS going to ship soon (are you now going to claim I made a last call?) The chair chastised him for making changes, and you chastise him for not making changes some of which only you seem to want. How about thanking him for what seems to be lots of abuse from you and a couple of others that do not seem to know how to act professionally. Or at the very least post your item list (I do not think you have one). Do you have an issue list? Or is there just one item on your issue list that is to slow down CAP until you can ship your product? > I made a proposal and you did not disagree. In fact noone did so I would say that we did reach concensus. > Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12. You did not make a proposal at all. You declared you did not like something. Have you read the real proposals made by many that I read about on the list archive? Yet you are the FIRST to scream when what you want is not in CAP. Or when you want something removed from CAP. There WAS NO CONSENSUS - who do you think you are to demand it change? If you want to know the consensus - ask the chair and don't declare it yourself. I see you post nothing useful most of the time, you RARELY post suggestions or useful comments. Your only contribution to this list seems to be that you have an opinion that you badly document. You claimed that if you just had a diff then things would be wonderful. Then after you had your own diff you scream because you have to read it. Grow up. > Of course not. That would mean you'd have to acutally read the contents of posting of someone who wont back down > from you on the list. Given all those separate facts (that you didnt read) its not hard to see why your motives could be > called into question. You may not like it but thats just how I interpret the actions I see. If I call you an idiot will you listen to me? If I call you a moron will you then help me? If you are incapable of posting technical issues. Why do you bother posting? WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND ABUSE OF OTHERS!! It takes for ever to read the archives and I am finding that a HUGE percentage of Bruce's posts are inflated self ego with no technical contribution, but its lots of text. > 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... ----- Message from Mark Smith on Sat, 06 Sep 2003 15:35:36 -0600 ----- To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' Bruce_Kahn@notesdev.ibm.com wrote: > > Doug seemed confused on 09/04/2003 09:59:42 PM: > > > > Go re-read Bruces email and tell me if he has posted even ONE > post > > > > that backs up (some in recent posts); > > > > > > > > (a) ...I certainly dont recall any WG discussion on some of > the bigger > > > > issues ... > > > > > > Please point to the WG thread(s) where we discussed and resolved > the > > > issue of scoping on SEARCH? > > > > Go re-read my post (a) was not about SEARCH. It was was in response > > to the text you sent. Your mis quoting me again. > > Hello! McFly!! Your (a) was a citation from one of my emails and > your charge was I didnt describe "bigger issues" I was referring to. > I did that. I listed 3 even (of which you only how include 1)! I have seen you LIE on this list many times. At what point will the chair of this working group stop this trouble maker? You ether do not have a clue what he sent or your just lying. Are you getting paid to keep CAP from being published? I mean you call everyone names that disagrees with you. Your said: > Of course, you say there is an answer but you wont provide it. Typical. You did that for all discussion over the past 4 > months. "I dont have to prove anything." (loosely paraphrased). Well in the IETF if you cant back up your statements then > but the other folks can then yours dont hold much water... Not only was that on a non-CAP topic - IT HAD NOTHING WHAT SO EVER TO DO WITH WHAT HE SENT IN THE REPLY YOU ARE POSTING TO OR CAP. > It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately. Did you bother reading his post? He CAN NOT change such things until the chair calls consensus. CAP IS going to ship soon. > I made a proposal and you did not disagree. In fact noone did so I would say that we did reach concensus. > Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12. Yet you are the FIRST to scream when what you want is not in CAP. Or when you want something removed from CAP. There WAS NO CONSENSUS - who do you think you are? I see you post nothing useful, you RARELY post suggestions or useful comments. > Of course not. That would mean you'd have to acutally read the contents of posting of someone who wont back down > from you on the list. Given all those separate facts (that you didnt read) its not hard to see why your motives could be > called into question. You may not like it but thats just how I interpret the actions I see. If you are incapable of posting technical issues - why do you bother posting. If I call you an idiot will you listen to me? WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND ABUSE OF OTHERS!! > 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 005CA71D85256D9A_= Content-Type: text/html; charset="US-ASCII"
> With the RECURRENCE-ID issue you and Robert have changed your mind
> several times, yet claim
> he is the one that is pig headed. Your so arrogant you will not even
> admit that

We did not change are minds.  The scope of the original discussion was changing an instance of a repeat set.
It was than asked is there ever a case where the recurrence-id's can be reset.
The response was, If the CHAIR sends out a REQUEST with no RECURRENCE-ID the REQUEST applies to the entire repeat set.

In that case the CHAIR is resetting the RULE/RDATE/EXRULE/EXDATE information for the set and thus resetting the RECURRENCE-ID's for the entire set.  The recipient of such a REQUEST must obsolete/delete or move the existing set and accept the new information from the CHAIR.  This procedure has been referred to as NUKING the recipients calendar store.


Mark Smith <mark@inet-calendar.net>
Sent by: owner-ietf-calendar@mail.imc.org

09/06/2003 07:37 PM

To
ietf-calendar@imc.org
cc
Subject
[Fwd: CAP-12 - interm version 'A']






Bruce_Kahn@notesdev.ibm.com wrote:
>
> Doug seemed confused on 09/04/2003 09:59:42 PM:
> > >  > Go re-read Bruces email and tell me if he has posted even ONE
> post
> > >  > that backs up (some in recent posts);
> > >  >
> > >  > (a)   ...I certainly dont recall any WG discussion on some of
> the bigger
> > >  >       issues ...
> > >
> > > Please point to the WG thread(s) where we discussed and resolved
> the
> > > issue of scoping on SEARCH?
> >
> > Go re-read my post (a) was not about SEARCH. It was was in response
> > to the text you sent. Your mis quoting me again.
>
> Hello!  McFly!!  Your (a) was a citation from one of my emails and
> your charge was I didnt describe "bigger issues" I was referring to.
>  I did that.  I listed 3 even (of which you only how include 1)!

I have seen you LIE on this list many times. At what point will the
chair of this working group stop this trouble maker?

You ether do not have a clue what he sent or your just lying.

You seem to think that just because you post that means consensus and it
does not.

You got upset because his name is on the footer of the doc and make
that a BIG issue. Are you just jealous?

You clam that one space and not two is a BIG issue. Do you know how to
use a computer and read? Get a life!

With the RECURRENCE-ID issue you and Robert have changed your mind
several times, yet claim
he is the one that is pig headed. Your so arrogant you will not even
admit that
you changed your mind or opinion and you still slam him with lies and
insults.
You started the RECURRENCE-ID issue by declaring that it was fixed
forever.
Now you say it changes with the set, you changed your mind to be mostly
compatible with the non-fixed model, admit it and stop slamming him or
anyone simply because you changed your mind to agree with them.

Your said:

> Of course, you say there is an answer but you wont provide it.  Typical.  You did that for all discussion over the past 4
> months.  "I dont have to prove anything." (loosely paraphrased).  Well in the IETF if you cant back up your statements then
> but the other folks can then yours dont hold much water...

Not only was that on a non-CAP topic. IT HAD NOTHING WHAT SO EVER TO DO
WITH WHAT HE SENT OR CAP. Is your mail tool busted? Or are you?

I looked at your diff and never having seen CAP until -08, I figured
it out in a couple of minutes  - go hire someone competent if you can
figure it out.
This is a technical mailing list, not a list of people who subscribed
just to hear Bruce
demand other do his work.

> It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately.

Did you bother reading his post? He CAN NOT change such things until the
chair calls consensus. Because CAP IS going to ship soon (are you
now going to claim I made a last call?)

The chair chastised him for making changes, and you chastise him for not
making changes
some of which only you seem to want. How about thanking him for what
seems to be lots
of abuse from you and a couple of others that do not seem to know how to
act professionally.
Or at the very least post your item list (I do not think you have one).

Do you have an issue list? Or is there just one item on your issue list
that
is to slow down CAP until you can ship your product?

> I made a proposal and you did not disagree.  In fact noone did so I would say that we did reach concensus.
> Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12.

You did not make a proposal at all. You declared you did not like
something. Have you read
the real proposals made by many that I read about on the list archive?

Yet you are the FIRST to scream when what you want is not in CAP.
Or when you want something removed from CAP.

There WAS NO CONSENSUS - who do you think you are to demand it change?
If you want to know the consensus - ask the chair and don't declare it
yourself.

I see you post nothing useful most of the time, you RARELY post
suggestions
or useful comments. Your only contribution to this list seems to be that
you have an opinion that you badly document.

You claimed that if you just had a diff then things would be wonderful.
Then after you had your own diff you scream because you have to
read it. Grow up.

> Of course not.  That would mean you'd have to acutally read the contents of posting of someone who wont back down
> from you on the list.  Given all those separate facts (that you didnt read) its not hard to see why your motives could be
> called into question.  You may not like it but thats just how I interpret the actions I see.

If I call you an idiot will you listen to me? If  I call you a moron
will you then help me?

If you are incapable of posting technical issues. Why do you bother
posting?

WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND
ABUSE OF OTHERS!! It takes for ever to read the archives and I am
finding that a HUGE percentage of Bruce's posts are inflated self ego
with
no technical contribution, but its lots of text.


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


----- Message from Mark Smith <mark@INET-Calendar.net> on Sat, 06 Sep 2003 15:35:36 -0600 -----
To:
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject:
Re: CAP-12 - interm version 'A'


Bruce_Kahn@notesdev.ibm.com wrote:
>
> Doug seemed confused on 09/04/2003 09:59:42 PM:
> > >  > Go re-read Bruces email and tell me if he has posted even ONE
> post
> > >  > that backs up (some in recent posts);
> > >  >
> > >  > (a)   ...I certainly dont recall any WG discussion on some of
> the bigger
> > >  >       issues ...
> > >
> > > Please point to the WG thread(s) where we discussed and resolved
> the
> > > issue of scoping on SEARCH?
> >
> > Go re-read my post (a) was not about SEARCH. It was was in response
> > to the text you sent. Your mis quoting me again.
>
> Hello!  McFly!!  Your (a) was a citation from one of my emails and
> your charge was I didnt describe "bigger issues" I was referring to.
>  I did that.  I listed 3 even (of which you only how include 1)!

I have seen you LIE on this list many times. At what point will the
chair of this working group stop this trouble maker?

You ether do not have a clue what he sent or your just lying.

Are you getting paid to keep CAP from being published?
I mean you call everyone names that disagrees with you.

Your said:

> Of course, you say there is an answer but you wont provide it.  Typical.  You did that for all discussion over the past 4
> months.  "I dont have to prove anything." (loosely paraphrased).  Well in the IETF if you cant back up your statements then
> but the other folks can then yours dont hold much water...

Not only was that on a non-CAP topic - IT HAD NOTHING WHAT SO EVER TO DO
WITH WHAT HE SENT
IN THE REPLY YOU ARE POSTING TO OR CAP.

> It was NOT resolved. Another issue you conveniently forgot for CAP-11 or to acknowledge lately.

Did you bother reading his post? He CAN NOT change such things until the
chair
calls consensus. CAP IS going to ship soon.


> I made a proposal and you did not disagree.  In fact noone did so I would say that we did reach concensus.
> Ill leave it to you to go get the final text from that discussion and include it in the next version of CAP-12.

Yet you are the FIRST to scream when what you want is not in CAP.
Or when you want something removed from CAP.

There WAS NO CONSENSUS - who do you think you are?

I see you post nothing useful, you RARELY post suggestions or useful
comments.

> Of course not.  That would mean you'd have to acutally read the contents of posting of someone who wont back down
> from you on the list.  Given all those separate facts (that you didnt read) its not hard to see why your motives could be
> called into question.  You may not like it but thats just how I interpret the actions I see.

If you are incapable of posting technical issues - why do you bother
posting.
If I call you an idiot will you listen to me?

WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND
ABUSE OF OTHERS!!


> 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 005CA71D85256D9A_=-- From owner-ietf-calendar@mail.imc.org Sun Sep 7 14:33:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26834 for ; Sun, 7 Sep 2003 14:33:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87HvEgc069895 for ; Sun, 7 Sep 2003 10:57:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h87HvE1U069894 for ietf-calendar-bks; Sun, 7 Sep 2003 10:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87HvCgc069889 for ; Sun, 7 Sep 2003 10:57:12 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: Recurrence ID recommendation - almost there MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Sun, 7 Sep 2003 13:58:05 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.2CF2|July 23, 2003) at 09/07/2003 01:57:14 PM, Serialize complete at 09/07/2003 01:57:14 PM Content-Type: multipart/alternative; boundary="=_alternative 0062B3BD85256D9A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0062B3BD85256D9A_= Content-Type: text/plain; charset="us-ascii" I promised the list that I would post my findings and recommendation on the Recurrence ID issue. I wanted to let the list know that I have not forgotten this promise. I have indeed been working on just exactly that. However, I have added to my chores production of a list of CAP issues. Since I have been wading through 18 months of emails I discovered I may have the ability to put down a short, succinct list of issues. Also, I'm hoping to be able to "glean" consensus on some of them and violent non-consensus on many others. If I am doing this legwork, it will be of value to the list as well. In addition, I am making sure, with the original authors, that what I am proposing is valid and will work. There is no sense mucking up a list that is already overburdened with far too many nonproductive notes. Even this one qualifies as nonproductive because it does not have my answer. But that is coming. And not in a month - but, I'm hoping, by the end of this week. I hesitate to put a date if I can't make it - but I am going to try. The diff issue that was raised by Bruce sort of put me back a bit - but it was worthwhile and necessary to work on that issue too. And, sigh, being a small business owner, I had to go work on paying my mortgage. I hate it when that happens. Not apologizing - just giving you all a reality check on my part. --=_alternative 0062B3BD85256D9A_= Content-Type: text/html; charset="us-ascii"
I promised the list that I would post my findings and recommendation on the Recurrence ID issue.  I wanted to let the list know that I have not forgotten this promise.  I have indeed been working on just exactly that.  However, I have added to my chores production of a list of CAP issues.  Since I have been wading through 18 months of emails I discovered I may have the ability to put down a short, succinct list of issues.  Also, I'm hoping to be able to "glean" consensus on some of them and violent non-consensus on many others.  If I am doing this legwork, it will be of value to the list as well.

In addition, I am making sure, with the original authors, that what I am proposing is valid and will work.  There is no sense mucking up a list that is already overburdened with far too many nonproductive notes.  Even this one qualifies as nonproductive because it does not have my answer.  But that is coming.  And not in a month - but, I'm hoping, by the end of this week.  I hesitate to put a date if I can't make it - but I am going to try.  The diff issue that was raised by Bruce sort of put me back a bit - but it was worthwhile and necessary to work on that issue too.  And, sigh, being a small business owner, I had to go work on paying my mortgage.  I hate it when that happens.  Not apologizing - just giving you all a reality check on my part.
 --=_alternative 0062B3BD85256D9A_=-- From owner-ietf-calendar@mail.imc.org Sun Sep 7 15:15:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00533 for ; Sun, 7 Sep 2003 15:15:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87IXcgc075365 for ; Sun, 7 Sep 2003 11:33:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h87IXc1x075364 for ietf-calendar-bks; Sun, 7 Sep 2003 11:33:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87IXbgc075359 for ; Sun, 7 Sep 2003 11:33:37 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h87IXaGv004496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 7 Sep 2003 11:33:38 -0700 Message-ID: <3F5B79FA.7050900@Royer.com> Date: Sun, 07 Sep 2003 12:33:30 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070305080109010909090702" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070305080109010909090702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > > With the RECURRENCE-ID issue you and Robert have changed your mind > > several times, yet claim > > he is the one that is pig headed. Your so arrogant you will not even > > admit that you changed your mind or opinion and you still slam him > > with lies and insults. You started the RECURRENCE-ID issue by declaring > > that it was fixed forever. Now you say it changes with the set, > > you changed your mind to be mostly compatible with the non-fixed > > model, admit it and stop slamming him or anyone simply because > > you changed your mind to agree with them. > We did not change are minds. The scope of the original discussion was > changing an instance of a repeat set. > It was than asked is there ever a case where the recurrence-id's can be > reset. Re-read the archives, You declared that it never changed. You said on May 19: > I disagree, the recurrence-id must always refer to the original date. > > of the meeting. Lets say i had a 5 day repeating meeting. However I invited > you to just Monday Tuesday to start with, but for some reason you have not > received the mail yet. > I now reschedule Thursday Friday to a later time in the day and add you > to the invitee list. > You now get a sequence 2 invite for Thursday Friday > Later you finally receive the meeting for Monday Tuesday with sequence of 1. > If I allow recurrence dates to reset on a reschedule, I can not tell if the > Monday Tuesday invitee was rescheduled to Thursday Friday or if this is a > separate invite. Now you claim that it changes under some circumstances. And you have later admitted that because you got the sequence 2 before the sequence 1 that you would know to do a REFRESH. Marks comment is on the mark :-) -- 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 --------------ms070305080109010909090702 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTA3MTgzMzMxWjAjBgkqhkiG9w0BCQQxFgQUXCjFUoSfBiJda6a9E1UE wYQvPpswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAGYkBt03BJw94tttjX/l39XPkjJ+OuyhOvARjll6Pwn8eX5Byld8DtUAHWOn1+D1H zeSHPwDmFNvITglOjfS2klTxGOeTqZYYYkkGnqDqFKVUSg8BwphfEsvEweoF5CdkfQnCdqa5 Rgq9wZqqnluRdpG1VTa6ZE7rIjviPYnN1vBsVoMancRDEDaNGe3X8SDXTNpkHm5kdyEJE+Ka yqz4Vdcim2w92IZOskc5l0XN0PEOaYmVC0F6guoxrHQxbin+vHYAYyA0iFWkzMglMALSS/+L O9YloG7UOiD9Z9iQTU7+OVPBbdJaNlQleCu71wZ+GjWCbohH6X2JArXSsFQA1gAAAAAAAA== --------------ms070305080109010909090702-- From owner-ietf-calendar@mail.imc.org Mon Sep 8 00:07:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04852 for ; Mon, 8 Sep 2003 00:07:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h883bYeo001682 for ; Sun, 7 Sep 2003 20:37:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h883bY8d001681 for ietf-calendar-bks; Sun, 7 Sep 2003 20:37:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h883bXeo001675 for ; Sun, 7 Sep 2003 20:37:33 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F5B79FA.7050900@Royer.com> To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Sun, 7 Sep 2003 15:40:13 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/07/2003 11:39:04 PM, Serialize complete at 09/07/2003 11:39:04 PM Content-Type: multipart/alternative; boundary="=_alternative 006B9D0785256D9A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B9D0785256D9A_= Content-Type: text/plain; charset="US-ASCII" It does not change as long as you are changing just instance dates. It only changes if you change the entire rule. We were originally discussing changing instance dates. My response was in that scope. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 09/07/2003 02:33 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: [Fwd: CAP-12 - interm version 'A'] Robert_Ransdell@notesdev.ibm.com wrote: > > > With the RECURRENCE-ID issue you and Robert have changed your mind > > several times, yet claim > > he is the one that is pig headed. Your so arrogant you will not even > > admit that you changed your mind or opinion and you still slam him > > with lies and insults. You started the RECURRENCE-ID issue by declaring > > that it was fixed forever. Now you say it changes with the set, > > you changed your mind to be mostly compatible with the non-fixed > > model, admit it and stop slamming him or anyone simply because > > you changed your mind to agree with them. > We did not change are minds. The scope of the original discussion was > changing an instance of a repeat set. > It was than asked is there ever a case where the recurrence-id's can be > reset. Re-read the archives, You declared that it never changed. You said on May 19: > I disagree, the recurrence-id must always refer to the original date. > > of the meeting. Lets say i had a 5 day repeating meeting. However I invited > you to just Monday Tuesday to start with, but for some reason you have not > received the mail yet. > I now reschedule Thursday Friday to a later time in the day and add you > to the invitee list. > You now get a sequence 2 invite for Thursday Friday > Later you finally receive the meeting for Monday Tuesday with sequence of 1. > If I allow recurrence dates to reset on a reschedule, I can not tell if the > Monday Tuesday invitee was rescheduled to Thursday Friday or if this is a > separate invite. Now you claim that it changes under some circumstances. And you have later admitted that because you got the sequence 2 before the sequence 1 that you would know to do a REFRESH. Marks comment is on the mark :-) -- 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 --=_alternative 006B9D0785256D9A_= Content-Type: text/html; charset="US-ASCII"
It does not change as long as you are changing just instance dates.
It only changes if you change the entire rule.

We were originally discussing changing instance dates.  My response was in that scope.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


Doug Royer <Doug@royer.com>
Sent by: owner-ietf-calendar@mail.imc.org

09/07/2003 02:33 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: [Fwd: CAP-12 - interm version 'A']







Robert_Ransdell@notesdev.ibm.com wrote:
>
>  > With the RECURRENCE-ID issue you and Robert have changed your mind
>  > several times, yet claim
>  > he is the one that is pig headed. Your so arrogant you will not even
>  > admit that you changed your mind or opinion and you still slam him
>  > with lies and insults. You started the RECURRENCE-ID issue by declaring
>  > that it was fixed forever.  Now you say it changes with the set,
>  > you changed your mind to be mostly compatible with the non-fixed
>  > model, admit it and stop slamming him or anyone simply because
>  > you changed your mind to agree with them.

> We did not change are minds.  The scope of the original discussion was
> changing an instance of a repeat set.
> It was than asked is there ever a case where the recurrence-id's can be
> reset.

Re-read the archives, You declared that it never changed.

You said on May 19:

> I disagree, the recurrence-id must always refer to the original date.
>
> of the meeting.  Lets say i had a 5 day repeating meeting. However I
invited > you to just Monday Tuesday to start with, but for some reason you
have not
> received the mail yet.
> I now reschedule Thursday Friday to a later time in the day and add you
> to the invitee list.
> You now get a sequence 2 invite for Thursday Friday
> Later you finally receive the meeting for Monday Tuesday with sequence of 1.
> If I allow recurrence dates to reset on a reschedule, I can not tell if the
> Monday Tuesday invitee was rescheduled to Thursday Friday or if this is a
> separate invite.

Now you claim that it changes under some circumstances.
And you have later admitted that because you got the sequence 2 before
the sequence 1 that you would know to do a REFRESH.

Marks comment is on the mark :-)


--

 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
--=_alternative 006B9D0785256D9A_=-- From owner-ietf-calendar@mail.imc.org Mon Sep 8 11:26:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29567 for ; Mon, 8 Sep 2003 11:26:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88EwAeo074160 for ; Mon, 8 Sep 2003 07:58:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88Ew934074159 for ietf-calendar-bks; Mon, 8 Sep 2003 07:58:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Ew7eo074152 for ; Mon, 8 Sep 2003 07:58:07 -0700 (PDT) (envelope-from mark@ScheduleWorld.com) Received: from lin.home2.mark (CPE0080c6e8c57c-CM014500005442.cpe.net.cable.rogers.com [24.157.60.247]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 5E5E75062 for ; Mon, 8 Sep 2003 10:57:49 -0400 (EDT) From: Mark Swanson Organization: Web Service Solutions, Inc. To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] Date: Mon, 8 Sep 2003 10:58:34 -0400 User-Agent: KMail/1.5 References: <3F5A6FB3.D03EB25A@INET-Calendar.net> In-Reply-To: <3F5A6FB3.D03EB25A@INET-Calendar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309081058.34063.mark@ScheduleWorld.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On September 6, 2003 7:37 pm, Mark Smith wrote: > > I have seen you LIE on this list many times. At what point will the > chair of this working group stop this trouble maker? The process for calling someone a liar is to state the instance (perhaps recurring) where you thought the individual lied so they have the opportunity to defend. It's only fair. Heck, even I (no, it's true!) have been known to change my mind and even learn something from the posts on this list. I know I would like the chance to defend or explain a previous post if someone thought I was lying. Cheers. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web start (JNLP): http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Sep 8 14:09:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11675 for ; Mon, 8 Sep 2003 14:09:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88HrAeo085494 for ; Mon, 8 Sep 2003 10:53:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88HrAKU085493 for ietf-calendar-bks; Mon, 8 Sep 2003 10:53:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Hr9eo085487 for ; Mon, 8 Sep 2003 10:53:10 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F58EB57.8090904@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12 - interm version 'A' MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 8 Sep 2003 13:01:45 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/08/2003 01:54:37 PM, Serialize complete at 09/08/2003 01:54:37 PM Content-Type: multipart/alternative; boundary="=_alternative 005D90AF85256D9B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005D90AF85256D9B_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 09/05/2003 04:00:23 PM: > > Then how come not all text was changed like this? > > Not done. They why did you release CAP-12 and CAP-12-a if that change was not done? > > rules. After all, _that_ RFC uses 2 spaces after a period... > > 1) A draft does not obsolete an RFC until it is released. If you actualy read RFC 2223 then you'd see that it uses 2 spaces after a period, just like normal English. Guess you ignored that and misinterpreted that 1 line in the guidelines you cite. Had RFC 2223 meant for a single space to be used, _it_ would have used them... > 2) It does look as if that is the new direction. The only new direction I see is your change. The RFC editors are working to make it clearer I think by replacing that 1 line in RFC 2223 with the paragraph that expressly says how spacing should be. > 3) The draft is at -07 (not -06). And did that paragraph get removed between -06 and -07?.. So if the RFCs after 2223 have 2 spaces AND RFC 2223 uses 2 spaces after a period AND the new draft "Instructions for RFC Authors" guidelines the editorspoint you to (from http://www.rfc-editor.org/policy.html) says: (7) Spaces at the End of a Sentence When a sentence ended by a period is immediately followed by another sentence, there should be two blank spaces after the period. This rule provides clarity when an RFC is displayed or printed with a fixed-width font. I think our draft should follow their guidelines use 2 spaces after a period. It would make for a smaller diff than 707 changes so finding actual content changes would be easier for everyone. Unless you dont want folks to be able to easily find the changes... 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 005D90AF85256D9B_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 09/05/2003 04:00:23 PM:
> > Then how come not all text was changed like this?  
>
> Not done.
They why did you release CAP-12 and CAP-12-a if that change was not done?

> > rules.  After all, _that_ RFC uses 2 spaces after a period...
>
> 1) A draft does not obsolete an RFC until it is released.
If you actualy read RFC 2223 then you'd see that it uses 2 spaces after a period, just like normal English.  Guess you ignored that and misinterpreted that 1 line in the guidelines you cite.  Had RFC 2223 meant for a single space to be used, _it_ would have used them...

> 2) It does look as if that is the new direction.
The only new direction I see is your change.  The RFC editors are working to make it clearer I think by replacing that 1 line in RFC 2223 with the paragraph that expressly says how spacing should be.

> 3) The draft is at -07 (not -06).
And did that paragraph get removed between -06 and -07?..

So if the RFCs after 2223 have 2 spaces AND RFC 2223 uses 2 spaces after a period AND the new draft  "Instructions for RFC Authors" guidelines the editorspoint you to (from http://www.rfc-editor.org/policy.html) says:

       (7) Spaces at the End of a Sentence

         When a sentence ended by a period is immediately followed by
         another sentence, there should be two blank spaces after the
         period.  This rule provides clarity when an RFC is displayed
         or printed with a fixed-width font.

I think our draft should follow their guidelines use 2 spaces after a period.

It would make for a smaller diff than 707 changes so finding actual content changes would be easier for everyone.  Unless you dont want folks to be able to easily find the changes...

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 005D90AF85256D9B_=-- From owner-ietf-calendar@mail.imc.org Mon Sep 8 15:11:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15501 for ; Mon, 8 Sep 2003 15:11:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88ItGeo092218 for ; Mon, 8 Sep 2003 11:55:16 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88ItG9K092217 for ietf-calendar-bks; Mon, 8 Sep 2003 11:55:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88ItFeo092212 for ; Mon, 8 Sep 2003 11:55:16 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F5A6FB3.D03EB25A@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 8 Sep 2003 14:52:33 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/08/2003 02:55:15 PM, Serialize complete at 09/08/2003 02:55:15 PM Content-Type: multipart/alternative; boundary="=_alternative 0067B5AD85256D9B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067B5AD85256D9B_= Content-Type: text/plain; charset="US-ASCII" Mark mused on 09/06/2003 07:37:23 PM: >>>>> Go re-read Bruces email and tell me if he has posted even ONE >>>>> post >>>>> that backs up (some in recent posts); >>>>> >>>>> (a) ...I certainly dont recall any WG discussion on some of the bigger >>>>> issues ... >>>> >>>> Please point to the WG thread(s) where we discussed and resolved the >>>> issue of scoping on SEARCH? >>> >>> Go re-read my post (a) was not about SEARCH. It was was in response >>> to the text you sent. Your mis quoting me again. >> >> Hello! McFly!! Your (a) was a citation from one of my emails and >> your charge was I didnt describe "bigger issues" I was referring to. >> I did that. I listed 3 even (of which you only how include 1)! > > I have seen you LIE on this list many times. At what point will the > chair of this working group stop this trouble maker? I just have to laugh. I find it quite funny that Mark says I "LIE" when the citation Doug used were my own quotes and I was responding to their use. Doug claimed that I failed to back up any of my recent 'claims' with facts and cited (a) - (c). In response I sent back details supporting each reference and I separated them out in response to each point. In response to Dougs (a) citation from one of my emails (above) I provided not 1 but 3 actual references to "back up" that comment. The first one being: Please point to the WG thread(s) where we discussed and resolved the issue of scoping on SEARCH? Dougs response? He ignored 2 of the 3 references and simply said: Go re-read my post (a) was not about SEARCH. It was was in response to the text you sent. Your mis quoting me again. Well I dont know what he thought I was referring to in (a) (it was my comment he was quoting after all) but the undiscussed and unresolved issue of scoping results on a SEARCH is certainly a larger CAP issue that we recently found but NEVER actually discussed NOR has Doug acknowledged it in his rush to get to Last Call. Instead of any actual discussion, Mark proceeds to meander around, making lots of disparaging comments and totally unrelated or unfounded comments like: > With the RECURRENCE-ID issue you and Robert have changed your mind > several times, Sorry Mark, simply not true. Ive never changed my answer for the scenarios we discussed. Furthermore my answer was corroborated by both an analysis of the model in iTIP and eventually by the authors themselves. > You started the RECURRENCE-ID issue by declaring that it was fixed > forever. The scenario we were discussing was the case of simple instance reschedules. For that the RECURRENCE-ID never changes. No change of answer there. If you change the change the _recurrence_set_defintion_ then the RECURRENCE-ID "might also change" (iCalendar, Section 4.8.8.4). This however was not the scneario we were discussing. Perhaps you would have preferred if I qualified my answer with text unrelated to the discussion at the time so would have just confuse folks. No matter, my answer is still the same: RECURRENCE-ID does NOT change on an instance reschedule. >> It was NOT resolved. Another issue you conveniently forgot for > CAP-11 or to acknowledge lately. > > Did you bother reading his post? He CAN NOT change such things until the > chair calls consensus. Because CAP IS going to ship soon (are you > now going to claim I made a last call?) If he cant change things in CAP then why are there 707 changes reported by diff? Whats the rush to have CAP-12 and CAP-12-a so soon after CAP-11 if nothings changed? If you honestly believe there were "thousands" of typos and grammar changes then I have some land to sell you... Instead of discussing the issues raised you perfer to waste time and cycles with personal attacks. Gee, you sound so much like Doug you could be his twin brother. Misquoting or misunderstanding so often I have to laugh... > Or at the very least post your item list (I do not think you have one). Already done twice. Better learn to read the postings before you reply to them. > Do you have an issue list? Or is there just one item on your issue list > that > is to slow down CAP until you can ship your product? I dont need to do Dougs job for him do I? He's the editor so he's supposed to keep the issues list. In fact he claimed to have done that already but he failed to list the 3 that I mentioned already. On that same note I wouldn't dream of doing Dougs job of stalling CAP any more than hes already done by derailing discussion and haranguing those who try to raise issues; hes done a pretty good job of that so far. Im not working on any CAP product like Doug is; I merely am making sure there are no glaring issues in CAP 1.0 that should be resolved before it goes to Last Call. > You did not make a proposal at all. You declared you did not like > something. Have you read > the real proposals made by many that I read about on the list archive? Hehehe, you must be very blissful Mark. I made a clear proposal at least 4 times so far. You managed to miss that and the posted issues so either you are missing them intentionally like Doug or you just ignored them in an attempt to fire off your posting and distract from the WG from the real questions at hand. > I see you post nothing useful most of the time, you RARELY post > suggestions > or useful comments. Here a suggestion just for you Mark: read the postings before you respond. Ive posted both suggestions, comments and proposals. Both you and Doug seem to have a flair for ignoring them. > WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND > ABUSE OF OTHERS!! Oh, another funny. Just gotta laugh again since Im not the one whose stated goal is to use email bombarding to silence folks from discussing changes to CAP. Ive been a voice regarding the misinterpreting of iCalendar/iTIP and Im making sure that Doug does not just ignore raised issues with CAP in an attempt to get it out the door ASAP rather than fixing it first. Im not the only one nor am I going to just wither under some comic personal attack that reads much like one of Dougs digressions. > It takes for ever to read the archives and I am > finding that a HUGE percentage of Bruce's posts are inflated self ego > with > no technical contribution, but its lots of text. Hehehe, that describes your posting to a letter. Now, why dont you actually read some of the proposals and issues that have raised before you come back and waste more cycles? Or are you just interested in providing some comic distraction and deflection from discussion of the 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 0067B5AD85256D9B_= Content-Type: text/html; charset="US-ASCII"
Mark mused on 09/06/2003 07:37:23 PM:
>>>>> Go re-read Bruces email and tell me if he has posted even ONE
>>>>> post
>>>>> that backs up (some in recent posts);
>>>>>
>>>>> (a)   ...I certainly dont recall any WG discussion on some of the bigger
>>>>>       issues ...
>>>>
>>>> Please point to the WG thread(s) where we discussed and resolved the
>>>> issue of scoping on SEARCH?
>>>
>>> Go re-read my post (a) was not about SEARCH. It was was in response
>>> to the text you sent. Your mis quoting me again.
>>
>> Hello!  McFly!!  Your (a) was a citation from one of my emails and
>> your charge was I didnt describe "bigger issues" I was referring to.
>>  I did that.  I listed 3 even (of which you only how include 1)!
>
> I have seen you LIE on this list many times. At what point will the
> chair of this working group stop this trouble maker?
I just have to laugh.  I find it quite funny that Mark says I "LIE" when the citation Doug used were my own quotes and I was responding to their use.  

Doug claimed that I failed to back up any of my recent 'claims' with facts and cited (a) - (c).  In response I sent back details supporting each reference and I separated them out in response to each point.

In response to Dougs (a) citation from one of my emails (above) I provided not 1 but 3 actual references to "back up" that comment.  The first one being:

Please point to the WG thread(s) where we discussed and resolved the issue of scoping on SEARCH?

Dougs response?  He ignored 2 of the 3 references and simply said:

Go re-read my post (a) was not about SEARCH. It was was in response
to the text you sent. Your mis quoting me again.

Well I dont know what he thought I was referring to in (a) (it was my comment he was quoting after all) but the undiscussed and unresolved issue of scoping results on a SEARCH is certainly a larger CAP issue that we recently found but NEVER actually discussed NOR has Doug acknowledged it in his rush to get to Last Call.

Instead of any actual discussion, Mark proceeds to meander around, making lots of disparaging comments and totally unrelated or unfounded comments like:

> With the RECURRENCE-ID issue you and Robert have changed your mind
> several times,

Sorry Mark, simply not true.  Ive never changed my answer for the scenarios we discussed.  

Furthermore my answer was corroborated by both an analysis of the model in iTIP and eventually by the authors themselves.

> You started the RECURRENCE-ID issue by declaring that it was fixed
> forever.
The scenario we were discussing was the case of simple instance reschedules.  For that the RECURRENCE-ID never changes.  No change of answer there.

If you change the change the _recurrence_set_defintion_ then the RECURRENCE-ID "might also change" (iCalendar, Section 4.8.8.4).  This however was not the scneario we were discussing.  Perhaps you would have preferred if I qualified my answer with text unrelated to the discussion at the time so would have just confuse folks.  No matter, my answer is still the same: RECURRENCE-ID does NOT change on an instance reschedule.

>> It was NOT resolved. Another issue you conveniently forgot for
> CAP-11 or to acknowledge lately.
>
> Did you bother reading his post? He CAN NOT change such things until the
> chair calls consensus. Because CAP IS going to ship soon (are you
> now going to claim I made a last call?)
If he cant change things in CAP then why are there 707 changes reported by diff?  Whats the rush to have CAP-12 and CAP-12-a so soon after CAP-11 if nothings changed?  If you honestly believe there were "thousands" of typos and grammar changes then I have some land to sell you...

Instead of discussing the issues raised you perfer to waste time and cycles with personal attacks.  Gee, you sound so much like Doug you could be his twin brother.  Misquoting or misunderstanding so often I have to laugh...

> Or at the very least post your item list (I do not think you have one).
Already done twice.  Better learn to read the postings before you reply to them.

> Do you have an issue list? Or is there just one item on your issue list
> that
> is to slow down CAP until you can ship your product?
I dont need to do Dougs job for him do I?  He's the editor so he's supposed to keep the issues list.  In fact he claimed to have done that already but he failed to list the 3 that I mentioned already.  On that same note I wouldn't dream of doing Dougs job of stalling CAP any more than hes already done by derailing discussion and haranguing those who try to raise issues; hes done a pretty good job of that so far.

Im not working on any CAP product like Doug is; I merely am making sure there are no glaring issues in CAP 1.0 that should be resolved before it goes to Last Call.

> You did not make a proposal at all. You declared you did not like
> something. Have you read
> the real proposals made by many that I read about on the list archive?
Hehehe, you must be very blissful Mark.  I made a clear proposal at least 4 times so far.  You managed to miss that and the posted issues so either you are missing them intentionally like Doug or you just ignored them in an attempt to fire off your posting and distract from the WG from the real questions at hand.

> I see you post nothing useful most of the time, you RARELY post
> suggestions
> or useful comments.

Here a suggestion just for you Mark: read the postings before you respond.  

Ive posted both suggestions, comments and proposals.  Both you and Doug seem to have a flair for ignoring them.  

> WILL THE CHAIR PLEASE STOP BRUCE FROM HIS ENDLESS CRYING, LYING, AND
> ABUSE OF OTHERS!!

Oh, another funny.  Just gotta laugh again since Im not the one whose stated goal is to use email bombarding to silence folks from discussing changes to CAP.  

Ive been a voice regarding the misinterpreting of iCalendar/iTIP and Im making sure that Doug does not just ignore raised issues with CAP in an attempt to get it out the door ASAP rather than fixing it first.  Im not the only one nor am I going to just wither under some comic personal attack that reads much like one of Dougs digressions.

>                    It takes for ever to read the archives and I am
> finding that a HUGE percentage of Bruce's posts are inflated self ego
> with
> no technical contribution, but its lots of text.
Hehehe, that describes your posting to a letter.  

Now, why dont you actually read some of the proposals and issues that have raised before you come back and waste more cycles?  Or are you just interested in providing some comic distraction and deflection from discussion of the 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 0067B5AD85256D9B_=-- From owner-ietf-calendar@mail.imc.org Mon Sep 8 15:13:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15855 for ; Mon, 8 Sep 2003 15:13:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88INdeo090200 for ; Mon, 8 Sep 2003 11:23:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88INdg3090199 for ietf-calendar-bks; Mon, 8 Sep 2003 11:23:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88INbeo090190 for ; Mon, 8 Sep 2003 11:23:38 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h88INYGv019685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 8 Sep 2003 11:23:36 -0700 Message-ID: <3F5CC921.5080800@Royer.com> Date: Mon, 08 Sep 2003 12:23:29 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'A' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060203060807060100000602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060203060807060100000602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 09/05/2003 04:00:23 PM: > > > Then how come not all text was changed like this? > > > > Not done. > > They why did you release CAP-12 and CAP-12-a if that change was not done? So that you would not complain about not kowing what was done. And -12-b is ready. This next weekend I expect 12-c. -- 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 --------------ms060203060807060100000602 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTA4MTgyMzI5WjAjBgkqhkiG9w0BCQQxFgQU3f777WQDb+AWeGwjqFxQ qXmY9pMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEArg5tTHA2vkHtPaANk2LG7cj0c6VTlki4BSInKdhWvHBmI26ap57l92vkbSBL7Xpc mNbXb4gwKnqesPiXil9xDQrzDIgcfd3rZbEfHhdafuML0nzrpetbPjHq5kvP8CpUZKOi3tsN U+3OeGE6de4IlVBx0o67d7VjfcjHdpOFT8q6C2d04Wb7m/diefZgF6v/dkNCbK/QZ8bq4jb1 ye0uVlrTMb4luQzUlzQ/cOyi4pQLGiFLHm1t0EPyiK+MCzIY4k0sOczDGVtMK+13PZb0czIV ks8BErIwhrdgCw6JgOcjhyebyMwksmDZBpF+sH8jpUOE8+VKQNNLpW/8AKfM3AAAAAAAAA== --------------ms060203060807060100000602-- From owner-ietf-calendar@mail.imc.org Mon Sep 8 15:57:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18035 for ; Mon, 8 Sep 2003 15:57:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Jh3eo095648 for ; Mon, 8 Sep 2003 12:43:03 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88Jh33w095647 for ietf-calendar-bks; Mon, 8 Sep 2003 12:43:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Jh2eo095637 for ; Mon, 8 Sep 2003 12:43:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h88Jh1Gv020565 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 8 Sep 2003 12:43:03 -0700 Message-ID: <3F5CDBBF.5000808@Royer.com> Date: Mon, 08 Sep 2003 13:42:55 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010801080900010208090002" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010801080900010208090002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > >> It was NOT resolved. Another issue you conveniently forgot for > > CAP-11 or to acknowledge lately. > > > > Did you bother reading his post? He CAN NOT change such things until the > > chair calls consensus. Because CAP IS going to ship soon (are you > > now going to claim I made a last call?) > > If he cant change things in CAP then why are there 707 changes reported > by diff? Whats the rush to have CAP-12 and CAP-12-a so soon after > CAP-11 if nothings changed? If you honestly believe there were > "thousands" of typos and grammar changes then I have some land to sell > you... > > Instead of discussing the issues raised you perfer to waste time and > cycles with personal attacks. Gee, you sound so much like Doug you > could be his twin brother. Misquoting or misunderstanding so often I > have to laugh... Robert I think that Mark made his point again. You obviously did not read the post or you would know why. -- 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 --------------ms010801080900010208090002 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTA4MTk0MjU2WjAjBgkqhkiG9w0BCQQxFgQULFcrtDR1TfAf94uaBmC5 rzgm3fowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAeInZ6YkNoVOnYH4eCUUdlaZz4FHLiSQm/veD33lMt6F8SHcHVV+K8bZWwi2DUA+E 1alDKxOJlFEEYbkVZ3Z71NnXiOS6A3boFJ/S6uk9N9EqVZUZjP2TsXphnJHAJd55Poe58P9i XSdM7tv3B6mxR9ZgQfG5qYVxbjG+HOM2ChgHQpIF8/AS+3N6HCzvbdNSKjcprVjsqcndLknz vsfa591rvSvFqDnOUQnRI5YsvdxaUWyDJfAEzmHxJ40O2BUG42vvSyI4WtWT5nxCuLnLviZ9 uZ1wra3jZIUkxk2Jw9J+KQQKr3fRrNAy1qOO3sbBjNu62WjcKsR6wxnLjd9NywAAAAAAAA== --------------ms010801080900010208090002-- From owner-ietf-calendar@mail.imc.org Mon Sep 8 17:46:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23373 for ; Mon, 8 Sep 2003 17:46:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88LVseo004154 for ; Mon, 8 Sep 2003 14:31:54 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88LVsfN004153 for ietf-calendar-bks; Mon, 8 Sep 2003 14:31:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88LVqeo004142 for ; Mon, 8 Sep 2003 14:31:52 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h88LVfQj019236 for ; Mon, 8 Sep 2003 15:31:41 -0600 (MDT) Message-ID: <3F5CF53D.33AAE1C9@INET-Calendar.net> Date: Mon, 08 Sep 2003 15:31:41 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 he cant change things in CAP then why are there 707 changes > reported by diff? Whats the rush to have CAP-12 and CAP-12-a so soon > after CAP-11 if nothings changed? If you honestly believe there were > "thousands" of typos and grammar changes then I have some land to sell > you... Just looking at your own diff file and doing some math: Some one cut out many diffs and header/footer from your diff so I am guessing to some of these numbers. (142) were footer changed and would have changed anyway because the date of the draft changed. That Bruce finds it necessary to comment about on this list. (147) were because the expire date changed on header and elsewhere and would have changed anyway. That Bruce finds it necessary to comment about on this list. The TOC is 3 pages, so I'll assume that is (3) changes in your diff count. That Bruce finds it necessary to comment about on this list. (1) changed because the name of the draft version. That is about (293) utterly nontechnical changes so far that would have changed anyway just by releasing a new version. That Bruce finds it necessary to comment about on this list. That leaves about (414) changes. About (100) typos that were fixed - double words, missing words, spelling errors and wrong words. And Bruce does not comment on or care about on this list. That leaves about (314) changes. (1) added explanation about the ordering of properties and parameters. And Bruce does not comment on or care about on this list. (13) abnf fixes (5 misspelled names fixed). That Bruce does not comment on or care about on this list. (1) fix to the name of valid/recommended components. And Bruce does not comment on or care about on this list. (2) changes to remove that mysterious missing text that you can not seem to find. And Bruce does not comment on or care about on this list. (1) change to the security considerations. And Bruce does not comment on or care about on this list. Conclusions (based on your 707 number): About 118 changes that if done incorrectly would effect the protocol And Bruce does not comment on or care about on this list. And about 589 changes that Bruce seems to focus on that have no effect on the protocol. Again, get a life! It sure looks to me as if Bruce is trying to stall CAP. > Whats the rush to have CAP-12 and CAP-12-a so soon after CAP-11 i > nothings changed? So you want to complain if he waits for lots of changes. And you want to complain if he does not wait for lots of canges. You want me to take you seriously? > If you honestly believe there were "thousands" of typos > and grammar changes then I have some land to sell you... Yet another dishonest (sorry Pat, it is a lie. Enthusiasm is for children) statement from Bruce. Doug said "thousands WG and private emails" not thousands of typos. Now who is the one trying to mislead this list? Mark > 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 Mon Sep 8 19:09:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27800 for ; Mon, 8 Sep 2003 19:09:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Mqseo009533 for ; Mon, 8 Sep 2003 15:52:54 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88MqsuA009532 for ietf-calendar-bks; Mon, 8 Sep 2003 15:52:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Mqpeo009523 for ; Mon, 8 Sep 2003 15:52:51 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19wUsW-0003nt-00 for ; Tue, 09 Sep 2003 00:53:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19wUsV-0003nl-00 for ; Tue, 09 Sep 2003 00:52:59 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19wUs9-0008H8-00 for ; Tue, 09 Sep 2003 00:52:37 +0200 From: "Michael Fair" Subject: Re: [Fwd: CAP-12 - interm version 'A'] Date: Mon, 8 Sep 2003 15:50:19 -0700 Lines: 144 Message-ID: References: <3F5CF53D.33AAE1C9@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark, thank you for your analysis of the diffs, this is exactly the kind of thing we were trying to get Doug to do but he wouldn't. Bruce was simply saying that a lot has changed and given Doug's track record of late he has reason to be suspicious of this many changes in what should have just been minor changes. I agree with Bruce. Very few of us (you being one major exception) have the time to go through every page of CAP and figure out what changed from one draft to the next. Bruce asked Doug on several occasions to please provide a list, or do a diff that we could all see so those of us invested in understanding the draft don't have to reinvest in reunderstanding the draft from scratch. Doug told Bruce to do the diff. Ultimately, Bruce did the diff and found the results to be unusable as too many things had changed and there was no context for the changes. Without going through the whole set of changes (as you did) there was no way for anyone to know what had changed in that rat's nest. Doug was wrong about eliminating the double spaces after sentence periods and rather than just admit that, he's trying to cover his ass and defend how he's in the right. Fine if he misunderstood, admit he misunderstood and move on. Doug doesn't do this, hasn't done this, and the demonstrated propensity by him to defend himself rather than just admit his fault and move on has been the damaging source of productivity on the list. Bruce, myself, and others are tired of fighting with Doug over what are very reasonable and provable items and requests. Doug currently has me on his ignore list because I demanded he prove his assertions and wouldn't stop asking him to prove it (he never even made an attempt to provide such proof, and the evidence against his position would have continued to mount). I was sick and tired of hearing him claim something, but whenever any of us tried to actually do what he said was possible and failed, he wouldn't tell us what went wrong. We were forced to conclude that nothing went wrong except that Doug's claims were wrong to begin with. Trying to get the answer to the question of whether or not he, or we, were wrong using reason and documentable evidence has proven impossible thus far. All we're looking for in this thread is an organized list of changes, completion on the known issues raised (which Doug has not declared as "known" or "raised" but instead berates those who attempt to get thier official status), and security in knowing what has changed so that we, as reviewers and authorizers, can do our self appointed jobs. If Doug was going to strip out a single space from every sentence, that should a rev all by itself, should be the only thing that changes and should take place all at once. Finally, we should be forewarned its about to happen and why it's going to happen so we're prepared and can verify its necessity. In this case we would have shown the need for such a change to be inaccurate and we wouldn't even be having a discussion about it. Even if it was needed, by being its own rev we would know that the new rev says the exact same thing the old rev did, but the whitespace would be all different. That gives us security in knowing what we are reviewing. Then typos and simple ommissions should be listed as just that, typos and ommisions, and if there are a significant number of them, make those their own rev as well. Again, we keep our confidence in what we are reviewing. Knowing that only simple fixes to what was already there were the only things that changed. We should also be given an expectation as too how many of these we should expect. This way if expect 550 of them, and the diff says something similar then we can be confident that's all that what was done. By doing this, when we start actually adding and deleting text, a simple diff makes those changes apparent and they aren't going to get confused with the simple typos. Having a dozen or even more typos and ommisions corrected is fine, we can wade through those, but certainly not hundreds of them. Doug did all of the above arbitrarily, all at once, and won't tell us what he did. That's where we have a problem. We are left with zero confidence that what we had before is still the same document. So the simple way to restore confidence is to have the editor tell us what was done. The editor in question (Doug) won't do that. So people like Pat and yourself and others have to take out their own time to duplicate the effort of finding out what the heck Doug did so that we can restore our confidence in knowing what we are editing. This confidence is extremely important, now even more so, that we've recently just gone through a painful 2 months of debate over things that iTIP should never have had in it to begin with. iTIP didn't go through the proper scrutiny before being last called and we've wasted weeks worth of man hours trying to clean up the mess on this list alone (not too mention anyone who actually tries to implement the draft). > Conclusions (based on your 707 number): > About 118 changes that if done incorrectly would effect the protocol > And Bruce does not comment on or care about on this list. Thanks, now all we need to do is figure how to separate these 188 from the other 589. > And about 589 changes that Bruce seems to focus on that have no > effect on the protocol. Again, get a life! We have lives - which is why going through 589 changes of which none of them are important is considered a waste of our time. > > If you honestly believe there were "thousands" of typos > > and grammar changes then I have some land to sell you... > > Yet another dishonest (sorry Pat, it is a lie. Enthusiasm is for > children) > statement from Bruce. Doug said "thousands WG and private emails" not > thousands of typos. Now who is the one trying to mislead this list? If you believe that Doug has actually received thousands of emails about this between Cap-10 and now then I have some land to sell you... Wading through 589 typo-class changes out of 700+, in our resource limited time frames is not a reasonable request. Also, if Doug were on the reverse end of this deal and he was committed to having confidence that he knew what he was reviewing and what had changed and the editor seemed to be trying to skim over important issues in favor of getting CAP last called I'm sure he'd feel the same way. If he didn't then he didn't have a resource limited time frame, or at least doesn't have any respect from whoever he has to steal time from in order to wade through them. -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Sep 8 19:22:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28273 for ; Mon, 8 Sep 2003 19:22:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88NAEeo010367 for ; Mon, 8 Sep 2003 16:10:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88NAERV010365 for ietf-calendar-bks; Mon, 8 Sep 2003 16:10:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ahimsa.guppylake.com (ahimsa.guppylake.com [208.177.184.197]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88NACeo010360 for ; Mon, 8 Sep 2003 16:10:12 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from guppylake.com (pm504-08.dialip.mich.net [204.39.227.210]) by ahimsa.guppylake.com (8.12.8/8.12.8) with ESMTP id h88MwOvf027306; Mon, 8 Sep 2003 18:58:25 -0400 Date: Mon, 8 Sep 2003 19:10:54 -0400 Subject: Re: [Fwd: CAP-12 - interm version 'A'] Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-calendar@imc.org To: Mark Smith From: Nathaniel Borenstein In-Reply-To: <3F5CF53D.33AAE1C9@INET-Calendar.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit What Mark did simply proved that it is possible to do what Bruce had asked for. It is silly for more than one person to have to do this, and I always understood this to be a part of the job of the document editor. BTW the whole problem can be simplified a bit if the editor uses a tool like xml2rfc and produces diffs using the relevant component files... -- Nathaniel On Monday, September 8, 2003, at 05:31 PM, Mark Smith wrote: > > Bruce_Kahn@notesdev.ibm.com wrote: > >> If he cant change things in CAP then why are there 707 changes >> reported by diff? Whats the rush to have CAP-12 and CAP-12-a so soon >> after CAP-11 if nothings changed? If you honestly believe there were >> "thousands" of typos and grammar changes then I have some land to sell >> you... > > Just looking at your own diff file and doing some math: > > Some one cut out many diffs and header/footer from your diff so I am > guessing to some of these numbers. > > (142) were footer changed and would have changed > anyway because the date of the draft changed. > That Bruce finds it necessary to comment about on this list. > > (147) were because the expire date changed on header > and elsewhere and would have changed anyway. > That Bruce finds it necessary to comment about on this list. > > The TOC is 3 pages, so I'll assume that is (3) changes in your diff > count. > That Bruce finds it necessary to comment about on this list. > > (1) changed because the name of the draft version. > > That is about (293) utterly nontechnical changes so far that would > have changed anyway just by releasing a new version. > That Bruce finds it necessary to comment about on this list. > > That leaves about (414) changes. > > About (100) typos that were fixed - double words, missing words, > spelling > errors and wrong words. > And Bruce does not comment on or care about on this list. > > That leaves about (314) changes. > > (1) added explanation about the ordering of properties and parameters. > And Bruce does not comment on or care about on this list. > > (13) abnf fixes (5 misspelled names fixed). > That Bruce does not comment on or care about on this list. > > (1) fix to the name of valid/recommended components. > And Bruce does not comment on or care about on this list. > > (2) changes to remove that mysterious missing text that you can not > seem to find. > And Bruce does not comment on or care about on this list. > > (1) change to the security considerations. > And Bruce does not comment on or care about on this list. > > Conclusions (based on your 707 number): > About 118 changes that if done incorrectly would effect the protocol > And Bruce does not comment on or care about on this list. > > And about 589 changes that Bruce seems to focus on that have no > effect on the protocol. Again, get a life! It sure looks to me > as if Bruce is trying to stall CAP. > >> Whats the rush to have CAP-12 and CAP-12-a so soon after CAP-11 i >> nothings changed? > > So you want to complain if he waits for lots of changes. > And you want to complain if he does not wait for lots of canges. > You want me to take you seriously? > >> If you honestly believe there were "thousands" of typos >> and grammar changes then I have some land to sell you... > > Yet another dishonest (sorry Pat, it is a lie. Enthusiasm is for > children) > statement from Bruce. Doug said "thousands WG and private emails" not > thousands of typos. Now who is the one trying to mislead this list? > > Mark > >> 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 Mon Sep 8 19:39:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28661 for ; Mon, 8 Sep 2003 19:39:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88NQEeo011469 for ; Mon, 8 Sep 2003 16:26:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88NQEYP011467 for ietf-calendar-bks; Mon, 8 Sep 2003 16:26:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88NQDeo011452 for ; Mon, 8 Sep 2003 16:26:13 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h88NPwQj019403; Mon, 8 Sep 2003 17:25:59 -0600 (MDT) Message-ID: <3F5D1006.A641747@INET-Calendar.net> Date: Mon, 08 Sep 2003 17:25:58 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Fair CC: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: <3F5CF53D.33AAE1C9@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > Mark, thank you for your analysis of the diffs, > this is exactly the kind of thing we were trying > to get Doug to do but he wouldn't. How much does Doug get paid to find out for you? > Bruce was simply saying that a lot has changed and > given Doug's track record of late he has reason to > be suspicious of this many changes in what should have > just been minor changes. > I agree with Bruce. > Very few of us (you being one major exception) have the > time to go through every page of CAP and figure out what > changed from one draft to the next. It took me about 20 minutes looking at Bruce's diff. If you do not have that much time to spend on the CAP draft your waisting eveyones time by posting your opinions. From owner-ietf-calendar@mail.imc.org Mon Sep 8 19:49:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28843 for ; Mon, 8 Sep 2003 19:49:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Nc1eo012139 for ; Mon, 8 Sep 2003 16:38:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88Nc13P012138 for ietf-calendar-bks; Mon, 8 Sep 2003 16:38:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Nc0eo012129 for ; Mon, 8 Sep 2003 16:38:00 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h88NbZQj019414; Mon, 8 Sep 2003 17:37:35 -0600 (MDT) Message-ID: <3F5D12BE.84C8183F@INET-Calendar.net> Date: Mon, 08 Sep 2003 17:37:34 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Nathaniel Borenstein CC: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Nathaniel Borenstein wrote: > > What Mark did simply proved that it is possible to do what Bruce had > asked for. It is silly for more than one person to have to do this, > and I always understood this to be a part of the job of the document > editor. When I read a draft after reading some previous version of the draft I do a diff. I do not know of any other IETF list that has produced diffs of draft versions. I also can not find a list of differences for versions of any draft except the ones that Doug used to publish. Check for yourself. I could not find any. The process seems to be that there is debate then at random times a new version shows up. I have looked in several IETF lists and web pages and I think you have been misled by someone on this list that is making more false statements or is just trying to disrupt this list. It does not seem to be normal process. There also seems to be a lack of chair participation on this list. It is very hard to find any consensus called even when there is a overwhelming agreement. > BTW the whole problem can be simplified a bit if the editor uses a tool > like xml2rfc and produces diffs using the relevant component files... If you noticed he also published the XML source on calsch.org and his web site. And again I could not find any XML diffs published. Do you know of any? Mark From owner-ietf-calendar@mail.imc.org Mon Sep 8 20:10:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29431 for ; Mon, 8 Sep 2003 20:10:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Nvbeo012963 for ; Mon, 8 Sep 2003 16:57:37 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88NvbIH012962 for ietf-calendar-bks; Mon, 8 Sep 2003 16:57:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88NvZeo012956 for ; Mon, 8 Sep 2003 16:57:36 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h88NvJQj019436; Mon, 8 Sep 2003 17:57:19 -0600 (MDT) Message-ID: <3F5D175F.3282FBB2@INET-Calendar.net> Date: Mon, 08 Sep 2003 17:57:19 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Fair CC: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: <3F5CF53D.33AAE1C9@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > > If you honestly believe there were "thousands" of typos > > > and grammar changes then I have some land to sell you... > > > > Yet another dishonest (sorry Pat, it is a lie. Enthusiasm is for > > children) > > statement from Bruce. Doug said "thousands WG and private emails" not > > thousands of typos. Now who is the one trying to mislead this list? > > If you believe that Doug has actually received thousands of > emails about this between Cap-10 and now then I have some > land to sell you... I just checked the list, there were 1580 emails on the list from the announcement of -10 (end of Feb) until now. He said he went back a month before editing -11, and feb had 280 (est), total 1860. If he went back to Jan that is about 150 (est) more. Bringing the total to 2010. Now assuming he got any private emails, 2,000 is 'thousands'. Minus some number between -11 (or -12) and now. How much for that bridge? :-) From owner-ietf-calendar@mail.imc.org Mon Sep 8 21:33:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01146 for ; Mon, 8 Sep 2003 21:33:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h891Ipeo016075 for ; Mon, 8 Sep 2003 18:18:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h891IpN6016073 for ietf-calendar-bks; Mon, 8 Sep 2003 18:18:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from DrPepper (adsl-67-119-131-54.dsl.lsan03.pacbell.net [67.119.131.54]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h891Ineo016068 for ; Mon, 8 Sep 2003 18:18:50 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 3A2CF88872F; Mon, 8 Sep 2003 18:18:52 -0700 (PDT) Received: from cocacola (unknown [192.168.1.102]) by DrPepper (Postfix) with ESMTP id 898A98113E3; Mon, 8 Sep 2003 18:18:50 -0700 (PDT) Message-ID: <00ef01c37670$562e5e80$6601a8c0@daclubhouse.net> From: "Michael Fair" To: "Mark Smith" Cc: References: <3F5CF53D.33AAE1C9@INET-Calendar.net> <3F5D175F.3282FBB2@INET-Calendar.net> Subject: Re: [Fwd: CAP-12 - interm version 'A'] Date: Mon, 8 Sep 2003 18:18:54 -0700 Organization: DaClubhouse 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.3 required=5.0 tests=FWD_MSG,QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > > If you honestly believe there were "thousands" of typos > > > > and grammar changes then I have some land to sell you... > > > > > > Yet another dishonest (sorry Pat, it is a lie. Enthusiasm is for > > > children) > > > statement from Bruce. Doug said "thousands WG and private emails" not > > > thousands of typos. Now who is the one trying to mislead this list? > > > > If you believe that Doug has actually received thousands of > > emails about this between Cap-10 and now then I have some > > land to sell you... > > I just checked the list, there were 1580 emails on the list > from the announcement of -10 (end of Feb) until now. > > He said he went back a month before editing -11, and feb > had 280 (est), total 1860. > > If he went back to Jan that is about 150 (est) more. > Bringing the total to 2010. > > Now assuming he got any private emails, 2,000 is 'thousands'. > Minus some number between -11 (or -12) and now. Oh come on, how many of those actaully had proposed changes in them or did the threads even warrant reading for proposed changes? On Feb. 28th Doug announced the availability of -10. Since then I can only find 1095 emails to the list. Of which 376 (roughly 25%) have been directly related to the July 28th RECURRENCE-ID discussion where the disagreements over RECURRENCE-ID really starting flying and none of that discussion has had one sugestion in about CAP yet. On June 30th, Doug announced what was going in the -11 rev changes, so we expected those, but he flat out refused to tell us what went into -12 and its successor -12-a or -12-b. On August 18th, he mentioned 75 typos, grammar fixes, and requests for clarification. No one commented on his proposals for the security changes from the same day so I wouldn't expect those to be in there. He did say thanks to some people for submitting typos and grammatical errors on -12, -12-a, and -12-b. How those became 700+ changes and his sudden flip in behavior towards not giving out information that he'd previously been forthcoming with is definitely cause for investigation. Investigation is not in itself an accusation, it's being responsible on our part. Doug as our trusted editor suddenly being defiant about our questioning of a certainly out of the ordinary changeset didn't help matters any. However in the interst of moving forward I'll take this one back. Doug, even though you won't read this because have decided to ignore me, I apologize for asserting that you hadn't actually had changes from over 2000 emails. I had made the inappropriate but I think reasonable assumption that the "this" we were talking about were actual textual change recommendations after a bunch of people said "I agree" or simple typo and ommission/duplicate fixes and not "total number of emails sent to the list and Doug personally." -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Sep 8 21:42:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01409 for ; Mon, 8 Sep 2003 21:42:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h891V4eo016739 for ; Mon, 8 Sep 2003 18:31:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h891V4qi016738 for ietf-calendar-bks; Mon, 8 Sep 2003 18:31:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h891V2eo016732 for ; Mon, 8 Sep 2003 18:31:02 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19wXLp-0002qe-00 for ; Tue, 09 Sep 2003 03:31:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19wXLo-0002qW-00 for ; Tue, 09 Sep 2003 03:31:24 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19wXLS-0003Qf-00 for ; Tue, 09 Sep 2003 03:31:02 +0200 From: "Michael Fair" Subject: Re: [Fwd: CAP-12 - interm version 'A'] Date: Mon, 8 Sep 2003 18:31:06 -0700 Lines: 50 Message-ID: References: <3F5CF53D.33AAE1C9@INET-Calendar.net> <3F5D1006.A641747@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Mark Smith" wrote in message news:3F5D1006.A641747@INET-Calendar.net... > > Michael Fair wrote: > > > > Mark, thank you for your analysis of the diffs, > > this is exactly the kind of thing we were trying > > to get Doug to do but he wouldn't. > > How much does Doug get paid to find out for you? He doesn't have to "find out" he made the changes, and if there's so many that even he doesn't know what all happened, then we need his help and participation even more and its that much more unreasonable for us to do it without his assistance. > It took me about 20 minutes looking at Bruce's diff. > If you do not have that much time to spend on the Agreed, but the 20 minutes you spent wasn't even half the time it would require to do a real analysis. Ensuring that significant changes (of which you didn't even give a real count as I saw about 200 changed items left unaccounted for in your 20 minute examnination), can take time, and no one knows how long it is going to take them to wade through 700+ changes especially since most of them shouldsn't count but might which requires you to at least double check (since looking at lots of the similar kinds of things makes it easy to miss a simple MAY that became a MUST and such). I have since the original post taken back my argument that Doug actually had thousands of recommended changes to make. I consider this whole tangent unproductive and way off-topic from all of our purposes here. Pat has stepped in and is organizing a lot from these past discussions and I plan on picking this up again once she has posted what she has put together. I figure we can all then work from that list and add anything should it be missing at that time. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Sep 9 09:07:55 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04856 for ; Tue, 9 Sep 2003 09:07:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89Cs1eo086819 for ; Tue, 9 Sep 2003 05:54:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89Cs1le086818 for ietf-calendar-bks; Tue, 9 Sep 2003 05:54:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ahimsa.guppylake.com (ahimsa.guppylake.com [208.177.184.197]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89Crxeo086810 for ; Tue, 9 Sep 2003 05:54:00 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from guppylake.com (pm433-08.dialip.mich.net [204.39.225.210]) by ahimsa.guppylake.com (8.12.8/8.12.8) with ESMTP id h89CfUvf030575; Tue, 9 Sep 2003 08:41:50 -0400 Date: Tue, 9 Sep 2003 08:53:49 -0400 Subject: Re: [Fwd: CAP-12 - interm version 'A'] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-calendar@imc.org To: Mark Smith From: Nathaniel Borenstein In-Reply-To: <3F5D12BE.84C8183F@INET-Calendar.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit FWIW, I've always published such diffs -- preferably high level explanations, alternately actual diffs -- whenever I've authored such a document. -- N On Monday, September 8, 2003, at 07:37 PM, Mark Smith wrote: > > Nathaniel Borenstein wrote: >> >> What Mark did simply proved that it is possible to do what Bruce had >> asked for. It is silly for more than one person to have to do this, >> and I always understood this to be a part of the job of the document >> editor. > > When I read a draft after reading some previous version of the draft > I do a diff. I do not know of any other IETF list that has produced > diffs of draft versions. I also can not find a list of differences > for versions of any draft except the ones that Doug used to publish. > Check for yourself. I could not find any. > > The process seems to be that there is debate then at random times a > new version shows up. I have looked in several IETF lists and web pages > and I think you have been misled by someone on this list that is making > more false statements or is just trying to disrupt this list. It does > not > seem to be normal process. > > There also seems to be a lack of chair participation on this list. > It is very hard to find any consensus called even when there is a > overwhelming agreement. > >> BTW the whole problem can be simplified a bit if the editor uses a >> tool >> like xml2rfc and produces diffs using the relevant component files... > > If you noticed he also published the XML source on calsch.org and > his web site. And again I could not find any XML diffs published. > Do you know of any? > > Mark > From owner-ietf-calendar@mail.imc.org Tue Sep 9 09:49:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07280 for ; Tue, 9 Sep 2003 09:49:57 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89DU7eo091194 for ; Tue, 9 Sep 2003 06:30:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89DU7OY091192 for ietf-calendar-bks; Tue, 9 Sep 2003 06:30:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89DU6eo091168 for ; Tue, 9 Sep 2003 06:30:06 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F5CF53D.33AAE1C9@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 9 Sep 2003 09:23:10 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/09/2003 09:30:05 AM, Serialize complete at 09/09/2003 09:30:05 AM Content-Type: multipart/alternative; boundary="=_alternative 004989D785256D9C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004989D785256D9C_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Mark noted on 09/08/2003 05:31:41 PM: > Just looking at your own diff file and doing some math: >=20 > Some one cut out many diffs and header/footer from your diff so I am > guessing to some of these numbers. I said I sent the trimmed diff output to Pat which she hosted. I also=20 said how I calculated my numbers so go reread the postings again. The unedited diff output is ~614K. The trimmed down (no TOC & fewer=20 headers/footers) one is ~505K. In order to be clear about all of the=20 changes Ive sent Pat the unedited copy to host also. Both should be=20 available once Pat has a chance to put it up on her web site and post the=20 URL. > (142) were footer changed and would have changed > anyway because the date of the draft changed. > That Bruce finds it necessary to comment about on this list. >=20 > (147) were because the expire date changed on header > and elsewhere and would have changed anyway. > That Bruce finds it necessary to comment about on this list. Since you had time to go thru the diff output at least to do some math on=20 the changes, why is that so hard for Doug to do it?=20 Its easier to make progress if he did it for everyone instead of asking=20 everyone to do it individually and then comment on the changes they may or = may not find. One thing though, the footer/headers counted together actually: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ***************************** draft-ietf-calsch-cap-10-17Feb03.txt, Line=20 54 Royer, Babics, Hill, Mansour Expires May 4, 2003 [Page 1] =0C Internet-Draft Calendar Access Protocol (CAP) November 2002 *********************************** draft-ietf-calsch-cap-12-a.txt, Line=20 54 Royer, et al. Expires February 28, 2004 [Page 1] =0C Internet-Draft Calendar Access Protocol (CAP) August 2003 so no double dipping out of the count there... > That is about (293) utterly nontechnical changes so far that would > have changed anyway just by releasing a new version. > That Bruce finds it necessary to comment about on this list. > > That leaves about (414) changes. Actually its 707 - 3 for the TOC and - ~148 for the headers/footers which=20 leaves ~550 changes. > About (100) typos that were fixed - double words, missing words, > spelling > errors and wrong words. > And Bruce does not comment on or care about on this list. Thats because the first non-TOC / header / footer changes were either LWSP = changes (to the boilerplate) or all of Section 1 and a block of 1.1 were=20 considered 1 diff: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D **************************** draft-ietf-calsch-cap-10-17Feb03.txt, Line=20 247 ********************************** draft-ietf-calsch-cap-12-a.txt, Line=20 227 1. Introduction This document specifies how a Calendar CUA interacts with a CS to [Snip,snip, snip] capitalized, quoted-strings of text. For example, "REPLY" refers to the method for replying to a "REQUEST". When I see large blocks of reported changes I just have to step back and=20 wonder what the heck changed. Im not about to play "hunt the change" in=20 ~50 lines of text just to find if its LWSP changes or content changes.=20 > That leaves about (314) changes. [Snip, snip] > (1) change to the security considerations. > And Bruce does not comment on or care about on this list. Good. You managed to identify 18 actual changes out of the 450+=20 differences let that were not TOC / header / footer (assuming your 100=20 count above was correct) . Thats a good start although not a very good=20 ratio for signal to noise, about 4%. Why is it that Doug could not have given us this tally? You should ask=20 him next time you talk w/him since he is not keen on actually answering=20 questions about it here. > So you want to complain if he waits for lots of changes. Did I? Actually Ive been questioning the frequency of revision w/the=20 amount of discussed and resolved issues and thats just the opposite of=20 what you claim. I have merely raised a flag at the amount of changes reported by diff (as=20 requested be used by Doug). Considering the lack of discussion on the=20 real technical issues and the number of changes found it was not=20 unwaranted. Unliked by you and Doug yes but not unwaranted. You are merely Dougs proxy (or his alter ego) and are taking the focus off = the issues in CAP and Doug. How about focusing on the raised issues for a = while since you have so much energy?=20 I stand by my diff output and the concerns Ive raised.=20 Oh by the way, would you mind posting citations of the 18 actual changes=20 to the group for the benefit of those who dont have the cycles to find=20 them? Bruce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Kahn INet:=20 Bruce=5FKahn@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 004989D785256D9C_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Mark noted on 09/08/2003 05:31:41 PM:
> Just looking at your own diff file and doing some math:
>
> Some one cut out many diffs and header/footer from your diff so I am
> guessing to some of these numbers.
I said I sent the trimmed diff output to Pat which she hosted.    I also said how I calculated my numbe= rs so go reread the postings again.

The unedited diff output is ~614K. &= nbsp;The trimmed down (no TOC & fewer headers/footers) one is ~505K.  In order to be clear about all of the changes Ive sent Pat the unedited copy to host also.  Both should be available once Pat has a chance to put it up on her web site and post the URL.

> (142) were footer changed and would have change= d
> anyway because the date of the draft changed.
> That Bruce finds it necessary to comment about on this list.
>
> (147) were because the expire date changed on header
> and elsewhere and would have changed anyway.
> That Bruce finds it necessary to comment about on this list.
Since you had time to go thru the di= ff output at least to do some math on the changes, why is that so hard for Doug to do it?  

Its easier to make progress if he did it for everyone instead of asking everyone to do it individually and then comment on the changes they may or may not find.

One thing though, the footer/headers counted together actually:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
***************************** draft-ie= tf-calsch-cap-10-17Feb03.txt, Line 54
Royer, Babics, Hill, Mansour   &n= bsp;Expires May 4, 2003             [Page 1]
=0C
Internet-Draft       Ca= lendar Access Protocol (CAP)        November 2002
*********************************** dr= aft-ietf-calsch-cap-12-a.txt, Line 54
Royer, et al.       &nb= sp;  Expires February 28, 2004                [Page 1]
=0C
Internet-Draft       Ca= lendar Access Protocol (CAP)          August 2003

so no double dipping out of the count there...

> That is about (293) utterly nontechnical changes so far that would
> have changed anyway just by releasing a new version.
> That Bruce finds it necessary to comment about on this list.
>
> That leaves about (414) changes.
Actually its 707 - 3 for the TOC and - ~148 for the headers/footers which leaves ~550 changes.

> About (100) typos that were fixed - double word= s, missing words,
> spelling
> errors and wrong words.
> And Bruce does not comment on or care about on this list.
Thats because the first non-TOC / he= ader / footer changes were either LWSP changes (to the boilerplate) or all of Section 1 and a block of 1.1 were considered 1 diff:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
**************************** draft-iet= f-calsch-cap-10-17Feb03.txt, Line 247
********************************** dra= ft-ietf-calsch-cap-12-a.txt, Line 227
1. Introduction

   This document specifies h= ow a Calendar CUA interacts with a CS to
[Snip,snip, snip]
   capitalized, quoted-strin= gs of text. For example, "REPLY" refers to
   the method for replying to a "REQUEST".

When I see large blocks of reported changes I just have to step back and wonder what the heck changed.  Im not about to play "hunt the change" in ~50 lines of text just to find if its LWSP changes or content changes.  

> That leaves about (314) changes.
[Snip, snip]
> (1) change to the security considerations.
>     And Bruce does not comment on or care about on this list.
Good.  You managed to identify 18 actual changes out of the 450+ differences let that were not TOC / header / footer (assuming your 100 count above was correct) .  Thats a good start although not a very good ratio for signal to noise, about 4%.

Why is it that Doug could not have g= iven us this tally?  You should ask him next time you talk w/him since he is not keen on actually answering questions about it here.

> So you want to complain if he waits for lots of changes.

Did I?  Actually Ive been quest= ioning the frequency of revision w/the amount of discussed and resolved issues and thats just the opposite of what you claim.

I have merely raised a flag at the a= mount of changes reported by diff (as requested be used by Doug).  Consideri= ng the lack of discussion on the real technical issues and the number of chang= es found it was not unwaranted.  Unliked by you and Doug yes but not unwaranted.

You are merely Dougs proxy (or his a= lter ego) and are taking the focus off the issues in CAP and Doug.  How about focusing on the raised issues for a while since you have so much energy?  

I stand by my diff output and the concerns Ive raised.  

Oh by the way, would you mind posting citations of the 18 actual changes to the group for the benefit of those who dont have the cycles to find them?

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                                INet: Bruce=5FKahn@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 004989D785256D9C_=-- From owner-ietf-calendar@mail.imc.org Tue Sep 9 10:58:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15176 for ; Tue, 9 Sep 2003 10:58:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89EdEeo097369 for ; Tue, 9 Sep 2003 07:39:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89EdEVT097368 for ietf-calendar-bks; Tue, 9 Sep 2003 07:39:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89EdCeo097360 for ; Tue, 9 Sep 2003 07:39:13 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F5D175F.3282FBB2@INET-Calendar.net> To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 9 Sep 2003 10:38:32 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/09/2003 10:39:09 AM, Serialize complete at 09/09/2003 10:39:09 AM Content-Type: multipart/alternative; boundary="=_alternative 0050700285256D9C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0050700285256D9C_= Content-Type: text/plain; charset="US-ASCII" Mark claimed on 09/08/2003 07:57:19 PM: > > If you believe that Doug has actually received thousands of > > emails about this between Cap-10 and now then I have some > > land to sell you... > > I just checked the list, there were 1580 emails on the list > from the announcement of -10 (end of Feb) until now. Actually Doug posted his notice of the final CAP-10 draft to the WG at 02/28/2003 05:49:21 PM MST (about 7:50PM EST or the middle of the night for Europe on a Friday) so for real purposes it wasnt really seen until 3-Mar-03. Also, several hundred of the postings recently have been TOTALLY unrelated to CAP: there were about Dougs insistance on the delta model for RECURRENCE-ID. So dont try to factor those into your inflated count. A quick check gives me a rough count of just over 350 RECURRENCE-ID related postings alone between CAP-11 and CAP-12. If you plan to inflate your numbers to try and justify your claims, make sure you at least try to stick to relevant messages so its not so blatently off. Doug reported on 18-Aug-03: I have received about 75 typos, grammar, and requests for clarification to the -11 version of CAP. So I could not get them all in this weekend. He did not report any reason for the quick release of CAP-12-a so soon after 12. > If he went back to Jan that is about 150 (est) more. > Bringing the total to 2010. The stored query issue was still in discussion until mid/late Jan so that should have appeared on the CAP issues list then. However doing so would require discussion on the issue that Doug did not want to have. My guess is he has other motivations for wanting to keep it in since there appears to be WG concensus on removing stored queries until after CAP 1.0. Back on 4-Aug-03 Doug replied to my request for a change list with: > 1: Is there a diffs of CAP-10 (17-Feb) to CAP-11? I for one have no > time to reread CAP from cover to cover looking for changes. I'll put one up and then post its location to the WG. but this never materialized. The list for CAP-10 to CAP-11 changes should have been pretty simple since we spent most of May/June on RECURRENCE-ID and not on CAP and there was little WG traffic A quick count of the WG postings between the 22-Jul-03 annoucement of intent to release CAP-11 and 1-Feb-03 reveals ~670 postings. Of those: ~180 were RECURRENCE-ID related ~110 were iCalendar / UTF-8 / charset related ~30 were "Is CAP-10 ready for Last Call" discussion (not actual issue discussion) ~15 were IETF meeting logistics related ~20 were DTEND / DURATION interchange related ~20 were iCalendar / BYDAY / YEARLY related ~10 were iSIP related If you subtract just the non-CAP related counts above from the total postings you will find we had only ~285 postings _potentially_ related to CAP (or otherwise uncounted above). Hardly anywhere near a thousand. Stop trying to distract our attention Doug and lets get to work on CAP. If your intent is still "to oppose ANY AND ALL changes to CAP" then I fear we can make no progress and CAP will never get fixed and shipped. 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 0050700285256D9C_= Content-Type: text/html; charset="US-ASCII"
Mark claimed on 09/08/2003 07:57:19 PM:
> > If you believe that Doug has actually received thousands of
> > emails about this between Cap-10 and now then I have some
> > land to sell you...
>
> I just checked the list, there were  1580 emails on the list
> from the announcement of -10 (end of Feb) until now.
Actually Doug posted his notice of the final CAP-10 draft to the WG at 02/28/2003 05:49:21 PM MST (about 7:50PM EST or the middle of the night for Europe on a Friday) so for real purposes it wasnt really seen until 3-Mar-03.

Also, several hundred of the postings recently have been TOTALLY unrelated to CAP: there were about Dougs insistance on the delta model for RECURRENCE-ID.   So dont try to factor those into your inflated count.  A quick check gives me a rough count of just over 350 RECURRENCE-ID related postings alone between CAP-11 and CAP-12.

If you plan to inflate your numbers to try and justify your claims, make sure you at least try to stick to relevant messages so its not so blatently off.

Doug reported on 18-Aug-03:

I have received about 75 typos, grammar, and requests for clarification
to the -11 version of CAP. So I could not get them all in this weekend.

He did not report any reason for the quick release of CAP-12-a so soon after 12.  

> If he went back to Jan that is about 150 (est) more.
> Bringing the total to 2010.
The stored query issue was still in discussion until mid/late Jan so that should have appeared on the CAP issues list then.  However doing so would require discussion on the issue that Doug did not want to have.  My guess is he has other motivations for wanting to keep it in since there appears to be WG concensus on removing stored queries until after CAP 1.0.

Back on 4-Aug-03 Doug replied to my request for a change list with:
> 1: Is there a diffs of CAP-10 (17-Feb) to CAP-11?  I for one have no
> time to reread CAP from cover to cover looking for changes.

I'll put one up and then post its location to the WG.
but this never materialized.  The list for CAP-10 to CAP-11 changes should have been pretty simple since we spent most of May/June on RECURRENCE-ID and not on CAP and there was little WG traffic

A quick count of the WG postings between the 22-Jul-03 annoucement of intent to release CAP-11 and 1-Feb-03 reveals ~670 postings.  Of those:

~180 were RECURRENCE-ID related
~110 were iCalendar / UTF-8 / charset related
~30 were "Is CAP-10 ready for Last Call" discussion (not actual issue discussion)
~15 were IETF meeting logistics related
~20 were DTEND / DURATION interchange related
~20 were iCalendar / BYDAY / YEARLY related
~10 were iSIP related

If you subtract just the non-CAP related counts above from the total postings you will find we had only ~285 postings _potentially_ related to CAP (or otherwise uncounted above).  Hardly anywhere near a thousand.

Stop trying to distract our attention Doug and lets get to work on CAP.  If your intent is still "to oppose ANY AND ALL changes to CAP" then I fear we can make no progress and CAP will never get fixed and shipped.

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 0050700285256D9C_=-- From owner-ietf-calendar@mail.imc.org Tue Sep 9 12:19:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19923 for ; Tue, 9 Sep 2003 12:19:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89G5Oeo006856 for ; Tue, 9 Sep 2003 09:05:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89G5NAU006855 for ietf-calendar-bks; Tue, 9 Sep 2003 09:05:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89G5Meo006846 for ; Tue, 9 Sep 2003 09:05:22 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h89G5GQj021177; Tue, 9 Sep 2003 10:05:16 -0600 (MDT) Message-ID: <3F5DFA3C.18BB143F@INET-Calendar.net> Date: Tue, 09 Sep 2003 10:05:16 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Joerg Reichelt , ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Joerg Reichelt wrote: > > Mark, > > Although such statistics are interesting and entertaining, > these kinds of messages are not really helpful in solving any > problems, and are wasting the time and energy of a lot of > people on this mailing list. I know you didn't start it, but > you are contributing, and I can't see how any of the messages > I received in this thread solve anything. So, let's move on. > We have bigger fish to fry. I am sorry that facts are not in your interest. A fact is that Bruce lied again. And a fact is that there were at least 2000 public emails. And is that it is reasonable to assume that at least one private email contained a change. A fact is that it does not look as if Doug is the the one misleading this list. From owner-ietf-calendar@mail.imc.org Tue Sep 9 12:24:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20155 for ; Tue, 9 Sep 2003 12:24:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GDZeo007149 for ; Tue, 9 Sep 2003 09:13:35 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89GDZMV007147 for ietf-calendar-bks; Tue, 9 Sep 2003 09:13:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GDXeo007133 for ; Tue, 9 Sep 2003 09:13:33 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h89GDGQj021185; Tue, 9 Sep 2003 10:13:16 -0600 (MDT) Message-ID: <3F5DFC1C.2FDDB816@INET-Calendar.net> Date: Tue, 09 Sep 2003 10:13:16 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Fair CC: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: <3F5CF53D.33AAE1C9@INET-Calendar.net> <3F5D175F.3282FBB2@INET-Calendar.net> <00ef01c37670$562e5e80$6601a8c0@daclubhouse.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > > > > > If you honestly believe there were "thousands" of typos > > > > > and grammar changes then I have some land to sell you... > > > > > > > > Yet another dishonest (sorry Pat, it is a lie. Enthusiasm is for > > > > children) > > > > statement from Bruce. Doug said "thousands WG and private emails" not > > > > thousands of typos. Now who is the one trying to mislead this list? > > > > > > If you believe that Doug has actually received thousands of > > > emails about this between Cap-10 and now then I have some > > > land to sell you... > > > > I just checked the list, there were 1580 emails on the list > > from the announcement of -10 (end of Feb) until now. > > > > He said he went back a month before editing -11, and feb > > had 280 (est), total 1860. > > > > If he went back to Jan that is about 150 (est) more. > > Bringing the total to 2010. > > > > Now assuming he got any private emails, 2,000 is 'thousands'. > > Minus some number between -11 (or -12) and now. > > Oh come on, how many of those actaully had > proposed changes in them or did the threads even warrant > reading for proposed changes? Who cares? > On Feb. 28th Doug announced the availability > of -10. Since then I can only find 1095 emails to > the list. Of which 376 (roughly 25%) have been > directly related to the July 28th RECURRENCE-ID > discussion where the disagreements over > RECURRENCE-ID really starting flying and none of > that discussion has had one sugestion in about > CAP yet. My list shows 1580, I wonder where the difference is. I copied the archive to a local file, made a 2nd copy deleted all of the messages prior to 28 feb, then loaded the result in netscape, it had 1580 email in it. Then just by looking I estimated the Feb ad Jan emails. You did not read all of the RECURRENCE-ID issues did you? They were not all only about RECURRENCE-ID. There were messages where people did not change the subject line or mixed multiple topics in the message. From owner-ietf-calendar@mail.imc.org Tue Sep 9 12:30:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20504 for ; Tue, 9 Sep 2003 12:30:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GKVeo007613 for ; Tue, 9 Sep 2003 09:20:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89GKVY4007612 for ietf-calendar-bks; Tue, 9 Sep 2003 09:20:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GKTeo007605 for ; Tue, 9 Sep 2003 09:20:30 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h89GK3Qj021194; Tue, 9 Sep 2003 10:20:03 -0600 (MDT) Message-ID: <3F5DFDB3.DEF9195@INET-Calendar.net> Date: Tue, 09 Sep 2003 10:20:03 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Fair CC: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: <3F5CF53D.33AAE1C9@INET-Calendar.net> <3F5D1006.A641747@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > "Mark Smith" wrote in message > news:3F5D1006.A641747@INET-Calendar.net... > > > > Michael Fair wrote: > > > > > > Mark, thank you for your analysis of the diffs, > > > this is exactly the kind of thing we were trying > > > to get Doug to do but he wouldn't. > > > > How much does Doug get paid to find out for you? > > He doesn't have to "find out" he made the changes, > and if there's so many that even he doesn't know > what all happened, then we need his help and > participation even more and its that much more > unreasonable for us to do it without his assistance. > > It took me about 20 minutes looking at Bruce's diff. > > If you do not have that much time to spend on the > > Agreed, but the 20 minutes you spent wasn't even half > the time it would require to do a real analysis. I feel confident that I understand the changes after 20 minutes. After looking at them I also feel confident that anyone that has been following CAP can figure it out from just a file diff in 20 or so minutes. If you are talking about comparing the mailing list to the changes then yes that will take time. I have not seen anyone ever produce a diff that contained cross references to mailing list archive entries. Where you said: > Pat has stepped in and is organizing a lot from these > past discussions and I plan on picking this up again > once she has posted what she has put together. I think that if this had been done in the past then these conspiracy theories would have not escalated. I applaud Pat for this work and am anxiously awaiting the results. From owner-ietf-calendar@mail.imc.org Tue Sep 9 12:36:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20824 for ; Tue, 9 Sep 2003 12:36:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GP2eo007812 for ; Tue, 9 Sep 2003 09:25:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89GP2U3007811 for ietf-calendar-bks; Tue, 9 Sep 2003 09:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GP1eo007803 for ; Tue, 9 Sep 2003 09:25:01 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h89GOvQj021204; Tue, 9 Sep 2003 10:24:57 -0600 (MDT) Message-ID: <3F5DFED8.510B272A@INET-Calendar.net> Date: Tue, 09 Sep 2003 10:24:56 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@notesdev.ibm.com CC: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: > > > (142) were footer changed and would have changed > > anyway because the date of the draft changed. > > That Bruce finds it necessary to comment about on this list. > > > > (147) were because the expire date changed on header > > and elsewhere and would have changed anyway. > > That Bruce finds it necessary to comment about on this list. > > Since you had time to go thru the diff output at least to do some math > on the changes, why is that so hard for Doug to do it? Why is is so hard for you to admit that your posts of late have no technical content or CAP protocol issues in them. > Oh by the way, would you mind posting citations of the 18 actual > changes to the group for the benefit of those who dont have the cycles > to find them? I did not make some management report to publish. I simply looked at the file and had a note book next to me. Something I think Doug has been saying you should do for yourself. From owner-ietf-calendar@mail.imc.org Tue Sep 9 12:38:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20897 for ; Tue, 9 Sep 2003 12:38:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GQMeo007869 for ; Tue, 9 Sep 2003 09:26:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89GQLkp007868 for ietf-calendar-bks; Tue, 9 Sep 2003 09:26:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GQKeo007862 for ; Tue, 9 Sep 2003 09:26:20 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (www.safexchange.cc [192.168.169.21]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h89GQGQj021209; Tue, 9 Sep 2003 10:26:16 -0600 (MDT) Message-ID: <3F5DFF28.2A1E2268@INET-Calendar.net> Date: Tue, 09 Sep 2003 10:26:16 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@notesdev.ibm.com CC: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: > > Mark claimed on 09/08/2003 07:57:19 PM: > > > If you believe that Doug has actually received thousands of > > > emails about this between Cap-10 and now then I have some > > > land to sell you... > > > > I just checked the list, there were 1580 emails on the list > > from the announcement of -10 (end of Feb) until now. > > Actually Doug posted his notice of the final CAP-10 draft to the WG at > 02/28/2003 05:49:21 PM MST (about 7:50PM EST or the middle of the > night for Europe on a Friday) so for real purposes it wasnt really > seen until 3-Mar-03. Which is relevant in what way to anything? From owner-ietf-calendar@mail.imc.org Tue Sep 9 12:53:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21807 for ; Tue, 9 Sep 2003 12:53:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GfWeo008567 for ; Tue, 9 Sep 2003 09:41:32 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89GfWoX008566 for ietf-calendar-bks; Tue, 9 Sep 2003 09:41:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GfVeo008560 for ; Tue, 9 Sep 2003 09:41:31 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h89GfUGv001177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 9 Sep 2003 09:41:31 -0700 Message-ID: <3F5E02B4.2000902@Royer.com> Date: Tue, 09 Sep 2003 10:41:24 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030106040701000604030600" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030106040701000604030600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Stop trying to distract our attention Doug and lets get to work on CAP. > If your intent is still "to oppose ANY AND ALL changes to CAP" then I > fear we can make no progress and CAP will never get fixed and shipped. Mark is right, you do not misunderstand what your read, your just lying when you imply that is the context of that quote. -- 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 --------------ms030106040701000604030600 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC 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+rthzH60wggUBMIIEaqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkw NTAwMDAwMFoXDTA0MDkxNzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA4ha84gjfhbq3TUP9jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvo LcGHWzI8bXMYWkexGTcsVwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98 J7m1oF/AYchfuBhlHdG4r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXg z7t4BNSxBZbbFuJ8yG7ySkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsC p2W/dTqWNTo3PlmMckJyHlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCC ARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG +EUBBgcEBhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIz h2lxOF9dZMORLGmHOKVqUPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpD MM6as2Y511y3P2f57nRnWHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMIIF ATCCBGqgAwIBAgIQMf+ObfuDfLv1v9fKUzQUwjANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVh bCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzA5MDUwMDAwMDBaFw0w NDA5MTcyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2Nh cGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5k b3VnQHJveWVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOIWvOII34W6 t01D/Y6NZDZw+ZroUD8lyUjvZLUcZVHg7bpwayFxXEX7zwkmuZpTOr7r6C3Bh1syPG1zGFpH sRk3LFcD9/bXZgpQ94nelLvxz4McQK2gjuWH5u6ZQEb0+NnCmhO7ps8/fCe5taBfwGHIX7gY ZR3RuK+0nepS1zcd43ZZBiB5OGsaR+I+viJEyRvVYRA7IfkyHpEfovFl4M+7eATUsQWW2xbi fMhu8kpCmwFFMxNrfJ1X3G38g9vcgZfBhWn7dT781ezM+rU5Y9mQ94FLAqdlv3U6ljU6Nz5Z jHJCch5V7bkrBG93pITMRl5BSX/5RAyIPJohjEk0hv0CAwEAAaOCARwwggEYMAkGA1UdEwQC MAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5j LjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQu IChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAUBgpghkgBhvhFAQYHBAYWBE5v bmUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCDngAwOPVPXNlEkTRUU3n0cUAFjILSM4dpcThfXWTDkSxp hzilalD2gC8gPHFg75yFibO4NDg/pkKVRQU4rD9eEyuJl4aByMvih7BKQzDOmrNmOddctz9n +e50Z1hysH/OLL0RrkjhtrgllSkls4G0CRo94wQNk7YrHnagQOc0ojGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAx/45t+4N8 u/W/18pTNBTCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMDkwOTE2NDEyNVowIwYJKoZIhvcNAQkEMRYEFLU4aNwx7XxznfGF KWsMkHKhabqXMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/ jm37g3y79b/XylM0FMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3 DQEBAQUABIIBAK+d9Tm0VQ7+aDiDIIpVqlWBq/RWS8nXsxcTvLTjjACcmX3IJnyDsbhYcwBi rJzks/36inmyNwmtxI+T1y+ocj3CQEfLuhfxQhGFQV8zxhoHueBXfD/s3jczfXSFyILQV7y7 SZ2hsaUDJ2FXZsJ5XFsd8Lw7TAgNoN0EIfQUkncEGE0aWoy180FYTcdVgQoZu8k4BshWWgmn ZGAsb6d0DCryXNBE5LCucXX4MxPzc4RZdA1dk+YPoljTcY0YdiuJlFvwa3y3TWfEPPRY/kJK UbY4orWd0Susy/NSp7CMLjSrovwmS5gRMslzft1jEOyehk7O0T5/nNWY+OBwmeM+Xd4AAAAA AAA= --------------ms030106040701000604030600-- From owner-ietf-calendar@mail.imc.org Wed Sep 10 19:29:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22881 for ; Wed, 10 Sep 2003 19:29:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ANA8eo046025 for ; Wed, 10 Sep 2003 16:10:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8ANA8tG046024 for ietf-calendar-bks; Wed, 10 Sep 2003 16:10:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ANA5eo046008 for ; Wed, 10 Sep 2003 16:10:05 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8ANA4Gv019702 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 10 Sep 2003 16:10:06 -0700 Message-ID: <3F5FAF47.8050901@Royer.com> Date: Wed, 10 Sep 2003 17:09:59 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP - BEEP Profile References: <3F09D5AC.4000502@Royer.com> In-Reply-To: <3F09D5AC.4000502@Royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000701030704050209050202" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000701030704050209050202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Looking through the latest CAP I noticed that I had forgot to include the BEEP profile information that I posted on 07-July-2003. This (unless there are objections) will be in the next release of CAP. This will be the contents of section 12.1: ----------------------------------------------------------------------- 12.1 BEEP Profile Registration Beep replies will be one to one (1:1 MSG/RPY) if possible and one to many (1:many MSG/ANS) when the TARGET changes. Profile Identification: specify a URI [10] that authoritatively identifies this profile. http://iana.org/beep/cap/1.0 Message Exchanged during Channel Creation: CUAs SHOULD supply the BEEP "localize" attributes in the BEEP "greeting" messages. CSs SHOULD supply the BEEP "localize" attributes in the BEEP "greeting" messages. CUAs SHOULD supply the BEEP "serverName" attribute at channel creation time to the CS so that if the CS is performing virtual hosting the CS can determine the intended virtual host. CSs that do not support virtual hosting may ignore the BEEP "serverName" attribute. Messages starting one-to-one exchanges: The initial message each direction MUST BE single "text/calendar" object containing a CAP "CAPABILITY" CMD and must not be part of a MIME multipart message. After the initial message then a BEEP "MSG" may contain one or more MIME objects at least one of which MUST be "text/calendar" and each "text/calendar" MIME object MUST contain a CAP "CMD" property. The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "MSG" so long as all of the "text/ calendar" CAP objects have the same "TARGET" property value. Messages in positive replies: After the initial message then a BEEP "RPY" may contain one or more MIME objects at least one of which MUST be "text/calendar" and each "text/calendar" MIME object MUST contain a CAP "CMD" property. All "text/calendar" MIME objects in a single BEEP "RPY" messages MUST have the same "TARGET" property value. The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "RPY" so long as all of the "text/ calendar" CAP objects have the same "TARGET" property value. MIME objects in a single BEEP "RPY" so long as all of the "text/ calendar" CAP objects have the same "TARGET" property value. Messages in negative replies: Any valid "text/calendar" MIME object that contains CAP "REQUEST-STATUS" property and a CAP "CMD" property with a property value of "REPLY". And where the CS has determined the requested operation to be a fatal error. And when the CS has performed NO operation that effected the contents of any part of the CS or any calendar controlled by the CS. Messages in one-to-many exchanges: After the initial message then a BEEP "MSG" may contain one or more MIME objects at least one of which MUST be "text/calendar" and each "text/calendar" MIME object MUST contain a CAP "CMD" property. The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "MSG" so long as all of the "text/ calendar" CAP objects have the same "TARGET" property value. The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "ANS" so long as all of the "text/ calendar" CAP objects in EACH BEEP "ANS" message have the same "TARGET" property value. Each unique "TARGET" property value per BEEP "ANS" message. Message Syntax: They are CAP "text/calendar" MIME objects as specified in this memo. Message Semantics: As defined in this memo. ------------------------------------------------------------------------- -- 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 --------------ms000701030704050209050202 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTEwMjMwOTU5WjAjBgkqhkiG9w0BCQQxFgQUXNqXxXeGePdRPq6IOHhg 4WKO+ZAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAnXj3TaHUYGpk+ALsW1l2WEyYFY+wLPqYvj8PSL+zNWvgJZiAdoTubagYVzK9IMrK gRxg1FSikcokqTQr7Kad5uyA1PZt+85JhIoK2z1ts+DrG3hsEj4OE1JrSZYDiyj6YaBASeQR 3ssSCxs4Lz8V2M+LLjnEEzJrvNHSSi6hH9B++LvvYav5Njt0RZM9mM65pYGtSNP//mYfsAiH Jf0AGu6F5z8v4H4Up4pC5wl/NzX0YZSL4pLXBFgRhp8xuyx3eDOaibLomIU3Xy07zsMVieIt LHdTKz7myOCYd93FfjDV8lkVXOB+S2qaZaKmfshflzH9+a6FwD5w7lfTMpJDegAAAAAAAA== --------------ms000701030704050209050202-- From owner-ietf-calendar@mail.imc.org Sun Sep 14 18:35:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16815 for ; Sun, 14 Sep 2003 18:35:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EMGfeo043643 for ; Sun, 14 Sep 2003 15:16:41 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8EMGfX5043642 for ietf-calendar-bks; Sun, 14 Sep 2003 15:16:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ahimsa.guppylake.com (ahimsa.guppylake.com [208.177.184.197]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EMGdeo043637 for ; Sun, 14 Sep 2003 15:16:39 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from guppylake.com (linksys.guppylake.com [208.177.184.199]) by ahimsa.guppylake.com (8.12.8/8.12.8) with ESMTP id h8EM4Xvf028726; Sun, 14 Sep 2003 18:04:33 -0400 Date: Sun, 14 Sep 2003 18:17:12 -0400 Subject: Re: CAP - BEEP Profile Content-Type: multipart/alternative; boundary=Apple-Mail-12--628713385 Mime-Version: 1.0 (Apple Message framework v552) From: Nathaniel Borenstein To: "ietf-calendar@imc.org" In-Reply-To: <3F5FAF47.8050901@Royer.com> Message-Id: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-12--628713385 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I'm not any more of a BEEP expert than I am a CAP expert, but I consulted Mr. BEEP himself, Marshall Rose, and got a few comments from him that look potentially useful. Most of them are just clarifications, although the last one seems to go a bit deeper. -- Nathaniel From: Marshall Rose Date: Thu Sep 11, 2003 6:02:10 PM America/Detroit To: Nathaniel Borenstein Subject: Re: Fwd: CAP - BEEP Profile >> Profile Identification: specify a URI [10] that authoritatively >> identifies this profile. >> >> http://iana.org/beep/cap/1.0 >> >> Message Exchanged during Channel Creation: >> >> CUAs SHOULD supply the BEEP "localize" attributes in the BEEP >> "greeting" messages. >> >> CSs SHOULD supply the BEEP "localize" attributes in the BEEP >> "greeting" messages. well, okay. the spec says: the "localize" attribute, if present, contains one or more language tokens (defined in ), each identifying a desirable language tag to be used by the remote BEEP peer when generating textual diagnostics for the "close" and "error" elements (the tokens are ordered from most to least desirable); and, >> CUAs SHOULD supply the BEEP "serverName" attribute at channel >> creation time to the CS so that if the CS is performing virtual >> hosting the CS can determine the intended virtual host. CSs that do >> not support virtual hosting may ignore the BEEP "serverName" >> attribute. well, okay. the spec says: The "serverName" attribute for the first successful "start" element received by a BEEP peer is meaningful for the duration of the BEEP session. If present, the BEEP peer decides whether to operate as the indicated "serverName"; if not, an "error" element is sent in a negative reply. so i guess that using "may" is ok, though perhaps "MAY" is more appropriate. in otherwords, you can lose the text about localize and serverName and wouldn't lose anything, since this is just saying what the spec says, albeit less precisely. >> Messages starting one-to-one exchanges: >> >> The initial message each direction MUST BE single "text/calendar" >> object containing a CAP "CAPABILITY" CMD and must not be part of a >> MIME multipart message. not a sentence. this would read better if it actually mentioned the term "MIME media type". actually, a state diagram of the messages exchanged might actually explain what's trying to be conveyed. >> After the initial message then a BEEP "MSG" may contain one or more >> MIME objects at least one of which MUST be "text/calendar" and each >> "text/calendar" MIME object MUST contain a CAP "CMD" property. >> >> The BEEP "MSG" messages can only contain MIME "multipart" MIME >> objects if the other endpoint has received a CAP "CAPABILITY" >> indicating the other endpoint supports multipart MIME objects. This >> does not prevent the endpoint from sending multiple "text/calendar" >> MIME objects in a single BEEP "MSG" so long as all of the "text/ >> calendar" CAP objects have the same "TARGET" property value. eh? how can you send multiple objects in the same MSG if you aren't using multipart as the outerwrapper. the spec says that each MSG, RPY, etc., contains a MIME object. it doesn't say that the each MSG, RPY, etc., contains one or more MIME objects concatenated together... >> Messages in positive replies: >> >> After the initial message then a BEEP "RPY" may contain one or more >> MIME objects at least one of which MUST be "text/calendar" and each >> "text/calendar" MIME object MUST contain a CAP "CMD" property. All >> "text/calendar" MIME objects in a single BEEP "RPY" messages MUST >> have the same "TARGET" property value. cf., comment on multipart above. >> The BEEP "RPY" messages can only contain MIME "multipart" MIME >> objects if the other endpoint has received a CAP "CAPABILITY" >> indicating the other endpoint supports multipart MIME objects. This >> does not prevent the endpoint from sending multiple "text/calendar" >> >> The BEEP "RPY" messages can only contain MIME "multipart" MIME >> objects if the other endpoint has received a CAP "CAPABILITY" >> indicating the other endpoint supports multipart MIME objects. This >> does not prevent the endpoint from sending multiple "text/calendar" >> MIME objects in a single BEEP "RPY" so long as all of the "text/ >> calendar" CAP objects have the same "TARGET" property value. >> MIME objects in a single BEEP "RPY" so long as all of the "text/ >> calendar" CAP objects have the same "TARGET" property value. duplicate paragraph. >> >> Messages in negative replies: >> >> Any valid "text/calendar" MIME object that contains CAP >> "REQUEST-STATUS" property and a CAP "CMD" property with a property >> value of "REPLY". And where the CS has determined the requested >> operation to be a fatal error. And when the CS has performed NO >> operation that effected the contents of any part of the CS or any >> calendar controlled by the CS. this is very hard to understand and could be clarified. >> Messages in one-to-many exchanges: >> >> After the initial message then a BEEP "MSG" may contain one or more >> MIME objects at least one of which MUST be "text/calendar" and each >> "text/calendar" MIME object MUST contain a CAP "CMD" property. >> >> The BEEP "MSG" messages can only contain MIME "multipart" MIME >> objects if the other endpoint has received a CAP "CAPABILITY" >> indicating the other endpoint supports multipart MIME objects. This >> does not prevent the endpoint from sending multiple "text/calendar" >> MIME objects in a single BEEP "MSG" so long as all of the "text/ >> calendar" CAP objects have the same "TARGET" property value. >> >> The BEEP "RPY" messages can only contain MIME "multipart" MIME >> objects if the other endpoint has received a CAP "CAPABILITY" >> indicating the other endpoint supports multipart MIME objects. This >> does not prevent the endpoint from sending multiple "text/calendar" >> MIME objects in a single BEEP "ANS" so long as all of the "text/ >> calendar" CAP objects in EACH BEEP "ANS" message have the same >> "TARGET" property value. Each unique "TARGET" property value per >> BEEP >> "ANS" message. this is so wrong, i don't know where to start. i guess that the idea is this: 1. a BEEP message (the contents of a MSG, a RPY, an ANS, or an ERR) must contain one or more text/calendar objects, each of which having the same TARGET property. 2. if the TARGET properties contained in the response are identical, then a one-to-many exchange should occur, and each ANS should contain one or more text/calendar objects, all having the same TARGET property. 3. if the TARGET properties contained in the response are identical, then a one-to-one exchange should occur, and that RPY should contain one or more text/calendar entries. the bug here is that to do the "or more" part of "one or more", you must use a multipart, because each BEEP message contains either zero or one MIME objects. my guess is that these rules could be written much more concisely and unambiguously once the multipart thing is resolved (e.g., if a response requires a multipart and the CS doesn't support multiparts, then the CS returns an ERR response). /mtr --Apple-Mail-12--628713385 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit I'm not any more of a BEEP expert than I am a CAP expert, but I consulted Mr. BEEP himself, Marshall Rose, and got a few comments from him that look potentially useful. Most of them are just clarifications, although the last one seems to go a bit deeper. -- Nathaniel From: Marshall Rose < Date: Thu Sep 11, 2003 6:02:10 PM America/Detroit To: Nathaniel Borenstein < Subject: Re: Fwd: CAP - BEEP Profile Profile Identification: specify a URI [10] that authoritatively identifies this profile. 1998,1998,FFFEhttp://iana.org/beep/cap/1.0 Message Exchanged during Channel Creation: CUAs SHOULD supply the BEEP "localize" attributes in the BEEP "greeting" messages. CSs SHOULD supply the BEEP "localize" attributes in the BEEP "greeting" messages. well, okay. the spec says: <the "localize" attribute, if present, contains one or more language tokens (defined in <), each identifying a desirable language tag to be used by the remote BEEP peer when generating textual diagnostics for the "close" and "error" elements (the tokens are ordered from most to least desirable); and,< CUAs SHOULD supply the BEEP "serverName" attribute at channel creation time to the CS so that if the CS is performing virtual hosting the CS can determine the intended virtual host. CSs that do not support virtual hosting may ignore the BEEP "serverName" attribute. well, okay. the spec says: <The "serverName" attribute for the first successful "start" element received by a BEEP peer is meaningful for the duration of the BEEP session. If present, the BEEP peer decides whether to operate as the indicated "serverName"; if not, an "error" element is sent in a negative reply.< so i guess that using "may" is ok, though perhaps "MAY" is more appropriate. in otherwords, you can lose the text about localize and serverName and wouldn't lose anything, since this is just saying what the spec says, albeit less precisely. Messages starting one-to-one exchanges: The initial message each direction MUST BE single "text/calendar" object containing a CAP "CAPABILITY" CMD and must not be part of a MIME multipart message. not a sentence. this would read better if it actually mentioned the term "MIME media type". actually, a state diagram of the messages exchanged might actually explain what's trying to be conveyed. After the initial message then a BEEP "MSG" may contain one or more MIME objects at least one of which MUST be "text/calendar" and each "text/calendar" MIME object MUST contain a CAP "CMD" property. The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "MSG" so long as all of the "text/ calendar" CAP objects have the same "TARGET" property value. eh? how can you send multiple objects in the same MSG if you aren't using multipart as the outerwrapper. the spec says that each MSG, RPY, etc., contains a MIME object. it doesn't say that the each MSG, RPY, etc., contains one or more MIME objects concatenated together... Messages in positive replies: After the initial message then a BEEP "RPY" may contain one or more MIME objects at least one of which MUST be "text/calendar" and each "text/calendar" MIME object MUST contain a CAP "CMD" property. All "text/calendar" MIME objects in a single BEEP "RPY" messages MUST have the same "TARGET" property value. cf., comment on multipart above. The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "RPY" so long as all of the "text/ calendar" CAP objects have the same "TARGET" property value. MIME objects in a single BEEP "RPY" so long as all of the "text/ calendar" CAP objects have the same "TARGET" property value. duplicate paragraph. Messages in negative replies: Any valid "text/calendar" MIME object that contains CAP "REQUEST-STATUS" property and a CAP "CMD" property with a property value of "REPLY". And where the CS has determined the requested operation to be a fatal error. And when the CS has performed NO operation that effected the contents of any part of the CS or any calendar controlled by the CS. this is very hard to understand and could be clarified. Messages in one-to-many exchanges: After the initial message then a BEEP "MSG" may contain one or more MIME objects at least one of which MUST be "text/calendar" and each "text/calendar" MIME object MUST contain a CAP "CMD" property. The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "MSG" so long as all of the "text/ calendar" CAP objects have the same "TARGET" property value. The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "ANS" so long as all of the "text/ calendar" CAP objects in EACH BEEP "ANS" message have the same "TARGET" property value. Each unique "TARGET" property value per BEEP "ANS" message. this is so wrong, i don't know where to start. i guess that the idea is this: 1. a BEEP message (the contents of a MSG, a RPY, an ANS, or an ERR) must contain one or more text/calendar objects, each of which having the same TARGET property. 2. if the TARGET properties contained in the response are identical, then a one-to-many exchange should occur, and each ANS should contain one or more text/calendar objects, all having the same TARGET property. 3. if the TARGET properties contained in the response are identical, then a one-to-one exchange should occur, and that RPY should contain one or more text/calendar entries. the bug here is that to do the "or more" part of "one or more", you must use a multipart, because each BEEP message contains either zero or one MIME objects. my guess is that these rules could be written much more concisely and unambiguously once the multipart thing is resolved (e.g., if a response requires a multipart and the CS doesn't support multiparts, then the CS returns an ERR response). /mtr --Apple-Mail-12--628713385-- From owner-ietf-calendar@mail.imc.org Mon Sep 15 14:45:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18689 for ; Mon, 15 Sep 2003 14:45:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FIG4eo075318 for ; Mon, 15 Sep 2003 11:16:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FIG4wr075317 for ietf-calendar-bks; Mon, 15 Sep 2003 11:16:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FIG3eo075310 for ; Mon, 15 Sep 2003 11:16:03 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8FIG2Gv024741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 15 Sep 2003 11:16:03 -0700 Message-ID: <3F6601DD.7070700@Royer.com> Date: Mon, 15 Sep 2003 12:15:57 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP - BEEP Profile References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> In-Reply-To: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> Content-Type: text/plain; charset=ISO-8859-1; 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 Nathaniel Borenstein wrote: > I'm not any more of a BEEP expert than I am a CAP expert, but I > consulted Mr. BEEP himself, Marshall Rose, and got a few comments from > him that look potentially useful. Most of them are just > clarifications, although the last one seems to go a bit deeper. -- > Nathaniel > > Messages starting one-to-one exchanges: > > The initial message each direction MUST BE single "text/calendar" > object containing a CAP "CAPABILITY" CMD and must not be part > of a > MIME multipart message. > > > not a sentence. this would read better if it actually mentioned the term > "MIME media type". I don't follow. Do you mean say "MIME media type of text/calendar"? > After the initial message then a BEEP "MSG" may contain one or > more > MIME objects at least one of which MUST be "text/calendar" and > each > "text/calendar" MIME object MUST contain a CAP "CMD" property. > > The BEEP "MSG" messages can only contain MIME "multipart" MIME > objects if the other endpoint has received a CAP "CAPABILITY" > indicating the other endpoint supports multipart MIME objects. > This > does not prevent the endpoint from sending multiple > "text/calendar" > MIME objects in a single BEEP "MSG" so long as all of the "text/ > calendar" CAP objects have the same "TARGET" property value. > > > eh? how can you send multiple objects in the same MSG if you aren't > using multipart as the outerwrapper. the spec says that each MSG, RPY, > etc., contains a MIME object. it doesn't say that the each MSG, RPY, > etc., contains one or more MIME objects concatenated together... It (they all) should say [iCAL], as in: The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple [iCAL] objects in a single BEEP "MSG" so long as all of the [iCAL] objects have the same "TARGET" property value. > Messages in negative replies: > > > Any valid "text/calendar" MIME object that contains CAP > "REQUEST-STATUS" property and a CAP "CMD" property with a > property > value of "REPLY". And where the CS has determined the requested > operation to be a fatal error. And when the CS has performed NO > operation that effected the contents of any part of the CS or any > calendar controlled by the CS. > > > this is very hard to understand and could be clarified. Anyone have suggestions? > > Messages in one-to-many exchanges: > > After the initial message then a BEEP "MSG" may contain one or > more > MIME objects at least one of which MUST be "text/calendar" and > each > "text/calendar" MIME object MUST contain a CAP "CMD" property. > > The BEEP "MSG" messages can only contain MIME "multipart" MIME > objects if the other endpoint has received a CAP "CAPABILITY" > indicating the other endpoint supports multipart MIME objects. > This > does not prevent the endpoint from sending multiple > "text/calendar" > MIME objects in a single BEEP "MSG" so long as all of the "text/ > calendar" CAP objects have the same "TARGET" property value. > > The BEEP "RPY" messages can only contain MIME "multipart" MIME > objects if the other endpoint has received a CAP "CAPABILITY" > indicating the other endpoint supports multipart MIME objects. > This > does not prevent the endpoint from sending multiple > "text/calendar" > MIME objects in a single BEEP "ANS" so long as all of the "text/ > calendar" CAP objects in EACH BEEP "ANS" message have the same > "TARGET" property value. Each unique "TARGET" property value per > BEEP > "ANS" message. > > > this is so wrong, i don't know where to start. i guess that the idea > is this: > > 1. a BEEP message (the contents of a MSG, a RPY, an ANS, or an ERR) > must contain one or more text/calendar objects, each of which having the > same TARGET property. > > 2. if the TARGET properties contained in the response are identical, > then a one-to-many exchange should occur, and each ANS should contain > one or more text/calendar objects, all having the same TARGET > property. No, the WG wanted the the opposite. If they are different TARGETs then they go in to multiple ANS messages. (not something I wanted so I do not understand why). > > 3. if the TARGET properties contained in the response are identical, > then a one-to-one exchange should occur, and that RPY should contain > one or more text/calendar entries. No and this sounds the same as (2) to me. And they can be combined only when they are the same TARGET. There are two ways to combine. If the recipient does not support multipart and all of the replies are for the same TARGET, they still can send one [iCAL] object with multiple replies (BEGIN/END VCALENDAR blobs) in the ONE RPY. > > the bug here is that to do the "or more" part of "one or more", you must > use a multipart, because each BEEP message contains either zero or one > MIME objects. Not all CUA's support multipart. So no that will not work. > > my guess is that these rules could be written much more concisely and > unambiguously once the multipart thing is resolved (e.g., if a response > requires a multipart and the CS doesn't support multipart, then the CS > returns an ERR response). (1) Not all CUAs or CSs support multipart. (2) The WG wanted all "text/calendar" objects in the same reply to be be of the same TARGET. (3) For those CUAs and CSs that do support multipart they can also have non-text/calendar objects (attached for example). > > /mtr > -- 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 Sep 15 15:09:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20500 for ; Mon, 15 Sep 2003 15:09:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FIw5eo077037 for ; Mon, 15 Sep 2003 11:58:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FIw5U5077036 for ietf-calendar-bks; Mon, 15 Sep 2003 11:58:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FIw4eo077031 for ; Mon, 15 Sep 2003 11:58:04 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8FIw4Gv025149 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 15 Sep 2003 11:58:06 -0700 Message-ID: <3F660BB7.1040505@Royer.com> Date: Mon, 15 Sep 2003 12:57:59 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP-12 - interm version 'C' 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 have placed the latest edit of CAP for your review at: http://inet-consulting.com/draft-ietf-calsch-cap-12-c.txt http://inet-consulting.com/draft-ietf-calsch-cap-12-c.html http://inet-consulting.com/draft-ietf-calsch-cap-12-c.xml -- 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 Sep 15 16:40:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25556 for ; Mon, 15 Sep 2003 16:40:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKKmeo082747 for ; Mon, 15 Sep 2003 13:20:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FKKmBH082746 for ietf-calendar-bks; Mon, 15 Sep 2003 13:20:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKKkeo082740 for ; Mon, 15 Sep 2003 13:20:46 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h8FKKmuJ001702; Mon, 15 Sep 2003 13:20:48 -0700 (PDT) Date: Mon, 15 Sep 2003 13:20:48 -0700 From: Marshall Rose To: "ietf-calendar@imc.org" Cc: Doug@royer.com Subject: Re: CAP - BEEP Profile Message-Id: <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> In-Reply-To: <3F6601DD.7070700@Royer.com> References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit doug - let's focus on the core issue: > > the bug here is that to do the "or more" part of "one or more", you must > > use a multipart, because each BEEP message contains either zero or one > > MIME objects. > > Not all CUA's support multipart. So no that will not work. sorry, those are BEEP's rules. so, either you make support of multipart mandatory, or you do not allow requests that would require a multipart response if multipart isn't available. /mtr From owner-ietf-calendar@mail.imc.org Mon Sep 15 16:44:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25676 for ; Mon, 15 Sep 2003 16:44:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKVVeo083077 for ; Mon, 15 Sep 2003 13:31:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FKVVcq083076 for ietf-calendar-bks; Mon, 15 Sep 2003 13:31:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKVUeo083070 for ; Mon, 15 Sep 2003 13:31:30 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8FKVUGv025964 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 15 Sep 2003 13:31:31 -0700 Message-ID: <3F66219D.1060808@Royer.com> Date: Mon, 15 Sep 2003 14:31:25 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP - BEEP Profile References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> In-Reply-To: <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> Content-Type: text/plain; charset=ISO-8859-1; 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 Marshall Rose wrote: >doug - let's focus on the core issue: > > > >>>the bug here is that to do the "or more" part of "one or more", you must >>>use a multipart, because each BEEP message contains either zero or one >>>MIME objects. >>> >>> >> >>Not all CUA's support multipart. So no that will not work. >> >> > >sorry, those are BEEP's rules. so, either you make support of multipart >mandatory, or you do not allow requests that would require a multipart >response if multipart isn't available. > > Not sure how that differs from what was said. If the capability of the endpoint does not include multipart, then you can not send multipart to that recipient. I think we agree. I can add text that says if you get a multipart and you said "no multipart", then you get a BEEP error... Is that what you were saying, add a BEEP error? -- 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 Sep 15 16:54:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25793 for ; Mon, 15 Sep 2003 16:54:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKhPeo083595 for ; Mon, 15 Sep 2003 13:43:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FKhPpZ083594 for ietf-calendar-bks; Mon, 15 Sep 2003 13:43:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKhOeo083588 for ; Mon, 15 Sep 2003 13:43:24 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h8FKhPuJ001753; Mon, 15 Sep 2003 13:43:25 -0700 (PDT) Date: Mon, 15 Sep 2003 13:43:25 -0700 From: Marshall Rose To: "ietf-calendar@imc.org" Cc: Doug@royer.com Subject: Re: CAP - BEEP Profile Message-Id: <20030915134325.608a0468.mrose@dbc.mtview.ca.us> In-Reply-To: <3F66219D.1060808@Royer.com> References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> <3F66219D.1060808@Royer.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I can add text that says if you get a multipart and you said "no > multipart", then > you get a BEEP error... Is that what you were saying, add a BEEP error? no. the problem is that you have text in your draft which says/implies/whatever that you can put more than one mime objects in a single MSG/RPY/ANS without using a multipart. that is also against beeps' rules. /mtr From owner-ietf-calendar@mail.imc.org Mon Sep 15 17:08:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26455 for ; Mon, 15 Sep 2003 17:08:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKvneo084157 for ; Mon, 15 Sep 2003 13:57:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FKvn4c084156 for ietf-calendar-bks; Mon, 15 Sep 2003 13:57:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKvmeo084150 for ; Mon, 15 Sep 2003 13:57:48 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8FKvlGv026205 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 15 Sep 2003 13:57:50 -0700 Message-ID: <3F6627C6.2020104@Royer.com> Date: Mon, 15 Sep 2003 14:57:42 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP - BEEP Profile References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> <3F66219D.1060808@Royer.com> <20030915134325.608a0468.mrose@dbc.mtview.ca.us> In-Reply-To: <20030915134325.608a0468.mrose@dbc.mtview.ca.us> Content-Type: text/plain; charset=ISO-8859-1; 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 Marshall Rose wrote: >>I can add text that says if you get a multipart and you said "no >>multipart", then >>you get a BEEP error... Is that what you were saying, add a BEEP error? >> >> > >no. the problem is that you have text in your draft which >says/implies/whatever that you can put more than one mime objects in a >single MSG/RPY/ANS without using a multipart. > >that is also against beeps' rules. > Yes I agree - I replied to that saying: It (they all) should say [iCAL], as in (fixed text below): The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple [iCAL] objects in a single BEEP "MSG" so long as all of the [iCAL] objects have the same "TARGET" property value. An iCAL object is a BEGIN/END VCALENDAR blob. And a single (non multipart) iCAL MIME object may contain one or more BEGIN/END VCALENDAR objects (per RFC 2445). This WG wanted: Those to still be valid as long as they all have the same TARGET. When they have different TARGET values, then they have to be in separate MIME objects. When the recipient does not allow multipart, then they have to be in separate BEEP ANSs. Does that fix the issue? -- 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 Sep 15 17:49:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27467 for ; Mon, 15 Sep 2003 17:49:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FLZFeo085860 for ; Mon, 15 Sep 2003 14:35:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FLZFZF085859 for ietf-calendar-bks; Mon, 15 Sep 2003 14:35:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FLZCeo085848 for ; Mon, 15 Sep 2003 14:35:13 -0700 (PDT) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3F5D12BE.84C8183F@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org, Nathaniel Borenstein , owner-ietf-calendar@mail.imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 Message-ID: From: pregen@egenconsulting.com Date: Mon, 15 Sep 2003 17:35:15 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.2CF2|July 23, 2003) at 09/15/2003 05:35:15 PM, Serialize complete at 09/15/2003 05:35:15 PM Content-Type: multipart/alternative; boundary="=_alternative 0076957285256DA2_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076957285256DA2_= Content-Type: text/plain; charset="US-ASCII" Hi Mark. You are indeed correct there is a lack of chair participation. Some of that is on purpose to make sure dialog continues. Some of that is because we too, Bob and I, can not keep up with the deluge of emails, in particular over the last several months. As for concensus, as I have stated many many times, one person making a comment does not mean concensus. Without feedback from people to the list it's hard to get concensus. I have exchanged some emails with people to get their "read" on whether or not concensus has been reached. When there has been one - i have put it on the list. However, one person saying no one responded so we have "concensus" is not concensus. I will say that again and continue saying that. So, read into that what you may - I take responsibility where needed. However, I do read each and every note and respond when appropriate. Mark Smith Sent by: owner-ietf-calendar@mail.imc.org 09/08/2003 19:37 To Nathaniel Borenstein cc ietf-calendar@imc.org Subject Re: [Fwd: CAP-12 - interm version 'A'] Nathaniel Borenstein wrote: > > What Mark did simply proved that it is possible to do what Bruce had > asked for. It is silly for more than one person to have to do this, > and I always understood this to be a part of the job of the document > editor. When I read a draft after reading some previous version of the draft I do a diff. I do not know of any other IETF list that has produced diffs of draft versions. I also can not find a list of differences for versions of any draft except the ones that Doug used to publish. Check for yourself. I could not find any. The process seems to be that there is debate then at random times a new version shows up. I have looked in several IETF lists and web pages and I think you have been misled by someone on this list that is making more false statements or is just trying to disrupt this list. It does not seem to be normal process. There also seems to be a lack of chair participation on this list. It is very hard to find any consensus called even when there is a overwhelming agreement. > BTW the whole problem can be simplified a bit if the editor uses a tool > like xml2rfc and produces diffs using the relevant component files... If you noticed he also published the XML source on calsch.org and his web site. And again I could not find any XML diffs published. Do you know of any? Mark --=_alternative 0076957285256DA2_= Content-Type: text/html; charset="US-ASCII"
Hi Mark.  You are indeed correct there is a lack of chair participation.  Some of that is on purpose to make sure dialog continues.
Some of that is because we too, Bob and I, can not keep up with the deluge of emails, in particular over the last several
months.  

As for concensus, as I have stated many many times, one person making a comment does not mean concensus.
Without feedback from people to the list it's hard to get concensus.  I have exchanged some emails with people
to get their "read" on whether or not concensus has been reached.  When there has been one - i have put it on the list.  
However, one person saying no one responded so we have "concensus" is not concensus.  I will say that again and continue
saying that.

So, read into that what you may - I take responsibility where needed.  However, I do read each and every note and respond
when appropriate.


Mark Smith <mark@inet-calendar.net>
Sent by: owner-ietf-calendar@mail.imc.org

09/08/2003 19:37

To
Nathaniel Borenstein <nsb@guppylake.com>
cc
ietf-calendar@imc.org
Subject
Re: [Fwd: CAP-12 - interm version 'A']






Nathaniel Borenstein wrote:
>
> What Mark did simply proved that it is possible to do what Bruce had
> asked for.  It is silly for more than one person to have to do this,
> and I always understood this to be a part of the job of the document
> editor.
When I read a draft after reading some previous version of the draft
I do a diff. I do not know of any other IETF list that has produced
diffs of draft versions. I also can not find a list of differences
for versions of any draft except the ones that Doug used to publish.
Check for yourself. I could not find any.
The process seems to be that there is debate then at random times a
new version shows up. I have looked in several IETF lists and web pages
and I think you have been misled by someone on this list that is making
more false statements or is just trying to disrupt this list. It does
not
seem to be normal process.
There also seems to be a lack of chair participation on this list.
It is very hard to find any consensus called even when there is a
overwhelming agreement.
> BTW the whole problem can be simplified a bit if the editor uses a tool
> like xml2rfc and produces diffs using the relevant component files...
If you noticed he also published the XML source on calsch.org and
his web site. And again I could not find any XML diffs published.
Do you know of any?
Mark
--=_alternative 0076957285256DA2_=-- From owner-ietf-calendar@mail.imc.org Mon Sep 15 18:30:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00157 for ; Mon, 15 Sep 2003 18:30:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FMHOeo087441 for ; Mon, 15 Sep 2003 15:17:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FMHOaK087440 for ietf-calendar-bks; Mon, 15 Sep 2003 15:17:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FMHLeo087432 for ; Mon, 15 Sep 2003 15:17:22 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19z1eP-0008Gr-00 for ; Tue, 16 Sep 2003 00:16:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19z1eO-0008Gj-00 for ; Tue, 16 Sep 2003 00:16:52 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19z1eb-0006Sy-00 for ; Tue, 16 Sep 2003 00:17:05 +0200 From: "Michael Fair" Subject: Re: CAP-12 - interm version 'C' Date: Mon, 15 Sep 2003 15:17:04 -0700 Lines: 63 Message-ID: References: <3F660BB7.1040505@Royer.com> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This whole being ignored by the editor thing really holds up progress. I'm totally disinclined to submit a review given that all my comments to the editor are being ignored. While I totally disagree that Doug had any justification for ignoring me, I realize that he has a right to ignore comments from people he doesn't like in regards to WG discussions (despite the rather immature method of handling the situation it is). However, as editor, there is a responsibility to collect information from all participants. I want to respect his privilege to classify all email from me as Spam, but now that conversation has evolved past him refusing to provide proof for his claims and my continued pressure that he provide proof and into CAP reviews I find it hard to justify a continuance of that behavior. I also request that Doug include the bugzilla address where he'd like submissions sent in every CAP announcement so that we don't have to go digging for it whenever we want it. I'm submitting this to BugZilla as well, but here it is on the list (an email which he won't see). In the last paragraph of the introduction second sentence we have: The first part summarizes and defined the new objects. This should probably be: The first part summarizes and defines the new objects. I'm just starting to work my way through CAP from beginning to end I expect more to come - but not today. -- Michael -- "Doug Royer" wrote in message news:3F660BB7.1040505@Royer.com... > > > > I have placed the latest edit of CAP for your review at: > > http://inet-consulting.com/draft-ietf-calsch-cap-12-c.txt > > http://inet-consulting.com/draft-ietf-calsch-cap-12-c.html > > http://inet-consulting.com/draft-ietf-calsch-cap-12-c.xml > > > -- > > 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 Sep 15 22:49:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07775 for ; Mon, 15 Sep 2003 22:49:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G2Wteo096580 for ; Mon, 15 Sep 2003 19:32:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G2Wt91096579 for ietf-calendar-bks; Mon, 15 Sep 2003 19:32:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G2Wreo096574 for ; Mon, 15 Sep 2003 19:32:54 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h8G2WuuJ003191; Mon, 15 Sep 2003 19:32:56 -0700 (PDT) Date: Mon, 15 Sep 2003 19:32:56 -0700 From: Marshall Rose To: "ietf-calendar@imc.org" Cc: Doug@royer.com Subject: Re: CAP - BEEP Profile Message-Id: <20030915193256.43c64823.mrose@dbc.mtview.ca.us> In-Reply-To: <3F6627C6.2020104@Royer.com> References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> <3F66219D.1060808@Royer.com> <20030915134325.608a0468.mrose@dbc.mtview.ca.us> <3F6627C6.2020104@Royer.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Does that fix the issue? i have no idea. the text in the document is so convoluted it should be sent to the 9th circuit court. do not put more than one top-level mime object in a MSG/RPY/ANS/ERR. if multiple mime objects must appear, then the top-level mime object must be a multipart. /mtr From owner-ietf-calendar@mail.imc.org Mon Sep 15 22:55:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07886 for ; Mon, 15 Sep 2003 22:55:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G2hYeo097002 for ; Mon, 15 Sep 2003 19:43:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G2hYMI097000 for ietf-calendar-bks; Mon, 15 Sep 2003 19:43:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G2hXeo096992 for ; Mon, 15 Sep 2003 19:43:33 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8G2hVGv029223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 15 Sep 2003 19:43:35 -0700 Message-ID: <3F6678CD.8020102@Royer.com> Date: Mon, 15 Sep 2003 20:43:25 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP - BEEP Profile References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> <3F66219D.1060808@Royer.com> <20030915134325.608a0468.mrose@dbc.mtview.ca.us> <3F6627C6.2020104@Royer.com> <20030915193256.43c64823.mrose@dbc.mtview.ca.us> In-Reply-To: <20030915193256.43c64823.mrose@dbc.mtview.ca.us> 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 Marshall Rose wrote: >>Does that fix the issue? >> >> > >i have no idea. the text in the document is so convoluted it should be >sent to the 9th circuit court. > Does anyone that knows iCAL and CAP understand what the issue is? -- 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 Tue Sep 16 02:25:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26257 for ; Tue, 16 Sep 2003 02:25:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G68Keo028653 for ; Mon, 15 Sep 2003 23:08:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G68KYq028651 for ietf-calendar-bks; Mon, 15 Sep 2003 23:08:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.pspl.co.in (www.pspl.co.in [202.54.11.65] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G68Heo028610 for ; Mon, 15 Sep 2003 23:08:18 -0700 (PDT) (envelope-from payod_deshpande@persistent.co.in) Received: (from root@localhost) by smtp.pspl.co.in (8.12.9/8.12.9) id h8G6I93B013593 for ; Tue, 16 Sep 2003 11:48:09 +0530 Received: from ps1056 (panini.pspl.co.in [210.210.81.200]) (authenticated bits=0) by persistent.co.in (8.12.9/8.12.9) with ESMTP id h8G6I7Cl013548 for ; Tue, 16 Sep 2003 11:48:08 +0530 Message-ID: <000701c37c18$ea3b9ae0$5801a8c0@persistent.co.in> From: "Payod Deshpande" To: Subject: Open Source Parsers Date: Tue, 16 Sep 2003 11:38:12 +0530 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=6.0 tests=none version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello everyone: I have a passing interest in developing vCalendar support for a mail client. I would like to know if there are any open source parsers (preferably in JAVA), which I can extend for my own purpose? Regards, Payod From owner-ietf-calendar@mail.imc.org Tue Sep 16 03:41:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28099 for ; Tue, 16 Sep 2003 03:41:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G7Q9eo054038 for ; Tue, 16 Sep 2003 00:26:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G7Q9Ag054037 for ietf-calendar-bks; Tue, 16 Sep 2003 00:26:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.pspl.co.in (www.pspl.co.in [202.54.11.65] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G7Q6eo053996 for ; Tue, 16 Sep 2003 00:26:07 -0700 (PDT) (envelope-from payod_deshpande@persistent.co.in) Received: (from root@localhost) by smtp.pspl.co.in (8.12.9/8.12.9) id h8G7ZuOF008126 for ; Tue, 16 Sep 2003 13:05:56 +0530 Received: from ps1056 (panini.pspl.co.in [210.210.81.200]) (authenticated bits=0) by persistent.co.in (8.12.9/8.12.9) with ESMTP id h8G7ZtCl008112 for ; Tue, 16 Sep 2003 13:05:55 +0530 Message-ID: <005401c37c23$c756cd00$5801a8c0@persistent.co.in> From: "Payod Deshpande" To: Subject: iCalendar libraries? Date: Tue, 16 Sep 2003 12:56:00 +0530 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=6.0 tests=none version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello: I need to add a vCalendar support for a mail client. I want to know if there are any open source parsers (in JAVA) that I can use. Secondly, I found libical library on sourceforge.net that implements RFC2445, RFC2446 and some of RFC2447 and the CAPdraft. However its in C (but provides JNI interface) for UNIX platform. I want something similar for Windows. Can anybody help me to fetch one. Regards, Payod From owner-ietf-calendar@mail.imc.org Tue Sep 16 05:25:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00023 for ; Tue, 16 Sep 2003 05:25:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G95aeo073885 for ; Tue, 16 Sep 2003 02:05:36 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G95adc073884 for ietf-calendar-bks; Tue, 16 Sep 2003 02:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from moorabbin.nexor.co.uk (moorabbin.nexor.co.uk [80.6.88.100]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G95Yeo073875 for ; Tue, 16 Sep 2003 02:05:34 -0700 (PDT) (envelope-from John.Berthels@nexor.co.uk) Received: from spectre.nexor.co.uk by moorabbin.nexor.co.uk with ESMTP (Mailer) with ESMTP; Tue, 16 Sep 2003 10:02:09 +0100 Date: Tue, 16 Sep 2003 10:05:13 +0100 (BST) From: John Berthels To: "ietf-calendar@imc.org" cc: Marshall Rose , Doug@royer.com Subject: Re: CAP - BEEP Profile In-Reply-To: <3F6678CD.8020102@Royer.com> Message-ID: References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> <3F66219D.1060808@Royer.com> <20030915134325.608a0468.mrose@dbc.mtview.ca.us> <3F6627C6.2020104@Royer.com> <20030915193256.43c64823.mrose@dbc.mtview.ca.us> <3F6678CD.8020102@Royer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-101.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_ADDRESS_EQ_REAL,USER_AGENT_PINE,USER_IN_WHITELIST version=2.43 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >>Does that fix the issue? > > > >i have no idea. the text in the document is so convoluted it should be > >sent to the 9th circuit court. > > > > Does anyone that knows iCAL and CAP understand what the issue is? If I understand correctly, I think its OK. BEEP appears to require a single mime entity per message. This mime entity may or may not be multipart, no matter. iCal has the ability to encode multiple objects in two ways: - one object per mime entity, encoded as multipart - multiple objects per mime entity, delimited with VBEGIN/VEND in a single text/calendar part. Is the following wording any help? ------------------------- Multiple iCal objects may be sent in a single BEEP message by either representing them as seperate MIME text/calendar parts contained within a MIME multipart/mixed part or by simple concatenation within a single text/calendar [**] part, seperated by a single blank line. In either case, all iCal objects transmitted together must have the same TARGET property. The sending of multipart MIME entities over BEEP is not permitted for CAP unless the other endpoint has indicated its ability to accept them via the appropriate CAPABILITY[*]. ------------------------- [* - I don't know which capability is this, it would be good to name it explicitly] regards, jb From owner-ietf-calendar@mail.imc.org Tue Sep 16 06:27:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01552 for ; Tue, 16 Sep 2003 06:27:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GA3Weo076446 for ; Tue, 16 Sep 2003 03:04:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GA3We0076445 for ietf-calendar-bks; Tue, 16 Sep 2003 03:03:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from eurekait.com (adsl-9-87.swiftdsl.com.au [218.214.9.87]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GA1geo076192 for ; Tue, 16 Sep 2003 03:03:29 -0700 (PDT) (envelope-from sfg@eurekait.com) Received: from laptop.eurekait.com (laptop [192.168.1.201]) by eurekait.com (Postfix) with ESMTP id 1CFE62BF7F for ; Tue, 16 Sep 2003 21:19:02 +1000 (EST) Subject: Re: iCalendar libraries? From: Stuart Guthrie To: ietf-calendar@imc.org In-Reply-To: <005401c37c23$c756cd00$5801a8c0@persistent.co.in> References: <005401c37c23$c756cd00$5801a8c0@persistent.co.in> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/YdkCmTI7xg2e5VAZ7cq" Organization: Eureka IT Pty Ltd Message-Id: <1063706489.2232.0.camel@laptop.eurekait.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2-3mdk Date: 16 Sep 2003 20:01:29 +1000 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-/YdkCmTI7xg2e5VAZ7cq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable http://www.sf.net/projects/jical HTH Stuart Guthrie On Tue, 2003-09-16 at 17:26, Payod Deshpande wrote: > Hello: >=20 > I need to add a vCalendar support for a mail client. I want to know if th= ere > are any open source parsers (in JAVA) that I can use. >=20 > Secondly, I found libical library on sourceforge.net that implements > RFC2445, RFC2446 and some of RFC2447 and the CAPdraft. > However its in C (but provides JNI interface) for UNIX platform. I want > something similar for Windows. Can anybody help me > to fetch one. >=20 > Regards, > Payod >=20 >=20 >=20 >=20 >=20 > !DSPAM:3f66ce65144322507721208! --=20 Stuart Guthrie Eureka IT Pty Ltd --=-/YdkCmTI7xg2e5VAZ7cq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/Zt95F26WA9www+ARAqZAAJ9b/ihwuoscbz77xzxsuoTQ2OadtQCeJDtB N+xwnQRb8AG5UCHRmiLpcIo= =od0r -----END PGP SIGNATURE----- --=-/YdkCmTI7xg2e5VAZ7cq-- From owner-ietf-calendar@mail.imc.org Tue Sep 16 12:29:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24983 for ; Tue, 16 Sep 2003 12:29:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GGEfeo090667 for ; Tue, 16 Sep 2003 09:14:41 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GGEfm1090666 for ietf-calendar-bks; Tue, 16 Sep 2003 09:14:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GGEeeo090661 for ; Tue, 16 Sep 2003 09:14:40 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8GGEdGv002854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 16 Sep 2003 09:14:41 -0700 Message-ID: <3F6736EA.4050106@Royer.com> Date: Tue, 16 Sep 2003 10:14:34 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP - BEEP Profile References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> <3F66219D.1060808@Royer.com> <20030915134325.608a0468.mrose@dbc.mtview.ca.us> <3F6627C6.2020104@Royer.com> <20030915193256.43c64823.mrose@dbc.mtview.ca.us> <3F6678CD.8020102@Royer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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 John Berthels wrote: > > >Is the following wording any help? > >------------------------- >Multiple iCal objects may be sent in a single BEEP message by either >representing them as separate MIME text/calendar parts contained within a >MIME multipart/mixed part or by simple concatenation within a single >text/calendar [**] part, separated by a single blank line. > >In either case, all iCal objects transmitted together must have the same >TARGET property. > >The sending of multipart MIME entities over BEEP is not permitted for CAP >unless the other endpoint has indicated its ability to accept them via the >appropriate CAPABILITY[*]. >------------------------- > Thanks. Much clearer. And the 'single blank line' is not in the ABNF of 2445, so no that is not valid. icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF icalbody "END" ":" "VCALENDAR" CRLF) And both are valid for recipients that allow multipart. That is you could send a multipart object where one or more of the parts contained one or more 'icalobject's. -- 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 Tue Sep 16 13:04:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27059 for ; Tue, 16 Sep 2003 13:04:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GGqDeo092587 for ; Tue, 16 Sep 2003 09:52:13 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GGqD5s092586 for ietf-calendar-bks; Tue, 16 Sep 2003 09:52:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from moorabbin.nexor.co.uk (moorabbin.nexor.co.uk [80.6.88.100]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GGqBeo092575 for ; Tue, 16 Sep 2003 09:52:11 -0700 (PDT) (envelope-from John.Berthels@nexor.co.uk) Received: from spectre.nexor.co.uk by moorabbin.nexor.co.uk with ESMTP (Mailer) with ESMTP; Tue, 16 Sep 2003 17:48:51 +0100 Date: Tue, 16 Sep 2003 17:51:57 +0100 (BST) From: John Berthels To: "ietf-calendar@imc.org" Subject: Re: CAP - BEEP Profile In-Reply-To: <3F6736EA.4050106@Royer.com> Message-ID: References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> <3F66219D.1060808@Royer.com> <20030915134325.608a0468.mrose@dbc.mtview.ca.us> <3F6627C6.2020104@Royer.com> <20030915193256.43c64823.mrose@dbc.mtview.ca.us> <3F6678CD.8020102@Royer.com> <3F6736EA.4050106@Royer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-101.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, TO_ADDRESS_EQ_REAL,USER_AGENT_PINE,USER_IN_WHITELIST version=2.43 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Thanks. Much clearer. > > And the 'single blank line' is not in the ABNF of 2445, so no that is > not valid. > > icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF > icalbody > "END" ":" "VCALENDAR" CRLF) > > And both are valid for recipients that allow multipart. That is you > could send a multipart object where one or more of the parts contained > one or more 'icalobject's. That would be because my understanding of iCal and CAP is very limited, so take the wording with more than a pinch of salt, I'm hoping the list will correct as necessary. regards, jb From owner-ietf-calendar@mail.imc.org Tue Sep 16 13:26:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28060 for ; Tue, 16 Sep 2003 13:26:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GHD9eo093345 for ; Tue, 16 Sep 2003 10:13:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GHD9fr093344 for ietf-calendar-bks; Tue, 16 Sep 2003 10:13:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GHD7eo093339 for ; Tue, 16 Sep 2003 10:13:07 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h8GHD8fR001040; Tue, 16 Sep 2003 10:13:08 -0700 (PDT) Date: Tue, 16 Sep 2003 10:13:08 -0700 From: Marshall Rose To: John Berthels Cc: "ietf-calendar@imc.org" , Doug@royer.com Subject: Re: CAP - BEEP Profile Message-Id: <20030916101308.64b3c23b.mrose@dbc.mtview.ca.us> In-Reply-To: References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> <3F66219D.1060808@Royer.com> <20030915134325.608a0468.mrose@dbc.mtview.ca.us> <3F6627C6.2020104@Royer.com> <20030915193256.43c64823.mrose@dbc.mtview.ca.us> <3F6678CD.8020102@Royer.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Is the following wording any help? yes! that should work fine. thanks! /mtr From owner-ietf-calendar@mail.imc.org Tue Sep 16 13:44:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28811 for ; Tue, 16 Sep 2003 13:44:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GHP6eo093833 for ; Tue, 16 Sep 2003 10:25:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GHP6F5093832 for ietf-calendar-bks; Tue, 16 Sep 2003 10:25:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GHP5eo093827 for ; Tue, 16 Sep 2003 10:25:05 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8GHP4Gv003512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 16 Sep 2003 10:25:06 -0700 Message-ID: <3F67476B.1090208@Royer.com> Date: Tue, 16 Sep 2003 11:24:59 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP - BEEP Profile References: <307915BC-E701-11D7-98FE-000A9571873E@guppylake.com> <3F6601DD.7070700@Royer.com> <20030915132048.2f3ef33b.mrose@dbc.mtview.ca.us> <3F66219D.1060808@Royer.com> <20030915134325.608a0468.mrose@dbc.mtview.ca.us> <3F6627C6.2020104@Royer.com> <20030915193256.43c64823.mrose@dbc.mtview.ca.us> <3F6678CD.8020102@Royer.com> <20030916101308.64b3c23b.mrose@dbc.mtview.ca.us> In-Reply-To: <20030916101308.64b3c23b.mrose@dbc.mtview.ca.us> 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 Great. With a couple of tweaks I'll use John's text in -12-d. Marshall Rose wrote: >>Is the following wording any help? >> >> > >yes! that should work fine. thanks! > >/mtr > > > -- 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 Tue Sep 16 20:55:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21726 for ; Tue, 16 Sep 2003 20:55:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H0XAeo014276 for ; Tue, 16 Sep 2003 17:35:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8H0XA0W014275 for ietf-calendar-bks; Tue, 16 Sep 2003 17:33:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H0Udeo014183 for ; Tue, 16 Sep 2003 17:33:09 -0700 (PDT) (envelope-from gsbarnes@u.washington.edu) Received: from mead12.u.washington.edu (mead12.u.washington.edu [140.142.12.176]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.08) with ESMTP id h8H0UVq4018836 for ; Tue, 16 Sep 2003 17:30:36 -0700 Received: from localhost (gsbarnes@localhost) by mead12.u.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h8H0UV7I015166 for ; Tue, 16 Sep 2003 17:30:31 -0700 Date: Tue, 16 Sep 2003 17:30:31 -0700 (PDT) From: "G. Barnes" To: ietf-calendar@imc.org Subject: Re: iCalendar libraries? In-Reply-To: <005401c37c23$c756cd00$5801a8c0@persistent.co.in> 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: On Tue, 16 Sep 2003, Payod Deshpande wrote: > I need to add a vCalendar support for a mail client. I want to know if there > are any open source parsers (in JAVA) that I can use. We have some iCalendar support in our open source Java calendaring system, UW Calendar. See . Look in calendar/src/edu/washington/cac/calendar/{uwical,icalendar}. It may help. Or it may not. It all kind of depends on what you want your input and output to be. You parse some iCalendar text, and what do you want to come out the other side? Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Wed Sep 17 07:11:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05549 for ; Wed, 17 Sep 2003 07:11:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HAqdeo094840 for ; Wed, 17 Sep 2003 03:52:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HAqdqh094839 for ietf-calendar-bks; Wed, 17 Sep 2003 03:52:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.web.de (smtp03.web.de [217.72.192.158]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HAqceo094830 for ; Wed, 17 Sep 2003 03:52:38 -0700 (PDT) (envelope-from matthias.laabs@web.de) Received: from [217.66.193.78] (helo=matt.shabdiz.100.16.172.in-addr.arpa) by smtp.web.de with asmtp (WEB.DE 4.99 #448) id 19zZuu-0000Ib-00 for ietf-calendar@imc.org; Wed, 17 Sep 2003 12:52:24 +0200 From: Matthias Laabs Organization: Chapar Shabdiz To: ietf-calendar@imc.org Subject: different calendar systems - i18n Date: Wed, 17 Sep 2003 15:22:52 +0430 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309171522.52246.matthias.laabs@web.de> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I wonder about the possibility of adding support for jalali(persian), hijri(islamic), indian civil and hebrew calendar systems (if i missed one which is still in use it should be added to the list). While you can easily translate a date among these on application side (except for hijri) there is an unsolved problem within reccurencies - having an event on every newyear's of the jalali calendar is not possible in iCal, neither an event on every first day of the month. I am new to this list and the mail archive lacks a search engine - so i am sorry if this topic has been discussed already and i would appreciate a link to the discussion. Please let me know what you think about this issue. Thanks alot, greets, Matthias Laabs From owner-ietf-calendar@mail.imc.org Wed Sep 17 13:52:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21754 for ; Wed, 17 Sep 2003 13:52:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HHZ8ej009692 for ; Wed, 17 Sep 2003 10:35:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HHZ8Y8009691 for ietf-calendar-bks; Wed, 17 Sep 2003 10:35:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HHZ7ej009683 for ; Wed, 17 Sep 2003 10:35:07 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8HHZ3Gv014257 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 17 Sep 2003 10:35:05 -0700 Message-ID: <3F689B42.60807@Royer.com> Date: Wed, 17 Sep 2003 11:34:58 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: different calendar systems - i18n References: <200309171522.52246.matthias.laabs@web.de> In-Reply-To: <200309171522.52246.matthias.laabs@web.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080700070503080803080709" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080700070503080803080709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I do not think there has been any serious discussions of non gregorian calendars. If the 'CALSCALE' were 'jalali' then would not yearly in a recurrence rule work? I am not an expert on 'jalali' so I would think that the rules would have to be discussed and published (rfc) then it seems to me as if it would work. Matthias Laabs wrote: >Hi, >I wonder about the possibility of adding support for jalali(persian), >hijri(islamic), indian civil and hebrew calendar systems (if i missed one >which is still in use it should be added to the list). >While you can easily translate a date among these on application side (except >for hijri) there is an unsolved problem within reccurencies - having an event >on every newyear's of the jalali calendar is not possible in iCal, neither an >event on every first day of the month. > >I am new to this list and the mail archive lacks a search engine - so i am >sorry if this topic has been discussed already and i would appreciate a link >to the discussion. > >Please let me know what you think about this issue. > >Thanks alot, > >greets, >Matthias Laabs > > -- 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 --------------ms080700070503080803080709 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTE3MTczNDU4WjAjBgkqhkiG9w0BCQQxFgQUWRC8k47qBjOq/WSyRElK crDTCSUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAjxGTbEip0LczcSFjwYp7+m//C87be1qr64I4PDA7gP/8KdhDnJZZj/HFXZ6ZxX/B mo2BcPqzpBozl648qfFJ4kpQEJMH0+34VSdNTBRa2hQ+shsncsJTkLCGSJI5JrnFAzWjpU0r U3AMNNPH5HjLQGQ+T4Rp9JISmr2iUwZzpxipUmHjTyF2QT7Sg99EqEV5XGLMnDPlWu0qrozP fHkoOf6LtTYjCi2TG8DdN/61nEPHMRJlNYSuf3cnwUJR66OvhMDOetrC2sYN60/yUNxXjFXQ YuMCzbzcLVn0hjTi4m0yAZQ2LmevL13O3JoKgOGUAz/MM8qsGKqALoOP6IAymAAAAAAAAA== --------------ms080700070503080803080709-- From owner-ietf-calendar@mail.imc.org Fri Sep 19 11:54:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01550 for ; Fri, 19 Sep 2003 11:54:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J7EIKP042958 for ; Fri, 19 Sep 2003 00:14:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8J7EIXa042957 for ietf-calendar-bks; Fri, 19 Sep 2003 00:14:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J7EEKP042911 for ; Fri, 19 Sep 2003 00:14:16 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1A0FSa-0002UC-00 for ; Fri, 19 Sep 2003 09:13:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1A0FSU-0002Tk-00 for ; Fri, 19 Sep 2003 09:13:38 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1A0FSo-0005NO-00 for ; Fri, 19 Sep 2003 09:13:58 +0200 From: "Michael Fair" Subject: Re: Recurrence ID recommendation - almost there Date: Fri, 19 Sep 2003 00:13:57 -0700 Lines: 34 Message-ID: References: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just wondering what the status on those lists are? I'm anxious to find out what the list of outstanding CAP issues are as well as getting the recurrence-id issued settled. -- Michael -- wrote in message news:OFB1DAC4B7.C5FCB740-ON85256D9A.00620BD5-85256D9A.0062B3C4@egenconsulting.com... > I promised the list that I would post my findings and recommendation on > the Recurrence ID issue. I wanted to let the list know that I have not > forgotten this promise. I have indeed been working on just exactly that. > However, I have added to my chores production of a list of CAP issues. > Since I have been wading through 18 months of emails I discovered I may > have the ability to put down a short, succinct list of issues. Also, I'm > hoping to be able to "glean" consensus on some of them and violent > non-consensus on many others. If I am doing this legwork, it will be of > value to the list as well. > > In addition, I am making sure, with the original authors, that what I am > proposing is valid and will work. There is no sense mucking up a list > that is already overburdened with far too many nonproductive notes. Even > this one qualifies as nonproductive because it does not have my answer. > But that is coming. And not in a month - but, I'm hoping, by the end of > this week. I hesitate to put a date if I can't make it - but I am going > to try. The diff issue that was raised by Bruce sort of put me back a bit > - but it was worthwhile and necessary to work on that issue too. And, > sigh, being a small business owner, I had to go work on paying my > mortgage. I hate it when that happens. Not apologizing - just giving you > all a reality check on my part. > From owner-ietf-calendar@mail.imc.org Fri Sep 19 20:25:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27364 for ; Fri, 19 Sep 2003 20:25:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8K02fKP037561 for ; Fri, 19 Sep 2003 17:02:41 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8K02fUP037560 for ietf-calendar-bks; Fri, 19 Sep 2003 17:02:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ahimsa.guppylake.com (ahimsa.guppylake.com [208.177.184.197]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8K02eKP037551 for ; Fri, 19 Sep 2003 17:02:40 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from guppylake.com (pm612-08.dialip.mich.net [204.39.229.210]) by ahimsa.guppylake.com (8.12.8/8.12.8) with ESMTP id h8JNokbv018813; Fri, 19 Sep 2003 19:50:47 -0400 Date: Fri, 19 Sep 2003 20:03:23 -0400 Subject: Re: different calendar systems - i18n Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Nathaniel Borenstein To: ietf-calendar@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <3F689B42.60807@Royer.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, September 17, 2003, at 01:34 PM, Doug Royer wrote: > I do not think there has been any serious discussions of non gregorian > calendars. > If the 'CALSCALE' were 'jalali' then would not yearly in a recurrence > rule work? I think the point is that right now there's no way to convey a recurring non-gregorian date in a way that the recurrence can be reconstituted by another calendar system that processes the ical data -- right now, the translation has to happen at the point of origin, so the best you can do is generate N different events for the next N years. This makes it impossible, for example, for me to configure most calendar systems to remind me, in perpetuity, about my mother's Yahrtzeit (the Jewish observance of the anniversary of a death). There are even services that have arisen to fill the gap (http://yizkor.ort.org) >> I wonder about the possibility of adding support for jalali(persian), >> hijri(islamic), indian civil and hebrew calendar systems (if i missed >> one which is still in use it should be added to the list). When we built a calendar system as part of the Andrew project in the mid-80's, Craig Everhart built a core engine that handled multiple calendar systems, including the Ecclesiastical Roman calendar. That should be on anyone's top ten list, I think. And personally, I'd like to be able to represent historical events using Julian rather than Gregorian dates, but I'll concede that the market demand for scheduling pre-18th century events is probably pretty low. What really matters is that the architecture be extensible. In particular, at this point, the only proper question to ask about ical and non-gregorian dates is simply how easily we can extend it in the future to support multiple calendars. I would hate to see any of the current documents delayed for that feature, but it wouldn't hurt to see if there's a general consensus on how such an extension might work. Is the combination of VERSION and CALSCALE in RFC 2445 and CAP-VERSION in the current draft sufficient for such extensions? I don't see why not, but then I'm still new to this stuff... --- Nathaniel From owner-ietf-calendar@mail.imc.org Fri Sep 19 21:04:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28306 for ; Fri, 19 Sep 2003 21:04:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8K0mcKP039548 for ; Fri, 19 Sep 2003 17:48:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8K0mcwh039547 for ietf-calendar-bks; Fri, 19 Sep 2003 17:48:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8K0maKP039542 for ; Fri, 19 Sep 2003 17:48:36 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8K0maGv006151 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 19 Sep 2003 17:48:37 -0700 Message-ID: <3F6BA3DF.9020404@Royer.com> Date: Fri, 19 Sep 2003 18:48:31 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: different calendar systems - i18n References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070906000801080902010204" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070906000801080902010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nathaniel Borenstein wrote: > > On Wednesday, September 17, 2003, at 01:34 PM, Doug Royer wrote: > >> I do not think there has been any serious discussions of non >> gregorian calendars. >> If the 'CALSCALE' were 'jalali' then would not yearly in a recurrence >> rule work? > > > I think the point is that right now there's no way to convey a > recurring non-gregorian date in a way that the recurrence can be > reconstituted by another calendar system that processes the ical data > -- right now, the translation has to happen at the point of origin, so > the best you can do is generate N different events for the next N > years. This makes it impossible, for example, for me to configure > most calendar systems to remind me, in perpetuity, about my mother's > Yahrtzeit (the Jewish observance of the anniversary of a death). > There are even services that have arisen to fill the gap > (http://yizkor.ort.org) I got the point and I agree. I know nothing about 'Yahrtzeit' or a Jewish calendar. If a 'jalali' RFC were published with the rules and given that fact that 'YEARLY' is NOT defined to mean every 365 days. Why would not 'YEARY' in a 'jalali' calendar, do the correct 'jalali' math to produce the correct dates? Or are you saying that YEARLY (or whatever) will not ever work? Or if needed, you could define a J-RECUR data type to solve the problem. > I think the point is that right now there's no way to convey a > recurring non-gregorian date in a way that the recurrence can be > reconstituted by another calendar system that processes the ical data > -- right now, the translation has to happen at the point of origin, so > the best you can do is generate N different events for the next N > years. This makes it impossible, for example, for me to configure > most calendar systems to remind me, in perpetuity, about my mother's > Yahrtzeit (the Jewish observance of the anniversary of a death). > There are even services that have arisen to fill the gap > (http://yizkor.ort.org) And my point was - if needed submit a draft, publish the results, and keep working at it until and RFC is published. -- 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 --------------ms070906000801080902010204 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTIwMDA0ODMxWjAjBgkqhkiG9w0BCQQxFgQUyfNYNmFjX8+NuskdJ5qU 1sSgBgEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAksmk5JM8ATOc3NA0ZMUltz5zlpe9mUsEWeTjTgwvCY9TFpmWBOf4rkJN6xtZGW/C Irp3YYXPUFPo6M+8cKW7LCGoPCXv/JikfL9zldaDJAFiCJKTwqstlycF98+H3HiOeBZibz0y BpLeaCo7EvFmXKVYurltf1fLXYZFWa1oW3hYEJ5id69hMq/JYgQbxilkFNM4hDzXZu5YxOO+ VfMDo/8Pe2CnaFGZfyYNf/FBzQuvAjIhf5FQwj78xvnG++n/YYeGTM93nGD+FtIYNOAcms4q yrfxAqxvJ23u4qtef69ZBkBb2QtjCTIT1rZpqN9z92rlT1a1tKrZKP5pp4V/WQAAAAAAAA== --------------ms070906000801080902010204-- From owner-ietf-calendar@mail.imc.org Sat Sep 20 13:47:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17400 for ; Sat, 20 Sep 2003 13:47:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8KHVMKP052725 for ; Sat, 20 Sep 2003 10:31:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8KHVM5B052724 for ietf-calendar-bks; Sat, 20 Sep 2003 10:31:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ahimsa.guppylake.com (ahimsa.guppylake.com [208.177.184.197]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8KHVKKP052716 for ; Sat, 20 Sep 2003 10:31:21 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from guppylake.com (pcp05307270pcs.wanarb01.mi.comcast.net [68.42.70.186]) by ahimsa.guppylake.com (8.12.8/8.12.8) with ESMTP id h8KHJTbv022621 for ; Sat, 20 Sep 2003 13:19:29 -0400 Date: Sat, 20 Sep 2003 13:32:09 -0400 Subject: Re: different calendar systems - i18n Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Nathaniel Borenstein To: ietf-calendar@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <3F6BA3DF.9020404@Royer.com> Message-Id: <5CFFFF9E-EB90-11D7-AE55-000A9571873E@guppylake.com> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, September 19, 2003, at 08:48 PM, Doug Royer wrote: > If a 'jalali' RFC were published with the rules and given that fact > that 'YEARLY' is NOT defined to mean > every 365 days. Why would not 'YEARY' in a 'jalali' calendar, do the > correct 'jalali' math > to produce the correct dates? Or are you saying that YEARLY (or > whatever) will not ever work? The point is simply that "yearly" won't work if the calendar data is passed off to a calendar server that doesn't understand the calendar type (CALSCALE) in the first place. This underscores the need to make sure the extensibility is "done right." (This is a sore point with me, since we defined "MIME-Version" so badly that there will probably never be anything but 1.0.) > Or if needed, you could define a J-RECUR data type to solve the > problem. This, on the other hand, is what I'm afraid of -- I want to make sure we *know* how such extensions should > And my point was - if needed submit a draft, publish the results, and > keep working at it until > an RFC is published. No dispute there, only the question (posed to the list as a whole): Does everyone agree that the current extension mechanisms (VERSION, CALSCALE, CAP-VERSION) suffice to ensure that the desired extensions can be done correctly, i.e. without ever creating situations like the one I describe above, in which an older server accepts calendar data that it really doesn't know how to handle because of the unsupported CALSCALE. My guess/hope is that the answer is yes, but I would feel better knowing that wiser heads than mine have thought seriously about the problem and come to the same conclusion. -- Nathaniel From owner-ietf-calendar@mail.imc.org Sat Sep 20 15:23:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20612 for ; Sat, 20 Sep 2003 15:23:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8KJ8SKP069863 for ; Sat, 20 Sep 2003 12:08:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8KJ8SHB069862 for ietf-calendar-bks; Sat, 20 Sep 2003 12:08:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8KJ8QKP069857 for ; Sat, 20 Sep 2003 12:08:26 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8KJ8QGv013820 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 20 Sep 2003 12:08:27 -0700 Message-ID: <3F6CA5A4.3010102@Royer.com> Date: Sat, 20 Sep 2003 13:08:20 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: different calendar systems - i18n References: <5CFFFF9E-EB90-11D7-AE55-000A9571873E@guppylake.com> In-Reply-To: <5CFFFF9E-EB90-11D7-AE55-000A9571873E@guppylake.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020408030405040402030201" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020408030405040402030201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nathaniel Borenstein wrote: > > No dispute there, only the question (posed to the list as a whole): > Does everyone agree that the current extension mechanisms (VERSION, > CALSCALE, CAP-VERSION) suffice to ensure that the desired extensions > can be done correctly, i.e. without ever creating situations like the > one I describe above, in which an older server accepts calendar data > that it really doesn't know how to handle because of the unsupported > CALSCALE. My guess/hope is that the answer is yes, but I would feel > better knowing that wiser heads than mine have thought seriously about > the problem and come to the same conclusion. -- Nathaniel There is no way that an older server will know how to process new extensions. A properly implemented server would look at CALSCALE, VERSION, ... (and what ever) and know that it does not know how to handle it. If your server gets CALSCALE:foo and it does not know what to do with 'foo' then it better send back an error. CAP would not care when RECUR-EXPAND is false what the CALSCALE value was set to as such a CS would never be trying to do anything with recurrence rules. If RECUR-EXPAND is true, then yes the CS should reject the data if it does not understand CALSCALE:foo . Do you think we need to say that in CAP? VERSION is the iCal format version, not the version of the data that it contains. So VCARD works as a valid iCAL data because it conforms to version 2.0 of the iCAL format. Such a CS would only need to add VCARD to its COMPONENT capability list. So I think that VERSION will never be effected by the CALSCALE value as VERSION does not change when new components, properties or parameters are added. CAP-VERSION is intended to tell the CUA which RFC's the CS supports. It would not imply that CALSCALE:foo is or is not supported. Do you think that we can say that RFC -XXX (CAP) supports GREGORIAN and only after a new CALSCALE value is published we could then add a new CAPABILITY to CAP that tells the CS what CALSCALEs the CS supports. Or do you feel we need to have a CALSCALE capability now? Or as CAP-VERSION is a comma separated list could such a CALSCALE:foo CS just add RFC-foo to its 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 --------------ms020408030405040402030201 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTIwMTkwODIwWjAjBgkqhkiG9w0BCQQxFgQU83M/YXBxC9ZFPPV8eVsU 74697EMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAE7DsCkjkodHMJ5Y/ND4ZgOHzeo9NY7q8WtUcjzRxCH30tTlLkav09X/E/E084lIO 5WJVpPibbub9SLfugYlZyXKrAr7nOs1XGJ7TlQvdiZ01urH0vaHEaAQAOPUYfcNU2ppbWJYC NTibwU3bsGaImre6xXdiWe6wDAFjiZX7b9pRvj9tx+E+JwFpkwPZUF5h8Z3cKgCPeWlE94b+ yzcway/4SjW2mxXKLoFIQnBcR/FZ5Y0sf6ON/If68wCquK3TC49dtBSGPH00+T2VWhvd1y5X JnTl+5qmraup9FlLyAv/6CPqeVbP+1A9P8ohAhWWt7ntXg9y6ZQA1DZSjNE15AAAAAAAAA== --------------ms020408030405040402030201-- From owner-ietf-calendar@mail.imc.org Sun Sep 21 22:28:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16105 for ; Sun, 21 Sep 2003 22:28:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8M2C9KP099351 for ; Sun, 21 Sep 2003 19:12:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8M2C9bR099350 for ietf-calendar-bks; Sun, 21 Sep 2003 19:12:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8M2C7KP099340 for ; Sun, 21 Sep 2003 19:12:07 -0700 (PDT) (envelope-from TimHare@comcast.net) Message-Id: <200309220212.h8M2C7KP099340@above.proper.com> Received: from 204.127.197.115 ([204.127.197.115]) by comcast.net (rwcrmhc11) with SMTP id <20030922021150013004kdo4e>; Mon, 22 Sep 2003 02:11:50 +0000 Received: from [66.233.166.231] by 204.127.197.115; Mon, 22 Sep 2003 02:11:50 +0000 From: TimHare@comcast.net To: ietf-calendar@imc.org Subject: Re: different calendar systems Date: Mon, 22 Sep 2003 02:11:50 +0000 X-Mailer: AT&T Message Center Version 1 (Sep 12 2003) X-Authenticated-Sender: VGltSGFyZUBjb21jYXN0Lm5ldA== Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My 1.5 cents worth: I believe that what we have is sufficient to implement different calendar systems, with a couple of small changes. In 10.7, the reply to the GET- CAPABILITY command needs to include the CALSCALE property, with all of its values (not just the first) as a required item to return: cap-vreply = "BEGIN" ":" "VCALENDAR" CRLF ; The following properties may be in any order. ; prodid version reply-cmd other-props "BEGIN" ":" "VREPLY" CRLF ; The following properties may be in any order. ; cap-version car-level components calscale-props stores-expanded maxdate mindate itip-version max-comp-size multipart query-level recur-accepted recur-expand recur-limit other-props "END" ":" "VREPLY" CRLF "END" ":" "VCALENDAR" CRLF This change allows the other end of a CAP session to determine immediately if its partner supports as one of its CALSCALEs the scale that it wants to use. We can, as I read CAP, already use VQUERY with TARGET to determine if a particular VAGENDA has a particular scale. I'm undecided about whether we need to specifically add new words for certain periods of time, or not, to accomodate recurrence rules in other scales, but that I feel is an iCAL/RFC2445 issue and not a CAP issue per se. Recurrence rules and their grammar are already a complex issue, I'd rather not drag them into CAP. Therefore, I propose that we change 10.7 to include the calscale-props as a required return to the GET-CAPABILITY command, and that we modify the example to reflect that by including a CALSCALE: GREGORIAN, HEBREW, JALALIL CRLF example. Do you all concur that this would help, and do you want to add this small change to CAP? Tim Hare Interested Bystander, non-inc. From owner-ietf-calendar@mail.imc.org Mon Sep 22 12:23:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23425 for ; Mon, 22 Sep 2003 12:22:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MG3mKP092522 for ; Mon, 22 Sep 2003 09:03:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8MG3mI9092521 for ietf-calendar-bks; Mon, 22 Sep 2003 09:03:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MG3lKP092514 for ; Mon, 22 Sep 2003 09:03:47 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F6BA3DF.9020404@Royer.com> To: ietf-calendar@imc.org Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: different calendar systems - i18n MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_09102003NP September 10, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 22 Sep 2003 12:02:14 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/22/2003 12:03:38 PM, Serialize complete at 09/22/2003 12:03:38 PM Content-Type: multipart/alternative; boundary="=_alternative 0057FF2085256DA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057FF2085256DA9_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 09/19/2003 08:48:31 PM: > I got the point and I agree. I know nothing about 'Yahrtzeit' or a > Jewish calendar. > > If a 'jalali' RFC were published with the rules and given that fact that > 'YEARLY' is NOT defined to mean > every 365 days. Why would not 'YEARY' in a 'jalali' calendar, do the > correct 'jalali' math > to produce the correct dates? Or are you saying that YEARLY (or > whatever) will not ever work? There are other GREGORIAN 'biases' in the current Recurrence Rule we have in iCalendar. Stuff like the days in the month, the number of months in the year, the weekday _names_, etc. As such its not a simple matter to just define another CALSCALE property value and be done with it. To support non-Gregorian calendars, iCalendar needs to have changes besides the new token for CALSCALE. It can be done using the current properties without any radical changes (ie: new properties, etc). The current properties can be reused but their property values (or 'sub-values' in the case of the grammars) need to be changed. I would also hope that noone blindly ignored checking CALSCALE, if its in the iCalendar stream, and just plows ahead with item evaluation... If they do, oh well they get what they get then... > Or if needed, you could define a J-RECUR data type to solve the problem. No need to define new properties that define the same function as existing properties but with slightly different data points (ie: weekday names/designations). That would be wasteful and needless really. Any new calendar scale draft should take the time to properly refine the recurrence/exclusion rules and related data items so that we dont get bloating or dupliation of semantics (ie: a new repeat rule property for each CALSCALE type is dumb IMNHO). > And my point was - if needed submit a draft, publish the results, and > keep working at it until > and RFC is published. I think we all agree here. The only question that remains unanswered is does CAP need to be changed to address this? For example, just how would a CUA detect if a CS supports CALSCALEs other than GREGORIAN short of doing 'probes' of some kind? Or does CAP need to care at this point since there are no other CALSCALEs even in draft at this point? We may not really care and since the "default" is GREGORIAN so no "CALSCALE" capability means essentially "only Gregorian spoken here"... For later CAP drafts, as new calendars are defined, we may need this but for now do we? (Will leaving it out be a problem later on?...) 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 0057FF2085256DA9_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 09/19/2003 08:48:31 PM:
> I got the point and I agree. I know nothing about 'Yahrtzeit' or a
> Jewish calendar.
>
> If a 'jalali' RFC were published with the rules and given that fact that
> 'YEARLY' is NOT defined to mean
> every 365 days. Why would not 'YEARY' in a 'jalali' calendar, do the
> correct 'jalali' math
> to produce the correct dates? Or are you saying that YEARLY (or
> whatever) will not ever work?
There are other GREGORIAN 'biases' in the current Recurrence Rule we have in iCalendar.  Stuff like the days in the month, the number of months in the year, the weekday _names_, etc.  As such its not a simple matter to just define another CALSCALE property value and be done with it.

To support non-Gregorian calendars, iCalendar needs to have changes besides the new token for CALSCALE.  It can be done using the current properties without any radical changes (ie: new properties, etc).  The current properties can be reused but their property values (or 'sub-values' in the case of the grammars) need to be changed.

I would also hope that noone blindly ignored checking CALSCALE, if its in the iCalendar stream, and just plows ahead with item evaluation...  If they do, oh well they get what they get then...

> Or  if needed, you could define a J-RECUR data type to solve the problem.
No need to define new properties that define the same function as existing properties but with slightly different data points (ie: weekday names/designations).  That would be wasteful and needless really.  Any new calendar scale draft should take the time to properly refine the recurrence/exclusion rules and related data items so that we dont get bloating or dupliation of semantics (ie: a new repeat rule property for each CALSCALE type is dumb IMNHO).

> And my point was - if needed submit a draft, publish the results, and
> keep working at it until
> and RFC is published.
I think we all agree here.  The only question that remains unanswered is does CAP need to be changed to address this?  

For example, just how would a CUA detect if a CS supports CALSCALEs other than GREGORIAN short of doing 'probes' of some kind?  Or does CAP need to care at this point since there are no other CALSCALEs even in draft at this point?  

We may not really care and since the "default" is GREGORIAN so no "CALSCALE" capability means essentially "only Gregorian spoken here"...  For later CAP drafts, as new calendars are defined, we may need this but for now do we?  (Will leaving it out be a problem later on?...)

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 0057FF2085256DA9_=-- From owner-ietf-calendar@mail.imc.org Mon Sep 22 13:53:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27498 for ; Mon, 22 Sep 2003 13:53:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MHZ3KP096142 for ; Mon, 22 Sep 2003 10:35:03 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8MHZ3uh096140 for ietf-calendar-bks; Mon, 22 Sep 2003 10:35:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MHZ2KP096131 for ; Mon, 22 Sep 2003 10:35:02 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <000701c37c18$ea3b9ae0$5801a8c0@persistent.co.in> To: "Payod Deshpande" Cc: ietf-calendar@imc.org Subject: Re: Open Source Parsers MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_09102003NP September 10, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 22 Sep 2003 13:32:04 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/22/2003 01:34:49 PM, Serialize complete at 09/22/2003 01:34:49 PM Content-Type: multipart/alternative; boundary="=_alternative 006038A385256DA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006038A385256DA9_= Content-Type: text/plain; charset="US-ASCII" Payod asked on 09/16/2003 02:08:12 AM: > I have a passing interest in developing vCalendar support for a mail client. > I would like to know if there are any open source parsers (preferably in > JAVA), which I can extend for my own purpose? Try looking at http://www.imc.org/pdi/ for vCalendar / vCard parsing code. Its not been updated to deal with iCalendar but it should help you out. Im not sure if the libiCal work will do what you want but you can also check out that effort at http://www.softwarestudio.org/libical/ or on SourceForge at http://www.sourceforge.net/projects/freeassociation/ 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 006038A385256DA9_= Content-Type: text/html; charset="US-ASCII"
Payod asked on 09/16/2003 02:08:12 AM:
> I have a passing interest in developing vCalendar support for a mail client.
> I would like to know if there are any open source parsers (preferably in
> JAVA), which I can extend for my own purpose?
Try looking at http://www.imc.org/pdi/ for vCalendar / vCard parsing code.  Its not been updated to deal with iCalendar but it should help you out.  

Im not sure if the libiCal work will do what you want but you can also check out that effort at http://www.softwarestudio.org/libical/ or on SourceForge at http://www.sourceforge.net/projects/freeassociation/

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 006038A385256DA9_=-- From owner-ietf-calendar@mail.imc.org Mon Sep 22 14:12:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28221 for ; Mon, 22 Sep 2003 14:12:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MGucKP094430 for ; Mon, 22 Sep 2003 09:56:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8MGucf4094429 for ietf-calendar-bks; Mon, 22 Sep 2003 09:56:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MGsGKP094283 for ; Mon, 22 Sep 2003 09:56:37 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8MGsDGv022515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 22 Sep 2003 09:54:17 -0700 Message-ID: <3F6F2930.3050601@Royer.com> Date: Mon, 22 Sep 2003 10:54:08 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: different calendar systems - i18n References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010204090108000100050805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010204090108000100050805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 09/19/2003 08:48:31 PM: > > I got the point and I agree. I know nothing about 'Yahrtzeit' or a > > Jewish calendar. > > > > If a 'jalali' RFC were published with the rules and given that fact > that > > 'YEARLY' is NOT defined to mean > > every 365 days. Why would not 'YEARY' in a 'jalali' calendar, do the > > correct 'jalali' math > > to produce the correct dates? Or are you saying that YEARLY (or > > whatever) will not ever work? > > There are other GREGORIAN 'biases' in the current Recurrence Rule we > have in iCalendar. Stuff like the days in the month, the number of > months in the year, the weekday _names_, etc. As such its not a > simple matter to just define another CALSCALE property value and be > done with it. When someone publishes the details for a new CALSCALE value then the debate will have meaning. Until then everyone seems to be saying that we can only guess and I agree. -- 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 --------------ms010204090108000100050805 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTIyMTY1NDA4WjAjBgkqhkiG9w0BCQQxFgQUUBYK7VoM3WD4W2LJes4b I03vBmswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEALztij7CE7R8WSWjPjh8yKXGyz1jCZ4ROMofcvqS/1VVBM6pdxigKcWDL+fMzmZx0 wQBnGrU0q4duRu7q0rtHiGNxYop3zr5M7zAc5ZxNYLj2NW9KBl6k4Hw+FbxcIY8QQCFQsqFV 55CnSFw/EdvaXK9CeDAhdZxTBf2NT4g6N51Ig3HYUDUz5TQFGyyQgAKMGQAi4bFmpAuz11PS rixSe6XcKzSYwX8ZcpOPsUq8ZcDqmAWYlxPyt8zqAuYHr7ey09JK8FANkQGLLjaY+8AXcQwO YarH5mwWIfK943BxwM7PmM/OzuyXgRTjAu24gLliJS4wpf3XHUGYKQAyEfj2JAAAAAAAAA== --------------ms010204090108000100050805-- From owner-ietf-calendar@mail.imc.org Mon Sep 22 14:52:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00510 for ; Mon, 22 Sep 2003 14:52:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MIaSKP098839 for ; Mon, 22 Sep 2003 11:36:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8MIaS3f098838 for ietf-calendar-bks; Mon, 22 Sep 2003 11:36:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MIaRKP098833 for ; Mon, 22 Sep 2003 11:36:27 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F5DFED8.510B272A@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_09102003NP September 10, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 22 Sep 2003 14:31:35 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 09/22/2003 02:36:11 PM, Serialize complete at 09/22/2003 02:36:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0065AB9085256DA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065AB9085256DA9_= Content-Type: text/plain; charset="US-ASCII" Mark pined on 09/09/2003 12:24:56 PM: > Why is is so hard for you to admit that your posts of late > have no technical content or CAP protocol issues in them. Thats because you and Doug continue to detract from actual discussions by claiming no remaining issues or insinuating that without a proposed solution any issue is not an issue. I have and will continue to point out the problems with CAP. Unlike you and Doug, I _have_ proposed changes but neither of you has opt'd to discuss them or propose alternatives of your own. I proposed the removal of the stored query from CAP 1.0 with general agreement from the WG. I see that this was reflected in CAP-12-c so thats goodness (albeit with some residuals that need removal still). I noted and then proposed a fix for the issue of busytime handling in CAP. Neither you nor Doug opt'd to discuss it; in fact neither of the 2 times I proposed it. The proposal is still on the table. Neither of you seem to think that Prestons issue about accesssing data outside the scope of a query is an issue but many of us do. This is a non-trivail concern thats gotten no WG discussion at all. In case you missed it, go back to early April 2003 and look for the "How do you get the METHOD property on a SEARCH" thread. As Ive tried to point out (and will continue to until its resolved), this needs to be fixed if CAP is to function properly. I dont have a proposed solution so dont ask me for one and say "Well if you dont have a proposal its not an issue." Raising issues does not obligate one to proposing a solution and besides I didnt raise it originally. Why not put some of your engergy into solving the issues rather than distracting us from getting CAP polished for prime time?... 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 0065AB9085256DA9_= Content-Type: text/html; charset="US-ASCII"
Mark pined on 09/09/2003 12:24:56 PM:
> Why is is so hard for you to admit that your posts of late
> have no technical content or CAP protocol issues in them.
Thats because you and Doug continue to detract from actual discussions by claiming no remaining issues or insinuating that without a proposed solution any issue is not an issue.

I have and will continue to point out the problems with CAP.  Unlike you and Doug, I _have_ proposed changes but neither of you has opt'd to discuss them or propose alternatives of your own.

I proposed the removal of the stored query from CAP 1.0 with general agreement from the WG.  I see that this was reflected in CAP-12-c so thats goodness (albeit with some residuals that need removal still).

I noted and then proposed a fix for the issue of busytime handling in CAP.  Neither you nor Doug opt'd to discuss it; in fact neither of the 2 times I proposed it.  The proposal is still on the table.

Neither of you seem to think that Prestons issue about accesssing data outside the scope of a query is an issue but many of us do.  This is a non-trivail concern thats gotten no WG discussion at all.  In case you missed it, go back to early April 2003 and look for the "How do you get the METHOD property on a SEARCH" thread.  As Ive tried to point out (and will continue to until its resolved), this needs to be fixed if CAP is to function properly.  I dont have a proposed solution so dont ask me for one and say "Well if you dont have a proposal its not an issue."  Raising issues does not obligate one to proposing a solution and besides I didnt raise it originally.

Why not put some of your engergy into solving the issues rather than distracting us from getting CAP polished for prime time?...

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 0065AB9085256DA9_=-- From owner-ietf-calendar@mail.imc.org Mon Sep 22 15:31:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04300 for ; Mon, 22 Sep 2003 15:31:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MJCoKP000428 for ; Mon, 22 Sep 2003 12:12:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8MJCoYl000427 for ietf-calendar-bks; Mon, 22 Sep 2003 12:12:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MJClKP000408 for ; Mon, 22 Sep 2003 12:12:48 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h8MJCiQj017218 for ; Mon, 22 Sep 2003 13:12:44 -0600 (MDT) Message-ID: <3F6F49AC.5BB0DB77@INET-Calendar.net> Date: Mon, 22 Sep 2003 13:12:44 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: CAP-12 - interm version 'A'] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: > > Mark pined on 09/09/2003 12:24:56 PM: > > Why is is so hard for you to admit that your posts of late > > have no technical content or CAP protocol issues in them. > > Thats because you and Doug continue to detract from actual discussions > by claiming no remaining issues or insinuating that without a proposed > solution any issue is not an issue. What is your list? From owner-ietf-calendar@mail.imc.org Mon Sep 22 16:27:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08765 for ; Mon, 22 Sep 2003 16:27:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MKB2KP002604 for ; Mon, 22 Sep 2003 13:11:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8MKB2HF002603 for ietf-calendar-bks; Mon, 22 Sep 2003 13:11:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MKB1KP002598 for ; Mon, 22 Sep 2003 13:11:01 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8MKB1Gv024302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 22 Sep 2003 13:11:02 -0700 Message-ID: <3F6F574F.6030903@Royer.com> Date: Mon, 22 Sep 2003 14:10:55 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP-12 - interm version 'D' Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030905040708050005050508" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030905040708050005050508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have placed the latest edit of CAP for your review at: http://inet-consulting.com/draft-ietf-calsch-cap-12-d.txt http://inet-consulting.com/draft-ietf-calsch-cap-12-d.html http://inet-consulting.com/draft-ietf-calsch-cap-12-d.xml -- 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 --------------ms030905040708050005050508 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTIyMjAxMDU1WjAjBgkqhkiG9w0BCQQxFgQUDRLIuGLdzD4NdOKt1wvf keDrO/gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAkRHszwKxswFh2bXr7wqNg+ziO5DNUzl7kXG7oGFbcJMCpVAO77/tfQurYRXzz1Pk 3lhi5w8VHG+FzLBDL/KZn4uUPU1kf1X4AEUdE19nHpnnOplMcklHAGwz05MXOdKyp2ZG+A0y eUMLCXLzKxoRPm8OJjVZql6fNhhMBWnceWPzVItlLgxNT0DrxOJzeWbIia54ct1hoE7yZs4o Kj8EGNAn0OWdPpKUxUKwfChTpE83imBKNJkJfinH+k9uom6aMjaTEdc9mS1pkLp8CuObF9D5 e4X69QUg89mQwlC3wKXB/PUO1lu0qsDve1904HdMDzu4OxjBqkoFi+AVYBYYhwAAAAAAAA== --------------ms030905040708050005050508-- From owner-ietf-calendar@mail.imc.org Mon Sep 22 22:43:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04153 for ; Mon, 22 Sep 2003 22:43:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8N2OFKP013854 for ; Mon, 22 Sep 2003 19:24:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8N2OFrf013853 for ietf-calendar-bks; Mon, 22 Sep 2003 19:24:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8N2OEKP013848 for ; Mon, 22 Sep 2003 19:24:14 -0700 (PDT) (envelope-from TimHare@comcast.net) Message-Id: <200309230224.h8N2OEKP013848@above.proper.com> Received: from 204.127.197.118 ([204.127.197.118]) by comcast.net (rwcrmhc13) with SMTP id <2003092302241101500ghal9e>; Tue, 23 Sep 2003 02:24:11 +0000 Received: from [66.233.166.10] by 204.127.197.118; Tue, 23 Sep 2003 02:24:11 +0000 From: TimHare@comcast.net To: "ietf-calendar@imc.org" Subject: Re: different calendar scales Date: Tue, 23 Sep 2003 02:24:11 +0000 X-Mailer: AT&T Message Center Version 1 (Sep 12 2003) X-Authenticated-Sender: VGltSGFyZUBjb21jYXN0Lm5ldA== Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I thought I sent this last night, but I don't see it reflected on the list, so here it is my proposal again (apologies if it shows up twice): I propose that CAP 10.7 be revised so that calscale-props is included as a required response to the GET-CAPABILITY command, and that any examples for GET- CAPABILITY be modified to show CALSCALE: GREGORIAN, HEBREW, JALALIL CRLF (or a similar list of calendar scales) being returned. Having CALSCALE returned will inform any CUA immediately whether or not the CS or other CUA has the capability to use a scale other than Gregorian. Any CUA can determine if a _particular_ VAGENDA is in a certain scale by using VQUERY with a TARGET for that VAGENDA. This doesn't address the issue of how individual implementations will handle the scales, nor does it address recurrence rules. This proposal is merely a "minor" change to make CAP able to communicate the capabilities of a particular endpoint regarding calendar scales. I feel the response should be _mandatory_ because the calendar scale determines so much of how other items in CAP are handled. Tim Hare Interested Bystander, non-inc. From owner-ietf-calendar@mail.imc.org Tue Sep 23 13:54:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27475 for ; Tue, 23 Sep 2003 13:54:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NHVOKP027801 for ; Tue, 23 Sep 2003 10:31:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8NHVOUU027800 for ietf-calendar-bks; Tue, 23 Sep 2003 10:31:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NHVMKP027793 for ; Tue, 23 Sep 2003 10:31:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8NHVLXZ012187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 23 Sep 2003 10:31:23 -0700 Message-ID: <3F708360.4000105@Royer.com> Date: Tue, 23 Sep 2003 11:31:12 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: When to publish -12 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080105030505050104080303" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080105030505050104080303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As the MN IETF is coming up I plan to publish -12 about Oct 15 th. -12-d has the latest typos and the updated BEEP profile in it. I do not plan on putting the CALSCALE capability into CAP unless the chairs call consensus on it to be added. It can be added later when (if) someone publishes a new CALSCALE value. Again I am down to zero CAP items. -- 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 --------------ms080105030505050104080303 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTIzMTczMTEyWjAjBgkqhkiG9w0BCQQxFgQU7eoZT/EJPuQkXW2t8PSQ 5npR9yMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAfNQi4QRK/WcKa9jcS/U0/39lNCjzu7880GIFrLcl6gxbt/6ietvmkUneeeKmbHQX 9r6JAPnAi0MQMvflr2kUSqihrkyevzcMdFnubMpepBXhdiF8xdu2wc32/gq2+W5QxTlqfkA0 0mXB4v2/bzkNcJ3KzhuEkzMN2t2VGzx/Rd/FEMEBCzxY98t2IprUVm3XINVwa3WCITl9Rf0M 0G3xi0zRkoDkVnwfiHlnyzsXRnXZaiRl850fFuOlZnDQPqqsK9sb5pR/rKW6B6UC6zpCadp2 7bZmROzEVgLav99xJ4KBAiu7d867jsqRfz1sIW9nIT97Jqkzn4na1zHme1YrbQAAAAAAAA== --------------ms080105030505050104080303-- From owner-ietf-calendar@mail.imc.org Tue Sep 23 16:16:37 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04898 for ; Tue, 23 Sep 2003 16:16:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NJwKKP035819 for ; Tue, 23 Sep 2003 12:58:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8NJwKaI035818 for ietf-calendar-bks; Tue, 23 Sep 2003 12:58:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from aretha.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NJwJKP035810 for ; Tue, 23 Sep 2003 12:58:19 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F708360.4000105@Royer.com> MIME-Version: 1.0 To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: When to publish -12 X-Mailer: Lotus Notes Build V70_09102003NP September 10, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 23 Sep 2003 15:58:12 -0400 X-MIMETrack: Serialize by Router on Aretha/Iris(Build V603_09142003NP|September 14, 2003) at 09/23/2003 04:00:15 PM, Serialize complete at 09/23/2003 04:00:15 PM Content-Type: multipart/alternative; boundary="=_alternative 006D927A85256DAA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D927A85256DAA_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 09/23/2003 01:31:12 PM: > Again I am down to zero CAP items. Not so fast Doug. There are at least 2 other known big issues still to be resolved, even if you refuse to track them. 1: Busytime in CAP 2: 'Scoping' concerns raised by Preson in April 2003. I know for one that I did not agree w/Dougs summary of what he thought Craig proposed (ie: 'Use existing CMD:CREATE to store VFREEBUSY objects." ) and we never fully resolved the issue before the long argument over RECURRENCE-ID. Other smaller issues include: I see that despite my prior postings about the poor ABNF, some changes have yet to still be made regarding queryc. According to the ABNF, the _only_ command that can have a VQUERY component in it is the CREATE command. This is wrong and was already noted in May/June 2003 but still remains unfixed. An analysis of the ABNF shows that queryc is ONLY used in the create-comp which only occurs for the CREATE command. As such, it is not legal by the ABNF to have a VQUERY inside a DELETE or SEARCH command. Clearly this was not intended but its not been corrected yet either. The ABNF for some commands like CREATE are well structured and have relatively clear request and reply sections but other commands like DELETE do not. The ABNF needs to be cleaned up and made consistant. The text of the CREATE command needs to be reordered a bit to be more logically correct. Currently, right after the "Formal Defintiion" text is a block titled "Response:". Further down is the text that describes the actual "request" (my lable). This seems backwards; the "request" bit of the command should be described before the "response" bit unless you like confusing readers. This same ordering check should be done to all commands. Lastly, I also see some changes that did not get fully done in CAP-12-c or -d. Some references to stored queries were removed but not all: QUERYID - A unique id for a stored query. (Section 8.27) can be removed along with all of Section 8.27 and any other references to queryid. Section 9.6 VQUERY Component needs to be updated a bit more to justt: 9.6 VQUERY Component Component Name: VQUERY Purpose: A component to specify what is to be fetched from a CS. Formal Definition: A "VQUERY" component is defined by the following notation: queryc = "BEGIN" ":" "VQUERY" CRLF queryprop "END" ":" "VCAR" CRLF queryprop = 1*( ; the following MUST occur at least once ; query / ; 'expand' is OPTIONAL but MUST NOT occur ; more than once. expand / ; the following are OPTIONAL, and MAY occur ; more than once ; other-props ) Description: A "VQUERY" contains properties that specify which properties and components the CS is requested to return during a SEARCH command. For examples, see Section 6.1.1. Also, technically speaking a VQUERY is NOT just used "to specify what is to be _fetched_" because the VQUERY can be (once we fix it) used in more than the just the SEARCH command. When used on some commands it "specifys a set of components to apply the command to", whatever the command is that uses it. That is, it specifys the set of components to delete on the DELETE command, those to move with the MOVE command, etc. Not every command "fetches" components so this Purpose is incorrect as it stands 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 006D927A85256DAA_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 09/23/2003 01:31:12 PM:
> Again I am down to zero CAP items.
Not so fast Doug.  There are at least 2 other known big issues still to be resolved, even if you refuse to track them.

1: Busytime in CAP
2: 'Scoping' concerns raised by Preson in April 2003.

I know for one that I did not agree w/Dougs summary of what he thought Craig proposed (ie: 'Use existing CMD:CREATE to store VFREEBUSY objects." ) and we never fully resolved the issue before the long argument over RECURRENCE-ID.

Other smaller issues include:

I see that despite my prior postings about the poor ABNF, some changes have yet to still be made regarding queryc.  According to the ABNF, the _only_ command that can have a VQUERY component in it is the CREATE command.  This is wrong and was already noted in May/June 2003 but still remains unfixed.  

An analysis of the ABNF shows that queryc is ONLY used in the create-comp which only occurs for the CREATE command.  As such, it is not legal by the ABNF to have a VQUERY inside a DELETE or SEARCH command.   Clearly this was not intended but its not been corrected yet either.  The ABNF for some commands like CREATE are well structured and have relatively clear request and reply sections but other commands like DELETE do not.  The ABNF needs to be cleaned up and made consistant.

The text of the CREATE command needs to be reordered a bit to be more logically correct.  Currently, right after the "Formal Defintiion" text is a block titled "Response:".  Further down is the text that describes the actual "request" (my lable).  This seems backwards; the "request" bit of the command should be described before the "response" bit unless you like confusing readers.  This same ordering check should be done to all commands.

Lastly, I also see some changes that did not get fully done in CAP-12-c or -d.  Some references to stored queries were removed but not all:

   QUERYID -  A unique id for a stored query. (Section 8.27)
can be removed along with all of Section 8.27 and any other references to queryid.

Section 9.6 VQUERY Component needs to be updated a bit more to justt:

9.6 VQUERY Component

  Component Name: VQUERY

  Purpose: A component to specify what is to be fetched from a CS.

  Formal Definition: A "VQUERY" component is defined by the following
  notation:

  queryc    =  "BEGIN" ":" "VQUERY" CRLF
               queryprop
               "END" ":" "VCAR" CRLF

  queryprop = 1*(
            ; the following MUST occur at least once
            ;
            query /
             ; 'expand' is OPTIONAL but MUST NOT occur
            ; more than once.

            expand /

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

  Description: A "VQUERY" contains properties that specify which
  properties and components the CS is requested to return during a
  SEARCH command.

  For examples, see Section 6.1.1.
Also, technically speaking a VQUERY is NOT just used "to specify what is to be _fetched_" because the VQUERY can be (once we fix it) used in more than the just the SEARCH command.  When used on some commands it "specifys a set of components to apply the command to", whatever the command is that uses it.  That is, it specifys the set of components to delete on the DELETE command, those to move with the MOVE command, etc.  Not every command "fetches" components so this Purpose is incorrect as it stands 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 006D927A85256DAA_=-- From owner-ietf-calendar@mail.imc.org Tue Sep 23 17:39:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08262 for ; Tue, 23 Sep 2003 17:39:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NLKuKP039396 for ; Tue, 23 Sep 2003 14:20:56 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8NLKur5039395 for ietf-calendar-bks; Tue, 23 Sep 2003 14:20:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NLKtKP039388 for ; Tue, 23 Sep 2003 14:20:55 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h8NLKpXZ014011 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 23 Sep 2003 14:20:55 -0700 Message-ID: <3F70B92D.9020101@Royer.com> Date: Tue, 23 Sep 2003 15:20:45 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040702000407030806090303" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040702000407030806090303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 09/23/2003 01:31:12 PM: > > Again I am down to zero CAP items. > > Not so fast Doug. There are at least 2 other known big issues still > to be resolved, even if you refuse to track them. > > 1: Busytime in CAP So what is the issue? > > 2: 'Scoping' concerns raised by Preson in April 2003. > > I know for one that I did not agree w/Dougs summary of what he thought > Craig proposed (ie: 'Use existing CMD:CREATE to store VFREEBUSY > objects." ) ... Do *YOU* have a proposal? Others did and their comments were incorporated. > > Other smaller issues include: > > I see that despite my prior postings about the poor ABNF, some changes > have yet to still be made regarding queryc. According to the ABNF, > the _only_ command that can have a VQUERY component in it is the > CREATE command. This is wrong and was already noted in May/June 2003 > but still remains unfixed. Not all of CAP is in ABNF. Read the text and you will find out when it is used. If you have ABNF proposals - please post them, if not it looks to me as if CAP explains when they can be used. > > Lastly, I also see some changes that did not get fully done in > CAP-12-c or -d. Some references to stored queries were removed but > not all: On this topic I will wait for consensus to be called. The only thing I can find is that auto-execute of queries was to be dropped was the topic. Not that some components types could not be saved. I do not see any debate on dropping QUERYID, in fact the archive is full of discussions on how to use it, and what to name it and how to describe how to use 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 --------------ms040702000407030806090303 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMwOTIzMjEyMDQ2WjAjBgkqhkiG9w0BCQQxFgQUVYXAXhMYcsy16880oLlc i+d3g+QwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAf5AChAslyBLn15OnG/iCbwa5fK93hs0B0LwiSGS+kaJKM6m9zpKlW/qD8ooq7IKS L1AE3A5Zbut10tviqR8Sljbfu5XKrudg36A2OHCVno5XwDQawaiTTsfHFECwa1U0d46AJEK2 HkWhr87LaTXHSS5p//KlDOliJDSFN1GcVCrT301bhBP1QeqhvhypW3y7LSrXoXm37VzOhsZN 5/eE9w5Be8JfVU7eqDbMZI5Ofuqme2da/CxWdLxq20SGJkdg/+L4HajqTDgFLoPX4ClYlrre 2miQCNFK9Z8ojGGjVqk31W7WQ3gKyp9wyCB98C/ZlwCzbt3i7+N0PYnNQN+WGwAAAAAAAA== --------------ms040702000407030806090303--