From owner-ietf-calendar@mail.imc.org Fri Nov 1 07:34:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04940 for ; Fri, 1 Nov 2002 07:34:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA1CRS923364 for ietf-calendar-bks; Fri, 1 Nov 2002 04:27:28 -0800 (PST) Received: from grizzly.poss.com (grizzly.poss.com [198.70.184.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA1CRQW23360 for ; Fri, 1 Nov 2002 04:27:27 -0800 (PST) Received: from endeavor.poss.com ([198.70.184.137]) by grizzly.poss.com; Fri, 01 Nov 2002 07:23:10 -0500 (EST) Received: from willy.commnav.com (willy.commnav.com [198.70.184.67]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) with ESMTP id <0H4W009SBD88JU@endeavor.poss.com> for ietf-calendar@imc.org; Fri, 01 Nov 2002 07:26:32 -0500 (EST) Date: Fri, 01 Nov 2002 07:28:22 -0500 (EST) From: dking@commnav.com Subject: Recurrence rule WKST clarification To: ietf-calendar@imc.org Message-id: <5119787.1036153702203.JavaMail.jworrall@willy.commnav.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Is WKST the first day of the week as defined by BYWEEKNO or the first day of the work week as defined by WKST? BYWEEKNO on page 43 of RFC 2445 states: "A week is defined as a seven day period, starting on the day of the week defined to be the week start (see WKST)." WKST on page 44 of RFC 2445 states: "The WKST rule part specifies the day on which the workweek starts." Thanks for your time, -David From owner-ietf-calendar@mail.imc.org Sat Nov 2 13:46:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10319 for ; Sat, 2 Nov 2002 13:46:12 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA2IYh928673 for ietf-calendar-bks; Sat, 2 Nov 2002 10:34:43 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA2IYfW28669 for ; Sat, 2 Nov 2002 10:34:41 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA2IYWIR003699 for ; Sat, 2 Nov 2002 10:34:42 -0800 Message-ID: <3DC41ACB.8060402@Royer.com> Date: Sat, 02 Nov 2002 11:34:51 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 6.1.1 CAL-QUERY Value Type (Updated QUERY ABNF) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070500080908010601070503" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070500080908010601070503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I believe this ABNF allows for VEVENT.prop-name as noted in the original email... cal-query = "SELECT" SP cap-val SP "FROM" SP comp-name SP "WHERE" SP cap-expr / "SELECT" SP cap-cols SP "FROM" SP comp-name cap-val = cap-cols / param / ( cap-val "," cap-val ) ; NOTE: there is NO space around the "," on ; the next line cap-cols = cap-col / ( cap-cols "," cap-col) / "*" ; A 'cap-col' is: ; ; Any property name ('cap-prop') found in the component ; named in the 'comp-name' used in the "FROM" clause. ; ; SELECT ORGANIZER FROM VEVENT ... ; ; OR ; ; A component name ('comp-name') of an existing component ; contained inside of the 'comp-name' used in the "FROM" ; clause. ; ; SELECT VALARM FROM VEVENT ... ; ; OR ; ; A component name ('comp-name') of an existing ; component contained inside of the 'comp-name' used ; in the "FROM" clause folowed by a property ; name ('cap-prop') to be selected from that component. ; (comp-name "." cap-prop) ; ; SELECT VALARM.TRIGGER FROM VEVENT ... cap-col = comp-name / comp-name "." cap-prop comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" / x-comp / iana-comp cap-prop = ; A property that may be in the 'cap-comp' named ; in the "SELECT" clause. cap-expr = "(" cap-expr ")" / cap-term cap-term = cap-expr SP cap-logical SP cap-expr / cap-factor cap-logical= "AND" / "OR" cap-factor = cap-colval SP cap-oper SP col-value / cap-colval SP "NOT LIKE" SP col-value / cap-colval SP "LIKE" SP col-value / cap-colval SP "IS NULL" / cap-colval SP "IS NOT NULL" / col-value SP "NOT IN" cap-colval" / col-value SP "IN" cap-colval" / "STATE()" "=" ( "BOOKED" / "UNPROCESSED" / "DELETED" ) cap-colval = cap-col / param param = "PARAM(" cap-col "," cap-param ")" cap-param = ; Any parameter that may be contained in the cap-col ; in the supplied PARAM() function col-value = col-literal / "SELF()" / "CAL-OWNERS()" / "CAL-OWNERS(" cal-address ")" / "CURRENT-TARGET()" cal-address = ; A CALID as define by CAP col-literal = "'" literal-data "'" literal-data = ; Any data that matches the value type of the ; column that is being compared. That is you can ; not compare PRIORITY to "some string" because ; PRIORITY has a value type of integer. If it is ; not preceded by the LIKE element, any '%' and '_' ; characters in the literal data are not treated as ; wildcard characters and do not have to be backslash ; escaped. ; ; OR ; ; If the literal-data is preceded by the LIKE ; element it may also contain the '%' and '_' ; wildcard characters. And if the literal data ; that is comparing contains any '%' or '_' ; characters, they MUST BE backslash escaped as ; described in the notes below in order for them not ; to be treated as wildcard characters. cap-oper = "=" / "!=" / "<" / ">" / "<=" / ">=" SP = ; A single white space ascii character ; (value in HEX %x20). x-comp = ; As defined in RFC 2445 section 4.6 iana-comp = ; As defined in RFC 2445 section 4.6 -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070500080908010601070503 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwMjE4MzQ1MVowIwYJKoZIhvcNAQkEMRYEFAmn8FtF QCyy9MbVHWijIxBZjHXSMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCDCN2TSudcV0joyFtd rUwY6ERg8SaYzPyl6XJ2kIF1CyEqgPb1U3BI8O5FFzNQYl6xO945AzmEor9SbHyppGda/3bp oxOcOryrVnhfL8iXN8ZkN1i9rvISTVfd6xp/GS+kFF+DRYOqsbM9jP4bkbt9a/hKXiQxdzUv i9jOQbx7OcZH+5uX9RniCqBVfG65l3eN7rJMPy1pB/O4C0YL8z9aQsUZyNulBm1OYX8fOdMR ZANl/zeg7l9tzbv/aF/J7ZaqwEEXfIjksZQNy0VgcyKYqYpXM7m/JTBqnmUkQIse+r4nBHXv ApFuK6s0tRDm0Ra3HAISZPOTCTPJClnBDGVYAAAAAAAA --------------ms070500080908010601070503-- From owner-ietf-calendar@mail.imc.org Sat Nov 2 14:04:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10524 for ; Sat, 2 Nov 2002 14:04:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA2IwoB29074 for ietf-calendar-bks; Sat, 2 Nov 2002 10:58:50 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA2IwmW29070 for ; Sat, 2 Nov 2002 10:58:48 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA2IwoIR004004 for ; Sat, 2 Nov 2002 10:58:50 -0800 Message-ID: <3DC4207D.3010201@Royer.com> Date: Sat, 02 Nov 2002 11:59:09 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: B-3 on INET-Consulting.com Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070707080405040508040800" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070707080405040508040800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I placed (Dated November 2nd) http://INET-Consulting.com/cap-09-b-3.txt http://INET-Consulting.com/cap-09-b-3.html http://INET-Consulting.com/cap-09-b-3.xml http://INET-Consulting.com/cap-09-b-2-3-diffs.txt I am going to try to get the error codes done today. If I can (Sorry Bruce :-) I will post a -4 tomorrow. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070707080405040508040800 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwMjE4NTkwOVowIwYJKoZIhvcNAQkEMRYEFHqIyRJR dX4z3YlTF3+vgK+bz3cfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAs1pqaLlJdacT33P45 LVpcdyI7buDbYE+kz7G2L8rRBSILU5QM0bq/nN9Woi03WYL8gO8o6CkaArZVNZ95RmyBMLn6 xYsQyxsnYNK6n7qqawOzECxJp1xhZASIyvKWd3kSFYbXN73ercZTIPvnUt7AbGAoh1DTeieN /LElvRilzaqhYIbpxsfj/hlT/H5zJygqMm7QdZaAuaCHm4vZRPxDWvZiM7uiqvtlkuxU7pKl 1xbgFa6xDb+XG4aZg43l5HjZvGF8TwMFigbNTu47uuqFwUi3grYUXDlruSKGfQ/ajpJoRGZB 0kn/r3bRDH0tT3J6iHpRN67lt0VNFxB27hruAAAAAAAA --------------ms070707080405040508040800-- From owner-ietf-calendar@mail.imc.org Sun Nov 3 20:42:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18787 for ; Sun, 3 Nov 2002 20:42:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA41V7901979 for ietf-calendar-bks; Sun, 3 Nov 2002 17:31:07 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA41V6W01975 for ; Sun, 3 Nov 2002 17:31:06 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA41V8IR004630 for ; Sun, 3 Nov 2002 17:31:08 -0800 Message-ID: <3DC5CDF6.6030706@Royer.com> Date: Sun, 03 Nov 2002 18:31:34 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: draft-ietf-calsch-cap-09.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060507000907090203090705" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060507000907090203090705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I just submitted draft-ietf-calsch-09.txt to the IETF. http://inet-consulting.com/cap-09-submitted.txt http://inet-consulting.com/cap-09-submitted.html http://inet-consulting.com/cap-09-submitted.xml The only difference between this one and the -09-b-3 is formatting and the date. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms060507000907090203090705 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNDAxMzEzNVowIwYJKoZIhvcNAQkEMRYEFCS1ildu pAUEdi0jrfRICF28usMHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQA3GJ2FLDvP2nE6KL+4 R7RZElkMaoYE86OWWq1BIw8bdscMrX6WKD0ziSBe8ZCyTN/sVjYDCnspBq7ALWelYMHlg4Ct IAwj8JJWBjUDSQbERLCPsaqUMheeR877P5JBOrMftfLrvs7AlJUkK78N7LFEkFPrgbLkOZzE JguD/t+YCpDIMyR5tLu8uCaVfU8CKWBsEjRzDIn30SwL3YfwJJCuBd6GrZHMG492CXQsEMBp 6Y1WrNZxsRnX3LWaPyHOMK+Jke3P2L38iQDOrrKGxVCZ3zDn84p+BHJK6kNe33HQuRG/Od2Y tEdQEDNG6P3MjNWj6jnv8YfScwwS9eKFewZOAAAAAAAA --------------ms060507000907090203090705-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 11:05:22 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19655 for ; Mon, 4 Nov 2002 11:05:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4FuZq07153 for ietf-calendar-bks; Mon, 4 Nov 2002 07:56:35 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4FuWW07149 for ; Mon, 4 Nov 2002 07:56:32 -0800 (PST) In-Reply-To: <3DC05448.6060600@Royer.com> To: ietf-calendar@imc.org Subject: Re: 2.2 Relationship of RFC-2446 (ITIP) and CAP: Soft deletes? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Nov 2002 10:26:48 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002 10:56:35 AM, Serialize complete at 11/04/2002 10:56:35 AM Content-Type: multipart/alternative; boundary="=_alternative 0054D87485256C67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054D87485256C67_= Content-Type: text/plain; charset="US-ASCII" > > The marked for delete state is used to keep the object around so that > > the CUA can process duplicate requests automatically. If a duplicate > > [iTIP] object is deposited into the CS and there exists identical > > marked for delete objects, then a CUA acting on behalf of the "OWNER" > > can silently drop those duplicate entries. > > > > I cant help but thinking that we just created 'soft deletes' and are > > mandating that all CUAs/CSs implement them. > > We did not 'just create' anything - it has been on the list for a long > time (years?). And I assume when you say 'soft deletes' you are talking about > the DELETED state? I dont see any talk of the use of soft deletions in CAP in the archives. We have talked about deletion stubs (aka tombstones or tombstoning for those using FT indexes) but I dont see any discussion of the use of soft deletes. I use the generic dB term "soft deletes" to indicate that the concept that 'an entry is marked for deletion but has not yet been removed from the store' concept. The information on and about that entry is therefore still available. This makes the duplicate detection your text describes (1st line) possible. If the entrys data has actually be deleted (it will happen eventually) and only some partial subset of the full entry is available for duplicate detection and the process of actual and accurate duplicate detection is no longer possible. > The CS does not automatically do anything. The DELETED state exists > for CUAs. If you do not want to tag objects as DELETED, then don't. Hmm, now I see a slight discrepancy in nomenclature/usage. I suspect the "DELETED" state is really a "Marked for removal" status instead of an indicator that the entry has actually been removed. If this is the case then we need some way to clearly differentiate between the 2 states since some proscribed ablities are not possible in the latter case. We need to be able to detect both cases since both are going to happen. > I can not find any text in CAP about 'silent deletions'. Better go reread the citation then. The text I was referring to (from 09-b) was: the CUA can process duplicate requests automatically. If a duplicate [iTIP] object is deposited into the CS and there exists identical marked for delete objects, then a CUA acting on behalf of the "OWNER" can silently drop those duplicate entries. 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 0054D87485256C67_= Content-Type: text/html; charset="US-ASCII"
> >    The marked for delete state is used to keep the object around so that
> >   the CUA can process duplicate requests automatically.  If a duplicate
> >   [iTIP] object is deposited into the CS and there exists identical
> >   marked for delete objects, then a CUA acting on behalf of the "OWNER"
> >   can silently drop those duplicate entries.
> >
> > I cant help but thinking that we just created 'soft deletes' and are
> > mandating that all CUAs/CSs implement them.
>
> We did not 'just create' anything - it has been on the list for a long
> time (years?). And I assume when you say 'soft deletes' you are talking about
> the DELETED state?
I dont see any talk of the use of soft deletions in CAP in the archives.  We have talked about deletion stubs (aka tombstones or tombstoning for those using FT indexes) but I dont see any discussion of the use of soft deletes.

I use the generic dB term "soft deletes" to indicate that the concept that 'an entry is marked for deletion but has not yet been removed from the store' concept.  The information on and about that entry is therefore still available.  This makes the duplicate detection your text describes (1st line) possible.  If the entrys data has actually be deleted (it will happen eventually) and only some partial subset of the full entry is available for duplicate detection and the process of actual and accurate duplicate detection is no longer possible.

> The CS does not automatically do anything. The DELETED state exists
> for CUAs. If you do not want to tag objects as DELETED, then don't.
Hmm, now I see a slight discrepancy in nomenclature/usage.  I suspect the "DELETED" state is really a "Marked for removal" status instead of an indicator that the entry has actually been removed.  If this is the case then we need some way to clearly differentiate between the 2 states since some proscribed ablities are not possible in the latter case.  

We need to be able to detect both cases since both are going to happen.

> I can not find any text in CAP about 'silent deletions'.
Better go reread the citation then.  The text I was referring to (from 09-b) was:

  the CUA can process duplicate requests automatically.  If a duplicate
 [iTIP] object is deposited into the CS and there exists identical
 marked for delete objects, then a CUA acting on behalf of the "OWNER"
 can silently drop those duplicate entries.

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 0054D87485256C67_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 13:23:17 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27037 for ; Mon, 4 Nov 2002 13:23:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4IGZQ16247 for ietf-calendar-bks; Mon, 4 Nov 2002 10:16:35 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4IGXW16242 for ; Mon, 4 Nov 2002 10:16:33 -0800 (PST) In-Reply-To: <0AE5DEE0-EC20-11D6-A80F-003065A8EEFC@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Nov 2002 13:16:19 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002 01:16:36 PM, Serialize complete at 11/04/2002 01:16:36 PM Content-Type: multipart/alternative; boundary="=_alternative 00645D8485256C67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00645D8485256C67_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 10/30/2002 10:55:41 AM: > Uhm... now I'm curious... How exactly do you design forward > compatibility in a protocol if you don't assume that "if a party > doesn't specify a later revision, we must assume it only supports an > earlier, known revision"? Note that I said _the default_. (I dont see 'default' in your question but Ill insert it accordingly) Actually you do NOT allow for defaulting of some values based on another AND still mandate a '1' instance in the ABNF. That is, you do not allow, say, COMPONENTS to just default to "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,VEVENT,VALARM,VTIMEZONE" if CAP-VERSION:1.0 is and the property MUST be sent anyway. That approach is kind of mixed up. The current approach is half in one camp, half in another and doesn't serve either well. If we intend CAP-VERSION to be used to detect defaults then it SHOULD be acceptable to allow the default to be used in both directions. That is, a CS should be able to send just CAP-VERSION:1.0 if it implements all the defaults defined by CAP 1.0. The CS should only send a non-default value if it does not support the defaults. For example, no RRULE support would be indicated by sending "RECUR-ACCEPTED:FALSE" but if the CS supports RRULEs then NO RECUR-ACCEPTED need be sent. Put another way: If 'defaults' have to be expressly sent then what good are they?? Two options come to mind. Using CAP-VERSION and default values one sidedly is poor design because its both verbose and superfluous as well as an accident waiting to happen. I see 2 possible choices to correct this: Alternative #1: We should either use CAP-VERSION to _always_ imply defaults and only send non-default indicators. For cases where CAP-VERSIONs are unknown (ie: a CAP 1.0 CUA talking to a CAP 2.0 CS) then there needs to be some way to request the full list (defaults included!) from either side. This should only be necessary for the case of the 'older' side since 'newer' implementations should have no problem keeping track of the 'older' settings since they've already been published so are pre-existing and can easily be stored in some internal table. Alternative #2: We do not rely on CAP-VERISON to do setting defaulting/detection; it is merely informational or used to detect if both sides are able to properly communicate. It is used strictly for protocol compatability checking (ie: CAP-VERSION:2.0;2.0 would tell a CAP-VERSION:1.0 CUA that it cannot safely speak CAP to this CS). In addition, _all_ values returned, including 'default' values which kind of makes them non-default but... This is much like the current role the CS has in the 09-b draft. After all, the way CAP-VERSION is described its the "Version of CAP" and has no direct relation to the other values returned (or defaulted) in the response. Those are CS specific settings/limits and NOT necessarily particular to the "version of CAP" that the CS _speaks_. I think that #2 is the better path to take since it keeps CAP-VERSION for how it is described and it prevents any possible version confusion later on. Im open to other alternatives though... > Coincidentally, that's how HTTP works - if a client doesn't specify an > HTTP version, the server assumes it can only do 1.0 (well, apart from > kludges). I hate kludges. They are the bane of of our collective existance as once out there they become a kind of lore and standard by which we have to deal with when trying to properly correct something. Also, each side has to guess at what the other can or cannot do by providing 'at will' headers in an attempt to get some course of action to happen or not (ie: "Can the server server handle byte range requests? Let me blindly try and see what they send back..."). We overcome this probing by having a GET-CAPABILITY response that clearly describes what the responding side can do. We just dont do it in a clean way for going forward. 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 00645D8485256C67_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 10/30/2002 10:55:41 AM:
> Uhm... now I'm curious... How exactly do you design forward
> compatibility in a protocol if you don't assume that "if a party
> doesn't specify a later revision, we must assume it only supports an
> earlier, known revision"? Note that I said _the default_.
(I dont see 'default' in your question but Ill insert it accordingly)  Actually you do NOT allow for defaulting of some values based on another AND still mandate a '1' instance in the ABNF.  That is, you do not allow, say, COMPONENTS to just default to "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,VEVENT,VALARM,VTIMEZONE" if CAP-VERSION:1.0 is and the property MUST be sent anyway.  That approach is kind of mixed up.  The current approach is half in one camp, half in another and doesn't serve either well.

If we intend CAP-VERSION to be used to detect defaults then it SHOULD be acceptable to allow the default to be used in both directions.  That is, a CS should be able to send just CAP-VERSION:1.0 if it implements all the defaults defined by CAP 1.0.  The CS should only send a non-default value if it does not support the defaults.  For example, no RRULE support would be indicated by sending "RECUR-ACCEPTED:FALSE" but if the CS supports RRULEs then NO RECUR-ACCEPTED need be sent.  Put another way: If 'defaults' have to be expressly sent then what good are they??

Two options come to mind.  Using CAP-VERSION and default values one sidedly is poor design because its both verbose and superfluous as well as an accident waiting to happen.   I see 2 possible choices to correct this:

Alternative #1: We should either use CAP-VERSION to _always_ imply defaults and only send non-default indicators.  For cases where CAP-VERSIONs are unknown (ie: a CAP 1.0 CUA talking to a CAP 2.0 CS) then there needs to be some way to request the full list (defaults included!) from either side.  This should only be necessary for the case of the 'older' side since 'newer' implementations should have no problem keeping track of the 'older' settings since they've already been published so are pre-existing and can easily be stored in some internal table.

Alternative #2: We do not rely on CAP-VERISON to do setting defaulting/detection; it is merely informational or used to detect if both sides are able to properly communicate.  It is used strictly for protocol compatability checking (ie: CAP-VERSION:2.0;2.0 would tell a CAP-VERSION:1.0 CUA that it cannot safely speak CAP to this CS).  In addition, _all_ values returned, including 'default' values which kind of makes them non-default but...  This is much like the current role the CS has in the 09-b draft.  After all, the way CAP-VERSION is described its the "Version of CAP" and has no direct relation to the other values returned (or defaulted) in the response.  Those are CS specific settings/limits and NOT necessarily particular to the "version of CAP" that the CS _speaks_.

I think that #2 is the better path to take since it keeps CAP-VERSION for how it is described and it prevents any possible version confusion later on.  Im open to other alternatives though...

> Coincidentally, that's how HTTP works - if a client doesn't specify an
> HTTP version, the server assumes it can only do 1.0 (well, apart from
> kludges).
I hate kludges.  They are the bane of of our collective existance as once out there they become a kind of lore and standard by which we have to deal with when trying to properly correct something.

Also, each side has to guess at what the other can or cannot do by providing 'at will' headers in an attempt to get some course of action to happen or not (ie: "Can the server server handle byte range requests?  Let me blindly try and see what they send back...").  We overcome this probing by having a GET-CAPABILITY response that clearly describes what the responding side can do.  We just dont do it in a clean way for going forward.

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 00645D8485256C67_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 13:36:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27854 for ; Mon, 4 Nov 2002 13:36:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4IS0E17628 for ietf-calendar-bks; Mon, 4 Nov 2002 10:28:00 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4IS0W17624 for ; Mon, 4 Nov 2002 10:28:00 -0800 (PST) In-Reply-To: <0AE5DEE0-EC20-11D6-A80F-003065A8EEFC@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Nov 2002 13:27:53 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002 01:28:02 PM, Serialize complete at 11/04/2002 01:28:02 PM Content-Type: multipart/alternative; boundary="=_alternative 00656CC385256C67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00656CC385256C67_= Content-Type: text/plain; charset="US-ASCII" [Tried to send this before but it seems to evaporate and not get sent. Pardon me if its a duplicate. -BK] Andrea replied on 10/30/2002 10:55:41 AM: > Uhm... now I'm curious... How exactly do you design forward > compatibility in a protocol if you don't assume that "if a party > doesn't specify a later revision, we must assume it only supports an > earlier, known revision"? Note that I said _the default_. (I dont see 'default' in your question but Ill insert it accordingly) Actually to solve this you do NOT allow for defaulting of some values based on another AND still mandate a '1' instance in the ABNF. That is you do not allow, say, COMPONENTS to just default to "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,VEVENT,VALARM,VTIMEZONE" if CAP-VERSION:1.0 is and the property MUST be sent anyway. That approach is kind of mixed up. The current approach is half in one camp, half in another and doesnt serve either well. If we intend CAP-VERSION to be used to detect defaults then it SHOULD be acceptable to allow the default to be used in both directions. That is, a CS should be able to send just CAP-VERSION:1.0 if it implements all the defaults defined by CAP 1.0. The CS should only send a non-default value if it does not support the defaults. For example, no RRULE support would be indicated by sending "RECUR-ACCEPTED:FALSE" but if the CS supports RRULEs then NO RECUR-ACCEPTED need be sent. Put another way: If 'defaults' have to be expressly sent then what good are they?? Two options come to mind. Using CAP-VERSION and default values one sidedly is poor design because its both verbose and superfluous as well as an accident waiting to happen. I see 2 possible choices to correct this: Alternative #1: We should either use CAP-VERSION to _always_ imply defaults and only send non-default indicators. For cases where CAP-VERSIONs are unknown (ie: a CAP 1.0 CUA and a CAP 2.0 CS) then there needs to be some way to request the full list (defaults included!) from either side. This should only be necessary for the case of the 'older' side since 'newer' implementations should have no problem keeping track of the 'older' settings since they've already been published so are pre-existing and can easily be stored in some internal table. Alternative #2: We do not rely on CAP-VERISON to do setting defaulting/detection; it is merely informational or used to detect if both sides are able to properly communicate. Its used strictly for protocol compatability checking (ie: CAP-VERSION:2.0;2.0 would tell a CAP-VERSION:1.0 CUA that it cannot safely speak CAP to this CS). All values that can be returned are returned, including default values. This is much like the current role the CS has in the 09-b draft. After all, CAP-VERSION is described as "Version of CAP" but we are using it as a settings default controler instead of as the means by which two different versions of a protocol can detect if they are compatible or not. Im kind of partial to Alternative #2 but there may be other alternatives I have not considered. Im open to other suggestions... > Coincidentally, that's how HTTP works - if a client doesn't specify an > HTTP version, the server assumes it can only do 1.0 (well, apart from > kludges). I hate kludges especially in a protocol. They become the bane of our collective existance and something that hinder rather than help when a proper solution is sought. In HTTP there is no convenient way for one side to accurately tell what abilities the other has w/o doing some 'blind probing" (ie: "Can the server return byte ranges for this URL? Ill ask for it but I may or may not get back just what I want..."). This is why we have explicit properties to be returned on the GET-CAPABILITY command, even with 'default' values; no need to guess or infer. 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 00656CC385256C67_= Content-Type: text/html; charset="US-ASCII"
[Tried to send this before but it seems to evaporate and not get sent. Pardon me if its a duplicate. -BK]

Andrea replied on 10/30/2002 10:55:41 AM:
> Uhm... now I'm curious... How exactly do you design forward
> compatibility in a protocol if you don't assume that "if a party
> doesn't specify a later revision, we must assume it only supports an
> earlier, known revision"? Note that I said _the default_.
(I dont see 'default' in your question but Ill insert it accordingly)  Actually to solve this you do NOT allow for defaulting of some values based on another AND still mandate a '1' instance in the ABNF.  That is you do not allow, say, COMPONENTS to just default to "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,VEVENT,VALARM,VTIMEZONE" if CAP-VERSION:1.0 is and the property MUST be sent anyway.  That approach is kind of mixed up.  The current approach is half in one camp, half in another and doesnt serve either well.

If we intend CAP-VERSION to be used to detect defaults then it SHOULD be acceptable to allow the default to be used in both directions.  That is, a CS should be able to send just CAP-VERSION:1.0 if it implements all the defaults defined by CAP 1.0.  The CS should only send a non-default value if it does not support the defaults.  For example, no RRULE support would be indicated by sending "RECUR-ACCEPTED:FALSE" but if the CS supports RRULEs then NO RECUR-ACCEPTED need be sent.  Put another way: If 'defaults' have to be expressly sent then what good are they??

Two options come to mind.  Using CAP-VERSION and default values one sidedly is poor design because its both verbose and superfluous as well as an accident waiting to happen.   I see 2 possible choices to correct this:

Alternative #1: We should either use CAP-VERSION to _always_ imply defaults and only send non-default indicators.  For cases where CAP-VERSIONs are unknown (ie: a CAP 1.0 CUA and a CAP 2.0 CS) then there needs to be some way to request the full list (defaults included!) from either side.  This should only be necessary for the case of the 'older' side since 'newer' implementations should have no problem keeping track of the 'older' settings since they've already been published so are pre-existing and can easily be stored in some internal table.

Alternative #2: We do not rely on CAP-VERISON to do setting defaulting/detection; it is merely informational or used to detect if both sides are able to properly communicate.  Its used strictly for protocol compatability checking (ie: CAP-VERSION:2.0;2.0 would tell a CAP-VERSION:1.0 CUA that it cannot safely speak CAP to this CS).  All values that can be returned are returned, including default values.  This is much like the current role the CS has in the 09-b draft.  After all, CAP-VERSION is described as "Version of CAP" but we are using it as a settings default controler instead of as the means by which two different versions of a protocol can detect if they are compatible or not.

Im kind of partial to Alternative #2 but there may be other alternatives I have not considered.  Im open to other suggestions...

> Coincidentally, that's how HTTP works - if a client doesn't specify an
> HTTP version, the server assumes it can only do 1.0 (well, apart from
> kludges).
I hate kludges especially in a protocol.  They become the bane of our collective existance and something that hinder rather than help when a proper solution is sought.  

In HTTP there is no convenient way for one side to accurately tell what abilities the other has w/o doing some 'blind probing" (ie: "Can the server return byte ranges for this URL?  Ill ask for it but I may or may not get back just what I want...").  This is why we have explicit properties to be returned on the GET-CAPABILITY command, even with 'default' values; no need to guess or infer.

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 00656CC385256C67_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 13:54:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28997 for ; Mon, 4 Nov 2002 13:54:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4IjXF18000 for ietf-calendar-bks; Mon, 4 Nov 2002 10:45:33 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4IjWW17996 for ; Mon, 4 Nov 2002 10:45:32 -0800 (PST) In-Reply-To: <3DC00C26.7080606@Royer.com> To: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Nov 2002 13:45:27 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002 01:45:35 PM, Serialize complete at 11/04/2002 01:45:35 PM Content-Type: multipart/alternative; boundary="=_alternative 0067084585256C67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067084585256C67_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/30/2002 11:43:18 AM: > (1) ATT-COUNT does not exist in iMIP, so you iTIP client would > have never added it. ATTCOUNTER should be added to iCalendar/iTIP/iMIP w/o CAP as its also needed in those places even w/o CAP. It was supposed to be proposed & added back in 2000 but the ball got dropped... > So given what ALL current iMIP implementaions would send > something like: Not all. Check out the COUNTERs I sent during CC3. > From: SomeAA@notesdev.ibm.com > To: Doug@Royer.com > Subject: Counter proposal for that conf. call > Content-Type: text/calendar; method=counter > > ... > METHOD:COUNTER > ... > ORGANIZER:mailto:Doug@Royer.com > ATTENDEE;SENT-BY="SomeAA@ibm.com" > ;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com > ATTENDEE;SENT-BY="SomeAA@ibm.com" > ;CN="Other Guy/NotesDev/IBM":mailto:Other_Guy@notesdev.ibm.com > ATTENDEE:mailto:SomeAA@notesdev.ibm.com > > The CUA would add the ATT-COUNTER property to the object by > using the 'e-mail From address' and set it to: Not if its going to be in iTIP/iMIP. The value for ATTCOUNTER property should be the same as that for ATTENDEE, a CAL-ADDRESS. In the iTIP/iMIP case it would be a mailto URI but in CAP it could/would be some other form of address. Also, your SENT-BY values are not iTIP valid, they need to be MAILTO URIs as well. SENT-BY is also a CAL-ADDRESS valued property parameter. See Section 4.2.18 Sent By of 2445. Third, there is NO SENT-BY added to the "Other Guy/NotesDev/IBM" address since the AA is responding on MY behalf, not his. They _may_ be the AA for both of us but they are _responding_ on my behalf w/this message, not BOTH of us. > What would the LANG, CN, and SENT-BY be set to in the ATT-COUNTER > property? The same role they play on ATTENDEE. In the case where I send the COUNTER it would be my CN="Bruce Kahn/NotesDev/IBM" value that I share w/my ATTENDEE property. As for LANG, I refer you to 2445, Section 4.8.4.1 Attendee: If the LANGUAGE property parameter is specified, the identified language applies to the CN parameter. (top of page 103). If I were Swedish or had some accented characters in my CN I certainly would want them to render properly... As for SENT-BY on the COUNTER, its ONLY there if my AA did the COUNTER for me and it would have their cal-address in it as I previously showed. Remember that on the COUNTER the Organzier should be using the ATTCOUNTER info to determine counter proposed, NOT use the ATTENDEE properties since its possible that the COUNTER also removed the CU that sent it ("Invite Tom Ransdell to this meeting instead of me.") Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0067084585256C67_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/30/2002 11:43:18 AM:
> (1) ATT-COUNT does not exist in iMIP, so you iTIP client would
>      have never added it.
ATTCOUNTER should be added to iCalendar/iTIP/iMIP w/o CAP as its also needed in those places even w/o CAP.   It was supposed to be proposed & added back in 2000 but the ball got dropped...

>      So given what ALL current iMIP implementaions would send
>      something like:
Not all.  Check out the COUNTERs I sent during CC3.

>       From: SomeAA@notesdev.ibm.com
>       To: Doug@Royer.com
>       Subject: Counter proposal for that conf. call
>       Content-Type: text/calendar; method=counter
>
>       ...
>       METHOD:COUNTER
>       ...
>       ORGANIZER:mailto:Doug@Royer.com
>       ATTENDEE;SENT-BY="SomeAA@ibm.com"
>        ;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com
>       ATTENDEE;SENT-BY="SomeAA@ibm.com"
>        ;CN="Other Guy/NotesDev/IBM":mailto:Other_Guy@notesdev.ibm.com
>       ATTENDEE:mailto:SomeAA@notesdev.ibm.com
>
>      The CUA would add the ATT-COUNTER property to the object by
>      using the 'e-mail From address' and set it to:
Not if its going to be in iTIP/iMIP.  The value for ATTCOUNTER property should be the same as that for ATTENDEE, a CAL-ADDRESS.  In the iTIP/iMIP case it would be a mailto URI but in CAP it could/would be some other form of address.

Also, your SENT-BY values are not iTIP valid, they need to be MAILTO URIs as well.  SENT-BY is also a CAL-ADDRESS valued property parameter.  See Section 4.2.18 Sent By of 2445.

Third, there is NO SENT-BY added to the "Other Guy/NotesDev/IBM" address since the AA is responding on MY behalf, not his.  They _may_ be the AA for both of us but they are _responding_ on my behalf w/this message, not BOTH of us.

>      What would the LANG, CN, and SENT-BY be set to in the ATT-COUNTER
>      property?
The same role they play on ATTENDEE.  In the case where I send the COUNTER it would be my CN="Bruce Kahn/NotesDev/IBM" value that I share w/my ATTENDEE property.  As for LANG, I refer you to 2445, Section 4.8.4.1 Attendee:

                                                If the LANGUAGE property
  parameter is specified, the identified language applies to the CN
  parameter.

(top of page 103).  If I were Swedish or had some accented characters in my CN I certainly would want them to render properly...

As for SENT-BY on the COUNTER, its ONLY there if my AA did the COUNTER for me and it would have their cal-address in it as I previously showed.  

Remember that on the COUNTER the Organzier should be using the ATTCOUNTER info to determine counter proposed, NOT use the ATTENDEE properties since its possible that the COUNTER also removed the CU that sent it ("Invite Tom Ransdell to this meeting instead of me.")

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

--=_alternative 0067084585256C67_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 14:01:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29344 for ; Mon, 4 Nov 2002 14:01:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4ItP118252 for ietf-calendar-bks; Mon, 4 Nov 2002 10:55:25 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4ItNW18248 for ; Mon, 4 Nov 2002 10:55:23 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA4ItOIR012181 for ; Mon, 4 Nov 2002 10:55:24 -0800 Message-ID: <3DC6C2BB.3000309@Royer.com> Date: Mon, 04 Nov 2002 11:55:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010301090006080403000101" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010301090006080403000101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > If we intend CAP-VERSION to be used to detect defaults then it SHOULD be > acceptable to allow the default to be used in both directions. That is, > a CS should be able to send just CAP-VERSION:1.0 if it implements all > the defaults defined by CAP 1.0. The CS should only send a non-default > value if it does not support the defaults. For example, no RRULE > support would be indicated by sending "RECUR-ACCEPTED:FALSE" but if the > CS supports RRULEs then NO RECUR-ACCEPTED need be sent. Put another > way: If 'defaults' have to be expressly sent then what good are they?? FYI - the current model does NOT do that. The current model says that if the CUA does not send a GET-CAPABILITY reply - then it the protocol IS CAP-1.0 and the CS must use the defaults as defined in the spec. There is no point at which they are mixed. > Two options come to mind. Using CAP-VERSION and default values one > sidedly is poor design because its both verbose and superfluous as well > as an accident waiting to happen. I see 2 possible choices to correct > this: > > Alternative #1: ... > > Alternative #2: ... Again CAP-VERSION does not 'SET THE DEFAULTS'. So your premise to both options lead me to think that they do not apply. If the CUA sends a GET-CAPABILTY reply, then use those settings. If the CUA does not send a GET-CAPABILITY reply, the protocol is CAP-1.0 and the CS MUST use the CAP-1.0 defaults. > I think that #2 is the better path to take since it keeps CAP-VERSION > for how it is described and it prevents any possible version confusion > later on. Im open to other alternatives though... > > > Coincidentally, that's how HTTP works - if a client doesn't specify an > > HTTP version, the server assumes it can only do 1.0 (well, apart from > > kludges). > > I hate kludges. They are the bane of of our collective existance as > once out there they become a kind of lore and standard by which we have > to deal with when trying to properly correct something. > > Also, each side has to guess at what the other can or cannot do by > providing 'at will' headers in an attempt to get some course of action > to happen or not (ie: "Can the server server handle byte range requests? > Let me blindly try and see what they send back..."). We overcome this > probing by having a GET-CAPABILITY response that clearly describes what > the responding side can do. We just dont do it in a clean way for going > forward. No 'guessing' required - it's CAP 1.0 unless specifically specified. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms010301090006080403000101 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNDE4NTU1NVowIwYJKoZIhvcNAQkEMRYEFLTusBk0 NFum8IqneVWrv347BPvdMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBs5lwQB0zqZgaJz3Oa 2n1/6RbL+yQ8/KOpynAEFqWAScdZp8XGwKP0BCbfpqKS4CxF6Itjz3Xga4E5pGjah9fSKAR3 0Ol8Gc89JQtxx2TZpDqLMlz+FyneRlCI0omxTrbDr5m+bON8fZUjqRQOs6wCtKqI/E7MGG8r 5O8JPxhKQt4QSkEANvsiTe48igYa3Wb29O/L7L1aBLbJJ2gXWZkgw2+pmNojD4htIkhnVg4h I0BmC1ixPkX4huR7OUuH28uNGsxcm/Lc+m/IgD4NKbWGGEyXzNxqLjZiozA1cMjR545+rFgx 9o5IILXR4uCM51CCwuQC++aMpq+zRlC/B5ilAAAAAAAA --------------ms010301090006080403000101-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 14:04:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29533 for ; Mon, 4 Nov 2002 14:04:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4Iwmx18458 for ietf-calendar-bks; Mon, 4 Nov 2002 10:58:48 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4IwmW18453 for ; Mon, 4 Nov 2002 10:58:48 -0800 (PST) In-Reply-To: <3DC00D86.8000000@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Nov 2002 13:58:39 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002 01:58:50 PM, Serialize complete at 11/04/2002 01:58:50 PM Content-Type: multipart/alternative; boundary="=_alternative 00683DC985256C67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00683DC985256C67_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/30/2002 11:49:10 AM: > > Question 1: > > If CAP-VERSION can have a range (ie: CAP-VERSION:1.0;2.0) then what are > > the default values to be used by the CS when it supports multiple > > versions of CAP? The 1.0? 2.0? Some mix (assuming they are not > > mutually exclusive)? > > The default value as specified in the draft is "1.0". If an > implementation supported several version, then it would not > be the default, it would be 1.0;2.0 Poorly phrased on my part. The defaults for the other properties returned (ie: CAR-LEVEL, COMPONENTS, etc) are all for CAP 1.0 so what would a CS getting a CAP-VERSION:1.0;2.0 response back from a CUA be able to deduce about the non-returned 'default' values?? Would they be the 1.0 default values? Some unknown 2.0 values? Some mix? Deduction by overloading the CAP-VERSION is NOT good or sufficient in this case. This is why ALL properties MUST be returned by both sides, even 'default' values. They no longer are 'default' values since they are expressly specified though... A new designation would be in order or we just omit it and say that all properties must have a value and 'value of XYZ means its not supported'. "Down with defaults!"... > > Question 2: > > Just what should a CUA or CS do when they detect a CAP-VERSION value > > that is above/below what they can deal with? For example, my CUA is > > CAP-VERSION:1.0 and my CS is CAP-VERSION:2.0;2.0 then what should happen > > when they try to work together? We never expressly codify what should > > happen in this case. > > It says '[It] must include at lest "1.0"..." > > So do you think it is valid to send only "2.0;2.0"? Its perfectly valid for a CAP 2.0 CS to send back that if it only speaks CAP 2.0 and does not want to deal with any CAP 1.0 issues. Thats exactly why we have minver and maxver. Still, this answer is less important the #1 above... If we no longer have defaulting of values then this becomes almost moot... > > Question 3: > > (Assumption: We finally realize that blind assumption about default > > values for unknown clients is bad and correct this in the draft so that > > both sides MUST support GET-CAPABILITY) > > What good are defaults if both sides are mandated to send back a > > response to GET-CAPABLITY? > > Your logic is failing :-) There has been no such agreement. Thats why I made the clear statement of assumption. We can come back to this once we get to that point... :^) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00683DC985256C67_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/30/2002 11:49:10 AM:
> > Question 1:
> > If CAP-VERSION can have a range (ie: CAP-VERSION:1.0;2.0) then what are
> > the default values to be used by the CS when it supports multiple
> > versions of CAP?  The 1.0?  2.0?  Some mix (assuming they are not
> > mutually exclusive)?
>
>   The default value as specified in the draft is "1.0". If an
>   implementation supported several version, then it would not
>   be the default, it would be 1.0;2.0
Poorly phrased on my part.  The defaults for the other properties returned (ie: CAR-LEVEL, COMPONENTS, etc) are all for CAP 1.0 so what would a CS getting a CAP-VERSION:1.0;2.0 response back from a CUA be able to deduce about the non-returned 'default' values??  Would they be the 1.0 default values?  Some unknown 2.0 values?  Some mix?

Deduction by overloading the CAP-VERSION is NOT good or sufficient in this case.  This is why ALL properties MUST be returned by both sides, even 'default' values.  They no longer are 'default' values since they are expressly specified though...  A new designation would be in order or we just omit it and say that all properties must have a value and 'value of XYZ means its not supported'.  "Down with defaults!"...

> > Question 2:
> > Just what should a CUA or CS do when they detect a CAP-VERSION value
> > that is above/below what they can deal with?  For example, my CUA is
> > CAP-VERSION:1.0 and my CS is CAP-VERSION:2.0;2.0 then what should happen
> > when they try to work together?  We never expressly codify what should
> > happen in this case.
>
>   It says '[It] must include at lest "1.0"..."
>
>   So do you think it is valid to send only "2.0;2.0"?
Its perfectly valid for a CAP 2.0 CS to send back that if it only speaks CAP 2.0 and does not want to deal with any CAP 1.0 issues.  Thats exactly why we have minver and maxver.

Still, this answer is less important the #1 above...  If we no longer have defaulting of values then this becomes almost moot...

> > Question 3:
> > (Assumption: We finally realize that blind assumption about default
> > values for unknown clients is bad and correct this in the draft so that
> > both sides MUST support GET-CAPABILITY)
> > What good are defaults if both sides are mandated to send back a
> > response to GET-CAPABLITY?
>
>    Your logic is failing :-) There has been no such agreement.
Thats why I made the clear statement of assumption.  We can come back to this once we get to that point... :^)

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

--=_alternative 00683DC985256C67_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 14:26:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00993 for ; Mon, 4 Nov 2002 14:26:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4JKHd20501 for ietf-calendar-bks; Mon, 4 Nov 2002 11:20:17 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4JKGW20493 for ; Mon, 4 Nov 2002 11:20:16 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA4JKHIR012419 for ; Mon, 4 Nov 2002 11:20:17 -0800 Message-ID: <3DC6C890.7010906@Royer.com> Date: Mon, 04 Nov 2002 12:20:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020406040005000505030909" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020406040005000505030909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 10/30/2002 11:43:18 AM: > > (1) ATT-COUNT does not exist in iMIP, so you iTIP client would > > have never added it. > > ATTCOUNTER should be added to iCalendar/iTIP/iMIP w/o CAP as its also > needed in those places even w/o CAP. It was supposed to be proposed & > added back in 2000 but the ball got dropped... > > > So given what ALL current iMIP implementaions would send > > something like: > > Not all. Check out the COUNTERs I sent during CC3. So you added an X-property? > > > Not if its going to be in iTIP/iMIP. No where in CAP does it say that - I did not say that. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms020406040005000505030909 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNDE5MjA0OFowIwYJKoZIhvcNAQkEMRYEFFZNGeo3 XpBKSzdQ+w7BEwQLvcEkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCJO9dlfPC45hm3PoPC 1poNPosFma3/ZBpLbupr+gOxNIiaX9VOqxk+EmRcLLr3RWEtn4kUL8r9Df1HumJ6kERNnUzg HJanwqwEjU42u3vurtBaeGJAiolwNbeLTCCva9ge26yX+bq989nz1yREV1onVFd5/5Lgo5Bl FTw+LTuiRL1LZnMITjlYTlN/mFPrRHslcmdhT9gjJPsVAClvgqXJB+ANGU9KQA3lwl6AYKty iIi3TI6Asnx6bF527iZx9igi/zBmMcOraYmVxLlPtVn9ajE8TrOqYPwPi3S3rddl3o94HFfD hsXVNN425V/OcymqgMe9FELhj7Arh3BVdEsGAAAAAAAA --------------ms020406040005000505030909-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 15:37:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05288 for ; Mon, 4 Nov 2002 15:37:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4KUN523825 for ietf-calendar-bks; Mon, 4 Nov 2002 12:30:23 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4KUMW23819 for ; Mon, 4 Nov 2002 12:30:22 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA4KUNIR013062 for ; Mon, 4 Nov 2002 12:30:24 -0800 Message-ID: <3DC6D8FE.9020907@Royer.com> Date: Mon, 04 Nov 2002 13:30:54 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010503030609060509030305" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010503030609060509030305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 10/30/2002 11:49:10 AM: > > > Question 1: > > > If CAP-VERSION can have a range (ie: CAP-VERSION:1.0;2.0) then what > are > > > the default values to be used by the CS when it supports multiple > > > versions of CAP? The 1.0? 2.0? Some mix (assuming they are not > > > mutually exclusive)? > > > > The default value as specified in the draft is "1.0". If an > > implementation supported several version, then it would not > > be the default, it would be 1.0;2.0 > > Poorly phrased on my part. The defaults for the other properties > returned (ie: CAR-LEVEL, COMPONENTS, etc) are all for CAP 1.0 so what > would a CS getting a CAP-VERSION:1.0;2.0 response back from a CUA be > able to deduce about the non-returned 'default' values?? Would they be > the 1.0 default values? Some unknown 2.0 values? Some mix? Again poorly phrased - If the CUA were to return the values, then the default are not used - as the values returned would be used. The defaults are used when the CUA does not respond to a GET-CAPABILITY reply. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms010503030609060509030305 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNDIwMzA1NFowIwYJKoZIhvcNAQkEMRYEFIEHjq1S YqHJjKL7pgU3021Bxu1AMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBUWE4xnneSeq5ldmiJ HFR+XFdauEaYJPp7GRPxVcNv2Lu7IxdUG88FoiY3fohM8JP+0T4b2C6w5iEaxUYm8TGXmeAC e+lmS1XZH2P+AxzGsylG6eDTjTE/+08L9UWA6Dr5v5KTuspreu5ZtTuc1Eho1DUBPPUidSU5 0TRobkP3gX1zkkf5Oi1LXUaK36rQUXAnTbWxNMckUm8drei9s45aPm1eQbFp2ZAzNdyMu/5B w8vpwFILg6EgD2zEgdG7Yss2jMVXnaaL2ivNP6v9LQPY+Y4CyPoS5KJVUY3QSuNe6zJcQEeb KhZMbVzyVJaNAzX+s+YMvqVONscraPwbcmhPAAAAAAAA --------------ms010503030609060509030305-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 16:16:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07240 for ; Mon, 4 Nov 2002 16:16:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LAiN25664 for ietf-calendar-bks; Mon, 4 Nov 2002 13:10:44 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4LAeW25655 for ; Mon, 4 Nov 2002 13:10:40 -0800 (PST) In-Reply-To: <3DC03C96.6080306@Royer.com> To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Nov 2002 16:10:16 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002 04:10:47 PM, Serialize complete at 11/04/2002 04:10:47 PM Content-Type: multipart/alternative; boundary="=_alternative 00744A9B85256C67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00744A9B85256C67_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/30/2002 03:09:58 PM: > > A CUA may create a "BOOKED" state entry by depositing a iCalendar > > object into the store. This is done by depositing an object that > > does not have a "METHOD" property. > > > > However this is not 100% accurate as a CUA can deposit a VCAR into the > > CS w/o a METHOD property and by this definition the VCAR would be > > considered "BOOKED". (Same goes for a VQUERY, VTIMEZONE, etc) > > What's the problem? So I can now 'book' a VQUERY, VCAR or VTIMEZONE? Sounds illogical to me. "BOOKED" as a state is only logical when it relates to workflow oriented components like VEVENTs, VTODOs and VJOURNALs. Other components dont have associated workflow and are stateless so they shouldn't be tagged with one (implicitly or explicitly). 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 00744A9B85256C67_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/30/2002 03:09:58 PM:
> >    A CUA may create a "BOOKED" state entry by depositing a iCalendar
> >   object into the store.  This is done by depositing an object that
> >   does not have a "METHOD" property.
> >
> > However this is not 100% accurate as a CUA can deposit a VCAR into the
> > CS w/o a METHOD property and by this definition the VCAR would be
> > considered "BOOKED".  (Same goes for a VQUERY, VTIMEZONE, etc)
>
> What's the problem?
So I can now 'book' a VQUERY, VCAR or VTIMEZONE?  Sounds illogical to me.  "BOOKED" as a state is only logical when it relates to workflow oriented components like VEVENTs, VTODOs and VJOURNALs.  Other components dont have associated workflow and are stateless so they shouldn't be tagged with one (implicitly or explicitly).

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 00744A9B85256C67_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 16:28:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07726 for ; Mon, 4 Nov 2002 16:28:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LEkU26292 for ietf-calendar-bks; Mon, 4 Nov 2002 13:14:46 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4LEiW26284 for ; Mon, 4 Nov 2002 13:14:45 -0800 (PST) In-Reply-To: <3DC03D30.80205@Royer.com> To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Nov 2002 16:13:08 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002 04:14:48 PM, Serialize complete at 11/04/2002 04:14:48 PM Content-Type: multipart/alternative; boundary="=_alternative 00748D8085256C67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00748D8085256C67_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/30/2002 03:12:32 PM: > > After all you do not put deleted VCARs or VTIMEZONEs into a "DELETED" > > state do you? > > Why not? What purpose does it serve to mark a VCAR as "marked for deletion" instead of just removing it (and possibly keeping some indicator that its no more)? Does a "marked for deletion" VCAR have any effect on the system or my ability to access it? It shouldn't. So why should the CS keep it around as "marked for deletion" instead of just removing it?? Too much cruft!! 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 00748D8085256C67_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/30/2002 03:12:32 PM:
> > After all you do not put deleted VCARs or VTIMEZONEs into a "DELETED"
> > state do you?
>
> Why not?
What purpose does it serve to mark a VCAR as "marked for deletion" instead of just removing it (and possibly keeping some indicator that its no more)?   Does a "marked for deletion" VCAR have any effect on the system or my ability to access it?  It shouldn't.  So why should the CS keep it around as "marked for deletion" instead of just removing it??  

Too much cruft!!

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 00748D8085256C67_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 16:31:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07914 for ; Mon, 4 Nov 2002 16:31:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LNJw27180 for ietf-calendar-bks; Mon, 4 Nov 2002 13:23:19 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4LNGW27169 for ; Mon, 4 Nov 2002 13:23:16 -0800 (PST) In-Reply-To: <3DC03CCF.4030209@Royer.com> To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Nov 2002 16:22:16 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002 04:23:20 PM, Serialize complete at 11/04/2002 04:23:20 PM Content-Type: multipart/alternative; boundary="=_alternative 007563DE85256C67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007563DE85256C67_= Content-Type: text/plain; charset="US-ASCII" Doug answered on 10/30/2002 03:10:55 PM: > > We may want to create an explicit definition as to what a Calendar Entry > > is versus a Calendar Entity since we use the terms freely but not do not > > explicitly define them (see above). This could allow some folks to > > interpret the distinction incorrectly. To seed the distinction I would > > define entry explicitly as VEVENTs, VTODOs or VJOURNALs only and be done > > w/it. We cant just say "Any [RFC2445] defined components" because that > > would include VTIMEZONEs, VFREEBUSYs and VALARMs." > > Again - what's the problem? It is true. The problem is that you are creating a component with state for a stateless component using the definition I cited. Should stateless components like VCARs or VTIMEZONEs now be given a state like "BOOKED"? I think not. Now if you want to create some label besides "BOOKED" to associate with stateless components for query purposes I can possibly see that but I disagree with associating a state with stateless components. 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 007563DE85256C67_= Content-Type: text/html; charset="US-ASCII"
Doug answered on 10/30/2002 03:10:55 PM:
> > We may want to create an explicit definition as to what a Calendar Entry
> > is versus a Calendar Entity since we use the terms freely but not do not
> > explicitly define them (see above).  This could allow some folks to
> > interpret the distinction incorrectly.   To seed the distinction I would
> > define entry explicitly as VEVENTs, VTODOs or VJOURNALs only and be done
> > w/it.  We cant just say "Any [RFC2445] defined components" because that
> > would include VTIMEZONEs, VFREEBUSYs and VALARMs."
>
> Again - what's the problem? It is true.
The problem is that you are creating a component with state for a stateless component using the definition I cited.  Should stateless components like VCARs or VTIMEZONEs now be given a state like "BOOKED"?  I think not.

Now if you want to create some label besides "BOOKED" to associate with stateless components for query purposes I can possibly see that but I disagree with associating a state with stateless components.

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 007563DE85256C67_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 16:41:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08434 for ; Mon, 4 Nov 2002 16:41:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LYqe28085 for ietf-calendar-bks; Mon, 4 Nov 2002 13:34:52 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4LYpW28080 for ; Mon, 4 Nov 2002 13:34:51 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA4LYqIR013528 for ; Mon, 4 Nov 2002 13:34:53 -0800 Message-ID: <3DC6E81C.6020704@Royer.com> Date: Mon, 04 Nov 2002 14:35:24 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010102040602010305020205" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010102040602010305020205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 10/30/2002 03:09:58 PM: > > > A CUA may create a "BOOKED" state entry by depositing a iCalendar > > > object into the store. This is done by depositing an object that > > > does not have a "METHOD" property. > > > > > > However this is not 100% accurate as a CUA can deposit a VCAR into the > > > CS w/o a METHOD property and by this definition the VCAR would be > > > considered "BOOKED". (Same goes for a VQUERY, VTIMEZONE, etc) > > > > What's the problem? > > So I can now 'book' a VQUERY, VCAR or VTIMEZONE? Sounds illogical to > me. "BOOKED" as a state is only logical when it relates to workflow > oriented components like VEVENTs, VTODOs and VJOURNALs. Other > components dont have associated workflow and are stateless so they > shouldn't be tagged with one (implicitly or explicitly). A while back the WG list agreed that iTIP workflow (METHOD) would be separated from STATE. There is no such relationship. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms010102040602010305020205 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNDIxMzUyNFowIwYJKoZIhvcNAQkEMRYEFKntoN+a s4tmcnu5P5YS8ccIdbyWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAy4iurDbbIhaHa8I64 DszUnb/RNhMri3ZqDprHldDFmpJPOVhHKVpF94MHnAK0G51jgzsUXaGywRNMvVf2C5r7VwNL cmgGsLCw6wDR7F/o0cXrZYG5MysqMWhIIdmTyRHwUOfG6idHa/AUEba+quZydMd74Ep7v6gZ Q3j/TEy52EyDiWvHOIhM0k7zeH/6tbmGPYOfpQ5brIZu7JgHh8jGi3l5wrXsKBX31C31IFLS PH8gY4Cc+XJd7uObRe4fJQWlTi+5Qt3fMmiJbv/Sr3Ovt1qOju+LR/nfmiKFJBNDP7Xg6NhJ JIJL+/B12/NIh3gsarEHTC1R3tdeEs/gYI7uAAAAAAAA --------------ms010102040602010305020205-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 17:15:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10209 for ; Mon, 4 Nov 2002 17:15:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4MA2l29755 for ietf-calendar-bks; Mon, 4 Nov 2002 14:10:02 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4M9xW29743 for ; Mon, 4 Nov 2002 14:10:00 -0800 (PST) In-Reply-To: <3DC03E9A.3000101@Royer.com> To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Nov 2002 17:07:04 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002 05:10:04 PM, Serialize complete at 11/04/2002 05:10:04 PM Content-Type: multipart/alternative; boundary="=_alternative 00797DB885256C67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00797DB885256C67_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 10/30/2002 03:18:34 PM: > No, that won't work. Other reasons for the DELETED state are: > > Detection of duplicate iTIP messages > Your going to have to keep the entire object in > order to detect if it is a duplicate. I dont recall seeing duplicate object detection by doing full object data comparison as a CAP requirement. Since all iCalendar objects are fully self-contained all you need is the UID, [RECURRENCE-ID,] SEQUENCE and DTSTAMP to detect if you have newer data then the object you are processing or not and so you can tell if you should ignore the object or not. All other properties are extraneous to the issue of sequencing. I strongly disagree w/the contention that my CS cannot actually delete an entry because it prevents some CUA from doing duplicate detection. Since I see no way to undelete an entry marked as "DELETED" (but not actually deleted to any degree) and I see no mention of when these marked entries can actually be deleted I have a hard time swallowing the design w/o it expressly declaring that some form of soft deletion is in use. > Ignoring events for which you do not wish to attend. > If you keep getting a REQUEST for a meeting, > you can mark it as DELETED and then ignore any > updates. This is some new functional ability I never knew was in CAP. A CUA that can recall if I deleted a REQUEST on purpose and no longer want to see any REQUESTS or if I deleted a REQUEST by accident but want to stay involved or if I deleted a REQUEST on purpose but now want to get involved again. Wow, all that from a simple DELETE action. Im very impressed. And just how is this magic achieved?... > In some cases you will want to remain > on the distribution list, even if you are not > going to attend a specific instance. Again Im curious to know how the CUA achieves this magical state of enlightenment... > AND > I do not recall this WG discussing ANY options that would > allow the CS or CUA to remove anything from the marked for > deleted objects. > > The only change to the object is it state. So a deletion is just a change of state and never an actual removal? You work for a storage maker or something? All data becomes effectively READ-ONLY? I cant actually physically delete those REPLYs I just processed?? Is it just more or does this sound like Bad Joss to 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 00797DB885256C67_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 10/30/2002 03:18:34 PM:
> No, that won't work. Other reasons for the DELETED state are:
>
>    Detection of duplicate iTIP messages
>         Your going to have to keep the entire object in
>       order to detect if it is a duplicate.
I dont recall seeing duplicate object detection by doing full object data comparison as a CAP requirement.  

Since all iCalendar objects are fully self-contained all you need is the UID, [RECURRENCE-ID,] SEQUENCE and DTSTAMP to detect if you have newer data then the object you are processing or not and so you can tell if you should ignore the object or not.  All other properties are extraneous to the issue of sequencing.

I strongly disagree w/the contention that my CS cannot actually delete an entry because it prevents some CUA from doing duplicate detection.  Since I see no way to undelete an entry marked as "DELETED" (but not actually deleted to any degree) and I see no mention of when these marked entries can actually be deleted I have a hard time swallowing the design w/o it expressly declaring that some form of soft deletion is in use.

>    Ignoring events for which you do not wish to attend.
>       If you keep getting a REQUEST for a meeting,
>       you can mark it as DELETED and then ignore any
>       updates.

This is some new functional ability I never knew was in CAP.  A CUA that can recall if I deleted a REQUEST on purpose and no longer want to see any REQUESTS or if I deleted a REQUEST by accident but want to stay involved or if I deleted a REQUEST on purpose but now want to get involved again.  Wow, all that from a simple DELETE action.  Im very impressed.  And just how is this magic achieved?...

>                 In some cases you will want to remain
>       on the distribution list, even if you are not
>       going to attend a specific instance.
Again Im curious to know how the CUA achieves this magical state of enlightenment...

> AND
>    I do not recall this WG discussing ANY options that would
>    allow the CS or CUA to remove anything from the marked for
>    deleted objects.
>
>    The only change to the object is it state.
So a deletion is just a change of state and never an actual removal?  You work for a storage maker or something?  All data becomes effectively READ-ONLY?  I cant actually physically delete those REPLYs I just processed??  Is it just more or does this sound like Bad Joss to 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 00797DB885256C67_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 4 17:58:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12877 for ; Mon, 4 Nov 2002 17:58:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4MrUp02602 for ietf-calendar-bks; Mon, 4 Nov 2002 14:53:30 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4MrTJ02598 for ; Mon, 4 Nov 2002 14:53:29 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA4MrUIR014316 for ; Mon, 4 Nov 2002 14:53:31 -0800 Message-ID: <3DC6FA8A.6030504@Royer.com> Date: Mon, 04 Nov 2002 15:54:02 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090203000804070503030803" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090203000804070503030803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Since all iCalendar objects are fully self-contained all you need is the > UID, [RECURRENCE-ID,] SEQUENCE and DTSTAMP to detect if you have newer > data then the object you are processing or not and so you can tell if > you should ignore the object or not. All other properties are > extraneous to the issue of sequencing. Feel free to modify the object - there is no CAP requirement that CAP force a CS to do that :-) > I strongly disagree w/the contention that my CS cannot actually delete > an entry because it prevents some CUA from doing duplicate detection. Could you please point out in CAP where it says that? Or which e-mail I sent that said that? > Since I see no way to undelete an entry marked as "DELETED" (but not > actually deleted to any degree) and I see no mention of when these > marked entries can actually be deleted I have a hard time swallowing the > design w/o it expressly declaring that some form of soft deletion is in > use. Again - feel free not use use that feature. If I wanted to re-create it, I would just store an object that looked like it - then remove the old marked for delete one. > > In some cases you will want to remain > > on the distribution list, even if you are not > > going to attend a specific instance. > > Again Im curious to know how the CUA achieves this magical state of > enlightenment... By setting PARTSTAT == no to only that instance. > > AND > > I do not recall this WG discussing ANY options that would > > allow the CS or CUA to remove anything from the marked for > > deleted objects. > > > > The only change to the object is it state. > > So a deletion is just a change of state and never an actual removal? Nor was that said or written. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms090203000804070503030803 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNDIyNTQwMlowIwYJKoZIhvcNAQkEMRYEFCFPqwNM A+p+cQLepBNehj7KHHXjMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBrHs3MRTC8zMjk/HTM CHEr8sF1oxCsDugclTMPUvRNtnTSEV+oPYRe8mRqEqIMlYwgl0B80VOYfPPHhoA06veCRxlT c1czu9HnVKL1junLFM84Z9VGFVyl21lRy0mE3s/erFMtLNPmDeE3uPZgRrFlmpsfLwwS5OMG j/QWEvM1yAPzqVZBqouoUju8jb8VOx+z50ckOE3fNsLYAe+0VMbEkG9MQii3D8VlAlioZgM4 XmdxngAI1rrtoVY1poKiN3j/bumdSWQKWrT3RUx3iK/kDaZojmnlvKMXNS1iaNd3jaQVknO/ jt2IV+tc6GozYH0j0Q3pnTb6mTquczA2eKBkAAAAAAAA --------------ms090203000804070503030803-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 11:08:55 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26500 for ; Tue, 5 Nov 2002 11:08:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5FwWH28825 for ietf-calendar-bks; Tue, 5 Nov 2002 07:58:32 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5FwVv28820 for ; Tue, 5 Nov 2002 07:58:32 -0800 (PST) In-Reply-To: <3DC178B6.5060806@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: GET-CAPABILITY - reply MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 10:58:05 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 10:58:34 AM, Serialize complete at 11/05/2002 10:58:34 AM Content-Type: multipart/alternative; boundary="=_alternative 0057B58685256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057B58685256C68_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/31/2002 01:38:46 PM: > Thanks - I have changed the text to: > > When the CUA does not support sending a "GET-CAPABILITY" > reply, then the CS MUST assume the defaults listed below. > The following properties are returned in response to > a "GET-CAPABILITY" command: > > Better? Crossing the threads a bit here but NO its not. I think that both sides MUST support GET-CAPABILITY and that defaults are a bad thing. This is Day One design work and Ive yet to hear a good justification for NOT making boths sides support GET-CAPABILITY but Ive given several why they should. 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 0057B58685256C68_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/31/2002 01:38:46 PM:
> Thanks - I have changed the text to:
>
>    When the CUA does not support sending a "GET-CAPABILITY"
>    reply, then the CS MUST assume the defaults listed below.
>    The following properties are returned in response to
>    a "GET-CAPABILITY" command:
>
> Better?
Crossing the threads a bit here but NO its not.  I think that both sides MUST support GET-CAPABILITY and that defaults are a bad thing.  This is Day One design work and Ive yet to hear a good justification for NOT making boths sides support GET-CAPABILITY but Ive given several why they should.

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 0057B58685256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 11:30:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27650 for ; Tue, 5 Nov 2002 11:30:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5GLJK29465 for ietf-calendar-bks; Tue, 5 Nov 2002 08:21:19 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5GL9v29458 for ; Tue, 5 Nov 2002 08:21:10 -0800 (PST) In-Reply-To: <3DC17658.3080907@Royer.com> To: ietf-calendar@imc.org Subject: Re: 3.1 System Model MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 11:16:22 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 11:21:18 AM, Serialize complete at 11/05/2002 11:21:18 AM Content-Type: multipart/alternative; boundary="=_alternative 0059620D85256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059620D85256C68_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/31/2002 01:28:40 PM: > There are possible solutions: > > (1) We alter the ABNF for CAP to allow it. > (2) We create a new object that will only contain > a CMD property. > > I would go for (1) by adding the following in section "2. Additions to > iCalendar", after the 'calprops' ABNF and before the "In addition.." > paragraph: > > Also the 'component' part of the 'icalbody' ABNF as described > in [iCAL] section 4.6 is optional when the "VCALENDAR" component > is sending a command as shown in the following modified ABNF: > > icalbody = calprops component > > ; If the "VCALENDAR" component contains the "CMD" > ; component then the 'component' is optional: > ; > / calprops > That sounds ok. Lets not forget to TARGET is in the same boat as CMD. We can modify the ABNF for 2445 but for those cases where we send only calprops we need to be clear in CAP that we are sending iCalendar objects and not iTIP objects. A minor distinction but one that is relevant if iTIP failover or gatewaying is being considered in the future. One thing to note in the new ABNF is that its illogical to have a TARGET w/o a CMD. This should be noted in the ABNF, like: calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once. ; prodid /version / ; These are optional, but MUST NOT occur ; more than once. ; calscale / method / cmd / ; These are optional, and may occur more ; than once. 'target' MUST NOT occur if ; 'cmd' does not. ; target / iana-prop / x-prop ) or put another way (to make this more parser friendly): calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once. prodid /version / ; These are optional, but MUST NOT occur ; more than once. calscale / method / ; These are optional, but MUST NOT occur ; more than once. ( cmd / ( cmd / 1*target ) ) / ; These are optional, and may occur more ; than once. iana-prop / x-prop ) 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 0059620D85256C68_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/31/2002 01:28:40 PM:
> There are possible solutions:
>
>    (1) We alter the ABNF for CAP to allow it.
>    (2) We create a new object that will only contain
>        a CMD property.
>
> I would go for (1) by adding the following in section "2. Additions to
> iCalendar", after the 'calprops' ABNF and before the "In addition.."
> paragraph:
>
>    Also the 'component' part of the 'icalbody' ABNF as described
>    in [iCAL] section 4.6 is optional when the "VCALENDAR" component
>    is sending a command as shown in the following modified ABNF:
>
>     icalbody = calprops component
>
>         ; If the "VCALENDAR" component contains the "CMD"
>                    ; component then the 'component' is optional:
>                    ;
>                    / calprops
>

That sounds ok.

Lets not forget to TARGET is in the same boat as CMD.  We can modify the ABNF for 2445 but for those cases where we send only calprops we need to be clear in CAP that we are sending iCalendar objects and not iTIP objects.  A minor distinction but one that is relevant if iTIP failover or gatewaying is being considered in the future.

One thing to note in the new ABNF is that its illogical to have a TARGET w/o a CMD.  This should be noted in the ABNF, like:

        calprops   = 2*(

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

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

                  ; These are optional, and may occur more
                  ; than once.  'target' MUST NOT occur if
                   ; 'cmd' does not.
                  ;
                  target          /
                  iana-prop       /
                  x-prop
                   )
or put another way (to make this more parser friendly):

        calprops   = 2*(

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

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

                  ; These are optional, but MUST NOT occur
                  ; more than once.
                   ( cmd             /
                  ( cmd / 1*target )
                   )          /
                   ; These are optional, and may occur more
                  ; than once.
                   iana-prop       /
                  x-prop
                   )
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 0059620D85256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 11:32:12 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27724 for ; Tue, 5 Nov 2002 11:32:12 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5GM3W29490 for ietf-calendar-bks; Tue, 5 Nov 2002 08:22:03 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5GM2v29485 for ; Tue, 5 Nov 2002 08:22:02 -0800 (PST) In-Reply-To: <3DC17A43.2090202@Royer.com> To: ietf-calendar@imc.org Subject: Re: 2.2 Relationship of RFC-2446 (ITIP) and CAP: Taking no action MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 11:21:41 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 11:22:05 AM, Serialize complete at 11/05/2002 11:22:05 AM Content-Type: multipart/alternative; boundary="=_alternative 0059DED785256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059DED785256C68_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/31/2002 01:45:23 PM: > I added the sentence: > > The CUA could also ignore objects for later processing. > > to the end of the above paragraph - okay? Yes, thanks. > The entire paragraph now reads: > > The CUA could also decide not to book the object. In which case > the "UNPROCESSED" state objects could be removed from the CS or the > CUA could set those object to the marked for delete state. > The CUA could also ignore objects for later processing. I like most of this. The part that is confusing and ambiguous is "could be removed from the CS or the CUA could set those object to the marked for delete state". This says that the entry can be _actually_ deleted from the CS OR "marked for" deletion. These are 2 separate actions/concepts that seem to get blurred when I look @ the DELETE command and its use/intent. I understood the DELETE command to be used to do the former but as our recent discussions have shown, some think it the latter. We need to reach some agreement on dealing with actual deletions and just "marking for deletion" but Ill leave that for the other thread where we are going over it now. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0059DED785256C68_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/31/2002 01:45:23 PM:
> I added the sentence:
>
>    The CUA could also ignore objects for later processing.
>
> to the end of the above paragraph - okay?
Yes, thanks.

> The entire paragraph now reads:
>
>    The CUA could also decide not to book the object. In which case
>    the "UNPROCESSED" state objects could be removed from the CS or the
>    CUA could set those object to the marked for delete state.
>    The CUA could also ignore objects for later processing.
I like most of this.  

The part that is confusing and ambiguous is "could be removed from the CS or the CUA could set those object to the marked for delete state".  This says that the entry can be _actually_ deleted from the CS OR "marked for" deletion.  These are 2 separate actions/concepts that seem to get blurred when I look @ the DELETE command and its use/intent.  I understood the DELETE command to be used to do the former but as our recent discussions have shown, some think it the latter.

We need to reach some agreement on dealing with actual deletions and just "marking for deletion" but Ill leave that for the other thread where we are going over it now.

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

--=_alternative 0059DED785256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 11:44:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28201 for ; Tue, 5 Nov 2002 11:44:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5GYFJ29802 for ietf-calendar-bks; Tue, 5 Nov 2002 08:34:15 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5GYAv29797 for ; Tue, 5 Nov 2002 08:34:10 -0800 (PST) In-Reply-To: <3DC17ECE.5070007@Royer.com> To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 11:32:16 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 11:34:13 AM, Serialize complete at 11/05/2002 11:34:13 AM Content-Type: multipart/alternative; boundary="=_alternative 005AD6E085256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005AD6E085256C68_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 10/31/2002 02:04:46 PM: > > A CUA may create a "BOOKED" state entry by depositing a iCalendar > > object into the store. This is done by depositing an object that > > does not have a "METHOD" property. > > > > However this is not 100% accurate as a CUA can deposit a VCAR into the > > CS w/o a METHOD property and by this definition the VCAR would be > > considered "BOOKED". (Same goes for a VQUERY, VTIMEZONE, etc) > > Yes - they are booked. Semantic meaning of 'booked' is being overloaded. "BOOKED" has a workflow oriented semantic meaning; "I cant make 9:30AM, Im already booked then", "Sorry, all of our rooms are booked for that date.", etc. For non-workflow components (VQUERY, VCAR, etc) there is NO matching semantic meaning that can be applied; "Im sorry, your booked Access Rights are insufficient to read that entry". We can (and in fact are) overloading the semantic meaning of "BOOKED" and that is my objection. Its not a ship stopper but its still an objection I wanted raised. > > Editorial suggestion: The text: > > > > All scheduled entries are > > [iTIP] objects. > > > > should include the phrase "group" to be more accurate: > > > > All group scheduled entries are > > [iTIP] objects. > > > > since I can schedule an event on my calendar w/o using iTIP (ie: I > > create a doctors appointment w/o using iTIP). > > As I don't see the distinction, (are not all ITIP object > group scheduling objects?) How about: The distinction is that I can create entries on my calendar that affect my schedule but have NO workflow involved. I would insert a "Doctor Appt @ 10:30AM - 11:15AM" on my calendar after getting off the phone w/them. There is no associated workflow. In other words, PIM Calendaring is also part of Calendaring & Scheduling and those PIM objects are NOT iTIP objects. They have no METHOD, there is no workflow involved. Hence its not 'group scheduling'. All iTIP objects are group scheduled entries but not "All scheduled entires" are iTIP objects. > > the same kind of change goes for changing: > > > > 3. A marked for delete component is set to the "DELETE" state. > > > > to something like: > > > > 3. A "DELETED" state entry has been marked for deletion or > > actually removed from the Calendar. > > That would make it - not true. > > I used: > > A "DELETED" state entry is created by sending a "DELETE" command > with the "OPTION" parameter value set to "MARK". We will continue this actual vs marked for deletion discussion in a single thread so hold that thought... 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 005AD6E085256C68_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 10/31/2002 02:04:46 PM:
> >    A CUA may create a "BOOKED" state entry by depositing a iCalendar
> >   object into the store.  This is done by depositing an object that
> >   does not have a "METHOD" property.
> >
> > However this is not 100% accurate as a CUA can deposit a VCAR into the
> > CS w/o a METHOD property and by this definition the VCAR would be
> > considered "BOOKED".  (Same goes for a VQUERY, VTIMEZONE, etc)
>
> Yes - they are booked.
Semantic meaning of 'booked' is being overloaded.  "BOOKED" has a workflow oriented semantic meaning; "I cant make 9:30AM, Im already booked then", "Sorry, all of our rooms are booked for that date.", etc.  For non-workflow components (VQUERY, VCAR, etc) there is NO matching semantic meaning that can be applied; "Im sorry, your booked Access Rights are insufficient to read that entry".

We can (and in fact are) overloading the semantic meaning of "BOOKED" and that is my objection.  Its not a ship stopper but its still an objection I wanted raised.

> > Editorial suggestion:  The text:
> >
> >                                   All scheduled entries are
> >          [iTIP] objects.
>  >
> > should include the phrase "group" to be more accurate:
> >
> >                                   All group scheduled entries are
> >          [iTIP] objects.
>  >
> > since I can schedule an event on my calendar w/o using iTIP (ie: I
> > create a doctors appointment w/o using iTIP).
>
> As I don't see  the distinction, (are not all ITIP object
> group scheduling objects?) How about:
The distinction is that I can create entries on my calendar that affect my schedule but have NO workflow involved.  I would insert a "Doctor Appt @ 10:30AM - 11:15AM" on my calendar after getting off the phone w/them.  There is no associated workflow.  In other words, PIM Calendaring is also part of Calendaring & Scheduling and those PIM objects are NOT iTIP objects.  They have no METHOD, there is no workflow involved.  Hence its not 'group scheduling'.   All iTIP objects are group scheduled entries but not "All scheduled entires" are iTIP objects.

> > the same kind of change goes for changing:
> >
> >       3.  A marked for delete component is set to the "DELETE" state.
> >
> > to something like:
> >
> >       3.  A "DELETED" state entry has been marked for deletion or
> > actually removed from the Calendar.
>
> That would make it - not true.
>
> I used:
>
>     A "DELETED" state entry is created by sending a "DELETE" command
>     with the "OPTION" parameter value set to "MARK".
We will continue this actual vs marked for deletion discussion in a single thread so hold that thought...

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 005AD6E085256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 11:54:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28899 for ; Tue, 5 Nov 2002 11:54:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5GfwP00504 for ietf-calendar-bks; Tue, 5 Nov 2002 08:41:58 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5Gfvv00500 for ; Tue, 5 Nov 2002 08:41:58 -0800 (PST) In-Reply-To: <5119787.1036153702203.JavaMail.jworrall@willy.commnav.com> To: ietf-calendar@imc.org Cc: dking@commnav.com Subject: Re: Recurrence rule WKST clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 11:41:36 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 11:42:00 AM, Serialize complete at 11/05/2002 11:42:00 AM Content-Type: multipart/alternative; boundary="=_alternative 005BB19E85256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005BB19E85256C68_= Content-Type: text/plain; charset="US-ASCII" dking@commnav.com asked on 11/01/2002 07:28:22 AM: > Is WKST the first day of the week as defined by BYWEEKNO or the > first day of the work week as defined by WKST? The latter. From 2445, p. 44: The WKST rule part specifies the day on which the workweek starts. > BYWEEKNO on page 43 of RFC 2445 states: > "A week is defined as a seven day period, starting on the day of the > week defined to be the week start (see WKST)." > > WKST on page 44 of RFC 2445 states: > "The WKST rule part specifies the day on which the workweek starts." WKST defines what day the 7 day week begins on and that in turn helps evaluate the BYWEEKNO and other parts of the recurrence rule as decribed in the text of Section 4.3.10 Recurrence Rule. You can also check your assumptions by using some of the examples that use it like on pp 119 - 125. 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 005BB19E85256C68_= Content-Type: text/html; charset="US-ASCII"
dking@commnav.com asked on 11/01/2002 07:28:22 AM:
> Is WKST the first day of the week as defined by BYWEEKNO or the
> first day of the work week as defined by WKST?

The latter.  From 2445, p. 44:

   The WKST rule part specifies the day on which the workweek starts.

> BYWEEKNO on page 43 of RFC 2445 states:
> "A week is defined as a seven day period, starting on the day of the
> week defined to be the week start (see WKST)."
>
> WKST on page 44 of RFC 2445 states:
> "The WKST rule part specifies the day on which the workweek starts."

WKST defines what day the 7 day week begins on and that in turn helps evaluate the BYWEEKNO and other parts of the recurrence rule as decribed in the text of Section 4.3.10 Recurrence Rule.  

You can also check your assumptions by using some of the examples that use it like on pp 119 - 125.

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 005BB19E85256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 12:03:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29369 for ; Tue, 5 Nov 2002 12:03:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5Gpdv00730 for ietf-calendar-bks; Tue, 5 Nov 2002 08:51:39 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5Gpcv00726 for ; Tue, 5 Nov 2002 08:51:38 -0800 (PST) In-Reply-To: <3DC4207D.3010201@Royer.com> To: ietf-calendar@imc.org Subject: Re: B-3 on INET-Consulting.com MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 11:51:18 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 11:51:40 AM, Serialize complete at 11/05/2002 11:51:40 AM Content-Type: multipart/alternative; boundary="=_alternative 005C94E185256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C94E185256C68_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/02/2002 01:59:09 PM: > I placed (Dated November 2nd) > > http://INET-Consulting.com/cap-09-b-3.txt > http://INET-Consulting.com/cap-09-b-3.html > http://INET-Consulting.com/cap-09-b-3.xml > http://INET-Consulting.com/cap-09-b-2-3-diffs.txt > > I am going to try to get the error codes done today. > If I can (Sorry Bruce :-) I will post a -4 tomorrow. Hehe, at least this time I wont start rereading -09-b-3 if -4 is coming out ASAP (I just tried to get to -4 but its either hidden or Doug is a bit busy and didnt make an 03-Nov release date)... :^b Id like to ask 1 favor of the Energizer Editor: Can we please get these drafts at least mirrored on the www.calsch.org web site? The copies there are woefully out of date and not everyone can keep up w/the sheer volume of postings here. Thanks! 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 005C94E185256C68_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/02/2002 01:59:09 PM:
> I placed (Dated November 2nd)
>    
>    http://INET-Consulting.com/cap-09-b-3.txt
>    http://INET-Consulting.com/cap-09-b-3.html
>    http://INET-Consulting.com/cap-09-b-3.xml
>    http://INET-Consulting.com/cap-09-b-2-3-diffs.txt
>
> I am going to try to get the error codes done today.
> If I can (Sorry Bruce :-) I will post a -4 tomorrow.
Hehe, at least this time I wont start rereading -09-b-3 if -4 is coming out ASAP (I just tried to get to -4 but its either hidden or Doug is a bit busy and didnt make an 03-Nov release date)... :^b

Id like to ask 1 favor of the Energizer Editor: Can we please get these drafts at least mirrored on the www.calsch.org web site?  The copies there are woefully out of date and not everyone can keep up w/the sheer volume of postings here.

Thanks!

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 005C94E185256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 12:37:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01022 for ; Tue, 5 Nov 2002 12:37:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5HOM903431 for ietf-calendar-bks; Tue, 5 Nov 2002 09:24:22 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5HOLv03427 for ; Tue, 5 Nov 2002 09:24:21 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA5HOMIR022323 for ; Tue, 5 Nov 2002 09:24:22 -0800 Message-ID: <3DC7FEC3.7030503@Royer.com> Date: Tue, 05 Nov 2002 10:24:19 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: B-3 on INET-Consulting.com References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020404080803090806060607" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020404080803090806060607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > Can we please get these > drafts at least mirrored on the www.calsch.org web site? I have no control over that web site. I do not know who does. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms020404080803090806060607 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNTE3MjQxOVowIwYJKoZIhvcNAQkEMRYEFHxHAIfm +ifs3yigIn9n+5xcc1UWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBXVSWjrGxthCLF/1Us HX1fa3ZDVaXcIfWO40/yNJavWU9R/S4adkXCbgbARJ9LCfV+5dbgUlP7+MKYyxTr4gBHBWlP 0Ahv0rn0RyDqseYBLysEwCn+oV01YunvLtqmQNBfzAzD1bpozZ1USvj42cV3h4RZ3rTtnxvF +5n97TF3s92vzDLrHPEvu/xeSIQJiG//vHQtvKBm5QexCVjPcxFUvcaDwoCi86DE++ADeETv 8PsMgigZI+MTfhfzPMsiM3phYCU8YNvG+LDPdHG88woqigrvA3ACNIlQHogtvXiseFD/0QvD PQnBxvh1fXjPebl38fY9kv+cZV3AFta8fPelAAAAAAAA --------------ms020404080803090806060607-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 12:42:12 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01293 for ; Tue, 5 Nov 2002 12:42:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5HViG03593 for ietf-calendar-bks; Tue, 5 Nov 2002 09:31:44 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5HVhv03589 for ; Tue, 5 Nov 2002 09:31:43 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA5HViIR022386 for ; Tue, 5 Nov 2002 09:31:44 -0800 Message-ID: <3DC8007D.30607@Royer.com> Date: Tue, 05 Nov 2002 10:31:41 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080505010309020201060905" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080505010309020201060905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug responded on 10/31/2002 02:04:46 PM: > > > A CUA may create a "BOOKED" state entry by depositing a iCalendar > > > object into the store. This is done by depositing an object that > > > does not have a "METHOD" property. > > > > > > However this is not 100% accurate as a CUA can deposit a VCAR into the > > > CS w/o a METHOD property and by this definition the VCAR would be > > > considered "BOOKED". (Same goes for a VQUERY, VTIMEZONE, etc) > > > > Yes - they are booked. > > Semantic meaning of 'booked' is being overloaded. "BOOKED" has a > workflow oriented semantic meaning; "I cant make 9:30AM, Im already > booked then", "Sorry, all of our rooms are booked for that date.", etc. > For non-workflow components (VQUERY, VCAR, etc) there is NO matching > semantic meaning that can be applied; "Im sorry, your booked Access > Rights are insufficient to read that entry". > > We can (and in fact are) overloading the semantic meaning of "BOOKED" > and that is my objection. Its not a ship stopper but its still an > objection I wanted raised. CAP is a protocol - within the CAP protocol - I do not see that BOOLED is overloaded. The name "BOOKED" came from the Canada meeting hosted by then CS&T, I just used the name from the meeting. The fact is that the data is booked or not (BOOKED). Or it is an iTIP object or not (UNPROCESSED). Or is it marked for delete or not (DELETED). Those are the states of object in the CAP protocol. > > > > As I don't see the distinction, (are not all ITIP object > > group scheduling objects?) How about: > > The distinction is that I can create entries on my calendar that affect > my schedule but have NO workflow involved. I would insert a "Doctor > Appt @ 10:30AM - 11:15AM" on my calendar after getting off the phone > w/them. There is no associated workflow. In other words, PIM > Calendaring is also part of Calendaring & Scheduling and those PIM > objects are NOT iTIP objects. They have no METHOD, there is no workflow > involved. Hence its not 'group scheduling'. All iTIP objects are > group scheduled entries but not "All scheduled entires" are iTIP objects. I do not see that workflow has anything to do with it. That is a CUA usage issue - not a CAP protocol issue. Those PIM objects are ether non-iCalendar (a.k.a. out of scope), or they are BOOKED objects. Ether way - I just do not follow why the protocol would need to change to store (BOOK) them. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms080505010309020201060905 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNTE3MzE0MVowIwYJKoZIhvcNAQkEMRYEFLtaQ1tO j63sopmvGJxlwtLRZAirMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAkC7SPtskao+0O6FQ9 pFvWM03mEbLD/3OxvTq26K6oRKCCsl4t7VJcMefX9dVCIbWzjkG13fCPtqpdawqbDe4wKNS3 BacW5kI8wo/4BMv9LkvZk9vQmAtm6K+5OldHJalT88ShsgeU4YjYZzxjJ8M2/m9nILguw8RG PUub4LcaCWrY60JXGDOCl+Fwx2eFVM+qPIh/89oI3HOCwagFRfypJqPTEFnrsyNtvaL2cAEz sIU6sY+YA1+5Q4yG9qHAt7sb0/Zs47qh9l6537DMbPlLflsviGPnBAQxtx372JWMnphipM3c s+7WVjiw1PCWJD+7+yY2rx62E88sr2KicXNCAAAAAAAA --------------ms080505010309020201060905-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 14:07:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06007 for ; Tue, 5 Nov 2002 14:07:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5Ix5008981 for ietf-calendar-bks; Tue, 5 Nov 2002 10:59:05 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5Iwvv08958 for ; Tue, 5 Nov 2002 10:58:58 -0800 (PST) In-Reply-To: <3DC6D8FE.9020907@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 13:55:45 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 01:59:07 PM, Serialize complete at 11/05/2002 01:59:07 PM Content-Type: multipart/alternative; boundary="=_alternative 0067F9E485256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067F9E485256C68_= Content-Type: text/plain; charset="US-ASCII" Doug retorted on 11/04/2002 03:30:54 PM: > Again poorly phrased - If the CUA were to return the values, > then the default are not used - as the values returned would > be used. Then I'd say its poorly designed. There has been no, repeat _NO_ good reason to date as to why the CUA should not be mandated to support GET-CAPABILITY in CAP 1.0 and we do away with default value. Perhaps if you can provide one then I could mull over why you so firmly love it but until then I just see the potential in any future release of CAP to have no end of confusion. Which is simpler and less error prone: 1: Imply some default values based on a different value (and therefore ALL of the implied values MUST be true and valid!!) OR 2: Expressly declare all supported values and not infer or deduce 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 0067F9E485256C68_= Content-Type: text/html; charset="US-ASCII"
Doug retorted on 11/04/2002 03:30:54 PM:
> Again poorly phrased - If the CUA were to return the values,
> then the default are not used - as the values returned would
> be used.
Then I'd say its poorly designed.  

There has been no, repeat _NO_ good reason to date as to why the CUA should not be mandated to support GET-CAPABILITY in CAP 1.0 and we do away with default value.  Perhaps if you can provide one then I could mull over why you so firmly love it but until then I just see the potential in any future release of CAP to have no end of confusion.

Which is simpler and less error prone:

1: Imply some default values based on a different value (and therefore ALL of the implied values MUST be true and valid!!)  OR
2: Expressly declare all supported values and not infer or deduce 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 0067F9E485256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 14:10:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06137 for ; Tue, 5 Nov 2002 14:10:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5In9o08340 for ietf-calendar-bks; Tue, 5 Nov 2002 10:49:09 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5In8v08336 for ; Tue, 5 Nov 2002 10:49:08 -0800 (PST) In-Reply-To: <3DC6C2BB.3000309@Royer.com> To: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 13:48:38 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 01:49:11 PM, Serialize complete at 11/05/2002 01:49:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0067531885256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067531885256C68_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/04/2002 01:55:55 PM: > > CS supports RRULEs then NO RECUR-ACCEPTED need be sent. Put another > > way: If 'defaults' have to be expressly sent then what good are they?? > > FYI - the current model does NOT do that. > > The current model says that if the CUA does not send a GET-CAPABILITY > reply - then it the protocol IS CAP-1.0 and the CS must use the defaults > as defined in the spec. There is no point at which they are mixed. I strongly think that we should mandate both CS and CUA MUST implement GET-CAPABILITY in CAP 1.0 AND that we do not use any defaults since all properties are '1' except experimental ones. Otherwise CAP 1.0 is NOT just used to detect what version of the protocol one side speaks but it also implys default values for several properties. Since this can NEVER change in any future rev of CAP I think we should do it the right way now. Is there any good reason not to?? > Again CAP-VERSION does not 'SET THE DEFAULTS'. So your premise > to both options lead me to think that they do not apply. Wrong. CAP 1.0 clearly specifys default values for each property including CAP-VERSION. This effectively "sets the defaults". So far only Doug seems to think we should keep on using defaults which can cause us grief later on. I just wish I could understand why... > If the CUA sends a GET-CAPABILTY reply, then use those settings. > If the CUA does not send a GET-CAPABILITY reply, the protocol is CAP-1.0 > and the CS MUST use the CAP-1.0 defaults. So when CAP 2.0 is released there can be no implicit assumption of what the CUA is can there since the CS has no way to differentiate 1.0 from 2.0. As such all CUAs will have to implement GET-CAPABILITY then or risk being restricted to 1.0 functionality levels. Why not do it right from the start and mandate it now?? Doing this right now would mean that we no longer have any defaults and life is much better for everyone.... > No 'guessing' required - it's CAP 1.0 unless specifically specified. A cleaner option: GET-CAPABILITY is required by all sides in CAP 1.0 and there wont have to be any guessing or assumptions made or defaults implied. 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 0067531885256C68_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/04/2002 01:55:55 PM:
> > CS supports RRULEs then NO RECUR-ACCEPTED need be sent.  Put another
> > way: If 'defaults' have to be expressly sent then what good are they??
>
> FYI - the current model does NOT do that.
>
> The current model says that if the CUA does not send a GET-CAPABILITY
> reply - then it the protocol IS CAP-1.0 and the CS must use the defaults
> as defined in the spec. There is no point at which they are mixed.
I strongly think that we should mandate both CS and CUA MUST implement GET-CAPABILITY in CAP 1.0 AND that we do not use any defaults since all properties are '1' except experimental ones.

Otherwise CAP 1.0 is NOT just used to detect what version of the protocol one side speaks but it also implys default values for several properties.  Since this can NEVER change in any future rev of CAP I think we should do it the right way now.  Is there any good reason not to??

> Again CAP-VERSION does not 'SET THE DEFAULTS'. So your premise
> to both options lead me to think that they do not apply.
Wrong.  CAP 1.0 clearly specifys default values for each property including CAP-VERSION.  This effectively "sets the defaults".

So far only Doug seems to think we should keep on using defaults which can cause us grief later on.  I just wish I could understand why...

> If the CUA sends a GET-CAPABILTY reply, then use those settings.
> If the CUA does not send a GET-CAPABILITY reply, the protocol is CAP-1.0
> and the CS MUST use the CAP-1.0 defaults.
So when CAP 2.0 is released there can be no implicit assumption of what the CUA is can there since the CS has no way to differentiate 1.0 from 2.0.  As such all CUAs will have to implement GET-CAPABILITY then or risk being restricted to 1.0 functionality levels.

 Why not do it right from the start and mandate it now??  Doing this right now would mean that we no longer have any defaults and life is much better for everyone....

> No 'guessing' required -  it's CAP 1.0 unless specifically specified.
A cleaner option: GET-CAPABILITY is required by all sides in CAP 1.0 and there wont have to be any guessing or assumptions made or defaults implied.

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 0067531885256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 14:44:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08160 for ; Tue, 5 Nov 2002 14:44:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5JAAm10538 for ietf-calendar-bks; Tue, 5 Nov 2002 11:10:10 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5JA9v10532 for ; Tue, 5 Nov 2002 11:10:09 -0800 (PST) In-Reply-To: <3DC6E81C.6020704@Royer.com> To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 14:09:51 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 02:10:12 PM, Serialize complete at 11/05/2002 02:10:12 PM Content-Type: multipart/alternative; boundary="=_alternative 0069441C85256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069441C85256C68_= Content-Type: text/plain; charset="US-ASCII" Doug shot back on 11/04/2002 04:35:24 PM: > > So I can now 'book' a VQUERY, VCAR or VTIMEZONE? Sounds illogical to > > me. "BOOKED" as a state is only logical when it relates to workflow > > oriented components like VEVENTs, VTODOs and VJOURNALs. Other > > components dont have associated workflow and are stateless so they > > shouldn't be tagged with one (implicitly or explicitly). > > A while back the WG list agreed that iTIP workflow (METHOD) would beseparated > from STATE. There is no such relationship. Thats not how CAP describes it. Draft 09-b-3 (sorry, cant find -4 still) says: 2.2 Relationship of RFC-2446 (ITIP) and CAP [Snip] A CUA may create a "BOOKED" state object by depositing a iCalendar object into the store. This is done by depositing an object that does not have a "METHOD" property. The CS then knows to set the state of the object to the "BOOKED" state. If the object has a "METHOD" property then the object is stored in the "UNPROCESSED" state. Thus you are using the iTIP METHOD property to determine the state (or STATE) of the entry. This is an overloading of the METHOD properties definition and creates a linkage you say you didnt want. When talking about the state of an object, under the definition of BOOKED, you constantly (and correctly) refer to "scheduling object" in many places. A VCAR is NOT a scheduling object. A VQUERY is NOT a scheduling object. A VAGENDA is NOT a scheduling object. So these components should have no STATE. A VEVENT IS a scheduling object. So are VTODOs and VJOURNALs. So these components SHOULD have STATE. This distinction is part of my original posting: you incorrectly group non-scheduling objects w/scheduling objects when you wrote: 2. A "BOOKED" state entry is stored with the "CREATE" command. It is an object that has been acted on by a CU or CUA and there has been a decision to store an object. "scheduling object" != any arbitrary "object" that can be stored using CAP. I was/am trying to ammend this. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0069441C85256C68_= Content-Type: text/html; charset="US-ASCII"
Doug shot back on 11/04/2002 04:35:24 PM:
> > So I can now 'book' a VQUERY, VCAR or VTIMEZONE?  Sounds illogical to
> > me.  "BOOKED" as a state is only logical when it relates to workflow
> > oriented components like VEVENTs, VTODOs and VJOURNALs.  Other
> > components dont have associated workflow and are stateless so they
> > shouldn't be tagged with one (implicitly or explicitly).
>
> A while back the WG list agreed that iTIP workflow (METHOD) would beseparated
> from STATE. There is no such relationship.
Thats not how CAP describes it.  Draft 09-b-3 (sorry, cant find -4 still) says:

2.2 Relationship of RFC-2446 (ITIP) and CAP

[Snip]
   A CUA may create a "BOOKED" state object by depositing a iCalendar
  object into the store.  This is done by depositing an object that
  does not have a "METHOD" property.  The CS then knows to set the
  state of the object to the "BOOKED" state.  If the object has a
  "METHOD" property then the object is stored in the "UNPROCESSED"
  state.
Thus you are using the iTIP METHOD property to determine the state (or STATE) of the entry.   This is an overloading of the METHOD properties definition and creates a linkage you say you didnt want.

When talking about the state of an object, under the definition of BOOKED, you constantly (and correctly) refer to "scheduling object" in many places.  A VCAR is NOT a scheduling object.  A VQUERY is NOT a scheduling object. A VAGENDA is NOT a scheduling object.  So these components should have no STATE.  A VEVENT IS a scheduling object.  So are VTODOs and VJOURNALs.  So these components SHOULD have STATE.  This distinction is part of my original posting: you incorrectly group non-scheduling objects w/scheduling objects when you wrote:

      2.  A "BOOKED" state entry is stored with the "CREATE" command.
         It is an object that has  been acted on by a CU or CUA and
         there has been a decision to store an object.

"scheduling object" != any arbitrary "object" that can be stored using CAP.  I was/am trying to ammend this.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0069441C85256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 15:10:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10250 for ; Tue, 5 Nov 2002 15:10:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5K2Xm12587 for ietf-calendar-bks; Tue, 5 Nov 2002 12:02:33 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5K2Wv12581 for ; Tue, 5 Nov 2002 12:02:33 -0800 (PST) In-Reply-To: <3DC6FA8A.6030504@Royer.com> To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 15:00:21 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 03:02:36 PM, Serialize complete at 11/05/2002 03:02:36 PM Content-Type: multipart/alternative; boundary="=_alternative 006E0F4C85256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E0F4C85256C68_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/04/2002 05:54:02 PM: > > Since all iCalendar objects are fully self-contained all you need is the > > UID, [RECURRENCE-ID,] SEQUENCE and DTSTAMP to detect if you have newer > > data then the object you are processing or not and so you can tell if > > you should ignore the object or not. All other properties are > > extraneous to the issue of sequencing. > > Feel free to modify the object - there is no CAP requirement > that CAP force a CS to do that :-) You suggested that all the properties must be preserved to do duplicate detection when you replied with: > No, that won't work. Other reasons for the DELETED state are: > > Detection of duplicate iTIP messages > Your going to have to keep the entire object in > order to detect if it is a duplicate. but thats not true for the reasons I cited so its not a justification for having a DELETED state but not actual deleting of entries. CAP does not have any MUST/SHOULD/MAY/etc text to this effect but you still have the suggestion of it when you write: If a duplicate [iTIP] object is deposited into the CS and there exists identical marked for delete objects, then a CUA acting on behalf of the "OWNER" can silently drop those duplicate entries. > > I strongly disagree w/the contention that my CS cannot actually delete > > an entry because it prevents some CUA from doing duplicate detection. > > Could you please point out in CAP where it says that? Sure think. In Draft 09-b-3 its on the bottom of p 18 and top of p 19: If a duplicate [iTIP] object is deposited into the CS and there exists identical marked for delete objects, then a CUA acting on behalf of the "OWNER" can silently drop those duplicate entries. The same text is also in draft 09-b-2 (verbatim I think). Perhaps its removed in draft 09-b-4... > > Since I see no way to undelete an entry marked as "DELETED" (but not > > actually deleted to any degree) and I see no mention of when these > > marked entries can actually be deleted I have a hard time swallowing the > > design w/o it expressly declaring that some form of soft deletion is in > > use. > > Again - feel free not use use that feature. > If I wanted to re-create it, I would just store an object > that looked like it - then remove the old marked for delete one. So now this is an unspecified feature of CAP??... This is all unspecified voodoo that is inconsistant behaviour from the CUAs point of view. This is why I raise the entire issue of actual vs soft deletes (or as you say "marked for deletion"). If the spec is ambiguoius then implemenations will be ambiguous and not interoperate properly. When that happens we've not done the job correctly. > > > In some cases you will want to remain > > > on the distribution list, even if you are not > > > going to attend a specific instance. > > > > Again Im curious to know how the CUA achieves this magical state of > > enlightenment... > > By setting PARTSTAT == no to only that instance. PARTSTAT=DECLINED does not imbue the CUA w/any magical ability to deduce my intent! It merely indicates to the CUA/CS that I declined participation in that entry or instance. It cannot deduce if I did something by accident or on purpose NOR can it tell if I want to stay informed or not (actually that can be done via the RSVP property parameter) but this still remains some kind of voodoo thats unclear how it should be done by everyone... > > > AND > > > I do not recall this WG discussing ANY options that would > > > allow the CS or CUA to remove anything from the marked for > > > deleted objects. > > > > > > The only change to the object is it state. > > > > So a deletion is just a change of state and never an actual removal? > > Nor was that said or written. You just did. A DELETE is not an actual deletion of the entry its only a "change to the object...state" (aka "marked for deletion" as is often used in the CAP draft). How else is one to interpret: In which case the "UNPROCESSED" state objects could be removed from the CS or the CUA could set those object to the marked for delete state. The entry is "removed from the CS or ...marked for delete." is 2 distinct cases: actually removed from the CS or marked for removal from the CS. Just like most mail clients have a trash bin of some form where "marked for deletion" messages go before they are actually "removed from the" mail file, you have proscribed the concept of soft deleting an entry since you also allow it to be "marked for deletion", available for duplicate detection (or recreation/restoration) BUT its unpurgable from the system. This is all a digression from BOOKED state to the issue of deletions (although its relevant to the DELETED state). I return to the original relevant portion I sent: > On the topic of querying for deleted entries, we should clearly state > (preferably in 1.3) that no actual data is guaranteed to be returned for > a "DELETED" entry with maybe the exception of the UID (maybe...). Unless we unambiguously and categorically define how deletions are to be dealt with then we risk turning the DELETED state into the "recurrence rule of CAP"... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006E0F4C85256C68_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/04/2002 05:54:02 PM:
> > Since all iCalendar objects are fully self-contained all you need is the
> > UID, [RECURRENCE-ID,] SEQUENCE and DTSTAMP to detect if you have newer
> > data then the object you are processing or not and so you can tell if
> > you should ignore the object or not.  All other properties are
> > extraneous to the issue of sequencing.
>
> Feel free to modify the object - there is no CAP requirement
> that CAP force a CS to do that :-)
You suggested that all the properties must be preserved to do duplicate detection when you replied with:

> No, that won't work. Other reasons for the DELETED state are:
>
>    Detection of duplicate iTIP messages
>         Your going to have to keep the entire object in
>       order to detect if it is a duplicate.

but thats not true for the reasons I cited so its not a justification for having a DELETED state but not actual deleting of entries.

CAP does not have any MUST/SHOULD/MAY/etc text to this effect but you still have the suggestion of it when you write:

                                                     If a duplicate
  [iTIP] object is deposited into the CS and there exists identical
  marked for delete objects, then a CUA acting on behalf of the "OWNER"
  can silently drop those duplicate entries.
> > I strongly disagree w/the contention that my CS cannot actually delete
> > an entry because it prevents some CUA from doing duplicate detection.
>
> Could you please point out in CAP where it says that?

Sure think.  In Draft 09-b-3 its on the bottom of p 18 and top of p 19:

                                                     If a duplicate
  [iTIP] object is deposited into the CS and there exists identical
  marked for delete objects, then a CUA acting on behalf of the "OWNER"
  can silently drop those duplicate entries.
The same text is also in draft 09-b-2 (verbatim I think).  Perhaps its removed in draft 09-b-4...

> >  Since I see no way to undelete an entry marked as "DELETED" (but not
> > actually deleted to any degree) and I see no mention of when these
> > marked entries can actually be deleted I have a hard time swallowing the
> > design w/o it expressly declaring that some form of soft deletion is in
> > use.
>
> Again - feel free not use use that feature.
> If I wanted to re-create it, I would just store an object
> that looked like it - then remove the old marked for delete one.
So now this is an unspecified feature of CAP??...

This is all unspecified voodoo that is inconsistant behaviour from the CUAs point of view.  This is why I raise the entire issue of actual vs soft deletes (or as you say "marked for deletion").

If the spec is ambiguoius then implemenations will be ambiguous and not interoperate properly.  When that happens we've not done the job correctly.

> >  >                 In some cases you will want to remain
> >  >       on the distribution list, even if you are not
> >  >       going to attend a specific instance.
> >
> > Again Im curious to know how the CUA achieves this magical state of
> > enlightenment...
>
> By setting PARTSTAT == no to only that instance.
PARTSTAT=DECLINED does not imbue the CUA w/any magical ability to deduce my intent!  It merely indicates to the CUA/CS that I declined participation in that entry or instance.  It cannot deduce if I did something by accident or on purpose NOR can it tell if I want to stay informed or not (actually that can be done via the RSVP property parameter) but this still remains some kind of voodoo thats unclear how it should be done by everyone...

> >  > AND
> >  >    I do not recall this WG discussing ANY options that would
> >  >    allow the CS or CUA to remove anything from the marked for
> >  >    deleted objects.
> >  >
> >  >    The only change to the object is it state.
> >
> > So a deletion is just a change of state and never an actual removal?
>
> Nor was that said or written.
You just did.  A DELETE is not an actual deletion of the entry its only a "change to the object...state" (aka "marked for deletion" as is often used in the CAP draft).  How else is one to interpret:

                                                    In which case the
  "UNPROCESSED" state objects could be removed from the CS or the CUA
  could set those object to the marked for delete state.

The entry is "removed from the CS or ...marked for delete." is 2 distinct cases: actually removed from the CS or marked for removal from the CS.  Just like most mail clients have a trash bin of some form where "marked for deletion" messages go before they are actually "removed from the" mail file, you have proscribed the concept of soft deleting an entry since you also allow it to be "marked for deletion", available for duplicate detection (or recreation/restoration) BUT its unpurgable from the system.

This is all a digression from BOOKED state to the issue of deletions (although its relevant to the DELETED state).   I return to the original relevant portion I sent:

> On the topic of querying for deleted entries, we should clearly state
> (preferably in 1.3) that no actual data is guaranteed to be returned for
> a "DELETED" entry with maybe the exception of the UID (maybe...).

Unless we unambiguously and categorically define how deletions are to be dealt with then we risk turning the DELETED state into the "recurrence rule of CAP"...

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

--=_alternative 006E0F4C85256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 15:49:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13457 for ; Tue, 5 Nov 2002 15:49:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5Keci14800 for ietf-calendar-bks; Tue, 5 Nov 2002 12:40:38 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5KeWv14788 for ; Tue, 5 Nov 2002 12:40:33 -0800 (PST) In-Reply-To: <3DC7FEC3.7030503@Royer.com> To: ietf-calendar@imc.org Subject: Re: B-3 on INET-Consulting.com MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 15:36:22 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 03:40:40 PM, Serialize complete at 11/05/2002 03:40:40 PM Content-Type: multipart/alternative; boundary="=_alternative 00712FF385256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00712FF385256C68_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/05/2002 12:24:19 PM: > > Can we please get these > > drafts at least mirrored on the www.calsch.org web site? > > I have no control over that web site. I do not know who does. Our illustrious leaders do. Its hosted @ MIT I believe so Bob or Pat should be able to arrange for you to be given higher rank than the rest of us. Pat?? Bob?? Can you wave your magical wands and bless Doug so CAP drafts can put on our WGs web site? 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 00712FF385256C68_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/05/2002 12:24:19 PM:
>  > Can we please get these
> > drafts at least mirrored on the www.calsch.org web site?
>
> I have no control over that web site. I do not know who does.
Our illustrious leaders do.  Its hosted @ MIT I believe so Bob or Pat should be able to arrange for you to be given higher rank than the rest of us.

Pat??  Bob??  Can you wave your magical wands and bless Doug so CAP drafts can put on our WGs web site?

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 00712FF385256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 15:59:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14166 for ; Tue, 5 Nov 2002 15:59:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5KpIM15412 for ietf-calendar-bks; Tue, 5 Nov 2002 12:51:18 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5KpHv15406 for ; Tue, 5 Nov 2002 12:51:18 -0800 (PST) In-Reply-To: <3DC8007D.30607@Royer.com> To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 15:50:58 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 03:51:21 PM, Serialize complete at 11/05/2002 03:51:21 PM Content-Type: multipart/alternative; boundary="=_alternative 0072863C85256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072863C85256C68_= Content-Type: text/plain; charset="US-ASCII" Doug expounded on 11/05/2002 12:31:41 PM: > CAP is a protocol - within the CAP protocol - I do not see that > BOOLED is overloaded. The name "BOOKED" came from the Canada > meeting hosted by then CS&T, I just used the name from the meeting. > > The fact is that the data is booked or not (BOOKED). Or it is an iTIP > object or not (UNPROCESSED). Or is it marked for delete or not (DELETED). > Those are the states of object in the CAP protocol. Let me try to put my original point in finer detail: Applying a state of "BOOKED" to a non-scheduling component is illogical since its not contextually thought of that way in normal human grammar/language. As such the conceptual states like BOOKED and DELETED do not normally apply to non-scheduling components like VCARs, VAGENDAs or VQUERYs. These components just "are" or "are not" there; they are not involved with the normal workflow process between CUs. So I wanted to clear up the overly broad definition of BOOKED and DELETED so that it was clear they referred to scheduling components. For all other components the 'state' of them should just be "there" or "not there". There are bigger issues to deal with (Tombstones / soft-deletions!) so Ill just leave my concern as noted. If some still want to think of every componenting having workflow oriented states then thats their choice to make... > Those PIM objects are ether non-iCalendar (a.k.a. out of scope), > or they are BOOKED objects. Ether way - I just do not follow why > the protocol would need to change to store (BOOK) them. PIM (aka Calendaring) is NOT out of scope of CAP. I dont need to create any workflow message to create a doctor appointment on my calendar or to just block of some 'quiet work time' on my calendar do I??? My doctor appoinment is "BOOKED" but the VCARs I create on my calendar that I put the appointment onto are NOT "BOOKED" from a linguistic POV. They are from the current CAP POV and I think that its incorrect. See above if necessary... Related question: Why should the CS keep my deleted (nay, "marked for deletion" only) VCARs if they are no longer used? They should just be removed (or possibly tombstoned if you want to do Sync 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 0072863C85256C68_= Content-Type: text/html; charset="US-ASCII"
Doug expounded on 11/05/2002 12:31:41 PM:
> CAP is a protocol - within the CAP protocol - I do not see that
> BOOLED is overloaded. The name "BOOKED" came from the Canada
> meeting hosted by then CS&T, I just used the name from the meeting.
>
> The fact is that the data is booked or not (BOOKED). Or it is an iTIP
> object or not (UNPROCESSED). Or is it marked for delete or not (DELETED).
> Those are the states of object in the CAP protocol.
Let me try to put my original point in finer detail:

Applying a state of "BOOKED" to a non-scheduling component is illogical since its not contextually thought of that way in normal human grammar/language.  As such the conceptual states like BOOKED and DELETED do not normally apply to non-scheduling components like VCARs, VAGENDAs or VQUERYs.  These components just "are" or "are not" there; they are not involved with the normal workflow process between CUs.

So I wanted to clear up the overly broad definition of BOOKED and DELETED so that it was clear they referred to scheduling components.  For all other components the 'state' of them should just be "there" or "not there".  

There are bigger issues to deal with (Tombstones / soft-deletions!) so Ill just leave my concern as noted.  If some still want to think of every componenting having workflow oriented states then thats their choice to make...

> Those PIM objects are ether non-iCalendar (a.k.a. out of scope),
> or they are BOOKED objects. Ether way - I just do not follow why
> the protocol would need to change to store (BOOK) them.
PIM (aka Calendaring) is NOT out of scope of CAP.  I dont need to create any workflow message to create a doctor appointment on my calendar or to just block of some 'quiet work time' on my calendar do I???

My doctor appoinment is "BOOKED" but the VCARs I create on my calendar that I put the appointment onto are NOT "BOOKED" from a linguistic POV.  They are from the current CAP POV and I think that its incorrect.  See above if necessary...

Related question: Why should the CS keep my deleted (nay, "marked for deletion" only) VCARs if they are no longer used?  They should just be removed (or possibly tombstoned if you want to do Sync 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 0072863C85256C68_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 5 16:14:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15090 for ; Tue, 5 Nov 2002 16:14:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5L6Ku17187 for ietf-calendar-bks; Tue, 5 Nov 2002 13:06:20 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5L6Jv17181 for ; Tue, 5 Nov 2002 13:06:19 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Nov 2002 16:06:15 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/05/2002 04:06:23 PM, Serialize complete at 11/05/2002 04:06:23 PM Content-Type: multipart/alternative; boundary="=_alternative 0073E55585256C68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073E55585256C68_= Content-Type: text/plain; charset="US-ASCII" Doug replied: > > > So you agree, and Bruce agrees, and Andrea agrees, I agree, everyone who > > has expressed an opinion on the subject agrees... > > No - not everyone agreed - please re-read the archives. I changed > it to what it is now after that debate. From what Ive read it appears that Andrea, George and I agree and you disagree with this. The rest abstain by their silence or we take the iCalendar approach and the rest agree by staying quiet... > It would be great to get rid of the default values and go back > to minimumims. Sounds like we all agree that default values are to be removed. I dont think minimums are necessary. Instead we should just have each side expresslly send values in response. That way there is no confusion. What good are minimums if there is no way to determine the 'maximums' (whatever they may be)?? I like Georges proposal: All sides MUST support GET-CAPABILITY and NO defaulting of any values! Anyone else like 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 0073E55585256C68_= Content-Type: text/html; charset="US-ASCII"
Doug replied:
>
> >     So you agree, and Bruce agrees, and Andrea agrees, I agree, everyone who
> > has expressed an opinion on the subject agrees...
>
> No - not everyone agreed - please re-read the archives. I changed
> it to what it is now after that debate.
From what Ive read it appears that Andrea, George and I agree and you disagree with this.  The rest abstain by their silence or we take the iCalendar approach and the rest agree by staying quiet...

> It would be great to get rid of the default values and go back
> to minimumims.
Sounds like we all agree that default values are to be removed.  I dont think minimums are necessary.  Instead we should just have each side expresslly send values in response.  That way there is no confusion.  What good are minimums if there is no way to determine the 'maximums' (whatever they may be)??  

I like Georges proposal: All sides MUST support GET-CAPABILITY and NO defaulting of any values!  Anyone else like 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 0073E55585256C68_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 05:16:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10688 for ; Wed, 6 Nov 2002 05:16:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6A5Bb16900 for ietf-calendar-bks; Wed, 6 Nov 2002 02:05:11 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6A5Av16896 for ; Wed, 6 Nov 2002 02:05:10 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 29CD1155C9; Wed, 6 Nov 2002 11:05:09 +0100 (CET) Date: Wed, 6 Nov 2002 11:05:09 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION Message-ID: <20021106100509.GC25132@inet.it> References: 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.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Nov 05, 2002 at 04:06:15PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > I like Georges proposal: All sides MUST support GET-CAPABILITY and NO > defaulting of any values! Anyone else like it? Make that: All sides MUST support GET-CAPABILITY, all sides MUST send it before anything else, NO defaulting of any values. I like it. -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Nov 6 10:36:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27133 for ; Wed, 6 Nov 2002 10:36:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6FQO212614 for ietf-calendar-bks; Wed, 6 Nov 2002 07:26:24 -0800 (PST) Received: from server1.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6FQMv12609 for ; Wed, 6 Nov 2002 07:26:23 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: B-3 on INET-Consulting.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 6 Nov 2002 10:26:34 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 11/06/2002 10:26:24 AM, Serialize complete at 11/06/2002 10:26:24 AM Content-Type: multipart/alternative; boundary="=_alternative 0054D48A85256C69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054D48A85256C69_= Content-Type: text/plain; charset="us-ascii" Doug, can you send me the drafts. I and Bob have control over the web site. I believe it says it on the list and we've said it on this list often. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 11/05/2002 12:24 Please respond to ietf-calendar To: ietf-calendar@imc.org cc: Subject: Re: B-3 on INET-Consulting.com Bruce_Kahn@notesdev.ibm.com wrote: > Can we please get these > drafts at least mirrored on the www.calsch.org web site? I have no control over that web site. I do not know who does. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --=_alternative 0054D48A85256C69_= Content-Type: text/html; charset="us-ascii"
Doug, can you send me the drafts.  I and Bob have control over the web site.  I believe it says it on the list and we've said it on this list often.  
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

11/05/2002 12:24
Please respond to ietf-calendar

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: B-3 on INET-Consulting.com





Bruce_Kahn@notesdev.ibm.com wrote:

> Can we please get these
> drafts at least mirrored on the www.calsch.org web site?

I have no control over that web site. I do not know who does.

--
-
Doug Royer                       Work: (208)612-INET
Doug@Royer.com                   Fax:  (866)594-8574
http://INET-Consulting.com       Cell: (208)520-4044
http://Royer.com/People/Doug

--=_alternative 0054D48A85256C69_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 12:33:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03256 for ; Wed, 6 Nov 2002 12:33:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6HMwY19949 for ietf-calendar-bks; Wed, 6 Nov 2002 09:22:58 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6HMuv19938 for ; Wed, 6 Nov 2002 09:22:56 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA6HMvIR000508 for ; Wed, 6 Nov 2002 09:22:58 -0800 Message-ID: <3DC94FEE.400@Royer.com> Date: Wed, 06 Nov 2002 10:22:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: B-3 on INET-Consulting.com References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010000040001010805020700" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010000040001010805020700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > Doug, can you send me the drafts. Pat, I Cc'd you and Bob on the submission to the IETF. A copy is at: http://INET-Consulting.com/cap-09-submitted.xml http://INET-Consulting.com/cap-09-submitted.txt http://INET-Consulting.com/cap-09-submitted.html I have already removed all of the edit version that are between -08 and -09-submitted. They were for discussion only and only confused those who read those old versions. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms010000040001010805020700 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNjE3MjI1NVowIwYJKoZIhvcNAQkEMRYEFFotIhQI TlTxR3BIEqO4eVVMd+lTMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAQYqlwLUAMG2XwInLy Spdp1Vdrk6nzRp9PbvT46qjZprpJQBsNnvoHsWX0rVwe4vxezwVVqtEEF7MXxw95r7JwRsIk Hag9FyaamxqC3Iqb8D+hHYRMNjVi5wv3o/386LdSbqlgZ5IsvxOO3K+nsr+2JSiIRkYxByGU JDVueltSnjQUDfCAmAIUcQH/s28N0gFGD89np6ydXax3VOuCSgFTmaQzYsyc/Qc4lgxwjUwp CYJa6klW4fcx0KQC4FBnbox+rkKZp806yjOXSVVCNXv3+E8oXzm01A0xM1brGhmhaVseUKGp VG/3rQdBLgtOpPSudN0sv5eLpSBQ8dMAppjEAAAAAAAA --------------ms010000040001010805020700-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 17:45:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15873 for ; Wed, 6 Nov 2002 17:45:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6MaNk09159 for ietf-calendar-bks; Wed, 6 Nov 2002 14:36:23 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6MaMv09151 for ; Wed, 6 Nov 2002 14:36:22 -0800 (PST) To: ietf-calendar@imc.org Subject: 1.3 Definitions: Calendar Identifier , Qualified Calendar Identifier & Relative Calendar Identifier MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Nov 2002 17:36:18 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/06/2002 05:36:26 PM, Serialize complete at 11/06/2002 05:36:26 PM Content-Type: multipart/alternative; boundary="=_alternative 007C47D385256C69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007C47D385256C69_= Content-Type: text/plain; charset="US-ASCII" It seems that some older issues have not been addressed in the submitted draft (09-b-3 is now "403). In particular there needs to be some clearer guidelines/descriptions when defining Calendar Identifier , Qualified Calendar Identifier & Relative Calendar Identifier. The relevant texts are: Calendar Identifier (CalID) - A globally unique identifier associated with a calendar. Calendars reside within a CS. See Qualified Calendar Identifier and Relative Calendar Identifier. All CalIDs start with "cap:". Qualified Calendar Identifier (Qualified CalID) - A CalID in which both the scheme and csid of the CAP URI are present. Relative Calendar Identifier (Relative CalID) - An identifier for an individual calendar in a calendar store. It MUST BE unique within a calendar store. A Relative CalID consists of the "URL path" of the "Common Internet Scheme Syntax" portion of a URL, as defined by [URI] and [URLGUIDE]. One concern is that there is no clear format guidlines for a CalID. There are references to the Qualfied CalID and Relative CalID defintions but neither clearly defines the format of the CalID (aka CAP URI)! The Qualified CalID defintion refers to the 'scheme and csid of the CAP URI' but "CAP URI" is never used or defined in the draft. I expect that it should be "CalID" but maybe thats just me. If so then the CalID definition needs to be fully described so that all URI subcomponents are clearly defined. The mention of "cap:" under CalID reads like the defintion of a URI schema but its not labeled as such. The Relative CalID defintion uses "URL path" and "Common Internet Scheme Syntax" much like Qualified CalID used "scheme and csid". Its not consistant nor is it clear. Can we please have the full CAP URI format defined under CalID and get the other related definitions to consistantly refer to the parts defined under CalID? I didnt propose any explicit text as I didnt want to just assume that CAP URI was the same as CalID, just in case... 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 007C47D385256C69_= Content-Type: text/html; charset="US-ASCII"
It seems that some older issues have not been addressed in the submitted draft (09-b-3 is now "403).  

In particular there needs to be some clearer guidelines/descriptions when defining Calendar Identifier , Qualified Calendar Identifier & Relative Calendar Identifier.  The relevant texts are:

   Calendar Identifier (CalID) -  A globally unique identifier
     associated with a calendar.  Calendars reside within a CS.  See
     Qualified Calendar Identifier and Relative Calendar Identifier.
     All CalIDs start with "cap:".
   Qualified Calendar Identifier (Qualified CalID) -  A CalID in which
     both the scheme and csid of the CAP URI are present.

  Relative Calendar Identifier (Relative CalID) -  An identifier for an
     individual calendar in a calendar store.  It MUST BE unique within
     a calendar store.  A Relative CalID consists of the "URL path" of
     the "Common Internet Scheme Syntax" portion of a URL, as defined
     by [URI] and [URLGUIDE].

One concern is that there is no clear format guidlines for a CalID.  There are references to the Qualfied CalID and Relative CalID defintions but neither clearly defines the format of the CalID (aka CAP URI)!

The Qualified CalID defintion refers to the 'scheme and csid of the CAP URI' but "CAP URI" is never used or defined in the draft.  I expect that it should be "CalID" but maybe thats just me.  If so then the CalID definition needs to be fully described so that all URI subcomponents are clearly defined.  The mention of "cap:" under CalID reads like the defintion of a URI schema but its not labeled as such.

The Relative CalID defintion uses "URL path" and "Common Internet Scheme Syntax" much like Qualified CalID used "scheme and csid".  Its not consistant nor is it clear.

Can we please have the full CAP URI format defined under CalID and get the other related definitions to consistantly refer to the parts defined under CalID?  I didnt propose any explicit text as I didnt want to just assume that CAP URI was the same as CalID, just in case...

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 007C47D385256C69_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 17:54:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16112 for ; Wed, 6 Nov 2002 17:54:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6Mldu09618 for ietf-calendar-bks; Wed, 6 Nov 2002 14:47:39 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6Mlcv09614 for ; Wed, 6 Nov 2002 14:47:39 -0800 (PST) To: ietf-calendar@imc.org Subject: 1.3 Definitions: Calendar Policy MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Nov 2002 17:47:31 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/06/2002 05:47:42 PM, Serialize complete at 11/06/2002 05:47:42 PM Content-Type: multipart/alternative; boundary="=_alternative 007D4EF685256C69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007D4EF685256C69_= Content-Type: text/plain; charset="US-ASCII" Shouldn't components be included in the description of a Calendar Policy? That is, should: Calendar Policy - A CAP operational restriction on the access or manipulation of a calendar. These may be outside of the scope of the CAP protocol. An example of an implementation or site policy is, "events MUST BE scheduled in unit intervals of one hour". be changed to: Calendar Policy - A CAP operational restriction on the access or manipulation of a calendar or components in that calendar. These may be outside of the scope of the CAP protocol. An example of an implementation or site policy is, "events MUST BE scheduled in unit intervals of one hour". After all a policy could be that only some UPNs can only read from the calendar and only special UPNs can read and write to it. Another example is that some UPNs may read and write events but they may not change the Calendar Access Rights lists.... 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 007D4EF685256C69_= Content-Type: text/html; charset="US-ASCII"
Shouldn't components be included in the description of a Calendar Policy?  That is, should:

   Calendar Policy -  A CAP operational restriction on the access or
     manipulation of a calendar.  These may be outside of the scope of
     the CAP protocol.  An example of an implementation or site policy
     is, "events MUST BE scheduled in unit intervals of one hour".

be changed to:

   Calendar Policy -  A CAP operational restriction on the access or
     manipulation of a calendar or components in that calendar.  These
      may be outside of the scope of the CAP protocol.  An example of
      an implementation or site policy is, "events MUST BE scheduled
      in unit intervals of one hour".
After all a policy could be that only some UPNs can only read from the calendar and only special UPNs can read and write to it.  Another example is that some UPNs may read and write events but they may not change the Calendar Access Rights lists....

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 007D4EF685256C69_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 18:02:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16350 for ; Wed, 6 Nov 2002 18:02:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6Mp0K09676 for ietf-calendar-bks; Wed, 6 Nov 2002 14:51:00 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6Moxv09669 for ; Wed, 6 Nov 2002 14:50:59 -0800 (PST) To: ietf-calendar@imc.org Subject: 1.3 Definitions: Calendar Store Properties MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Nov 2002 17:50:51 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/06/2002 05:51:03 PM, Serialize complete at 11/06/2002 05:51:03 PM Content-Type: multipart/alternative; boundary="=_alternative 007D9CEA85256C69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007D9CEA85256C69_= Content-Type: text/plain; charset="US-ASCII" Im confused by the definition: Calendar Store Properties - Properties maintained in a Calendar Store calendar store-wide information. The last bit seems redundant or cyclical to say the least. Perhaps its missing some text to make it express the desired defintion or maybe Im just loosing my grasp of English. Anyone else think so? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007D9CEA85256C69_= Content-Type: text/html; charset="US-ASCII"
Im confused by the definition:

   Calendar Store Properties -  Properties maintained in a Calendar
     Store calendar store-wide information.

The last bit seems redundant or cyclical to say the least.  Perhaps its missing some text to make it express the desired defintion or maybe Im just loosing my grasp of English.  Anyone else think so?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007D9CEA85256C69_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 18:10:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16463 for ; Wed, 6 Nov 2002 18:10:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6N34l09878 for ietf-calendar-bks; Wed, 6 Nov 2002 15:03:04 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6N32v09874 for ; Wed, 6 Nov 2002 15:03:02 -0800 (PST) To: ietf-calendar@imc.org Subject: 1.3 Defintions: User Principal Name MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Nov 2002 18:02:57 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/06/2002 06:03:05 PM, Serialize complete at 11/06/2002 06:03:05 PM Content-Type: multipart/alternative; boundary="=_alternative 007EB86B85256C69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007EB86B85256C69_= Content-Type: text/plain; charset="US-ASCII" In recomparing my comments from the 07 draft to the 09-submitted draft I see that this was still not clear. The draft says in part: User Principal Name (UPN) - A unique identifier that denotes a CU or a group of CU. A UPN is a RFC 822 compliant email address, with exceptions listed below, and in most cases it is deliverable to the CU. Its unclear what "is deliverable to the CU" means since a UPN is "A unique identifier" and is not an actual message or other object that can be 'delivered'. Also, just to be clear is the "group of CU" referred to in the 1st line the same as the "User Group (UG)" that is defined 2 terms above UPN? If so, why not use "User Group" in the 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... --=_alternative 007EB86B85256C69_= Content-Type: text/html; charset="US-ASCII"
In recomparing my comments from the 07 draft to the 09-submitted draft I see that this was still not clear.  The draft says in part:

   User Principal Name (UPN) -  A unique identifier that denotes a CU or
     a group of CU.  A UPN is a RFC 822 compliant email address, with
     exceptions listed below, and in most cases it is deliverable to
     the CU.

Its unclear what "is deliverable to the CU" means since a UPN is "A unique identifier" and is not an actual message or other object that can be 'delivered'.

Also, just to be clear is the "group of CU" referred to in the 1st line the same as the "User Group (UG)" that is defined 2 terms above UPN?  If so, why not use "User Group" in the 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... --=_alternative 007EB86B85256C69_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 18:22:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16680 for ; Wed, 6 Nov 2002 18:22:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6NF6B10144 for ietf-calendar-bks; Wed, 6 Nov 2002 15:15:06 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6NF5v10140 for ; Wed, 6 Nov 2002 15:15:05 -0800 (PST) To: ietf-calendar@imc.org Subject: What good are stored VQUERYs? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Nov 2002 18:14:55 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/06/2002 06:15:09 PM, Serialize complete at 11/06/2002 06:15:09 PM Content-Type: multipart/alternative; boundary="=_alternative 007FD10985256C69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007FD10985256C69_= Content-Type: text/plain; charset="US-ASCII" It seems that the question never got resolved after the hall way discussions we had a couple meetings ago. Throughout the draft there are lots of references to stored queries: NAME - Several storeable components such as "VCAR" and "VQUERY" may have the "NAME" property contained in them to describe in various locals the purpose of the component. and The conceptual model for a calendar store is shown below. The calendar store (VCALSTORE - Section 9.2) contains "VCAR"s, "VQUERY"s, "VTIMEZONE"s, "VAGENDA"s and calendar store properties. Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar properties. and VCALSTORE | +-- properties +-- VCARs +-- VQUERYs but I have yet to see what use storing queries can be. After all, I cannot 'wildcard' or macro expand anything in a query so I cannot create a stored query for "Find me all events on my calendar for today" or "What events have alarms that trigger in the next 15 minutes", etc. Each VQUERY that a CUA sends to the CS needs to be custom built to have the right parameters (ie: dates/times). So in the interest of KISS I ask why a CS should (MUST?) store VQUERYs if they are effectively 'single shot' queries? Unless there is a common case that Im just not seeing I would like to propose that we remove the concept of stored queries entirely. 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 007FD10985256C69_= Content-Type: text/html; charset="US-ASCII"
It seems that the question never got resolved after the hall way discussions we had a couple meetings ago.  Throughout the draft there are lots of references to stored queries:

   NAME -  Several storeable components such as "VCAR" and "VQUERY" may
     have the "NAME" property contained in them to describe in various
     locals the purpose of the component.

and

   The conceptual model for a calendar store is shown below.  The
  calendar store (VCALSTORE - Section 9.2) contains "VCAR"s, "VQUERY"s,
  "VTIMEZONE"s, "VAGENDA"s and calendar store properties.

   Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s,
  "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar
  properties.
and

   VCALSTORE
  |
  +-- properties
  +-- VCARs
  +-- VQUERYs
but I have yet to see what use storing queries can be.  After all, I cannot 'wildcard' or macro expand anything in a query so I cannot create a stored query for "Find me all events on my calendar for today" or "What events have alarms that trigger in the next 15 minutes", etc.  Each VQUERY that a CUA sends to the CS needs to be custom built to have the right parameters (ie: dates/times).

So in the interest of KISS I ask why a CS should (MUST?) store VQUERYs if they are effectively 'single shot' queries?

Unless there is a common case that Im just not seeing I would like to propose that we remove the concept of stored queries entirely.

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 007FD10985256C69_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 18:25:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16774 for ; Wed, 6 Nov 2002 18:25:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6NKsf10209 for ietf-calendar-bks; Wed, 6 Nov 2002 15:20:54 -0800 (PST) Received: from server1.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6NKqv10204 for ; Wed, 6 Nov 2002 15:20:52 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: B-3 on INET-Consulting.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 6 Nov 2002 18:20:54 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 11/06/2002 06:20:56 PM, Serialize complete at 11/06/2002 06:20:56 PM Content-Type: multipart/alternative; boundary="=_alternative 008041E085256C69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 008041E085256C69_= Content-Type: text/plain; charset="us-ascii" thanks. I'll get them loaded up there tomorrow ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 008041E085256C69_= Content-Type: text/html; charset="us-ascii"
thanks.  I'll get them loaded up there tomorrow
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 008041E085256C69_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 18:46:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17171 for ; Wed, 6 Nov 2002 18:46:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6NbvA10850 for ietf-calendar-bks; Wed, 6 Nov 2002 15:37:57 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6Nbtv10846 for ; Wed, 6 Nov 2002 15:37:56 -0800 (PST) To: ietf-calendar@imc.org Subject: 10.4 IDENTIFY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Nov 2002 18:37:46 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/06/2002 06:38:00 PM, Serialize complete at 11/06/2002 06:38:00 PM Content-Type: multipart/alternative; boundary="=_alternative 0081E8A085256C69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0081E8A085256C69_= Content-Type: text/plain; charset="US-ASCII" In trying to match earlier issues w/the latest draft I ran across this one. The 09-submitted draft says: The CS determines through an internal mechanism if the credentials supplied at authentication permit the operation as the selected identity. and this implys that whatever credentials (UPN??) I originally authenticate with determines if I can change my identity later on AND to which identities I can change to. This seems a bit restrictive as it basically puts the onus on the CS implementors to know in a priori not only what identities can authenticate w/the CS but also what identities they can assume. So, in order for my new AA to be able to assume my identity its not a matter of her proving it by some (re)authentication mechanism, its an issue of making sure my CS is configured w/this information somehow (the actual mechanism appears to be TBD). Unfortunately since we have no Administrative kinds of features like this spec'd in CAP 1.0 (at least not that Ive found yet) isnt this a kind of chicken and egg problem that will bite us in the butt at our first CAP interop?? There has to be a better way.... 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 0081E8A085256C69_= Content-Type: text/html; charset="US-ASCII"
In trying to match earlier issues w/the latest draft I ran across this one.  The 09-submitted draft says:

   The CS determines through an internal mechanism if the credentials
  supplied at authentication permit the operation as the selected
  identity.

and this implys that whatever credentials (UPN??) I originally authenticate with determines if I can change my identity later on AND to which identities I can change to.  This seems a bit restrictive as it basically puts the onus on the CS implementors to know in a priori not only what identities can authenticate w/the CS but also what identities they can assume.

So, in order for my new AA to be able to assume my identity its not a matter of her proving it by some (re)authentication mechanism, its an issue of making sure my CS is configured w/this information somehow (the actual mechanism appears to be TBD).  Unfortunately since we have no Administrative kinds of features like this spec'd in CAP 1.0 (at least not that Ive found yet) isnt this a kind of chicken and egg problem that will bite us in the butt at our first CAP interop??  There has to be a better way....

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 0081E8A085256C69_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 19:00:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17560 for ; Wed, 6 Nov 2002 19:00:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6Np3012188 for ietf-calendar-bks; Wed, 6 Nov 2002 15:51:03 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6Np2v12182 for ; Wed, 6 Nov 2002 15:51:02 -0800 (PST) To: ietf-calendar@imc.org Subject: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Nov 2002 18:50:58 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/06/2002 06:51:06 PM, Serialize complete at 11/06/2002 06:51:06 PM Content-Type: multipart/alternative; boundary="=_alternative 00831DDB85256C69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00831DDB85256C69_= Content-Type: text/plain; charset="US-ASCII" I hate it when I get distracted and forget to complete an email before sending. Sorry to split the issue on this section into 2 emails but... There is a discrepancy in the ABNF for identifyparam compared to the text and examples. The ABNF is: identifyparam = *( ; the following are optional, ; but MUST NOT occur more than once id-param / localize-param / latency-param ; the following MUST occur exactly once and only ; when the latency-param has been supplied and ; MUST NOT be supplied if the latency-param is ; not supplied. / action-param ; the following is optional, ; and MAY occur more than once / (";" xparam) ; The value is the UPN of the requested ; identity. If not supplied it is a request ; to return to the original authenticated identity. / option-param upn ) [Snip, snip] And for the CUA to return to its original authenticated identity the OPTIONS parameter is omitted: Alas the ABNF does NOT accurately reflect that option-param is truely optional. For this the line needs to be changed to the following to allow what the cited text above suggests: ; The value is the UPN of the requested ; identity. If not supplied it is a request ; to return to the original authenticated identity. / [ option-param ] upn Lastly, the behaviour for when an IDENTITY fails is unclear. The text simply says: If they do, the session assumes the new identity, otherwise a security error is returned. but does not expressly indicate that the original (or previous) identity is to be resumed. It could be that more than one IDENTITY command has been issued with some that worked. As such its unclear if the failure results in the last 'confirmed' or allowed identity to be used or if the original authentication identity is to be restored. I dont care either way, I just want consistant behaviour. 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 00831DDB85256C69_= Content-Type: text/html; charset="US-ASCII"
I hate it when I get distracted and forget to complete an email before sending.  Sorry to split the issue on this section into 2 emails but...

There is a discrepancy in the ABNF for identifyparam compared to the text and examples.  The ABNF is:

        identifyparam   = *(

                       ; the following are optional,
                       ; but MUST NOT occur more than once

                         id-param
                       / localize-param
                       / latency-param

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

                       / action-param

                       ; the following is optional,
                       ; and MAY occur more than once

                       / (";" xparam)

                       ; The value is the UPN of the requested
                       ; identity. If not supplied it is a request
                       ; to return to the original authenticated identity.

                       / option-param upn

                       )
[Snip, snip]
      And for the CUA to return to its original authenticated identity
     the OPTIONS parameter is omitted:

Alas the ABNF does NOT accurately reflect that option-param is truely optional.  For this the line needs to be changed to the following to allow what the cited text above suggests:

                        ; The value is the UPN of the requested
                       ; identity. If not supplied it is a request
                       ; to return to the original authenticated identity.

                       / [ option-param ] upn
Lastly, the behaviour for when an IDENTITY fails is unclear.  The text simply says:

   If they do, the session assumes the new identity,
  otherwise a security error is returned.
but does not expressly indicate that the original (or previous) identity is to be resumed.  It could be that more than one IDENTITY command has been issued with some that worked.  As such its unclear if the failure results in the last 'confirmed' or allowed identity to be used or if the original authentication identity is to be restored.  I dont care either way, I just want consistant behaviour.

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 00831DDB85256C69_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 19:19:51 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18009 for ; Wed, 6 Nov 2002 19:19:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA704ki13527 for ietf-calendar-bks; Wed, 6 Nov 2002 16:04:46 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA704fv13519 for ; Wed, 6 Nov 2002 16:04:41 -0800 (PST) To: ietf-calendar@imc.org Subject: ABNF for option-param/cmd-specific MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Nov 2002 19:04:35 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/06/2002 07:04:49 PM, Serialize complete at 11/06/2002 07:04:49 PM Content-Type: multipart/alternative; boundary="=_alternative 000086EC85256C6A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000086EC85256C6A_= Content-Type: text/plain; charset="US-ASCII" The ABNF for option-param is malformed IMHNO. It is currently: option-param = ";" "OPTIONS" "=" cmd-specific cmd-specific = ; The value supplied is dependent on the ; CMD value. See the specific CMDs below ; for the correct values to use for each ; CMD Problem #1: There are NO subsequent defintions of any CMD specific values. They should be under each command in an ABNF form of: cmd-specific /= "BLECH" | "YAWN" ; The IDENTITY value "BLECH" means you want to ; become an Anonymous CU. "YAWN" means you do not ; wish to assume any particular identity.... utlizing the '/=' notation from the ABNF RFC. Go see the partstatparam in 2445 if you need more help here. Problem #2: There is no way to differentiate between option-param (as defined) and anything that follows after it. For example: deleteparam = *( [Snip] / option-param "MARK" or identifyparam = *( [Snip] ; The value is the UPN of the requested ; identity. If not supplied it is a request ; to return to the original authenticated identity. / option-param upn upn = "@" / [ dot-atom-text ] "@" dot-atom-text ; dot-atom-text is defined in RFC 2822 [The upn ABNF is inserted simply as reference for analysis] So in a DELETE, how does one delimit where the "cmd-specific" value ends and the "MARK" begins? There needs to be some kind of delimiter between them. The same goes for the IDENTITY command, how does one differentiate between the option-param and the upn. >From looking @ the examples (Oh, bad bad man...) it appears that the intent was to make upn the 'cmd-specific' part of the option-param for IDENTITY. That is, in the identifyparam ABNF, 'cmd-specific' is NULL and 'upn' is always there. Hmm, now that I dive more perhaps its just an oversight and the example is bad. The single example is, in part: C: CMD;ID=unique-per-cua-999;OPTIONS=newUserId:IDENTIFY so I would think that cmd-specific would be "newUserId" and that there is _no_ upn part. Thats because "newUserId" does not adhere to the definition of UPN in Section 1.3 where it says that its bascially "User" '@' "Realm"... Im too tired to dive more but it looks as if there is some ABNF cleanup in order (and a fixed example too?)... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 000086EC85256C6A_= Content-Type: text/html; charset="US-ASCII"
The ABNF for option-param is malformed IMHNO.  It is currently:

   option-param     = ";" "OPTIONS" "=" cmd-specific

  cmd-specific     = ; The value supplied is dependent on the
                     ; CMD value. See the specific CMDs below
                     ; for the correct values to use for each
                     ; CMD

Problem #1: There are NO subsequent defintions of any CMD specific values.  They should be under each command in an ABNF form of:

   cmd-specific     /= "BLECH" | "YAWN"
                      ; The IDENTITY value "BLECH" means you want to
                      ; become an Anonymous CU.  "YAWN" means you do not
                      ; wish to assume any particular identity....

utlizing the '/=' notation from the ABNF RFC.  Go see the partstatparam in 2445 if you need more help here.

Problem #2: There is no way to differentiate between option-param (as defined) and anything that follows after it.  For example:

   deleteparam  = *(
[Snip]
                / option-param "MARK"

or

        identifyparam   = *(
[Snip]
                        ; The value is the UPN of the requested
                       ; identity. If not supplied it is a request
                       ; to return to the original authenticated identity.

                       / option-param upn

   upn        = "@"
                   / [ dot-atom-text ] "@" dot-atom-text
                     ; dot-atom-text is defined in RFC 2822

[The upn ABNF is inserted simply as reference for analysis]

So in a DELETE, how does one delimit where the "cmd-specific" value ends and the "MARK" begins?  There needs to be some kind of delimiter between them.  The same goes for the IDENTITY command, how does one differentiate between the option-param and the upn.

From looking @ the examples (Oh, bad bad man...) it appears that the intent was to make upn the 'cmd-specific' part of the option-param for IDENTITY.  That is, in the identifyparam ABNF, 'cmd-specific' is NULL and 'upn' is always there.

Hmm, now that I dive more perhaps its just an oversight and the example is bad.  The single example is, in part:

      C: CMD;ID=unique-per-cua-999;OPTIONS=newUserId:IDENTIFY

so I would think that cmd-specific would be "newUserId" and that there is _no_ upn part.  Thats because "newUserId" does not adhere to the definition of UPN in Section 1.3 where it says that its bascially "User" '@' "Realm"...  Im too tired to dive more but it looks as if there is some ABNF cleanup in order (and a fixed example too?)...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 000086EC85256C6A_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 19:53:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18628 for ; Wed, 6 Nov 2002 19:53:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA70jr715259 for ietf-calendar-bks; Wed, 6 Nov 2002 16:45:53 -0800 (PST) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA70jpv15255 for ; Wed, 6 Nov 2002 16:45:52 -0800 (PST) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id gA70jpj7005178; Thu, 7 Nov 2002 01:45:52 +0100 Date: Thu, 7 Nov 2002 01:45:48 +0100 Subject: Re: What good are stored VQUERYs? Content-Type: multipart/alternative; boundary=Apple-Mail-2-340689924 Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Bruce_Kahn@notesdev.ibm.com From: Andrea Campi In-Reply-To: Message-Id: <41E12C33-F1EA-11D6-A048-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-2-340689924 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Thursday, November 7, 2002, at 12:14 AM, Bruce_Kahn@notesdev.ibm.com=20= wrote: > but I have yet to see what use storing queries can be. =A0After all, I=20= > cannot 'wildcard' or macro expand anything in a query so I cannot=20 > create a stored query for "Find me all events on my calendar for=20 > today" or "What events have alarms that trigger in the next 15=20 > minutes", etc. =A0Each VQUERY that a CUA sends to the CS needs to be=20= > custom built to have the right parameters (ie: dates/times). > > So in the interest of KISS I ask why a CS should (MUST?) store VQUERYs=20= > if they are effectively 'single shot' queries? > > Unless there is a common case that Im just not seeing I would like to=20= > propose that we remove the concept of stored queries entirely. IMHO the best reason to KEEP stored query is precisely what you=20 mention, that is, the absence of parameters. Nowhere in the draft I see anything which implies stored queries MUST=20 translate to CAL-QL; the way I interpret this is, a CS can implement=20 them anyway it wishes. Looking at your example, a CS could expose a stored query named "All=20 events on my calendar for today", with no corresponding CAP-QL. When a=20= CUA executes the query, the CS simply "does the right thing", and=20 retrieves events for today. It's true that this doesn't improve interoperability at all, but it=20 allows matching CUA and CS to do very powerful queries with minimum=20 effort. Now, if we extended CAP-QL to allow parameters in stored query=20 invocation, I'd be even happier. However, allowing the syntax now and=20 building on it later on is better than nothing... Bye, Andrea= --Apple-Mail-2-340689924 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thursday, November 7, 2002, at 12:14 AM, Bruce_Kahn@notesdev.ibm.com wrote: but I have yet to see what use storing queries can be. =A0After all, I cannot 'wildcard' or macro expand anything in a query so I cannot create a stored query for "Find me all events on my calendar for today" or "What events have alarms that trigger in the next 15 minutes", etc. =A0Each VQUERY that a CUA sends to the CS needs to be custom built to have the right parameters (ie: dates/times). So in the interest of KISS I ask why a CS should (MUST?) store VQUERYs if they are effectively 'single shot' queries? Unless there is a common case that Im just not seeing I would like to propose that we remove the concept of stored queries entirely. IMHO the best reason to KEEP stored query is precisely what you mention, that is, the absence of parameters. Nowhere in the draft I see anything which implies stored queries MUST translate to CAL-QL; the way I interpret this is, a CS can implement them anyway it wishes. Looking at your example, a CS could expose a stored query named "All events on my calendar for today", with no corresponding CAP-QL. When a CUA executes the query, the CS simply "does the right thing", and retrieves events for today. It's true that this doesn't improve interoperability at all, but it allows matching CUA and CS to do very powerful queries with minimum effort. Now, if we extended CAP-QL to allow parameters in stored query invocation, I'd be even happier. However, allowing the syntax now and building on it later on is better than nothing... Bye, Andrea= --Apple-Mail-2-340689924-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 19:59:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18724 for ; Wed, 6 Nov 2002 19:59:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA70onX15477 for ietf-calendar-bks; Wed, 6 Nov 2002 16:50:49 -0800 (PST) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA70omv15473 for ; Wed, 6 Nov 2002 16:50:48 -0800 (PST) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id gA70ogaq011822; Thu, 7 Nov 2002 01:50:43 +0100 Date: Thu, 7 Nov 2002 01:50:40 +0100 Subject: Re: 10.4 IDENTIFY Command Content-Type: multipart/alternative; boundary=Apple-Mail-4-340982185 Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Bruce_Kahn@notesdev.ibm.com From: Andrea Campi In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-4-340982185 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Thursday, November 7, 2002, at 12:37 AM, Bruce_Kahn@notesdev.ibm.com=20= wrote: > So, in order for my new AA to be able to assume my identity its not a=20= > matter of her proving it by some (re)authentication mechanism, its an=20= > issue of making sure my CS is configured w/this information somehow=20 > (the actual mechanism appears to be TBD). =A0Unfortunately since we = have=20 > no Administrative kinds of features like this spec'd in CAP 1.0 (at=20 > least not that Ive found yet) isnt this a kind of chicken and egg=20 > problem that will bite us in the butt at our first CAP interop??=20 > =A0There has to be a better way.... > Sorry but I don't get your point. After all, we do use SASL, so we have=20= separate autentication and authorization information available.=20 Administration and storage of AAA is out of scope; everybody is free to=20= keep the info in whatever kind of store they prefer. Again, probably I'm not understanding what you're worried about... Bye, Andrea --Apple-Mail-4-340982185 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thursday, November 7, 2002, at 12:37 AM, Bruce_Kahn@notesdev.ibm.com wrote: So, in order for my new AA to be able to assume my identity its not a matter of her proving it by some (re)authentication mechanism, its an issue of making sure my CS is configured w/this information somehow (the actual mechanism appears to be TBD). =A0Unfortunately since we have no Administrative kinds of features like this spec'd in CAP 1.0 (at least not that Ive found yet) isnt this a kind of chicken and egg problem that will bite us in the butt at our first CAP interop?? =A0There has to be a better way.... Sorry but I don't get your point. After all, we do use SASL, so we have separate autentication and authorization information available. Administration and storage of AAA is out of scope; everybody is free to keep the info in whatever kind of store they prefer. Again, probably I'm not understanding what you're worried about...=20 Bye, Andrea --Apple-Mail-4-340982185-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 20:12:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19028 for ; Wed, 6 Nov 2002 20:12:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA716dM16175 for ietf-calendar-bks; Wed, 6 Nov 2002 17:06:39 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA716bv16171 for ; Wed, 6 Nov 2002 17:06:37 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA716eIR004851 for ; Wed, 6 Nov 2002 17:06:40 -0800 Message-ID: <3DC9BC9D.6010108@Royer.com> Date: Wed, 06 Nov 2002 18:06:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020605090300050403030802" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020605090300050403030802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > [Snip, snip] > And for the CUA to return to its original authenticated identity > the OPTIONS parameter is omitted: > > Alas the ABNF does NOT accurately reflect that option-param is truely > optional. For this the line needs to be changed to the following to > allow what the cited text above suggests: > > ; The value is the UPN of the requested > ; identity. If not supplied it is a request > ; to return to the original authenticated identity. > > / [ option-param ] upn Your right there is an error, however it would be: ; The value is the UPN of the requested ; identity. If not supplied it is a request ; to return to the original authenticated identity. ; The following MUST occur exactly once and only ; when the CU wished to change to another UPN. ; The following would not be supplied if the ; CU wished to switch to their original identity. / option-param upn Your ABNF would make it: CMDnew-upn-id:IDENTITY Where it should be this to ask to switch back to your original identity: CMD:IDENTITY Or to ask to switch to another identity: CMD;OPTIONS=new-upn-id:IDENTITY > Lastly, the behaviour for when an IDENTITY fails is unclear. The text > simply says: > > If they do, the session assumes the new identity, > otherwise a security error is returned. > > but does not expressly indicate that the original (or previous) identity > is to be resumed. It could be that more than one IDENTITY command has > been issued with some that worked. Please point to the section of CAP that says that you can send more than one IDENTITY command at a time. Or please point to the section of CAP that says you can send more than one CMD at a time. > As such its unclear if the failure > results in the last 'confirmed' or allowed identity to be used or if the > original authentication identity is to be restored. I dont care either > way, I just want consistant behaviour. What does 'otherwise' mean to you? -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms020605090300050403030802 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNzAxMDYzN1owIwYJKoZIhvcNAQkEMRYEFK0uD+w9 +k6u4uZIPWbqnhIawkfpMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCDUzGVP7qrSGNZi3fP +ZH2U3Jhce+YrRJkzMdW2tk81FyGOQeO/LzIdtaLqj4n/4VYA/A3bMMk8NMGSOrmp+ONydvT QK9ZAVWsF5R0mjj2MAN8VE0zJzuy9qThNk20SREwiOZ/RX21ePHdijou0kAR1HQTExvYT+8x 7p3V8jJJ4q8GC9W4DpH097suAynxYSl223oTEZ8VSr/0kbu4LNcK2DjeMZToyFZDirR1wazN fk2DTEFRLcLyoG2+179SHbSPggzdqBf9kIi1umttPu/3+4fRNAuabafxU6Ula27QPCn7grxV GVyUTjepMRpFFinoZUImSlRgiUEDty/oYMbkAAAAAAAA --------------ms020605090300050403030802-- From owner-ietf-calendar@mail.imc.org Wed Nov 6 20:21:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19112 for ; Wed, 6 Nov 2002 20:21:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA71Fwh16555 for ietf-calendar-bks; Wed, 6 Nov 2002 17:15:58 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA71Fuv16551 for ; Wed, 6 Nov 2002 17:15:56 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gA71FxIR004930 for ; Wed, 6 Nov 2002 17:15:59 -0800 Message-ID: <3DC9BECC.9010300@Royer.com> Date: Wed, 06 Nov 2002 18:15:56 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060308010400090107000806" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060308010400090107000806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In trying to match earlier issues w/the latest draft I ran across this > one. The 09-submitted draft says: > > The CS determines through an internal mechanism if the credentials > supplied at authentication permit the operation as the selected > identity. > > and this implys that whatever credentials (UPN??) I originally > authenticate with determines if I can change my identity later on AND to > which identities I can change to. This seems a bit restrictive as it > basically puts the onus on the CS implementors to know in a priori not > only what identities can authenticate w/the CS but also what identities > they can assume. Just curious, do you feel the the CS should ask the CUA if the user has permission? Or are you saying that the CS should not do it internally? > So, in order for my new AA to be able to assume my identity its not a > matter of her proving it by some (re)authentication mechanism, its an > issue of making sure my CS is configured w/this information somehow (the > actual mechanism appears to be TBD). Unfortunately since we have no > Administrative kinds of features like this spec'd in CAP 1.0 (at least > not that Ive found yet) isnt this a kind of chicken and egg problem that > will bite us in the butt at our first CAP interop?? There has to be a > better way.... Do you have a proposal that will allow one CUA to inform a CS 'trust me' I have permission? -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms060308010400090107000806 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEwNzAxMTU1NlowIwYJKoZIhvcNAQkEMRYEFAZ4V1Kv 5m013OsKRPQpdQPOTuB+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBos4x5+E7K9Ph2D7FY 1WQyP208AMcrG34Y7x1fr3ay0t+imoy/3T0B+W1Ish3RyQp0LgWxVuSKhomoAeO9jW/cHwyK 2Ss9dpWIZgs1s/vrREEAz8zQlNNrMnE9v022joUiQP4gMfCLcDEa9CevH3qDffO+BnvUScge DogQwZaCXfO3H8Igt+MFw1yp/Lx5HJ0v3PQH13Rrxv84TAXyKkEWM1xM5AaUy812P0JdxcID 538xK4FplMN8fP9756ISz2U0xcDKQSwpbPqKN9gIKBpYiEaBHh/r1phzP8MhRZbnenU6fbJx /CcuwEBUXmaa5W6KYd1J82KfXXTSf4YV65dcAAAAAAAA --------------ms060308010400090107000806-- From owner-ietf-calendar@mail.imc.org Thu Nov 7 06:44:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12597 for ; Thu, 7 Nov 2002 06:44:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7BN1b13557 for ietf-calendar-bks; Thu, 7 Nov 2002 03:23:01 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7BN0v13553 for ; Thu, 7 Nov 2002 03:23:00 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10045; Thu, 7 Nov 2002 06:20:30 -0500 (EST) Message-Id: <200211071120.GAA10045@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cap-09.txt Date: Thu, 07 Nov 2002 06:20:30 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Calendar Access Protocol (CAP) Author(s) : D. Royer, G. Babics, P. Hill, S. Mansour Filename : draft-ietf-calsch-cap-09.txt Pages : 137 Date : 2002-11-6 The Calendar Access Protocol (CAP) is an Internet protocol described in this memo that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). The CAP definition is based on requirements identified by the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) Working Group. More information about the IETF CALSCH Working Group activities can be found on the IMC web site at http:// www.imc.org/ietf-calendar and at the IETF web site at http:// www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the references within this memo for further information on how to access these various documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-09.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-ietf-calsch-cap-09.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-ietf-calsch-cap-09.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-6173814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6173814.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Thu Nov 7 15:47:17 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11580 for ; Thu, 7 Nov 2002 15:47:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7KdS125266 for ietf-calendar-bks; Thu, 7 Nov 2002 12:39:28 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7KEcv22109; Thu, 7 Nov 2002 12:14:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; Subject: Note Well Statement x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-ietf-calendar@mail.imc.org Thu Nov 7 21:55:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22555 for ; Thu, 7 Nov 2002 21:55:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA82ivT15053 for ietf-calendar-bks; Thu, 7 Nov 2002 18:44:57 -0800 (PST) Received: from server1.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA82itv15045 for ; Thu, 7 Nov 2002 18:44:55 -0800 (PST) Subject: Remote access to the CALSCH meeting in Atlanta To: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 7 Nov 2002 21:44:57 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 11/07/2002 09:45:00 PM 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: This time, the IETF is offering a neat way to participate on the meeting without being in Atlanta. The text below shows how to gain access. Our room is called CALSCH. The text was prepared by Marshal Rose. Remote Access for the 55th IETF meeting in Atlanta: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: testing Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. If you don't have a server available, email your presentation to To: presentations@ietf.org Subject: foobar and the Secretariat will put the presentation in a server so it can be accessed under: http://atlanta.ietf.org/presentations/foobar/ Don't wait until the last minute to send the email. 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ 2.5. Finally This is an experiment. Let's see how well it works and discuss it after the meeting. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 From owner-ietf-calendar@mail.imc.org Fri Nov 8 09:06:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19225 for ; Fri, 8 Nov 2002 09:06:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8E01o18934 for ietf-calendar-bks; Fri, 8 Nov 2002 06:00:01 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8Dxxv18920 for ; Fri, 8 Nov 2002 06:00:00 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id A1BFC1555F; Fri, 8 Nov 2002 14:59:59 +0100 (CET) Date: Fri, 8 Nov 2002 14:59:59 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II Message-ID: <20021108135959.GI44681@inet.it> References: 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.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Nov 06, 2002 at 06:50:58PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > > Lastly, the behaviour for when an IDENTITY fails is unclear. The text > simply says: > > If they do, the session assumes the new identity, > otherwise a security error is returned. By the way, I would like to propose that we change this so that IDENTIFY only affects the channel it is sent on, not the whole session. This would be beneficial for several reasons (such as accessing different targets with different credentials), but above all it would remove ambiguity. Otherwise, if you have ongoing traffic on other channels, what happens? When do the new credentials take effect? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Nov 11 10:34:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22440 for ; Mon, 11 Nov 2002 10:34:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABFDqC22470 for ietf-calendar-bks; Mon, 11 Nov 2002 07:13:52 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABFDpv22465 for ; Mon, 11 Nov 2002 07:13:51 -0800 (PST) In-Reply-To: <20021106100509.GC25132@inet.it> To: ietf-calendar@imc.org Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Nov 2002 10:13:47 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/11/2002 10:13:53 AM, Serialize complete at 11/11/2002 10:13:53 AM Content-Type: multipart/alternative; boundary="=_alternative 0053A91F85256C6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053A91F85256C6E_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 11/06/2002 05:05:09 AM: > Make that: All sides MUST support GET-CAPABILITY, all sides MUST send > it before anything else, NO defaulting of any values. > > I like it. Thats 2 Yes votes so far. I think George would be a Yes vote but I have 500+ msgs to check this AM to be sure. 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 0053A91F85256C6E_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 11/06/2002 05:05:09 AM:
> Make that: All sides MUST support GET-CAPABILITY, all sides MUST send
> it before anything else, NO defaulting of any values.
>
> I like it.

Thats 2 Yes votes so far.  I think George would be a Yes vote but I have 500+ msgs to check this AM to be sure.  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 0053A91F85256C6E_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 10:45:58 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22752 for ; Mon, 11 Nov 2002 10:45:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABFRlx24281 for ietf-calendar-bks; Mon, 11 Nov 2002 07:27:47 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABFRkv24277 for ; Mon, 11 Nov 2002 07:27:46 -0800 (PST) In-Reply-To: <41E12C33-F1EA-11D6-A048-003065A8EEFC@inet.it> To: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Nov 2002 10:27:45 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/11/2002 10:27:48 AM, Serialize complete at 11/11/2002 10:27:48 AM Content-Type: multipart/alternative; boundary="=_alternative 0054F08185256C6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054F08185256C6E_= Content-Type: text/plain; charset="US-ASCII" Andrea responded on 11/06/2002 07:45:48 PM: > > Unless there is a common case that Im just not seeing I would like to > > propose that we remove the concept of stored queries entirely. > > IMHO the best reason to KEEP stored query is precisely what you > mention, that is, the absence of parameters. > Nowhere in the draft I see anything which implies stored queries MUST > translate to CAL-QL; the way I interpret this is, a CS can implement > them anyway it wishes. The actual storage of the query is not the concern here, its the utility of actually storing them in the first place. Since the query has to be encoded in CAP-QL and there is no way to interpret what cannot be encoded in CAP-QL I dont see how a CS can transcode a 'fixed' query into one that means "All events on my calendar for today". Should the CS somehow infer it from the explicit CAP-QL language? > Looking at your example, a CS could expose a stored query named "All > events on my calendar for today", with no corresponding CAP-QL. When a > CUA executes the query, the CS simply "does the right thing", and > retrieves events for today. Here is where Im a bit fuzzy. If there is no way to encode the query in CAP-QL then how is the CUA to send it in the first place?? Oh, are you suggesting that there is some Out-of-band mechanism to place non-CAP-QL encodable queries into the CS and then the CUA just references them? Seems like kind of a wishfull thing given CAP-QL and the robustness of it. Also, there is now way for the CUA to actually pull the VQUERY from the CS to check it or modify it. After all my CUA should be able to check all VQUERYs in the CS so just how would the CS encode the unencodable VQUERY that is stored?? Would the CS just say "Sorry, you cant have that VQUERY!"? I would prefer that we take a simpler approach instead of some assumption and hacks to deal w/your scenario. CAP and iCalendar are complex enough as is. There are 2 possible paths to take here: 1: Extend CAP-QL so that wildcarding is possible OR 2: Remove the concept of stored VQUERYs I dont say remove named VQUERYs since I can have more than 1 VQUERY 'in use' at any given time. Im just for simplifying the model a bit. If there is strong enough desire for #1 then some new ABNF and prose is in order and then we can discuss the impact of that change. We may also need a way for the CS to respond "I dont support query storage" in GET-CAPABILITY for those more lightweight CS's (a comment I posted a year or so ago I think). > It's true that this doesn't improve interoperability at all, but it > allows matching CUA and CS to do very powerful queries with minimum > effort. But CAP-QL was supposed to be so rich that we could craft any query in it. (Ok a bit of sarcasm on a Monday AM...) > Now, if we extended CAP-QL to allow parameters in stored query > invocation, I'd be even happier. However, allowing the syntax now and > building on it later on is better than nothing... Care to propose the new ABNF and prose then? 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 0054F08185256C6E_= Content-Type: text/html; charset="US-ASCII"
Andrea responded on 11/06/2002 07:45:48 PM:
> > Unless there is a common case that Im just not seeing I would like to
> > propose that we remove the concept of stored queries entirely.
>
> IMHO the best reason to KEEP stored query is precisely what you
> mention, that is, the absence of parameters.
> Nowhere in the draft I see anything which implies stored queries MUST
> translate to CAL-QL; the way I interpret this is, a CS can implement
> them anyway it wishes.
The actual storage of the query is not the concern here, its the utility of actually storing them in the first place.

Since the query has to be encoded in CAP-QL and there is no way to interpret what cannot be encoded in CAP-QL I dont see how a CS can transcode a 'fixed' query into one that means "All events on my calendar for today".   Should the CS somehow infer it from the explicit CAP-QL language?

> Looking at your example, a CS could expose a stored query named "All
> events on my calendar for today", with no corresponding CAP-QL. When a
> CUA executes the query, the CS simply "does the right thing", and
> retrieves events for today.
Here is where Im a bit fuzzy.  If there is no way to encode the query in CAP-QL then how is the CUA to send it in the first place??

Oh, are you suggesting that there is some Out-of-band mechanism to place non-CAP-QL encodable queries into the CS and then the CUA just references them?  Seems like kind of a wishfull thing given CAP-QL and the robustness of it.  

Also, there is now way for the CUA to actually pull the VQUERY from the CS to check it or modify it.  After all my CUA should be able to check all VQUERYs in the CS so just how would the CS encode the unencodable VQUERY that is stored??  Would the CS just say "Sorry, you cant have that VQUERY!"?

I would prefer that we take a simpler approach instead of some assumption and hacks to deal w/your scenario.  CAP and iCalendar are complex enough as is.  There are 2 possible paths to take here:

1: Extend CAP-QL so that wildcarding is possible OR
2: Remove the concept of stored VQUERYs

I dont say remove named VQUERYs since I can have more than 1 VQUERY 'in use' at any given time.  

Im just for simplifying the model a bit.  If there is strong enough desire for #1 then some new ABNF and prose is in order and then we can discuss the impact of that change.  We may also need a way for the CS to respond "I dont support query storage" in GET-CAPABILITY for those more lightweight CS's (a comment I posted a year or so ago I think).

> It's true that this doesn't improve interoperability at all, but it
> allows matching CUA and CS to do very powerful queries with minimum
> effort.
But CAP-QL was supposed to be so rich that we could craft any query in it. (Ok a bit of sarcasm on a Monday AM...)

> Now, if we extended CAP-QL to allow parameters in stored query
> invocation, I'd be even happier. However, allowing the syntax now and
> building on it later on is better than nothing...
Care to propose the new ABNF and prose then?

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 0054F08185256C6E_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 11:58:12 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24730 for ; Mon, 11 Nov 2002 11:58:12 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABGpAZ07752 for ietf-calendar-bks; Mon, 11 Nov 2002 08:51:10 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABGp6v07726 for ; Mon, 11 Nov 2002 08:51:10 -0800 (PST) In-Reply-To: <3DC9BECC.9010300@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Nov 2002 11:15:01 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/11/2002 11:51:12 AM, Serialize complete at 11/11/2002 11:51:12 AM Content-Type: multipart/alternative; boundary="=_alternative 0059442F85256C6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059442F85256C6E_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/06/2002 08:15:56 PM: > Just curious, do you feel the the CS should ask the CUA if the > user has permission? Or are you saying that the CS should not > do it internally? I think that we have a disjoin in our design WRT IDENTIFY. The CU can configure the CUA w/a list of identities to try and switch to but the CS has the final authority over allowing or disallowing the actualy IDENTIFY command to succeed or not. As such I think that there should be some way for the CUA to get the list of 'alternate' or assumable identities from the CS. Otherwise my CUA just has to take the list its configured w/and try to see if the CS will allow the change. Its possible that the list of, say, 20 alternate identities my AA has (she's also the team AA) does not jive w/the CS's derived list of allowable identities. So her CUA just keeps going "I want to change my identity to UPN2", "I want to change my identity to UPN3", etc. It would be MUCH simpler if the CUA had a way to get the list from the CS. That way it could cut down on extra network traffic AND it could do something nice in the UI like indicate "You are not authorized to assume UPN3 and UPN6 that you have configured." At one point early on in CAP we had the design that the CS would return back the 'primary' UPN that the CUA was assuming and we had discussed the possibility of sending back the list of alternate UPNs. It seems to me that this never got resolved (I didnt check, I have 500+ msgs to wade thru still) but I think we should do it. If not at authentication time (not everyone will change identities) then via a command of some kind. > Do you have a proposal that will allow one CUA to inform a CS > 'trust me' I have permission? You misread my concern. I think the CUA should have a way to get the list of allowable identities from the CS, not push a list to the CS. That would be "administration" stuff and not something on the list of discussable topics for 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 0059442F85256C6E_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/06/2002 08:15:56 PM:
> Just curious, do you feel the the CS should ask the CUA if the
> user has permission? Or are you saying that the CS should not
> do it internally?
I think that we have a disjoin in our design WRT IDENTIFY.  The CU can configure the CUA w/a list of identities to try and switch to but the CS has the final authority over allowing or disallowing the actualy IDENTIFY command to succeed or not.  As such I think that there should be some way for the CUA to get the list of 'alternate' or assumable identities from the CS.

Otherwise my CUA just has to take the list its configured w/and try to see if the CS will allow the change.  Its possible that the list of, say, 20 alternate identities my AA has (she's also the team AA) does not jive w/the CS's derived list of allowable identities.  So her CUA just keeps going "I want to change my identity to UPN2", "I want to change my identity to UPN3", etc.  

It would be MUCH simpler if the CUA had a way to get the list from the CS.  That way it could cut down on extra network traffic AND it could do something nice in the UI like indicate "You are not authorized to assume UPN3 and UPN6 that you have configured."

At one point early on in CAP we had the design that the CS would return back the 'primary' UPN that the CUA was assuming and we had discussed the possibility of sending back the list of alternate UPNs.  It seems to me that this never got resolved (I didnt check, I have 500+ msgs to wade thru still) but I think we should do it.  If not at authentication time (not everyone will change identities) then via a command of some kind.

> Do you have a proposal that will allow one CUA to inform a CS
> 'trust me' I have permission?
You misread my concern.  I think the CUA should have a way to get the list of allowable identities from the CS, not push a list to the CS.  That would be "administration" stuff and not something on the list of discussable topics for 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 0059442F85256C6E_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 11:58:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24756 for ; Mon, 11 Nov 2002 11:58:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABGp7n07737 for ietf-calendar-bks; Mon, 11 Nov 2002 08:51:07 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABGp6v07725 for ; Mon, 11 Nov 2002 08:51:06 -0800 (PST) In-Reply-To: To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Nov 2002 11:05:03 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/11/2002 11:51:09 AM, Serialize complete at 11/11/2002 11:51:09 AM Content-Type: multipart/alternative; boundary="=_alternative 00585AAC85256C6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00585AAC85256C6E_= Content-Type: text/plain; charset="US-ASCII" Andrea Campi wrote on 11/06/2002 07:50:40 PM: > Sorry but I don't get your point. After all, we do use SASL, so we have > separate autentication and authorization information available. Yes we do but we do not have any clear way to get that information to the CUA. That is, there is no clear proscribed way for the CUA to "discover" what credentials they may use as inputs for the IDENTIFY command. A long time ago a suggestion was made about resolving this disjoin. One suggestion was to have the CS always return the UPN and other identities (UPNs) that were assumable when the CUA authenticated. Another was to have some command that a CUA could use to query "What other identities can I assume based on my authenticated credentials?" in case they actually wanted to do it (Most non-AA types wont really need to do it really). I dont think either got any WG discussion. I just find it somewhat cumbersome to provide a command to change UPNs but we have no clear and interoperable way to get them from the CS. After all the CS uses some undefined voodoo to decide if I can change my identity so the CUA must either play Marco Polo to figure out what I can actually change my identity to (even if my CUA were given the list by the CU in some dialog, the CS does not necessarily agree w/that list!) OR I just have to expect that some OOB mechanism is in play to make sure that whatever my AA configures her CUA with is also configured on the CS... > Again, probably I'm not understanding what you're worried about... Does this make it clearer? 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 00585AAC85256C6E_= Content-Type: text/html; charset="US-ASCII"
Andrea Campi wrote on 11/06/2002 07:50:40 PM:
> Sorry but I don't get your point. After all, we do use SASL, so we have
> separate autentication and authorization information available.

Yes we do but we do not have any clear way to get that information to the CUA.  That is, there is no clear proscribed way for the CUA to "discover" what credentials they may use as inputs for the IDENTIFY command.  A long time ago a suggestion was made about resolving this disjoin.

One suggestion was to have the CS always return the UPN and other identities (UPNs) that were assumable when the CUA authenticated.  Another was to have some command that a CUA could use to query "What other identities can I assume based on my authenticated credentials?" in case they actually wanted to do it (Most non-AA types wont really need to do it really).  I dont think either got any WG discussion.

I just find it somewhat cumbersome to provide a command to change UPNs but we have no clear and interoperable way to get them from the CS.  After all the CS uses some undefined voodoo to decide if I can change my identity so the CUA must either play Marco Polo to figure out what I can actually change my identity to (even if my CUA were given the list by the CU in some dialog, the CS does not necessarily agree w/that list!) OR I just have to expect that some OOB mechanism is in play to make sure that whatever my AA configures her CUA with is also configured on the CS...

> Again, probably I'm not understanding what you're worried about...
Does this make it clearer?

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 00585AAC85256C6E_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 12:01:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24860 for ; Mon, 11 Nov 2002 12:01:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABGp8r07741 for ietf-calendar-bks; Mon, 11 Nov 2002 08:51:08 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABGp7v07731 for ; Mon, 11 Nov 2002 08:51:07 -0800 (PST) In-Reply-To: <3DC9BC9D.6010108@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Nov 2002 11:45:36 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/11/2002 11:51:09 AM, Serialize complete at 11/11/2002 11:51:09 AM Content-Type: multipart/alternative; boundary="=_alternative 005C111985256C6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C111985256C6E_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/06/2002 08:06:37 PM: > Your right there is an error, however it would be: > > ; The value is the UPN of the requested > ; identity. If not supplied it is a request > ; to return to the original authenticated identity. > ; The following MUST occur exactly once and only > ; when the CU wished to change to another UPN. > ; The following would not be supplied if the > ; CU wished to switch to their original identity. > > / option-param upn This newer ABNF does NOT make it clear that option-param AND the related UPN are either MUST or not at all (to get that "CU wished to switch to their original identity.") You need to make that entire line a "0 or 1" instance then. The comment in the ABNF does not transcode to the actual ABNF thats verifiable otherwise. > Your ABNF would make it: > > CMDnew-upn-id:IDENTITY A related change I posted was that there is NO cmd-specific for any commands. The UPN in this case _is_ that cmd-specific and it should be noted as such (see other thread). As such, the UPN _could_not_ appear as you suggested since its the cmd-specific of the IDENTIFY command. Mea culpa for not linking the two in this post, sorry. > Where it should be this to ask to switch back to your original identity: > > CMD:IDENTITY > > Or to ask to switch to another identity: > > CMD;OPTIONS=new-upn-id:IDENTITY This is not a valid example as the new-upn-id is NOT valid per the definition of allowable UPNs in 1.3 Definitions: User Principal Name (UPN) - A unique identifier that denotes a CU or a group of CU. A UPN is a RFC 822 compliant email address, with exceptions listed below, and in most cases it is deliverable to the CU. In some cases it is identical to the CU's well known email address. A CU's UPN MUST never be an e-mail address that is deliverable to a different person as there is no requirement that a person's UPN MUST BE their e-mail address. A UPN is formatted as a user name followed by "@" followed by a Realm in the form of a valid, and unique, DNS domain name. The user name MUST BE unique within the Realm. In it's simplest form it looks like "user@example.com". In certain cases a UPN will not be RFC 822 compliant. When anonymous authentication is used, or anonymous authorization is being defined, the special UPN "@" will be used. When authentication MUST BE used, but unique identity MUST BE obscured, a UPN of the form @DNS-domain-name may be used. For example, "@example.com". The example used is just the username part of the UPN and not the full UPN. Please make sure all examples have properly formed UPNs in the draft for those that only code by example... > > Lastly, the behaviour for when an IDENTITY fails is unclear. The text > > simply says: > > > > If they do, the session assumes the new identity, > > otherwise a security error is returned. > > > > but does not expressly indicate that the original (or previous) identity > > is to be resumed. It could be that more than one IDENTITY command has > > been issued with some that worked. > > Please point to the section of CAP that says that you can > send more than one IDENTITY command at a time. 1: I can pipleine several commands at a time so its perfectly valid (and probably a good way to attack a CS) to send > 1 IDENTIFY (not IDENTITY) command at a time. 2: I did not say I sent them _concurrently_. My groups AA may need to change identities often based on requests from people in my group (as well as having to do her own C&S). No place in the draft does it say that a CU MUST change back to their initial identity before changing into another so its perfectly valid for her to change from herself to my boss and then to me and then to another person. My point is that its 100% unspecified what identity is 'active' if an IDENTIFY fails! Does it revert to the last one that was in use? To the initial one? None? Flip a coin and pick one??... > Or please > point to the section of CAP that says you can send more than > one CMD at a time. Thats the purpose of the id-param, so you can pipeline cmds and be able to match responses to multiple concurrent commands (among other things): id-param = ";" "ID" "=" unique-id ; The text value supplied is a unique value ; shared between the CUA and CS to uniquely ; identify the instance of command in the ; the current CUA session. The value has ; no meaning to other CUAs or other sessions. > > As such its unclear if the failure > > results in the last 'confirmed' or allowed identity to be used or if the > > original authentication identity is to be restored. I dont care either > > way, I just want consistant behaviour. > > What does 'otherwise' mean to you? The full sentence is: If they do, the session assumes the new identity, otherwise a security error is returned. So the CUA knows that it was rejected, that part I grok. It does not know what identity if is now effectively using though. Or did I just overlook that part? CAP should expressly declare what identity the CUA now is using on a failure besides just saying the CS rejects it. None? The last accepted one (in the AA case above...)? The original one? Anonymous? In order to properly make different CUAs and CSs interoperate CAP should be clear on this point. Making an assumption is a BAD idea... 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 005C111985256C6E_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/06/2002 08:06:37 PM:
> Your right there is an error, however it would be:
>    
>                     ; The value is the UPN of the requested
>                     ; identity. If not supplied it is a request
>                     ; to return to the original authenticated identity.
>                     ; The following MUST occur exactly once and only
>                     ; when the CU wished to change to another UPN.
>                     ; The following would not be supplied if the
>                     ; CU wished to switch to their original identity.
>
>                     /  option-param upn
This newer ABNF does NOT make it clear that option-param AND the related UPN are either MUST or not at all (to get that "CU wished to switch to their original identity.")  You need to make that entire line a "0 or 1" instance then.  The comment in the ABNF does not transcode to the actual ABNF thats verifiable otherwise.

> Your ABNF would make it:
>
>       CMDnew-upn-id:IDENTITY
A related change I posted was that there is NO cmd-specific for any commands.  The UPN in this case _is_ that cmd-specific and it should be noted as such (see other thread).  As such, the UPN _could_not_ appear as you suggested since its the cmd-specific of the IDENTIFY command.  Mea culpa for not linking the two in this post, sorry.

> Where it should be this to ask to switch back to your original identity:
>
>       CMD:IDENTITY
>
> Or to ask to switch to another identity:
>
>       CMD;OPTIONS=new-upn-id:IDENTITY
<SIDENOTE>
This is not a valid example as the new-upn-id is NOT valid per the definition of allowable UPNs in 1.3 Definitions:

   User Principal Name (UPN) -  A unique identifier that denotes a CU or
     a group of CU.  A UPN is a RFC 822 compliant email address, with
     exceptions listed below, and in most cases it is deliverable to
     the CU.  In some cases it is identical to the CU's well known
     email address.  A CU's UPN MUST never be an e-mail address that is
     deliverable to a different person as there is no requirement that
     a person's UPN MUST BE their e-mail address.  A UPN is formatted
     as a user name followed by "@" followed by a Realm in the form of
     a valid, and unique, DNS domain name.  The user name MUST BE
     unique within the Realm.  In  it's simplest form it looks like
     "user@example.com".

     In certain cases a UPN will not be RFC 822 compliant.  When
     anonymous authentication is used, or anonymous authorization is
     being defined, the special UPN "@" will be used.  When
     authentication MUST BE used, but unique identity MUST BE obscured,
     a UPN of the form @DNS-domain-name may be used.  For example,
     "@example.com".

The example used is just the username part of the UPN and not the full UPN.  Please make sure all examples have properly formed UPNs in the draft for those that only code by example...
</SIDENOTE>

> > Lastly, the behaviour for when an IDENTITY fails is unclear.  The text
> > simply says:
> >
> >    If they do, the session assumes the new identity,
> >   otherwise a security error is returned.
> >
> > but does not expressly indicate that the original (or previous) identity
> > is to be resumed.  It could be that more than one IDENTITY command has
> > been issued with some that worked.
>
> Please point to the section of CAP that says that you can
> send more than one IDENTITY command at a time.

1: I can pipleine several commands at a time so its perfectly valid (and probably a good way to attack a CS) to send > 1 IDENTIFY (not IDENTITY) command at a time.

2: I did not say I sent them _concurrently_.  My groups AA may need to change identities often based on requests from people in my group (as well as having to do her own C&S).  No place in the draft does it say that a CU MUST change back to their initial identity before changing into another so its perfectly valid for her to change from herself to my boss and then to me and then to another person.

My point is that its 100% unspecified what identity is 'active' if an IDENTIFY fails!  Does it revert to the last one that was in use?  To the initial one?  None? Flip a coin and pick one??...

>                                                  Or please
> point to the section of CAP that says you can send more than
> one CMD at a time.
Thats the purpose of the id-param, so you can pipeline cmds and be able to match responses to multiple concurrent commands (among other things):

   id-param         = ";" "ID" "=" unique-id
                   ; The text value supplied is a unique value
                   ; shared between the CUA and CS to uniquely
                   ; identify the instance of command in the
                   ; the current CUA session. The value has
                   ; no meaning to other CUAs or other sessions.
> > As such its unclear if the failure
> > results in the last 'confirmed' or allowed identity to be used or if the
> > original authentication identity is to be restored.  I dont care either
> > way, I just want consistant behaviour.
>
> What does 'otherwise' mean to you?
The full sentence is:

           If they do, the session assumes the new identity,
  otherwise a security error is returned.

So the CUA knows that it was rejected, that part I grok.  It does not know what identity if is now effectively using though.  Or did I just overlook that part?  

CAP should expressly declare what identity the CUA now is using on a failure besides just saying the CS rejects it.  None?  The last accepted one (in the AA case above...)?  The original one?   Anonymous?  In order to properly make different CUAs and CSs interoperate CAP should be clear on this point.  Making an assumption is a BAD idea...

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 005C111985256C6E_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 13:02:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26177 for ; Mon, 11 Nov 2002 13:02:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABHtCD13570 for ietf-calendar-bks; Mon, 11 Nov 2002 09:55:12 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABHtAg13561 for ; Mon, 11 Nov 2002 09:55:11 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP: Cleanly disconnecting MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Nov 2002 12:54:11 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/11/2002 12:55:14 PM, Serialize complete at 11/11/2002 12:55:14 PM Content-Type: multipart/alternative; boundary="=_alternative 0062587785256C6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0062587785256C6E_= Content-Type: text/plain; charset="US-ASCII" In the latest CAP draft I notice that there is still no command to allow a CUA to cleanly disconnect from the CAP server. This issue was raised a long time ago (pre-BEEP) and Im not BEEP proficient enough to tell if there is some clean disconnect mechanism in BEEP that can be utilizied by the CS to detect clean disconnects from 'unclean' ones. In the past it was claimed that it was not necessary but I think that there is no reason NOT to have one since it will allow for a CS to better do resource management and logging of issues like link drops, etc. After all there is a distinction between "Network connection lost" for every use all the time and "User UPN1 disconnected at 10:13:52 EST from IP xxx.xxx.xxx.xxx" and "Network connection for UPN1 timed out". The latter is a failure, the former is is not. Is there any reason we dont have or need a "BYE" or "DISCONNECT" command in CAP? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0062587785256C6E_= Content-Type: text/html; charset="US-ASCII"
In the latest CAP draft I notice that there is still no command to allow a CUA to cleanly disconnect from the CAP server.

This issue was raised a long time ago (pre-BEEP) and Im not BEEP proficient enough to tell if there is some clean disconnect mechanism in BEEP that can be utilizied by the CS to detect clean disconnects from 'unclean' ones.

In the past it was claimed that it was not necessary but I think that there is no reason NOT to have one since it will allow for a CS to better do resource management and logging of issues like link drops, etc.  After all there is a distinction between "Network connection lost" for every use all the time and "User UPN1 disconnected at 10:13:52 EST from IP xxx.xxx.xxx.xxx" and "Network connection for UPN1 timed out".  The latter is a failure, the former is is not.

Is there any reason we dont have or need a "BYE" or "DISCONNECT" command in CAP?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0062587785256C6E_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 13:42:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27164 for ; Mon, 11 Nov 2002 13:42:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABIVip14989 for ietf-calendar-bks; Mon, 11 Nov 2002 10:31:44 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABIVhg14985 for ; Mon, 11 Nov 2002 10:31:43 -0800 (PST) In-Reply-To: <20021108135959.GI44681@inet.it> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Nov 2002 13:31:41 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/11/2002 01:31:46 PM, Serialize complete at 11/11/2002 01:31:46 PM Content-Type: multipart/alternative; boundary="=_alternative 0065C74C85256C6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065C74C85256C6E_= Content-Type: text/plain; charset="US-ASCII" Andrea Campi wrote on 11/08/2002 08:59:59 AM: > By the way, I would like to propose that we change this so that > IDENTIFY only affects the channel it is sent on, not the whole session. Are you talking about a BEEP session or a CAP session? It sounds as if you are referring to the BEEP session since currently a CAP session is just a BEEP channel: CAP Session - An open communication channel between a CUA and a Calendar Server. If the CAP session is authenticated, the CU is "authenticated" and it is an "authenticated CAP session". so establishing another BEEP channel would cause a new CAP session to be created on the current BEEP session. This does not sound to be too expensive to do say compared to creating the actual BEEP session... Actually the definition does not expressly say its a "BEEP channel" between the CUA and CS so this could be read as a being a single network connection ala TCPIP socket connection. Is it an incorrect assumption to read "BEEP session" or "BEEP channel" in place of "communcation channel"? If so, whats the linkage between "communication channel" and CAP/BEEP? If not, can we clean up the text a bit here? If you are referring to a CAP session instead of a BEEP session then don't read further as Im basing the rest on this assumption. Do we want to add the complexity of multiple identities per CAP session/BEEP channel? Why wouldn't we just use a new BEEP channel to establish a new CAP session? That way any failure would result in that channel being closed instead of all CAP sessions/BEEP channels. Along the same lines of thought, which session is this text referring to: IDENTIFY - Set a new identity for the session. Initiated by the CUA only. (Section 10.4) I assume its a CAP session (aka BEEP channel) but its not clear. Doug? There is some text about terminating the BEEP session instead of the CAP session that directly relates to your response: If a CS considers the "IDENTIFY" command an attempt to violate security, the CS MAY terminate the BEEP session without any further notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. In this case it expressly states that its the BEEP session in question rather than the CAP session. Being a BEEP novice Im not sure if its proper/safe to use the two terms interchangably. Perhaps Marshal can help out here... This text makes the CS drop all the CAP sessions if the IDENTIFY command fails on any CAP session/BEEP channel. Kind of a harsh response to a single failure at least in my mind. This is appropriate for DOS attacks or stopping hacking but its a bit strong for the simple case where the CS and CUA disagree on what identities an AA can actually assume. 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 0065C74C85256C6E_= Content-Type: text/html; charset="US-ASCII"
Andrea Campi <a.campi@inet.it> wrote on 11/08/2002 08:59:59 AM:
> By the way, I would like to propose that we change this so that
> IDENTIFY only affects the channel it is sent on, not the whole session.
Are you talking about a BEEP session or a CAP session?  It sounds as if you are referring to the BEEP session since currently a CAP session is just a BEEP channel:

   CAP Session -  An open communication channel between a CUA and a
     Calendar Server.  If the CAP session is authenticated, the CU is
     "authenticated" and it is an "authenticated CAP session".

so establishing another BEEP channel would cause a new CAP session to be created on the current BEEP session.  This does not sound to be too expensive to do say compared to creating the actual BEEP session...  

Actually the definition does not expressly say its a "BEEP channel" between the CUA and CS so this could be read as a being a single network connection ala TCPIP socket connection.  Is it an incorrect assumption to read "BEEP session" or "BEEP channel" in place of "communcation channel"?  If so, whats the linkage between "communication channel" and CAP/BEEP?  If not, can we clean up the text a bit here?

If you are referring to a CAP session instead of a BEEP session then don't read further as Im basing the rest on this assumption.

Do we want to add the complexity of multiple identities per CAP session/BEEP channel?  Why wouldn't we just use a new BEEP channel to establish a new CAP session?  That way any failure would result in that channel being closed instead of all CAP sessions/BEEP channels.

Along the same lines of thought, which session is this text referring to:

   IDENTIFY -  Set a new identity for the session.  Initiated by the CUA
     only.  (Section 10.4)

I assume its a CAP session (aka BEEP channel) but its not clear.  Doug?

There is some text about terminating the BEEP session instead of the CAP session that directly relates to your response:

   If a CS considers the "IDENTIFY" command an attempt to violate
  security, the CS MAY terminate the BEEP session without any further
  notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply.

In this case it expressly states that its the BEEP session in question rather than the CAP session.  Being a BEEP novice Im not sure if its proper/safe to use the two terms interchangably.  Perhaps Marshal can help out here...  This text makes the CS drop all the CAP sessions if the IDENTIFY command fails on any CAP session/BEEP channel.  Kind of a harsh response to a single failure at least in my mind.  This is appropriate for DOS attacks or stopping hacking but its a bit strong for the simple case where the CS and CUA disagree on what identities an AA can actually assume.

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 0065C74C85256C6E_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 14:16:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28331 for ; Mon, 11 Nov 2002 14:16:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABJ8KI18321 for ietf-calendar-bks; Mon, 11 Nov 2002 11:08:20 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABJ8Ig18317 for ; Mon, 11 Nov 2002 11:08:19 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gABJ8JIR011256 for ; Mon, 11 Nov 2002 11:08:19 -0800 Message-ID: <3DD00020.60201@Royer.com> Date: Mon, 11 Nov 2002 12:08:16 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010805020801030602070805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010805020801030602070805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 11/06/2002 08:15:56 PM: > > Just curious, do you feel the the CS should ask the CUA if the > > user has permission? Or are you saying that the CS should not > > do it internally? > > I think that we have a disjoin in our design WRT IDENTIFY. The CU can > configure the CUA w/a list of identities to try and switch to but the CS > has the final authority over allowing or disallowing the actualy > IDENTIFY command to succeed or not. As such I think that there should > be some way for the CUA to get the list of 'alternate' or assumable > identities from the CS. We agreed a long time ago that user administration is out of scope in this version if CAP. >... > At one point early on in CAP we had the design that the CS would return > back the 'primary' UPN that the CUA was assuming and we had discussed > the possibility of sending back the list of alternate UPNs. It seems to > me that this never got resolved (I didnt check, I have 500+ msgs to wade > thru still) but I think we should do it. If not at authentication time > (not everyone will change identities) then via a command of some kind. Yes - and we dropped it when we concluded that it was user administration. > ... -- 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 --------------ms010805020801030602070805 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMTE5MDgxNlowIwYJKoZIhvcNAQkEMRYEFATE8Nym P7ozQfwSLg91ws0VPBUbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAB9ptvQ0Iw/zHNvl5N Tk0Zv+UTWBJd8rVl4sHmB/nVDa5dL9ii3jyvIl8TVetw8gNIns4ACvKj/zEt5xVo8LHXsGxx rBVx/d61XO9+4bKTb7MEPXLG2qDbSPkpGPEtckrVUqHq9XyKK+4qftkXAxrW8W0n5O2c6Cvu lF7X+jra700lUV0D692GnhD+s8O0NNhH6QSSV2z3/39OekyGcg6lA6xpOuVXeyy022o8DM9Y MAEuia7CGiioKseQ4R9h9xb+9gUPz6t3sEK/AXhk9aj4wVD5R7bFwVvK9806z4Uy0k7LZYvd rkbZnU8FcFQchpdtElPklcG+S1C6IByfd+7tAAAAAAAA --------------ms010805020801030602070805-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 14:19:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28416 for ; Mon, 11 Nov 2002 14:19:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABJC8K18455 for ietf-calendar-bks; Mon, 11 Nov 2002 11:12:08 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABJC7g18450 for ; Mon, 11 Nov 2002 11:12:07 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gABJC8IR011291 for ; Mon, 11 Nov 2002 11:12:08 -0800 Message-ID: <3DD00105.4060409@Royer.com> Date: Mon, 11 Nov 2002 12:12:05 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040002030300020907020909" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040002030300020907020909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Andrea Campi wrote on 11/06/2002 07:50:40 PM: > > Sorry but I don't get your point. After all, we do use SASL, so we have > > separate autentication and authorization information available. > > Yes we do but we do not have any clear way to get that information to > the CUA. That is, there is no clear proscribed way for the CUA to > "discover" what credentials they may use as inputs for the IDENTIFY > command. A long time ago a suggestion was made about resolving this > disjoin. Yes - join the SASL WG and make SASL extensions :-) That's a whole new protocol and we agreed that user administration is out of scope. I don't see any reason that there can not be a separate draft written and proposed to add that functionality. -- 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 --------------ms040002030300020907020909 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMTE5MTIwNVowIwYJKoZIhvcNAQkEMRYEFGVNwEZU r7tGciQ+B4ghZjhjAKifMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBGzSUJ8VZ9WH5n3mFh aDKptIBFQC4TjodA+lCoimyT4JWRXY4AgT5y54TRGiQTYxEU/OpylaGN3HvPAMAtYfuLrKmO BY3IPCErM/9y+8EV6qS+5n64mpGUAFLPmBLPAm1OvKJqzs4CJnhw7NkS3y5XpfO00ydtMvXP WX+OYxTfvEZtYLbiZn2bIIjgT2bOCVJonPJXh4/kdP7hjhSGKdFLElivk4c9sN/Ud9cIucoq 5sRbDEONl97ew3p3RKcGqYlAS0QSHkILiloqLqPrphk+znC6OSSLNGA/hqZuxf4z9zNz0qLV MHNCRLbBGDHaczjAjvnPRtiCN45J0xmvI3hHAAAAAAAA --------------ms040002030300020907020909-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 14:23:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28501 for ; Mon, 11 Nov 2002 14:23:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABJI8p18777 for ietf-calendar-bks; Mon, 11 Nov 2002 11:18:08 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABJI6g18772 for ; Mon, 11 Nov 2002 11:18:07 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gABJI7IR011331 for ; Mon, 11 Nov 2002 11:18:07 -0800 Message-ID: <3DD0026C.7090604@Royer.com> Date: Mon, 11 Nov 2002 12:18:04 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060600070805030202040704" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060600070805030202040704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 11/06/2002 08:06:37 PM: > > Your right there is an error, however it would be: > > > > ; The value is the UPN of the requested > > ; identity. If not supplied it is a request > > ; to return to the original authenticated identity. > > ; The following MUST occur exactly once and only > > ; when the CU wished to change to another UPN. > > ; The following would not be supplied if the > > ; CU wished to switch to their original identity. > > > > / option-param upn > > This newer ABNF does NOT make it clear that option-param AND the related > UPN are either MUST or not at all (to get that "CU wished to switch to > their original identity.") You need to make that entire line a "0 or 1" > instance then. The comment in the ABNF does not transcode to the actual > ABNF thats verifiable otherwise. There is no way in ABNF to say when parameters may exist. It is always described in text. ABNF restricts the data to a specific set, but it can not without extra text describe it usage. > > Where it should be this to ask to switch back to your original identity: > > > > CMD:IDENTITY > > > > Or to ask to switch to another identity: > > > > CMD;OPTIONS=new-upn-id:IDENTITY > > > > The example used is just the username part of the UPN and not the full > UPN. Please make sure all examples have properly formed UPNs in the > draft for those that only code by example... Which example is a 'username' ? > > > Lastly, the behaviour for when an IDENTITY fails is unclear. The text > > > simply says: > > > > > > If they do, the session assumes the new identity, > > > otherwise a security error is returned. > > > > > > but does not expressly indicate that the original (or previous) > identity > > > is to be resumed. It could be that more than one IDENTITY command has > > > been issued with some that worked. > > > > Please point to the section of CAP that says that you can > > send more than one IDENTITY command at a time. > > 1: I can pipleine several commands at a time so its perfectly valid (and > probably a good way to attack a CS) to send > 1 IDENTIFY (not IDENTITY) > command at a time. So do you agree with (who ever sent it) that IDENTIFY is channel specific? -- 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 --------------ms060600070805030202040704 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMTE5MTgwNFowIwYJKoZIhvcNAQkEMRYEFGev6/fH bRIyrIFuAZs5Rr2HyN62MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCryqq2BPhAT3svdSP3 xBg1d5APGIrtCLZmlTn2GuyRCnhyue0mUfCxBOJmUdZiILZ9+iRFlGU6gMnKNiAH+D2HdTno GQNkR0ZnBghBH4qZ/nRjPBQwoEdZIh8VC7SJqGl3sOk+Rk/20XAvDCaJPOuycgbIY0HE//v9 l5CMcaOi61F0gnTcCTLQAeptFjMcr4rFKAfx6/UG8BegPc7EzF51yNN9MJTJfm2S3V7GOI5x Msn5MbVBPJa0uQ5l12sma0hX8kyRvmsUG+aTFatOnA1xZV9inv9f7FR0Q6j2IGgMlFYVY9+h J1usveKjnUMeLBG7zzA8yHJz23UGSNQmUlhlAAAAAAAA --------------ms060600070805030202040704-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 14:31:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28702 for ; Mon, 11 Nov 2002 14:31:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABJOLG18957 for ietf-calendar-bks; Mon, 11 Nov 2002 11:24:21 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABJOKg18953 for ; Mon, 11 Nov 2002 11:24:20 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gABJOLIR011378 for ; Mon, 11 Nov 2002 11:24:21 -0800 Message-ID: <3DD003E2.4080408@Royer.com> Date: Mon, 11 Nov 2002 12:24:18 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: Cleanly disconnecting References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040207000502090204080100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040207000502090204080100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In the latest CAP draft I notice that there is still no command to allow > a CUA to cleanly disconnect from the CAP server. Section 2.4 of BEEP describes how to close a connection by sending a close on channel zero (0). A CAP 'BUY' command would be superfluous. -- 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 --------------ms040207000502090204080100 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMTE5MjQxOVowIwYJKoZIhvcNAQkEMRYEFLNHX1wl WwbdGGHnAIY0zL/ZsC7tMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAh5XYb5gI4q69TWTgW JrQ61VT2a9Ow2F986VJC69DaXUgJhVMTAi8NXVux2HCdGbKIfFXMxtoY8Fwbxse/D7baVXpX +Rlc1iOn1fOlDBcwQ+mdKFLDBEpd5/YR07WtSnX0DRlc3G1YpQhmVzmTvCepTCPiIB+GOxAw iFBdu5Gwxc8nClqfe1xaNEnjKkZHzwwDLIcY+G21mSkuxbOr7g5j88DBxaEdW+6JSEYMSA53 FIOOREVPXZX8jZG9ZT4vomQ7VOlyHcYI3S9fsHRlIKiqM09f0yNG+tA+JQsQfS2Ed8rH1CEU j6tHVa67L/boq3itmNPLFrDajQnlds/BkTpSAAAAAAAA --------------ms040207000502090204080100-- From owner-ietf-calendar@mail.imc.org Mon Nov 11 14:55:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29321 for ; Mon, 11 Nov 2002 14:55:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABJoVl21750 for ietf-calendar-bks; Mon, 11 Nov 2002 11:50:31 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABJoUg21745 for ; Mon, 11 Nov 2002 11:50:30 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gABJoVIR011583 for ; Mon, 11 Nov 2002 11:50:31 -0800 Message-ID: <3DD00A04.3000206@Royer.com> Date: Mon, 11 Nov 2002 12:50:28 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090002090507030901010302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090002090507030901010302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Andrea Campi wrote on 11/08/2002 08:59:59 AM: > > By the way, I would like to propose that we change this so that > > IDENTIFY only affects the channel it is sent on, not the whole session. > > Are you talking about a BEEP session or a CAP session? It sounds as if > you are referring to the BEEP session since currently a CAP session is > just a BEEP channel: In section 4. of BEEP "Whenever a successful authentication occurs, on any channel, the authenticated identity is updated for all existing and future channels on the BEEP session; further, no additional attempts at authentication are allowed." So - you can only authenticate once per BEEP session. So the question to answer is: does the CAP IDENTIFY command effect one channel - or is it global? If global - then maybe we need to add something to CAP like: The new identity takes effect after pending commands complete from the CS's point of view and the identity does not change in the middle of executing a command. The new identity only effects new commands issued by the CUA and after receiving an IDENTIFY success reply code (x.x) from the CS. If per channel - then we need to add text like: An IDENTIFY command is per BEEP channel. The IDENTIFY command does not effect other channels. The new identity only effects new commands issued by the CUA and after receiving an IDENTIFY success reply code (x.x) from the CS on that channel. > There is some text about terminating the BEEP session instead of the CAP > session that directly relates to your response: > > If a CS considers the "IDENTIFY" command an attempt to violate > security, the CS MAY terminate the BEEP session without any further > notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. > > In this case it expressly states that its the BEEP session in question > rather than the CAP session. Being a BEEP novice Im not sure if its > proper/safe to use the two terms interchangably. Perhaps Marshal can help > out here... This text makes the CS drop all the CAP sessions if the > IDENTIFY command fails on any CAP session/BEEP channel. No that is not what it says. It does NOT say 'if the IDENTIFY command fails...', it says 'If a CS considers the "IDENTIFY" command an attempt to violate security...'. And I agree. > Kind of a harsh response to a single failure at least in my mind. Please point to the text that says 'a single failure' causes the BEEP session to be terminated when the IDENTIFY command fails. > This is appropriate for > DOS attacks or stopping hacking but its a bit strong for the simple case > where the CS and CUA disagree on what identities an AA can actually assume. -- 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 --------------ms090002090507030901010302 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMTE5NTAyOFowIwYJKoZIhvcNAQkEMRYEFBVXcxYQ ToHiJD2yXXYvEVCstwtpMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQC61Yr3YimvIWy1QOC/ 4oThBYB20A961d0pxjO2Wqgg3qXPDEzb8BEdqOlzv6jcI/c5/L5lQ5sS1mMJ39A3QE9nNaOh BNGK6dqfRw5VDj3OT/H91KMyTYz+Ou57+zVB4wtr1FJSQgOqbuanFgdycxrVh2UfQDNVzl+w ItQqfkrmxzLlZi9GeH9ytNHUBmI5aDVoIMYr0J7H9BFifXKMWQ6/YEje01hZJNyBDO55I/QC QNyNuwK/6HLyw2o5lvDG3Pf9Q+uGsi0UhwWvCzmcX3H1ZdSivVBbxlkSvewfGtmmSvyxIOkq KJU+feP+Ymjkh4qtO6xLFRPy9eJnNRD8I7lDAAAAAAAA --------------ms090002090507030901010302-- From owner-ietf-calendar@mail.imc.org Tue Nov 12 12:25:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07476 for ; Tue, 12 Nov 2002 12:25:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACHIBf06129 for ietf-calendar-bks; Tue, 12 Nov 2002 09:18:11 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACHI2g06121 for ; Tue, 12 Nov 2002 09:18:06 -0800 (PST) In-Reply-To: <3DD00105.4060409@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Nov 2002 10:39:59 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/12/2002 12:18:12 PM, Serialize complete at 11/12/2002 12:18:12 PM Content-Type: multipart/alternative; boundary="=_alternative 00560A1285256C6F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00560A1285256C6F_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 11/11/2002 02:12:05 PM: > > Yes we do but we do not have any clear way to get that information to > > the CUA. That is, there is no clear proscribed way for the CUA to > > "discover" what credentials they may use as inputs for the IDENTIFY > > command. A long time ago a suggestion was made about resolving this > > disjoin. > > Yes - join the SASL WG and make SASL extensions :-) Eh? So now its no longer an administrative issue, its a SASL extension thats undefined?? %^| Im curious how a CS implementation is to derive a UPN from _any_ SASL or CAP or (insert alternate plan here) authentication/authorization mechanism and use it for the CAP session if that feature/ability is "administration" and as such not defined in CAP 1.0? That seems to be deemed "administration" and as such not defined in CAP 1.0. Guess we just dont authenticate at all OR some magical voodoo happens in a per-CS implementation to derive some set of UPNs in any manner each sees fit which may result in different UPNs being generated for the same set of inputs... Just what I want in a protocol designed to promote interoperability. Ok, a bit of sarcasm creeping in due to more than a little frustration so Ill take a deep breath and try again... Still no answer I can grok here: Why is having the CS return a list of UPNs to the CUA after authentication/authorization has taken place considered "administration" or a "SASL" thing? If the CS has the list of UPNs it will allow me to assume using the IDENTIFY command then why is it that it cannot provide me that list on demand? Ahh, I get it; "That would be telling..." > That's a whole new protocol and we agreed that user administration > is out of scope. I don't see any reason that there can not be a > separate draft written and proposed to add that functionality. Let me say this again until it sinks in: Im am not, repeat _NOT_, talking about the CUA doing anything to change the list in any fashion! (Ok so far??) Im talking about having the ability for the CUA to simply read the list from the CS so that it can better use the IDENTIFY command w/o having to guess at what the CS will or will not allow. (Whew, I hope I didnt loose anyone there with such a complex concept.) FMI: Why is this not the "IDENTITY" command since the CUA is changing the identity they are operating as?? 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 00560A1285256C6F_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 11/11/2002 02:12:05 PM:
> > Yes we do but we do not have any clear way to get that information to
> > the CUA.  That is, there is no clear proscribed way for the CUA to
> > "discover" what credentials they may use as inputs for the IDENTIFY
> > command.  A long time ago a suggestion was made about resolving this
> > disjoin.
>
> Yes - join the SASL WG and make SASL extensions :-)
Eh?  So now its no longer an administrative issue, its a SASL extension thats undefined?? %^|

Im curious how a CS implementation is to derive a UPN from _any_ SASL or CAP or (insert alternate plan here) authentication/authorization mechanism and use it for the CAP session if that feature/ability is "administration" and as such not defined in CAP 1.0?  That seems to be deemed "administration" and as such not defined in CAP 1.0.  Guess we just dont authenticate at all OR some magical voodoo happens in a per-CS implementation to derive some set of UPNs in any manner each sees fit which may result in different UPNs being generated for the same set of inputs...  Just what I want in a protocol designed to promote interoperability.

Ok, a bit of sarcasm creeping in due to more than a little frustration so Ill take a deep breath and try again...

Still no answer I can grok here: Why is having the CS return a list of UPNs to the CUA after authentication/authorization has taken place considered "administration" or a "SASL" thing?  If the CS has the list of UPNs it will allow me to assume using the IDENTIFY command then why is it that it cannot provide me that list on demand?  Ahh, I get it; "That would be telling..."

> That's a whole new protocol and we agreed that user administration
> is out of scope. I don't see any reason that there can not be a
> separate draft written and proposed to add that functionality.
Let me say this again until it sinks in: Im am not, repeat _NOT_, talking about the CUA doing anything to change the list in any fashion!  (Ok so far??)  Im talking about having the ability for the CUA to simply read the list from the CS so that it can better use the IDENTIFY command w/o having to guess at what the CS will or will not allow. (Whew, I hope I didnt loose anyone there with such a complex concept.)

FMI: Why is this not the "IDENTITY" command since the CUA is changing the identity they are operating as??

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 00560A1285256C6F_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 12 12:28:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07581 for ; Tue, 12 Nov 2002 12:28:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACHIQD06138 for ietf-calendar-bks; Tue, 12 Nov 2002 09:18:26 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACHIFg06133 for ; Tue, 12 Nov 2002 09:18:17 -0800 (PST) In-Reply-To: <3DD00020.60201@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Nov 2002 10:27:35 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/12/2002 12:18:26 PM, Serialize complete at 11/12/2002 12:18:26 PM Content-Type: multipart/alternative; boundary="=_alternative 0054E76B85256C6F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054E76B85256C6F_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/11/2002 02:08:16 PM: > > I think that we have a disjoin in our design WRT IDENTIFY. The CU can > > configure the CUA w/a list of identities to try and switch to but the CS > > has the final authority over allowing or disallowing the actualy > > IDENTIFY command to succeed or not. As such I think that there should > > be some way for the CUA to get the list of 'alternate' or assumable > > identities from the CS. > > We agreed a long time ago that user administration is out of scope > in this version if CAP. Yes we did but this concern is NOT administration; its a usability issue!! I am _NOT_ talking about having the CUA somehow administer the list; Im talking about it getting the list so it can use it for the IDENTIFY command (and for any CUA side GUI-isms it wants/needs). I have said before and Ill say it again: There should be some consistant way for a CUA to get a list of identities that it can change to. Otherwise the CUA is just playing Marco Polo trying to see what UPNs the CS will let it switch to! We had this ability early on when the CS returned the 'primary' UPN and a list of other assumable UPNs as part of either authentiation or some other process (I dont have my very early CAP draft markups still...). I do not see this in CAP now and I think it should be there still; I never saw any talk of removing that feature/ability so why did it disappear? > Yes - and we dropped it when we concluded that it was user administration. Got a thread reference? I dont recall that discussion and I certainly disagree w/that conclusion. If the CUA is only reading the list from the CS I dont see how anyone can claim that its an administrative function w/a straight face. Thats like saying reading my calendar is administrative so we may as well drop that too... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0054E76B85256C6F_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/11/2002 02:08:16 PM:
> > I think that we have a disjoin in our design WRT IDENTIFY.  The CU can
> > configure the CUA w/a list of identities to try and switch to but the CS
> > has the final authority over allowing or disallowing the actualy
> > IDENTIFY command to succeed or not.  As such I think that there should
> > be some way for the CUA to get the list of 'alternate' or assumable
> > identities from the CS.
>
> We agreed a long time ago that user administration is out of scope
> in this version if CAP.
Yes we did but this concern is NOT administration; its a usability issue!!  I am _NOT_ talking about having the CUA somehow administer the list; Im talking about it getting the list so it can use it for the IDENTIFY command (and for any CUA side GUI-isms it wants/needs).

I have said before and Ill say it again: There should be some consistant way for a CUA to get a list of identities that it can change to. Otherwise the CUA is just playing Marco Polo trying to see what UPNs the CS will let it switch to!

We had this ability early on when the CS returned the 'primary' UPN and a list of other assumable UPNs as part of either authentiation or some other process (I dont have my very early CAP draft markups still...).  I do not see this in CAP now and I think it should be there still; I never saw any talk of removing that feature/ability so why did it disappear?

> Yes - and we dropped it when we concluded that it was user administration.
Got a thread reference?  I dont recall that discussion and I certainly disagree w/that conclusion.  

If the CUA is only reading the list from the CS I dont see how anyone can claim that its an administrative function w/a straight face.  Thats like saying reading my calendar is administrative so we may as well drop that too...

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

--=_alternative 0054E76B85256C6F_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 12 12:28:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07596 for ; Tue, 12 Nov 2002 12:28:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACHHuG06117 for ietf-calendar-bks; Tue, 12 Nov 2002 09:17:56 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACHHfg06111 for ; Tue, 12 Nov 2002 09:17:48 -0800 (PST) In-Reply-To: <3DD0026C.7090604@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Nov 2002 10:57:40 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/12/2002 12:17:58 PM, Serialize complete at 11/12/2002 12:17:58 PM Content-Type: multipart/alternative; boundary="=_alternative 0057A87885256C6F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057A87885256C6F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/11/2002 02:18:04 PM: > > This newer ABNF does NOT make it clear that option-param AND the related > > UPN are either MUST or not at all (to get that "CU wished to switch to > > their original identity.") You need to make that entire line a "0 or 1" > > instance then. The comment in the ABNF does not transcode to the actual > > ABNF thats verifiable otherwise. > > There is no way in ABNF to say when parameters may exist. It is always > described in text. ABNF restricts the data to a specific set, but it > can not without extra text describe it usage. Wrong, it just takes some changing to the ABNF to do this. For example, instead of: identifyparam = *( [Snip, snip] / option-param upn ) You can fix this to be correct using, say: identifyparam = *( [Snip, snip] / [ option-param ] cmd-specific =/ upn ; The option-param cmd-specific value for IDENTIFY ; is a UPN. This now correctly indicates that option-param on IDENTIFY is either there once or not at all. It also correctly indicates that cmd-specific for this command is a UPN (see RFC 2234, Section 3.3 Incremental Alternatives if this notation is unclear to you or go check 2445 where it was used.) > > > Where it should be this to ask to switch back to your original identity: > > > > > > CMD:IDENTITY > > > > > > Or to ask to switch to another identity: > > > > > > CMD;OPTIONS=new-upn-id:IDENTITY > > > > The example used is just the username part of the UPN and not the full > > UPN. Please make sure all examples have properly formed UPNs in the > > draft for those that only code by example... > > Which example is a 'username' ? The cmd-specific value in your last example (left in above) is just new-upn-id. By the defintion of UPN composition in Section 1.3 of all the drafts I checked the format of the UPN is basically: "username" '@' "realm". As such just how does one parse the "new-upn-id" as a valid UPN? Its got to be the username component OR the realm component. HOWEVER your definiton in Section 1.3 does NOT allow just those parts by themselves! Hence, the example is malformed. The example should be something like: CMD;OPTIONS=new-upn-id@some-realm:IDENTITY or you need to change the clear definition of UPN composition in 1.3 to be less accurate/clear. > > 1: I can pipleine several commands at a time so its perfectly valid (and > > probably a good way to attack a CS) to send > 1 IDENTIFY (not IDENTITY) > > command at a time. > > So do you agree with (who ever sent it) that IDENTIFY is channel specific? I havent seen anything that would preclude me from sending multiple IDENTIFY commands on the same channel. Then again I keep chasing drafts so I could have overlooked it. Where is that restriction in the 09-submitted 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 0057A87885256C6F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/11/2002 02:18:04 PM:
> > This newer ABNF does NOT make it clear that option-param AND the related
> > UPN are either MUST or not at all (to get that "CU wished to switch to
> > their original identity.")  You need to make that entire line a "0 or 1"
> > instance then.  The comment in the ABNF does not transcode to the actual
> > ABNF thats verifiable otherwise.
>
> There is no way in ABNF to say when parameters may exist. It is always
> described in text. ABNF restricts the data to a specific set, but it
> can not without extra text describe it usage.
Wrong, it just takes some changing to the ABNF to do this.  For example, instead of:

        identifyparam   = *(
[Snip, snip]
                        / option-param upn
                       )

You can fix this to be correct using, say:

        identifyparam   = *(
[Snip, snip]
                        / [ option-param ]

        cmd-specific     =/ upn
                            ; The option-param cmd-specific value for IDENTIFY
                            ; is a UPN.
This now correctly indicates that option-param on IDENTIFY is either there once or not at all.  It also correctly indicates that cmd-specific for this command is a UPN (see RFC 2234, Section 3.3 Incremental Alternatives if this notation is unclear to you or go check 2445 where it was used.)

> >  > Where it should be this to ask to switch back to your original identity:
> >  >
> >  >       CMD:IDENTITY
> >  >
> >  > Or to ask to switch to another identity:
> >  >
> >  >       CMD;OPTIONS=new-upn-id:IDENTITY
> >
> > The example used is just the username part of the UPN and not the full
> > UPN.  Please make sure all examples have properly formed UPNs in the
> > draft for those that only code by example...
>
> Which example is a 'username' ?
<DIGRESSION>
The cmd-specific value in your last example (left in above) is just new-upn-id.  By the defintion of UPN composition in Section 1.3 of all the drafts I checked the format of the UPN is basically: "username" '@' "realm".  As such just how does one parse the "new-upn-id" as a valid UPN?  Its got to be the username component OR the realm component.  HOWEVER your definiton in Section 1.3 does NOT allow just those parts by themselves!  Hence, the example is malformed.  The example should be something like:

CMD;OPTIONS=new-upn-id@some-realm:IDENTITY

or you need to change the clear definition of UPN composition in 1.3 to be less accurate/clear.
</DIGRESSION>

> > 1: I can pipleine several commands at a time so its perfectly valid (and
> > probably a good way to attack a CS) to send > 1 IDENTIFY (not IDENTITY)
> > command at a time.
>
> So do you agree with (who ever sent it) that IDENTIFY is channel specific?
I havent seen anything that would preclude me from sending multiple IDENTIFY commands on the same channel.  Then again I keep chasing drafts so I could have overlooked it.  Where is that restriction in the 09-submitted 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 0057A87885256C6F_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 12 13:02:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08525 for ; Tue, 12 Nov 2002 13:02:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACHusM08469 for ietf-calendar-bks; Tue, 12 Nov 2002 09:56:54 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACHurg08462 for ; Tue, 12 Nov 2002 09:56:53 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gACHurIR021987 for ; Tue, 12 Nov 2002 09:56:54 -0800 Message-ID: <3DD140E2.5080603@Royer.com> Date: Tue, 12 Nov 2002 10:56:50 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090005030205040907020203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090005030205040907020203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > > > Where it should be this to ask to switch back to your original > identity: > > > > > > > > CMD:IDENTITY > > > > > > > > Or to ask to switch to another identity: > > > > > > > > CMD;OPTIONS=new-upn-id:IDENTITY > > > > > > The example used is just the username part of the UPN and not the full > > > UPN. Please make sure all examples have properly formed UPNs in the > > > draft for those that only code by example... > > > > Which example is a 'username' ? > > > The cmd-specific value in your last example (left in above) is just > new-upn-id. By the defintion of UPN composition in Section 1.3 of all > the drafts I checked the format of the UPN is basically: "username" '@' > "realm". As such just how does one parse the "new-upn-id" as a valid > UPN? Its got to be the username component OR the realm component. > HOWEVER your definiton in Section 1.3 does NOT allow just those parts > by themselves! Hence, the example is malformed. The example should be > something like: > > CMD;OPTIONS=new-upn-id@some-realm:IDENTITY You are joking right? > or you need to change the clear definition of UPN composition in 1.3 to > be less accurate/clear. > > > > > 1: I can pipleine several commands at a time so its perfectly valid > (and > > > probably a good way to attack a CS) to send > 1 IDENTIFY (not > IDENTITY) > > > command at a time. > > > > So do you agree with (who ever sent it) that IDENTIFY is channel > specific? > > I havent seen anything that would preclude me from sending multiple > IDENTIFY commands on the same channel. Then again I keep chasing drafts > so I could have overlooked it. Where is that restriction in the > 09-submitted draft? You can not send more that one command at a time on the same channel - a BEEP restriction. So yes you can send IDENTIFY commands all day as long on the same channel as you only send one command at a time. The CS will or will error out on each one as received. -- 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 --------------ms090005030205040907020203 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMjE3NTY1MVowIwYJKoZIhvcNAQkEMRYEFCWAJy5x WeE+ZdrB9p0rHqsXMGZPMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBSgT6VvvTsrecc75/G V/+eG8YbadMni8KWkGbUyPCVuH/AJ+rFncQrp9WK3wOdIUE7S9/XJ8NFjHzOKHC0pTRZc2qc 2tXjmO+V4mPG5ZIGByjgCvpg425OyELOjpmCEMue53sI0KrmI7PWCsMXxxfytZs/cXjm/IZT SwuCuFFAd+iZjrr5/jWBmKBKiePjDCvLgR6v1kT5bEST5ALj+fAetku/oZyzteXQaXB4Fx4l G8oKBaku9MIMPSCw2UMHCzBWI//uA94pKG74hKsDPiWGvfH3pTXwuOnevKRl7aYDYfKnugBd EEyrUGgcdmqNywS+oJKjjgUZH60JtEnxDo8NAAAAAAAA --------------ms090005030205040907020203-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 11:50:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07828 for ; Wed, 13 Nov 2002 11:50:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADGZil21030 for ietf-calendar-bks; Wed, 13 Nov 2002 08:35:44 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADGZfg21024 for ; Wed, 13 Nov 2002 08:35:42 -0800 (PST) In-Reply-To: <3DD00A04.3000206@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Nov 2002 13:15:17 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 11:35:44 AM, Serialize complete at 11/13/2002 11:35:44 AM Content-Type: multipart/alternative; boundary="=_alternative 00645E4685256C6F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00645E4685256C6F_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 11/11/2002 02:50:28 PM: > So the question to answer is: does the CAP IDENTIFY command > effect one channel - or is it global? The more useful scenario is one per channel. That would allow an AA or proxy to maintain their own identity on one channel and open up as many other channels as necessary to do work on potentially several other CUs at the same time. Then they can act as themselves on their own channel and concurrently act on my behalf on another (and on my boses behalf on another and...). This does seem to negate the need to do multiple identity changes on a channel though. All that they would need to be able to do is open a new BEEP channel, change the identity once and then when done close the channel. If they needed to become a different identity they could simply open a new channel. Since they should already have a channel open for their principal identity there is not a pressing need to be able to revert back to it on the subsequently created channels. We could simplify CAP and IDENTIFY a bit by expressly modelling this and precluding multiple IDENTIFY commands on a channel... > If per channel - then we need to add text like: > > An IDENTIFY command is per BEEP channel. The IDENTIFY > command does not effect other channels. The new identity > only effects new commands issued by the CUA and after > receiving an IDENTIFY success reply code (x.x) from the CS > on that channel. That works. Given this do we want to allow multiple IDENTIFY commands per channel or not?? Im all for not allowing them but if making a new BEEP channel is an expensive operation then maybe we do want to allow it... > No that is not what it says. It does NOT say 'if the IDENTIFY command > fails...', it says 'If a CS considers the "IDENTIFY" command an attempt to > violate security...'. So even if the IDENTIFY is a success the CS could "consider the "IDENTIFY" command an attempt to violate security" and shut down my BEEP session "without any further notice" so I have no clue why the hell the CS just punted me for doing an IDENTIFY command that I should be able to do...??? Id love to hear the Tech Support call on that one. (Making this determination is an implementation issue and thus falls under Administration or Configuration which is OOB for CAP 1.0 but the CAP 1.0 does not distinguish between this happening for failure cases only which is where I think it should and any possible case...) > And I agree. If the draft clearly stated that such a determination was for failure cases then I would agree too. Currently it does not. As such some CS could have a policy that says "5 IDENTIFY commands w/in 1 minute may be a hacker so drop them" then its possible that my efficient team AA could accidentally trip this and get punted from the CS w/o warning or notice for using IDENTIFY to put a team meeting on all of our calendars. Poor design IMHO. > > Kind of a harsh response to a single failure at least in my mind. > > Please point to the text that says 'a single failure' causes the BEEP > session to be terminated when the IDENTIFY command fails. The determination of how the CS "considers the "IDENTIFY" command an attempt to violate security" is vague enough that its possible that a single failure could cause the termination of the BEEP session "without any further notice". The draft does not preclude it so it is possible; hence _my_ comment. While this determination is TBD (ie: Administrative) my point is that this determination should only happen on failure cases instead of either success OR failure. 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 00645E4685256C6F_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 11/11/2002 02:50:28 PM:
> So the question to answer is: does the CAP IDENTIFY command
> effect one channel - or is it global?
The more useful scenario is one per channel.  That would allow an AA or proxy to maintain their own identity on one channel and open up as many other channels as necessary to do work on potentially several other CUs at the same time.  Then they can act as themselves on their own channel and concurrently act on my behalf on another (and on my boses behalf on another and...).

This does seem to negate the need to do multiple identity changes on a channel though.  All that they would need to be able to do is open a new BEEP channel, change the identity once and then when done close the channel.  If they needed to become a different identity they could simply open a new channel.  Since they should already have a channel open for their principal identity there is not a pressing need to be able to revert back to it on the subsequently created channels.  We could simplify CAP and IDENTIFY a bit by expressly modelling this and precluding multiple IDENTIFY commands on a channel...

> If per channel - then we need to add text like:
>
>       An IDENTIFY command is per BEEP channel. The IDENTIFY
>       command does not effect other channels. The new identity
>       only effects new commands issued by the CUA and after
>                  receiving an IDENTIFY success reply code (x.x) from the CS
>       on that channel.
That works.  Given this do we want to allow multiple IDENTIFY commands per channel or not??  Im all for not allowing them but if making a new BEEP channel is an expensive operation then maybe we do want to allow it...

> No that is not what it says. It does NOT say 'if the IDENTIFY command
> fails...', it says 'If a CS considers the "IDENTIFY" command an attempt to
> violate  security...'.
So even if the IDENTIFY is a success the CS could "consider the "IDENTIFY" command an attempt to violate security" and shut down my BEEP session "without any further notice" so I have no clue why the hell the CS just punted me for doing an IDENTIFY command that I should be able to do...???   Id love to hear the Tech Support call on that one.  (Making this determination is an implementation issue and thus falls under Administration or Configuration which is OOB for CAP 1.0 but the CAP 1.0 does not distinguish between this happening for failure cases only which is where I think it should and any possible case...)

> And I agree.
If the draft clearly stated that such a determination was for failure cases then I would agree too.  Currently it does not.  As such some CS could have a policy that says "5 IDENTIFY commands w/in 1 minute may be a hacker so drop them" then its possible that my efficient team AA could accidentally trip this and get punted from the CS w/o warning or notice for using IDENTIFY to put a team meeting on all of our calendars.  Poor design IMHO.

>  >  Kind of a harsh  response to a single failure at least in my mind.
>
> Please point to the text that says 'a single failure' causes the BEEP
> session to be terminated when the IDENTIFY command fails.
The determination of how the CS "considers the "IDENTIFY" command an attempt to violate security" is vague enough that its possible that a single failure could cause the termination of the BEEP session "without any further notice".  The draft does not preclude it so it is possible; hence _my_ comment.  While this determination is TBD (ie: Administrative) my point is that this determination should only happen on failure cases instead of either success OR failure.

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 00645E4685256C6F_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 11:59:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08380 for ; Wed, 13 Nov 2002 11:59:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADGnjo21309 for ietf-calendar-bks; Wed, 13 Nov 2002 08:49:45 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADGnhg21305 for ; Wed, 13 Nov 2002 08:49:43 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP: action-param? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 11:49:40 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 11:49:46 AM, Serialize complete at 11/13/2002 11:49:46 AM Content-Type: multipart/alternative; boundary="=_alternative 005C654D85256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C654D85256C70_= Content-Type: text/plain; charset="US-ASCII" In diving on the 10.4 IDENTIFY issues w/Doug I noticed that in several ABNF bits there is an action-param used: 10.1.3 CONTINUE Command [Snip, snip] continueparam = *( ; the following are optional, ; but MUST NOT occur more than once id-param / localize-param / latency-param ; the following MUST occur exactly once and only ; when the latency-param has been supplied and ; MUST NOT be supplied if the latency-param is ; not supplied. / action-param but nowhere in the 09-submitted draft can I find the actual defintion of aciton-param. Did that get removed by accident or are all the instances of action-param legacy from a prior edit that did not get removed yet?? 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 005C654D85256C70_= Content-Type: text/html; charset="US-ASCII"
In diving on the 10.4 IDENTIFY issues w/Doug I noticed that in several ABNF bits there is an action-param used:

10.1.3 CONTINUE Command
[Snip, snip]
  continueparam   = *(
                  ; the following are optional,
                  ; but MUST NOT occur more than once

                    id-param
                  / localize-param
                  / latency-param

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

                  / action-param


but nowhere in the 09-submitted draft can I find the actual defintion of aciton-param.  Did that get removed by accident or are all the instances of action-param legacy from a prior edit that did not get removed yet??

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 005C654D85256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 12:00:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08454 for ; Wed, 13 Nov 2002 12:00:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADGp1E21357 for ietf-calendar-bks; Wed, 13 Nov 2002 08:51:01 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADGovg21353 for ; Wed, 13 Nov 2002 08:50:58 -0800 (PST) In-Reply-To: <3DD00020.60201@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Nov 2002 10:27:35 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 11:51:01 AM, Serialize complete at 11/13/2002 11:51:01 AM Content-Type: multipart/alternative; boundary="=_alternative 0054E76B85256C6F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054E76B85256C6F_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/11/2002 02:08:16 PM: > > I think that we have a disjoin in our design WRT IDENTIFY. The CU can > > configure the CUA w/a list of identities to try and switch to but the CS > > has the final authority over allowing or disallowing the actualy > > IDENTIFY command to succeed or not. As such I think that there should > > be some way for the CUA to get the list of 'alternate' or assumable > > identities from the CS. > > We agreed a long time ago that user administration is out of scope > in this version if CAP. Yes we did but this concern is NOT administration; its a usability issue!! I am _NOT_ talking about having the CUA somehow administer the list; Im talking about it getting the list so it can use it for the IDENTIFY command (and for any CUA side GUI-isms it wants/needs). I have said before and Ill say it again: There should be some consistant way for a CUA to get a list of identities that it can change to. Otherwise the CUA is just playing Marco Polo trying to see what UPNs the CS will let it switch to! We had this ability early on when the CS returned the 'primary' UPN and a list of other assumable UPNs as part of either authentiation or some other process (I dont have my very early CAP draft markups still...). I do not see this in CAP now and I think it should be there still; I never saw any talk of removing that feature/ability so why did it disappear? > Yes - and we dropped it when we concluded that it was user administration. Got a thread reference? I dont recall that discussion and I certainly disagree w/that conclusion. If the CUA is only reading the list from the CS I dont see how anyone can claim that its an administrative function w/a straight face. Thats like saying reading my calendar is administrative so we may as well drop that too... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0054E76B85256C6F_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/11/2002 02:08:16 PM:
> > I think that we have a disjoin in our design WRT IDENTIFY.  The CU can
> > configure the CUA w/a list of identities to try and switch to but the CS
> > has the final authority over allowing or disallowing the actualy
> > IDENTIFY command to succeed or not.  As such I think that there should
> > be some way for the CUA to get the list of 'alternate' or assumable
> > identities from the CS.
>
> We agreed a long time ago that user administration is out of scope
> in this version if CAP.
Yes we did but this concern is NOT administration; its a usability issue!!  I am _NOT_ talking about having the CUA somehow administer the list; Im talking about it getting the list so it can use it for the IDENTIFY command (and for any CUA side GUI-isms it wants/needs).

I have said before and Ill say it again: There should be some consistant way for a CUA to get a list of identities that it can change to. Otherwise the CUA is just playing Marco Polo trying to see what UPNs the CS will let it switch to!

We had this ability early on when the CS returned the 'primary' UPN and a list of other assumable UPNs as part of either authentiation or some other process (I dont have my very early CAP draft markups still...).  I do not see this in CAP now and I think it should be there still; I never saw any talk of removing that feature/ability so why did it disappear?

> Yes - and we dropped it when we concluded that it was user administration.
Got a thread reference?  I dont recall that discussion and I certainly disagree w/that conclusion.  

If the CUA is only reading the list from the CS I dont see how anyone can claim that its an administrative function w/a straight face.  Thats like saying reading my calendar is administrative so we may as well drop that too...

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

--=_alternative 0054E76B85256C6F_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 12:01:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08486 for ; Wed, 13 Nov 2002 12:01:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADGp6N21365 for ietf-calendar-bks; Wed, 13 Nov 2002 08:51:06 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADGp1g21361 for ; Wed, 13 Nov 2002 08:51:02 -0800 (PST) In-Reply-To: <3DD00105.4060409@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Nov 2002 10:39:59 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 11:51:07 AM, Serialize complete at 11/13/2002 11:51:07 AM Content-Type: multipart/alternative; boundary="=_alternative 00560A1285256C6F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00560A1285256C6F_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 11/11/2002 02:12:05 PM: > > Yes we do but we do not have any clear way to get that information to > > the CUA. That is, there is no clear proscribed way for the CUA to > > "discover" what credentials they may use as inputs for the IDENTIFY > > command. A long time ago a suggestion was made about resolving this > > disjoin. > > Yes - join the SASL WG and make SASL extensions :-) Eh? So now its no longer an administrative issue, its a SASL extension thats undefined?? %^| Im curious how a CS implementation is to derive a UPN from _any_ SASL or CAP or (insert alternate plan here) authentication/authorization mechanism and use it for the CAP session if that feature/ability is "administration" and as such not defined in CAP 1.0? That seems to be deemed "administration" and as such not defined in CAP 1.0. Guess we just dont authenticate at all OR some magical voodoo happens in a per-CS implementation to derive some set of UPNs in any manner each sees fit which may result in different UPNs being generated for the same set of inputs... Just what I want in a protocol designed to promote interoperability. Ok, a bit of sarcasm creeping in due to more than a little frustration so Ill take a deep breath and try again... Still no answer I can grok here: Why is having the CS return a list of UPNs to the CUA after authentication/authorization has taken place considered "administration" or a "SASL" thing? If the CS has the list of UPNs it will allow me to assume using the IDENTIFY command then why is it that it cannot provide me that list on demand? Ahh, I get it; "That would be telling..." > That's a whole new protocol and we agreed that user administration > is out of scope. I don't see any reason that there can not be a > separate draft written and proposed to add that functionality. Let me say this again until it sinks in: Im am not, repeat _NOT_, talking about the CUA doing anything to change the list in any fashion! (Ok so far??) Im talking about having the ability for the CUA to simply read the list from the CS so that it can better use the IDENTIFY command w/o having to guess at what the CS will or will not allow. (Whew, I hope I didnt loose anyone there with such a complex concept.) FMI: Why is this not the "IDENTITY" command since the CUA is changing the identity they are operating as?? 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 00560A1285256C6F_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 11/11/2002 02:12:05 PM:
> > Yes we do but we do not have any clear way to get that information to
> > the CUA.  That is, there is no clear proscribed way for the CUA to
> > "discover" what credentials they may use as inputs for the IDENTIFY
> > command.  A long time ago a suggestion was made about resolving this
> > disjoin.
>
> Yes - join the SASL WG and make SASL extensions :-)
Eh?  So now its no longer an administrative issue, its a SASL extension thats undefined?? %^|

Im curious how a CS implementation is to derive a UPN from _any_ SASL or CAP or (insert alternate plan here) authentication/authorization mechanism and use it for the CAP session if that feature/ability is "administration" and as such not defined in CAP 1.0?  That seems to be deemed "administration" and as such not defined in CAP 1.0.  Guess we just dont authenticate at all OR some magical voodoo happens in a per-CS implementation to derive some set of UPNs in any manner each sees fit which may result in different UPNs being generated for the same set of inputs...  Just what I want in a protocol designed to promote interoperability.

Ok, a bit of sarcasm creeping in due to more than a little frustration so Ill take a deep breath and try again...

Still no answer I can grok here: Why is having the CS return a list of UPNs to the CUA after authentication/authorization has taken place considered "administration" or a "SASL" thing?  If the CS has the list of UPNs it will allow me to assume using the IDENTIFY command then why is it that it cannot provide me that list on demand?  Ahh, I get it; "That would be telling..."

> That's a whole new protocol and we agreed that user administration
> is out of scope. I don't see any reason that there can not be a
> separate draft written and proposed to add that functionality.
Let me say this again until it sinks in: Im am not, repeat _NOT_, talking about the CUA doing anything to change the list in any fashion!  (Ok so far??)  Im talking about having the ability for the CUA to simply read the list from the CS so that it can better use the IDENTIFY command w/o having to guess at what the CS will or will not allow. (Whew, I hope I didnt loose anyone there with such a complex concept.)

FMI: Why is this not the "IDENTITY" command since the CUA is changing the identity they are operating as??

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 00560A1285256C6F_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 12:08:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08775 for ; Wed, 13 Nov 2002 12:08:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADGoeV21341 for ietf-calendar-bks; Wed, 13 Nov 2002 08:50:40 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADGoZg21337 for ; Wed, 13 Nov 2002 08:50:35 -0800 (PST) In-Reply-To: <3DD0026C.7090604@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Nov 2002 10:57:40 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 11:50:40 AM, Serialize complete at 11/13/2002 11:50:40 AM Content-Type: multipart/alternative; boundary="=_alternative 0057A87885256C6F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057A87885256C6F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/11/2002 02:18:04 PM: > > This newer ABNF does NOT make it clear that option-param AND the related > > UPN are either MUST or not at all (to get that "CU wished to switch to > > their original identity.") You need to make that entire line a "0 or 1" > > instance then. The comment in the ABNF does not transcode to the actual > > ABNF thats verifiable otherwise. > > There is no way in ABNF to say when parameters may exist. It is always > described in text. ABNF restricts the data to a specific set, but it > can not without extra text describe it usage. Wrong, it just takes some changing to the ABNF to do this. For example, instead of: identifyparam = *( [Snip, snip] / option-param upn ) You can fix this to be correct using, say: identifyparam = *( [Snip, snip] / [ option-param ] cmd-specific =/ upn ; The option-param cmd-specific value for IDENTIFY ; is a UPN. This now correctly indicates that option-param on IDENTIFY is either there once or not at all. It also correctly indicates that cmd-specific for this command is a UPN (see RFC 2234, Section 3.3 Incremental Alternatives if this notation is unclear to you or go check 2445 where it was used.) > > > Where it should be this to ask to switch back to your original identity: > > > > > > CMD:IDENTITY > > > > > > Or to ask to switch to another identity: > > > > > > CMD;OPTIONS=new-upn-id:IDENTITY > > > > The example used is just the username part of the UPN and not the full > > UPN. Please make sure all examples have properly formed UPNs in the > > draft for those that only code by example... > > Which example is a 'username' ? The cmd-specific value in your last example (left in above) is just new-upn-id. By the defintion of UPN composition in Section 1.3 of all the drafts I checked the format of the UPN is basically: "username" '@' "realm". As such just how does one parse the "new-upn-id" as a valid UPN? Its got to be the username component OR the realm component. HOWEVER your definiton in Section 1.3 does NOT allow just those parts by themselves! Hence, the example is malformed. The example should be something like: CMD;OPTIONS=new-upn-id@some-realm:IDENTITY or you need to change the clear definition of UPN composition in 1.3 to be less accurate/clear. > > 1: I can pipleine several commands at a time so its perfectly valid (and > > probably a good way to attack a CS) to send > 1 IDENTIFY (not IDENTITY) > > command at a time. > > So do you agree with (who ever sent it) that IDENTIFY is channel specific? I havent seen anything that would preclude me from sending multiple IDENTIFY commands on the same channel. Then again I keep chasing drafts so I could have overlooked it. Where is that restriction in the 09-submitted 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 0057A87885256C6F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/11/2002 02:18:04 PM:
> > This newer ABNF does NOT make it clear that option-param AND the related
> > UPN are either MUST or not at all (to get that "CU wished to switch to
> > their original identity.")  You need to make that entire line a "0 or 1"
> > instance then.  The comment in the ABNF does not transcode to the actual
> > ABNF thats verifiable otherwise.
>
> There is no way in ABNF to say when parameters may exist. It is always
> described in text. ABNF restricts the data to a specific set, but it
> can not without extra text describe it usage.
Wrong, it just takes some changing to the ABNF to do this.  For example, instead of:

        identifyparam   = *(
[Snip, snip]
                        / option-param upn
                       )

You can fix this to be correct using, say:

        identifyparam   = *(
[Snip, snip]
                        / [ option-param ]

        cmd-specific     =/ upn
                            ; The option-param cmd-specific value for IDENTIFY
                            ; is a UPN.
This now correctly indicates that option-param on IDENTIFY is either there once or not at all.  It also correctly indicates that cmd-specific for this command is a UPN (see RFC 2234, Section 3.3 Incremental Alternatives if this notation is unclear to you or go check 2445 where it was used.)

> >  > Where it should be this to ask to switch back to your original identity:
> >  >
> >  >       CMD:IDENTITY
> >  >
> >  > Or to ask to switch to another identity:
> >  >
> >  >       CMD;OPTIONS=new-upn-id:IDENTITY
> >
> > The example used is just the username part of the UPN and not the full
> > UPN.  Please make sure all examples have properly formed UPNs in the
> > draft for those that only code by example...
>
> Which example is a 'username' ?
<DIGRESSION>
The cmd-specific value in your last example (left in above) is just new-upn-id.  By the defintion of UPN composition in Section 1.3 of all the drafts I checked the format of the UPN is basically: "username" '@' "realm".  As such just how does one parse the "new-upn-id" as a valid UPN?  Its got to be the username component OR the realm component.  HOWEVER your definiton in Section 1.3 does NOT allow just those parts by themselves!  Hence, the example is malformed.  The example should be something like:

CMD;OPTIONS=new-upn-id@some-realm:IDENTITY

or you need to change the clear definition of UPN composition in 1.3 to be less accurate/clear.
</DIGRESSION>

> > 1: I can pipleine several commands at a time so its perfectly valid (and
> > probably a good way to attack a CS) to send > 1 IDENTIFY (not IDENTITY)
> > command at a time.
>
> So do you agree with (who ever sent it) that IDENTIFY is channel specific?
I havent seen anything that would preclude me from sending multiple IDENTIFY commands on the same channel.  Then again I keep chasing drafts so I could have overlooked it.  Where is that restriction in the 09-submitted 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 0057A87885256C6F_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 12:19:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09254 for ; Wed, 13 Nov 2002 12:19:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADH7i821833 for ietf-calendar-bks; Wed, 13 Nov 2002 09:07:44 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADH7gg21829 for ; Wed, 13 Nov 2002 09:07:42 -0800 (PST) In-Reply-To: <3DD140E2.5080603@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 12:07:40 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 12:07:45 PM, Serialize complete at 11/13/2002 12:07:45 PM Content-Type: multipart/alternative; boundary="=_alternative 005E0AED85256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E0AED85256C70_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/12/2002 12:56:50 PM: > > > > > CMD;OPTIONS=new-upn-id:IDENTITY [Snip, snip] > > CMD;OPTIONS=new-upn-id@some-realm:IDENTITY > > You are joking right? Actually no Im not. I should have used "@some-realm.org" actually so sorry about that. Here is the UPN definition in Section 1.3 of the 09-submitted: User Principal Name (UPN) - A unique identifier that denotes a CU or a group of CU. A UPN is a RFC 822 compliant email address, with exceptions listed below, and in most cases it is deliverable to the CU. In some cases it is identical to the CU's well known email address. A CU's UPN MUST never be an e-mail address that is deliverable to a different person as there is no requirement that a person's UPN MUST BE their e-mail address. A UPN is formatted as a user name followed by "@" followed by a Realm in the form of a valid, and unique, DNS domain name. The user name MUST BE unique within the Realm. In it's simplest form it looks like "user@example.com". In certain cases a UPN will not be RFC 822 compliant. When anonymous authentication is used, or anonymous authorization is being defined, the special UPN "@" will be used. When authentication MUST BE used, but unique identity MUST BE obscured, a UPN of the form @DNS-domain-name may be used. For example, "@example.com". [Emphasis added]. As such the UPN in your example (and the one in Section 10.4) are incorrect; the UPN used does not adhere to the defintion of UPN formatting. (Your example does not adhere to the 2 exceptions in the last paragraph that I can see either.) Unless there is some way to parse "new-upn-id" into the UPN components of Usern ame and Realm that Im just missing, the example you gave originally AND those in the draft are incorrect... > You can not send more that one command at a time on the same channel- a BEEP > restriction. Huh? No it does not. From RFC 3080: 2.6 Asynchrony BEEP accommodates asynchronous interactions, both within a single channel and between separate channels. This feature allows pipelining (intra-channel) and parallelism (inter-channel). 2.6.1 Within a Single Channel A BEEP peer acting in the client role may send multiple "MSG" messages on the same channel without waiting to receive the corresponding replies. This provides pipelining within a single channel. I see that it is possible to "send multiple "MSG" messages on the same channel" so I dont know where you got that idea from. Each MSG contains a new command so I can send multiple IDENTIFY command so this is perhaps what you are thinking about. However, BEEP has NO say in what the contents of CAPs payload are since CAP is newer than BEEP and BEEP does NOT put any kind of "only 1 command" restriction on any BEEP based payload. Also I see NOTHING in CAP 09-b-2, 09-b-3 or 09-submitted that says that the IDENTIFY command MUST be the only command sent in the single payload. We went over this > 1 "VCALENDAR" in a single MIME stream discussion w/John not 3 months ago and you agreed that 2445 allows for: BEGIN:VCALENDAR ... END:VCALENDAR BEGIN:VCALENDAR ... END:VCALENDAR kinds of data. As such I can legally send 2 CMD:IDENTIFY blocks in the same payload. The solution: Expressly preclude it in the next CAP draft. That is, "Only 1 outstanding IDENTIFY command is permitted per CAP session regardless of the number of channels in use." or some other such language. Use BEEPs " security layer negotiation" stuff as a kind of model for this text. Refocusing on the real stuff: Despite all this traffic I still see no argument so far why the CS should _NOT_ send back the list of UPNs that the CUA may use on any IDENTIFY command. There are good reasons to put the removed ability to get the UPNs from the CS back into CAP so I would like to see that done for the next draft (or interim release). Reading the list from the CS is not an administrative feature and that data directly relates to the use of the IDENTIFY command so why is it not in the spec? 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 005E0AED85256C70_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/12/2002 12:56:50 PM:
> >  > >  >       CMD;OPTIONS=new-upn-id:IDENTITY
[Snip, snip]
> > CMD;OPTIONS=new-upn-id@some-realm:IDENTITY
>
> You are joking right?
Actually no Im not.  I should have used "@some-realm.org" actually so sorry about that.  Here is the UPN definition in Section 1.3 of the 09-submitted:

   User Principal Name (UPN) -  A unique identifier that denotes a CU or
     a group of CU.  A UPN is a RFC 822 compliant email address, with
     exceptions listed below, and in most cases it is deliverable to
     the CU.  In some cases it is identical to the CU's well known
     email address.  A CU's UPN MUST never be an e-mail address that is
     deliverable to a different person as there is no requirement that
     a person's UPN MUST BE their e-mail address.  A UPN is formatted
     as a user name followed by "@" followed by a Realm in the form of
     a valid, and unique, DNS domain name.  The user name MUST BE
     unique within the Realm.  In  it's simplest form it looks like
     "user@example.com".

     In certain cases a UPN will not be RFC 822 compliant.  When
     anonymous authentication is used, or anonymous authorization is
     being defined, the special UPN "@" will be used.  When
     authentication MUST BE used, but unique identity MUST BE obscured,
     a UPN of the form @DNS-domain-name may be used.  For example,
     "@example.com".

[Emphasis added].  As such the UPN in your example (and the one in Section 10.4) are incorrect; the UPN used does not adhere to the defintion of UPN formatting.    (Your example does not adhere to the 2 exceptions in the last paragraph that I can see either.)

Unless there is some way to parse "new-upn-id" into the UPN components of Usern ame and Realm that Im just missing, the example you gave originally AND those in the draft are incorrect...

> You can not send more that one command at a time on the same channel- a BEEP
> restriction.

Huh?  No it does not.  From RFC 3080:

2.6 Asynchrony

  BEEP accommodates asynchronous interactions, both within a single
  channel and between separate channels.  This feature allows
  pipelining (intra-channel) and parallelism (inter-channel).

2.6.1 Within a Single Channel

  A BEEP peer acting in the client role may send multiple "MSG"
  messages on the same channel without waiting to receive the
  corresponding replies.  This provides pipelining within a single
  channel.

I see that it is possible to "send multiple "MSG" messages on the same channel" so I dont know where you got that idea from.  Each MSG contains a new command so I can send multiple IDENTIFY command so this is perhaps what you are thinking about.  However, BEEP has NO say in what the contents of CAPs payload are since CAP is newer than BEEP and BEEP does NOT put any kind of "only 1 command" restriction on any BEEP based payload.  Also I see NOTHING in CAP 09-b-2, 09-b-3 or 09-submitted that says that the IDENTIFY command MUST be the only command sent in the single payload.

We went over this > 1 "VCALENDAR" in a single MIME stream discussion w/John not 3 months ago and you agreed that 2445 allows for:

BEGIN:VCALENDAR
...
END:VCALENDAR
BEGIN:VCALENDAR
...
END:VCALENDAR

kinds of data.  As such I can legally send 2 CMD:IDENTIFY blocks in the same payload.

The solution: Expressly preclude it in the next CAP draft.  That is, "Only 1 outstanding IDENTIFY command is permitted per CAP session regardless of the number of channels in use." or some other such language.  Use BEEPs "security layer negotiation" stuff as a kind of model for this text.

Refocusing on the real stuff:

Despite all this traffic I still see no argument so far why the CS should _NOT_  send back the list of UPNs that the CUA may use on any IDENTIFY command.  There are good reasons to put the removed ability to get the UPNs from the CS back into CAP so I would like to see that done for the next draft (or interim release).

Reading the list from the CS is not an administrative feature and that data directly relates to the use of the IDENTIFY command so why is it not in the spec?

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 005E0AED85256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 12:23:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09417 for ; Wed, 13 Nov 2002 12:23:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADHDnB22005 for ietf-calendar-bks; Wed, 13 Nov 2002 09:13:49 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADHDlg22001 for ; Wed, 13 Nov 2002 09:13:47 -0800 (PST) In-Reply-To: <3DD140E2.5080603@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 12:13:45 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 12:13:49 PM, Serialize complete at 11/13/2002 12:13:49 PM Content-Type: multipart/alternative; boundary="=_alternative 005E998585256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E998585256C70_= Content-Type: text/plain; charset="US-ASCII" Doug responded wrote on 11/12/2002 12:56:50 PM: > > I havent seen anything that would preclude me from sending multiple > > IDENTIFY commands on the same channel. Then again I keep chasing drafts > > so I could have overlooked it. Where is that restriction in the > > 09-submitted draft? > > You can not send more that one command at a time on the same channel- a BEEP > restriction. So yes you can send IDENTIFY commands all day as long > on the same channel as you only send one command at a time. The CS will or > will error out on each one as received. Which is a better approach to take: 1: Make the CUA guess at what UPNs a CS will allow it to assume and risk getting the session terminated or generating extra network traffic, etc OR 2: Allow the CUA to get the list of allowed UPNs from the CS so that a single command can be issued (if allowed) w/o fear of seemingly arbitrary rejection I think #2 is the better approach for a new protocol. What about everyone 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 005E998585256C70_= Content-Type: text/html; charset="US-ASCII"
Doug responded wrote on 11/12/2002 12:56:50 PM:
> > I havent seen anything that would preclude me from sending multiple
> > IDENTIFY commands on the same channel.  Then again I keep chasing drafts
> > so I could have overlooked it.  Where is that restriction in the
> > 09-submitted draft?
>
> You can not send more that one command at a time on the same channel- a BEEP
> restriction. So yes you can send IDENTIFY commands all day as long
> on the same channel as you only send one command at a time. The CS will or
> will error out on each one as received.
Which is a better approach to take:

1: Make the CUA guess at what UPNs a CS will allow it to assume and risk getting the session terminated or generating extra network traffic, etc OR

2: Allow the CUA to get the list of allowed UPNs from the CS so that a single command can be issued (if allowed) w/o fear of seemingly arbitrary rejection

I think #2 is the better approach for a new protocol.  What about everyone 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 005E998585256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 12:37:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09756 for ; Wed, 13 Nov 2002 12:37:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADHRx122735 for ietf-calendar-bks; Wed, 13 Nov 2002 09:27:59 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADHRug22727 for ; Wed, 13 Nov 2002 09:27:56 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gADHRuIR032046 for ; Wed, 13 Nov 2002 09:27:56 -0800 Message-ID: <3DD28B99.507@Royer.com> Date: Wed, 13 Nov 2002 10:27:53 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030406020201040004040602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030406020201040004040602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > That works. Given this do we want to allow multiple IDENTIFY commands > per channel or not?? Im all for not allowing them but if making a new > BEEP channel is an expensive operation then maybe we do want to allow it... I do not think it makes any differance as a CUA could go from the original to I-1, back to the original, then to I-2, ... anyway on the same channel. > > No that is not what it says. It does NOT say 'if the IDENTIFY command > > fails...', it says 'If a CS considers the "IDENTIFY" command an > attempt to > > violate security...'. > > So even if the IDENTIFY is a success the CS could "consider the > "IDENTIFY" command an attempt to violate security" and shut down my BEEP > session "without any further notice" so I have no clue why the hell the > CS just punted me for doing an IDENTIFY command that I should be able to > do...??? Feel free to implement your security that way - I will not be doing that. I feel that other will not do that. However if your implementations considers that a security violation, then this current wording makes it work for both of us and in a compatible way. I for one do not need permission from a specification to terminate a connection without notice for a whatever I consider a security violation. > Id love to hear the Tech Support call on that one. (Making > this determination is an implementation issue and thus falls under > Administration or Configuration which is OOB for CAP 1.0 but the CAP 1.0 > does not distinguish between this happening for failure cases only which > is where I think it should and any possible case...) > . > > If the draft clearly stated that such a determination was for failure > cases then I would agree too. Currently it does not. As such some CS > could have a policy that says "5 IDENTIFY commands w/in 1 minute may be > a hacker so drop them" then its possible that my efficient team AA could > accidentally trip this and get punted from the CS w/o warning or notice > for using IDENTIFY to put a team meeting on all of our calendars. Poor > design IMHO. I think the current wording is correct. It is NOT per failure, it is for when the implementation considers it a security violation. If a specific implementation hangs up on your CUA without notice, call the owner of the CS or go to another vendor, ISP, or whatever. > > > Kind of a harsh response to a single failure at least in my mind. > > > > Please point to the text that says 'a single failure' causes the BEEP > > session to be terminated when the IDENTIFY command fails. > > The determination of how the CS "considers the "IDENTIFY" command an > attempt to violate security" is vague enough that its possible that a > single failure could cause the termination of the BEEP session "without > any further notice". Again - if your implementaion considers that a security violation, I would expect it to terminate the connection. I might consider any attempt to become the 'root' user a security violation when the connection from from the WAN and not the LAN and hang up on the first failure. Or I might not depending on the installation. -- 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 --------------ms030406020201040004040602 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzE3Mjc1M1owIwYJKoZIhvcNAQkEMRYEFAKC32WS CoqHM+vcHUaJa6k2q9tWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQA5S4WhGkOfpN8pAZNh UIJVNdWGlMCrkldyZT0lHnecIgq4W6Pu5uRpwu4maiX87wUr1N8+FsFol1T5y8Bf0L/Zzbgg Ag4HqsUnpRNr0FHY/LWCXF5vklQE0hJn5/0TU+ZkZYocGzH+nLoV/GoLwS1If/n27AKuTYiK o165+XJjoX/mFF1kAjFaGOK+5jpqORwAmx+6lQ/sCiWbU71Zo+EGWyU1f5NjYk1K1qaYyfwd fmvql1bstW+6Y1Nw4hk+OA1VEzvPaCTVGu3DBnu8GqKuj6XdeTaJp3iuSCviigSvZPWlvEKj hMB+hKLp1DJAMs/3bAEmNlGkN2tx1YAljD2LAAAAAAAA --------------ms030406020201040004040602-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 12:42:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10049 for ; Wed, 13 Nov 2002 12:42:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADHVkn23309 for ietf-calendar-bks; Wed, 13 Nov 2002 09:31:46 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADHVig23301 for ; Wed, 13 Nov 2002 09:31:44 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gADHViIR032079 for ; Wed, 13 Nov 2002 09:31:44 -0800 Message-ID: <3DD28C7D.90907@Royer.com> Date: Wed, 13 Nov 2002 10:31:41 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: action-param? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080009080306080208070408" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080009080306080208070408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In diving on the 10.4 IDENTIFY issues w/Doug I noticed that in several > ABNF bits there is an action-param used: > > 10.1.3 CONTINUE Command > [Snip, snip] > continueparam = *( > ; the following are optional, > ; but MUST NOT occur more than once > > id-param > / localize-param > / latency-param > > ; the following MUST occur exactly once and only > ; when the latency-param has been supplied and > ; MUST NOT be supplied if the latency-param is > ; not supplied. > > / action-param > > > but nowhere in the 09-submitted draft can I find the actual defintion of > aciton-param. Did that get removed by accident or are all the instances > of action-param legacy from a prior edit that did not get removed yet?? It is mis-spelled in section 10.1 as 'action-parm': action-parm = ";" "ACTION" "=" ( "ASK" / "ABORT" ) ; If latency is supplied then action MUST BE ; supplied. Thanks - I have fixed my copy. -- 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 --------------ms080009080306080208070408 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzE3MzE0MVowIwYJKoZIhvcNAQkEMRYEFDygqR7u FlMsvFkLtwB1bTf6jxQZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBhLygdqaSvbinlCbQF Dy2hhzHuRvVEX34uO5mVLHIdekp2pmEnGs/bEVkvkmCSJ0zomMjbQxyTZoN+S9ejQyiO1TY1 ocG83zBqsFIdVN58WjG5XKEh9z0X94NRL4FHerx7ci3UrlLEo4pUR1WS93NW3/vtBo4oDmnn yigAuiUEhLT3qQcPrv3z/vFN8U0rzHIk/SN1yyYwNIRpFKc1OyG16djVlTRvtLeVmof8EXb7 VhPl6JWDMmW1JbORJgKAfcZX3Ybh68G5h5sh8jDgLdxDy7Akm03RKS577I9HYkVcO5PZZW+W GlBQU2sIRuC4f/i4waQpv34ZwhgxprbWho2fAAAAAAAA --------------ms080009080306080208070408-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 12:50:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10397 for ; Wed, 13 Nov 2002 12:50:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADHg1S24993 for ietf-calendar-bks; Wed, 13 Nov 2002 09:42:01 -0800 (PST) Received: from web10704.mail.yahoo.com (web10704.mail.yahoo.com [216.136.130.212]) by above.proper.com (8.11.6/8.11.3) with SMTP id gADHfxg24987 for ; Wed, 13 Nov 2002 09:41:59 -0800 (PST) Message-ID: <20021113174200.1491.qmail@web10704.mail.yahoo.com> Received: from [63.243.84.50] by web10704.mail.yahoo.com via HTTP; Wed, 13 Nov 2002 09:42:00 PST Date: Wed, 13 Nov 2002 09:42:00 -0800 (PST) From: Frank Spafford Subject: RDATE question To: ietf-calendar@imc.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2105705964-1037209320=:590" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0-2105705964-1037209320=:590 Content-Type: text/plain; charset=us-ascii I looked through the archives, but I can't find an answer to this question. Suppose I have a repeating event, say a meeting, and the meeting has a LOCATION property of "Conference room 4". For one meeting, however, the location is changed to "Conference room 2". How should I handle this situation? Would this work: RDATE;LOCATION=Conference room 2;TZID="Central Time (US & Canada)":20021107T100000,20021108T100000 --------------------------------- Do you Yahoo!? U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD --0-2105705964-1037209320=:590 Content-Type: text/html; charset=us-ascii

I looked through the archives, but I can't find an answer to this question.

Suppose I have a repeating event, say a meeting, and the meeting has a LOCATION property of "Conference room 4".  For one meeting, however, the location is changed to "Conference room 2".

How should I handle this situation?

Would this work:

RDATE;LOCATION=Conference room 2;TZID="Central Time (US & Canada)":20021107T100000,20021108T100000

 


Do you Yahoo!?
U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD --0-2105705964-1037209320=:590-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 13:34:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11936 for ; Wed, 13 Nov 2002 13:34:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADIKxR26470 for ietf-calendar-bks; Wed, 13 Nov 2002 10:20:59 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADIKvg26463 for ; Wed, 13 Nov 2002 10:20:57 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP/BEEP: Establishing a session MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 13:19:36 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 01:21:00 PM, Serialize complete at 11/13/2002 01:21:00 PM Content-Type: multipart/alternative; boundary="=_alternative 0064BFB585256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064BFB585256C70_= Content-Type: text/plain; charset="US-ASCII" According to RFC 3030 (Section 2.5.1 Session Management) a mapping document like CAP should provide: A mapping document must define: o how a BEEP session is established; I just rescanned the CAP 09-submitted draft and do not see any such info in it. Did I overlook it or has it not been added? Im assuming it will be somewhere in the TBD part of: 12.1 BEEP Profile Registration TBD but I wanted to check just in case. 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 0064BFB585256C70_= Content-Type: text/html; charset="US-ASCII"
According to RFC 3030 (Section 2.5.1 Session Management) a mapping document like CAP should provide:

                                            A mapping document must
  define:

  o  how a BEEP session is established;

I just rescanned the CAP 09-submitted draft and do not see any such info in it.  Did I overlook it or has it not been added?  Im assuming it will be somewhere in the TBD part of:

12.1 BEEP Profile Registration

  TBD

but I wanted to check just in case.

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 0064BFB585256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 13:34:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11967 for ; Wed, 13 Nov 2002 13:34:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADINDj26784 for ietf-calendar-bks; Wed, 13 Nov 2002 10:23:13 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADINBg26777 for ; Wed, 13 Nov 2002 10:23:12 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP/BEEP: Session release & termination MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 13:21:51 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 01:23:14 PM, Serialize complete at 11/13/2002 01:23:14 PM Content-Type: multipart/alternative; boundary="=_alternative 0064F44A85256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064F44A85256C70_= Content-Type: text/plain; charset="US-ASCII" According to RFC 3030 (Section 2.5.1 Session Management) a mapping document like CAP should provide: A mapping document must define: [Snip] o how a BEEP session is released; and o how a BEEP session is terminated. I just rescanned the CAP 09-submitted draft and do not see any such info in it. Did I overlook it or has it not been added? Im assuming it will be somewhere in the TBD part of: 12.1 BEEP Profile Registration TBD but I wanted to check just in case. 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 0064F44A85256C70_= Content-Type: text/html; charset="US-ASCII"
According to RFC 3030 (Section 2.5.1 Session Management) a mapping document like CAP should provide:

                                            A mapping document must
  define:
[Snip]
  o  how a BEEP session is released; and

   o  how a BEEP session is terminated.

I just rescanned the CAP 09-submitted draft and do not see any such info in it.  Did I overlook it or has it not been added?  Im assuming it will be somewhere in the TBD part of:

12.1 BEEP Profile Registration

  TBD

but I wanted to check just in case.

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 0064F44A85256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 13:45:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12201 for ; Wed, 13 Nov 2002 13:45:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADIXde28411 for ietf-calendar-bks; Wed, 13 Nov 2002 10:33:39 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADIXbg28407 for ; Wed, 13 Nov 2002 10:33:37 -0800 (PST) To: ietf-calendar@imc.org Subject: 3.2 Calendar Store Object Model Revisited MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 13:32:17 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 01:33:40 PM, Serialize complete at 11/13/2002 01:33:40 PM Content-Type: multipart/alternative; boundary="=_alternative 0065E8BF85256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065E8BF85256C70_= Content-Type: text/plain; charset="US-ASCII" I see that for the 09-submitted draft half of my previously suggested changes got applied to the diagram in Section 3.2 Calendar Store Object Model. The "VFREEBUSY" was made plural correctly. However instead of making the diagram show plural VAGENDAs, mulitple singluar ones are used instead. I think we should be consistant in our diagram and remove the subsequent VAGENDA bit and make the 1st VAGENDA plural. 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 0065E8BF85256C70_= Content-Type: text/html; charset="US-ASCII"
I see that for the 09-submitted draft half of my previously suggested changes got applied to the diagram in Section 3.2 Calendar Store Object Model.  

The "VFREEBUSY" was made plural correctly.  However instead of making the diagram show plural VAGENDAs, mulitple singluar ones are used instead.  I think we should be consistant in our diagram and remove the subsequent VAGENDA bit and make the 1st VAGENDA plural.

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 0065E8BF85256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 13:54:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12606 for ; Wed, 13 Nov 2002 13:54:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADIj2m28638 for ietf-calendar-bks; Wed, 13 Nov 2002 10:45:02 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADIj0g28634 for ; Wed, 13 Nov 2002 10:45:00 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP: ABNF is incomplete MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 13:43:39 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 01:45:03 PM, Serialize complete at 11/13/2002 01:45:03 PM Content-Type: multipart/alternative; boundary="=_alternative 0066F33485256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066F33485256C70_= Content-Type: text/plain; charset="US-ASCII" In several places the ABNF is incomplete and therefore not usable as is. For example: id-param = ";" "ID" "=" unique-id ; The text value supplied is a unique value ; shared between the CUA and CS to uniquely ; identify the instance of command in the ; the current CUA session. The value has ; no meaning to other CUAs or other sessions. unique-id = ; text localize-param = ";" "LOCALIZE" "=" beep-localize ; The value supplied MUST BE one value from the initial ; BEEP greeting 'localize' attribute specifying ; the locale to use for error messages during ; this instance of the command sent. beep-localize = ; text In both of these cases there is no legal way to evaluate beep-localize and unique-id. Perhaps the intent was to have: beep-localize = text ;Some reference to 'localize' values from BEEP... but I dont want to make that assumption. In any case there should be no 'dangling' ABNF like we have above or its not possible to validate a CAP payload. 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 0066F33485256C70_= Content-Type: text/html; charset="US-ASCII"
In several places the ABNF is incomplete and therefore not usable as is.  For example:

   id-param         = ";" "ID" "=" unique-id
                   ; The text value supplied is a unique value
                   ; shared between the CUA and CS to uniquely
                   ; identify the instance of command in the
                   ; the current CUA session. The value has
                   ; no meaning to other CUAs or other sessions.

  unique-id        = ; text

  localize-param   = ";" "LOCALIZE" "=" beep-localize
                   ; The value supplied MUST BE one value from the initial
                   ; BEEP greeting 'localize' attribute specifying
                   ; the locale to use for error messages during
                   ; this instance of the command sent.

  beep-localize    = ; text

In both of these cases there is no legal way to evaluate beep-localize and unique-id.

Perhaps the intent was to have:

   beep-localize    = text ;Some reference to 'localize' values from BEEP...

but I dont want to make that assumption.  In any case there should be no 'dangling' ABNF like we have above or its not possible to validate a CAP payload.

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 0066F33485256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 14:04:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13098 for ; Wed, 13 Nov 2002 14:04:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADIu0a29142 for ietf-calendar-bks; Wed, 13 Nov 2002 10:56:00 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADItwg29138 for ; Wed, 13 Nov 2002 10:55:58 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP: integer in ABNF MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 13:54:37 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 01:56:01 PM, Serialize complete at 11/13/2002 01:56:01 PM Content-Type: multipart/alternative; boundary="=_alternative 0067F46785256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067F46785256C70_= Content-Type: text/plain; charset="US-ASCII" The ABNF in CAP 09-submitted has several references to integer in it: latency-param = ";" "LATENCY" "=" latency-sec ; The value supplied in the time in seconds. ; If latency is supplied then action MUST BE ; supplied. latency-sec = integer and alarm-seq = "SEQUENCE" alarmseqparam ":" integer CRLF however there is no definition of 'integer' in the CAP ABNF. There is no integer defined in the ABNF RFC so Im guessing that perhaps the definition from 2445 was assumed/intended? Is this correct? If it was then I think its wrong as the ABNF in 2445 defines it as: integer = (["+"] / "-") 1*DIGIT [Snip] The valid range for "integer" is -2147483648 to 2147483647. If the sign is not specified, then the value is assumed to be positive. so that would allow a negative value for nodes like latency-sec and alarm-seq. Clearly this is not what we want. I think that CAP should take a more proactive approach to defining the ABNF bits much like BEEP did with channel or seqno: seqno = 0..4294967295 This approach clearly delimits the upper and lower allowable values and prevents negatives where they should not be allowed. 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 0067F46785256C70_= Content-Type: text/html; charset="US-ASCII"
The ABNF in CAP 09-submitted has several references to integer in it:

   latency-param    = ";" "LATENCY" "=" latency-sec
                   ; The value supplied in the time in seconds.
                   ; If latency is supplied then action MUST BE
                   ; supplied.

  latency-sec      = integer

and

    alarm-seq   = "SEQUENCE" alarmseqparam ":" integer CRLF

however there is no definition of 'integer' in the CAP ABNF.  There is no integer defined in the ABNF RFC so Im guessing that perhaps the definition from 2445 was assumed/intended?  Is this correct?  

If it was then I think its wrong as the ABNF in 2445 defines it as:

     integer    = (["+"] / "-") 1*DIGIT
[Snip]
                          The valid range for "integer" is -2147483648 to
    2147483647. If the sign is not specified, then the value is assumed
    to be positive.

so that would allow a negative value for nodes like latency-sec and alarm-seq.  Clearly this is not what we want.

I think that CAP should take a more proactive approach to defining the ABNF bits much like BEEP did with channel or  seqno:

   seqno      = 0..4294967295

This approach clearly delimits the upper and lower allowable values and prevents negatives where they should not be allowed.

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 0067F46785256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 14:09:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13312 for ; Wed, 13 Nov 2002 14:09:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADIw1h29210 for ietf-calendar-bks; Wed, 13 Nov 2002 10:58:01 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADIvxg29206 for ; Wed, 13 Nov 2002 10:57:59 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP: option-value MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 13:56:39 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 01:58:02 PM, Serialize complete at 11/13/2002 01:58:02 PM Content-Type: multipart/alternative; boundary="=_alternative 006823F585256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006823F585256C70_= Content-Type: text/plain; charset="US-ASCII" In analyzing the ABNF I ran across an unused or orphaned bit: option-value = paramtext option-value is not mentioned or referenced in any part of the draft or ABNF. Did it get orphaned in some edit or did some other change happen that caused the bit to get left in by accident? 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 006823F585256C70_= Content-Type: text/html; charset="US-ASCII"
In analyzing the ABNF I ran across an unused or orphaned bit:

   option-value     = paramtext

option-value is not mentioned or referenced in any part of the draft or ABNF.  Did it get orphaned in some edit or did some other change happen that caused the bit to get left in by accident?

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 006823F585256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 14:13:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13521 for ; Wed, 13 Nov 2002 14:13:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADJ4lc29436 for ietf-calendar-bks; Wed, 13 Nov 2002 11:04:47 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADJ4ig29428 for ; Wed, 13 Nov 2002 11:04:45 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP ABNF and external references MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 14:04:41 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 02:04:48 PM, Serialize complete at 11/13/2002 02:04:48 PM Content-Type: multipart/alternative; boundary="=_alternative 0068C1CC85256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068C1CC85256C70_= Content-Type: text/plain; charset="US-ASCII" The ABNF in a draft should be fully self contained or at best note what other RFCs it is inheriting content from. RFC 2234 is assumed because it defines the ABNF notation. Other RFCs are not assumed normally and I can see no text that says "ABNF components from RFC 2445 and 3080 are used in some cases below". Mainly because I dont see much inheritance to note. I do see some that do require you to be very familiar w/the ABNF of 2445 to fully parse: latency-sec = integer [Snip] option-value = paramtext Given the minor ABNF content that is in really an external reference I think we should either clearly note it in the prose OR include the relevant ABNF parts here for completeness. I prefer the latter as it makes buidling an ABNF tree easier but it does add some 'duplicate' content (although very little from what Ive seen). 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 0068C1CC85256C70_= Content-Type: text/html; charset="US-ASCII"
The ABNF in a draft should be fully self contained or at best note what other RFCs it is inheriting content from.  RFC 2234 is assumed because it defines the ABNF notation.  Other RFCs are not assumed normally and I can see no text that says "ABNF components from RFC 2445 and 3080 are used in some cases below".  Mainly because I dont see much inheritance to note.

I do see some that do require you to be very familiar w/the ABNF of 2445 to fully parse:

   latency-sec      = integer
[Snip]
  option-value     = paramtext

Given the minor ABNF content that is in really an external reference I think we should either clearly note it in the prose OR include the relevant ABNF parts here for completeness.  I prefer the latter as it makes buidling an ABNF tree easier but it does add some 'duplicate' content (although very little from what Ive seen).

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 0068C1CC85256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 14:20:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13808 for ; Wed, 13 Nov 2002 14:20:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADJBcC29845 for ietf-calendar-bks; Wed, 13 Nov 2002 11:11:38 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADJBbg29841 for ; Wed, 13 Nov 2002 11:11:37 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP: Repeating iCalendar ABNF mistakes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 14:11:34 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 02:11:40 PM, Serialize complete at 11/13/2002 02:11:40 PM Content-Type: multipart/alternative; boundary="=_alternative 006962DF85256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006962DF85256C70_= Content-Type: text/plain; charset="US-ASCII" In trying to build a full ABNF tree from the 09-submitted draft I note that we are forgetting the mistakes of RFC 2445 when we have ABNF like: create-cmd = createparam ":" "CREATE" createparam = *( ; the following are optional, ; but MUST NOT occur more than once id-param / localize-param / latency-param ; the following MUST occur exactly once and only ; when the latency-param has been supplied and ; MUST NOT be supplied if the latency-param is ; not supplied. / action-param ; the following is optional, ; and MAY occur more than once / (";" xparam) ) To save time for those who dont recall the issue: The ABNF does not allow non-'X-" params on this command. That is, if we later define a new parameter for the CREATE command an older parser would treat the line as invalid as the new iana-token (or iana-prop if you prefer) is NOT valid in the older ABNF. We noted this last year in iCalendar and vowed to fix it. However we made the same mistake on all our CAP commands... We can either define an iana-param (ie: iana-param = iana-token '=' iana-token / x-token) and add it or we can use some other proper "iana-..." component in the ABNF. Related Note: I see that iana-prop is used in the ABNF often but is NEVER defined. It is NOT inherited from RFC 2445 so its just missing... 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 006962DF85256C70_= Content-Type: text/html; charset="US-ASCII"
In trying to build a full ABNF tree from the 09-submitted draft I note that we are forgetting the mistakes of RFC 2445 when we have ABNF like:

   create-cmd     = createparam ":" "CREATE"

  createparam    = *(

                 ; the following are optional,
                 ; but MUST NOT occur more than once

                  id-param
                 / localize-param
                 / latency-param

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

                 / action-param

                 ; the following is optional,
                 ; and MAY occur more than once

                 / (";" xparam)
                )

To save time for those who dont recall the issue: The ABNF does not allow non-'X-" params on this command.  That is, if we later define a new parameter for the CREATE command an older parser would treat the line as invalid as the new iana-token (or iana-prop if you prefer) is NOT valid in the older ABNF.  We noted this last year in iCalendar and vowed to fix it.  However we made the same mistake on all our CAP commands...

We can either define an iana-param (ie: iana-param = iana-token '=' iana-token / x-token) and add it or we can use some other proper "iana-..." component in the ABNF.

Related Note: I see that iana-prop is used in the ABNF often but is NEVER defined.  It is NOT inherited from RFC 2445 so its just missing...

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 006962DF85256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 14:42:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14592 for ; Wed, 13 Nov 2002 14:42:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADJWDP02672 for ietf-calendar-bks; Wed, 13 Nov 2002 11:32:13 -0800 (PST) Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADJW9g02667 for ; Wed, 13 Nov 2002 11:32:10 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp7.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id gADJW7BH003604; Wed, 13 Nov 2002 14:32:07 -0500 Date: Wed, 13 Nov 2002 14:32:07 -0500 Message-Id: <200211131932.gADJW7BH003604@smtp7.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: ietf-calendar@imc.org, Bruce_Kahn@notesdev.ibm.com In-reply-to: Subject: Re: CAP/BEEP: Establishing a session References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 13:19:36 -0500 [1 ] According to RFC 3030 (Section 2.5.1 Session Management) a mapping document like CAP should provide: [I presume you mean RFC 3080.] A "mapping document" for BEEP is mapping BEEP onto a lower network layer. In CAP's case, this is done by RFC 3081, which defines uses BEEP on top of TCP. A "BEEP profile" is what CAP is, and that's what 12.1 is reserved for. The requirements for a BEEP profile are in section 5.1 of RFC 3080. Larry From owner-ietf-calendar@mail.imc.org Wed Nov 13 14:44:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14650 for ; Wed, 13 Nov 2002 14:44:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADJYGL02713 for ietf-calendar-bks; Wed, 13 Nov 2002 11:34:16 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADJYCg02709 for ; Wed, 13 Nov 2002 11:34:12 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gADJYCIR000656 for ; Wed, 13 Nov 2002 11:34:12 -0800 Message-ID: <3DD2A931.605@Royer.com> Date: Wed, 13 Nov 2002 12:34:09 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RDATE question References: <20021113174200.1491.qmail@web10704.mail.yahoo.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010902050006060703040100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010902050006060703040100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit That's one reason for the ADD method. You can ADD a VEVENT to a repeating set of instances. It has the same UID as the associated repeating events. I recall it being added when we realized that if you meet once a month at location X on Monday, then need to change one instance (or more) to location Y on Tuesday (for example), then there was no way to keep it as part of the same set. So we added the 'ADD' method. Frank Spafford wrote: > I looked through the archives, but I can't find an answer to this question. > > Suppose I have a repeating event, say a meeting, and the meeting has a > LOCATION property of "Conference room 4". For one meeting, however, the > location is changed to "Conference room 2". > > How should I handle this situation? > > Would this work: > > RDATE;LOCATION=Conference room 2;TZID="Central Time (US & > Canada)":20021107T100000,20021108T100000 > > > > > ------------------------------------------------------------------------ > Do you Yahoo!? > U2 on LAUNCH > - > Exclusive medley & videos from Greatest Hits CD -- 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 --------------ms010902050006060703040100 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzE5MzQwOVowIwYJKoZIhvcNAQkEMRYEFMPDx1Bj +SPQztCr11fGDy96+cjTMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQA5Pog4OsUgEUJq9Rcg jmdLc6XDRMT2v+n/9Hgr6CxwB3ndN1gbYfGiy4pb3xr4w2m3YHNcmZMqjdEFDdqeDclWh62J 81BdJ2xCjXVY1WC1IGeyqXPkjDtscPuE0Amr/f/LwoaSXSM6U0cEZxTBJfmSxwgCMOGgHScV seWMXbrKAdxE1CZWjaGChU6W9et/+9/+98gKG8udZ01XfDoeYbXgRD0M1+v2zz0RozN65wgJ zm3U2lDau7iCNBSE8OTtA0SAe7Eo2Oj10j2LlXeJ2qkcxUEJHkdrJz9Xf8M7aiPoPPebsutA 5P3HATL4EC0PC2x2LjQ+0eNpy3d1ti+xNsrWAAAAAAAA --------------ms010902050006060703040100-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 14:49:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14911 for ; Wed, 13 Nov 2002 14:49:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADJcSJ02826 for ietf-calendar-bks; Wed, 13 Nov 2002 11:38:28 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADJcPg02822 for ; Wed, 13 Nov 2002 11:38:25 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gADJcMIR000704 for ; Wed, 13 Nov 2002 11:38:23 -0800 Message-ID: <3DD2AA2B.4030004@Royer.com> Date: Wed, 13 Nov 2002 12:38:19 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: ABNF is incomplete References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030402080000000100060105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030402080000000100060105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sorry - I maybe missing you point. Are you saying add the comment ';Some reference to 'localize' values from' to 'beep-locaize' describing its usage? Bruce_Kahn@notesdev.ibm.com wrote: > > In several places the ABNF is incomplete and therefore not usable as is. > For example: > > id-param = ";" "ID" "=" unique-id > ; The text value supplied is a unique value > ; shared between the CUA and CS to uniquely > ; identify the instance of command in the > ; the current CUA session. The value has > ; no meaning to other CUAs or other sessions. > > unique-id = ; text > > localize-param = ";" "LOCALIZE" "=" beep-localize > ; The value supplied MUST BE one value from the initial > ; BEEP greeting 'localize' attribute specifying > ; the locale to use for error messages during > ; this instance of the command sent. > > beep-localize = ; text > > In both of these cases there is no legal way to evaluate beep-localize > and unique-id. > > Perhaps the intent was to have: > > beep-localize = text ;Some reference to 'localize' values from > BEEP... > > but I dont want to make that assumption. In any case there should be no > 'dangling' ABNF like we have above or its not possible to validate a CAP > payload. > > 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... -- 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 --------------ms030402080000000100060105 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzE5MzgxOVowIwYJKoZIhvcNAQkEMRYEFNwLps1Y YhFaWQDeNV25JAYsWuw4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCdwbGv1W1qifXEnnO1 XPpJPLiBRQRQ6xhAtPoL/xIDNLv4CfxVWh+rP+HHgFN33omkxGf6HChhtJtckrVJvDepPdYH +5VpeiiJLHOlri1C/jJVI7ZdpoIf0T8ZjVRBfPkDYnX7WuMCKRcx+jV0u/QqwqTpLc+WdS0l FGKhH4kqA8pP3wmQA6AiIavsGIarZSRV9ffaax/X3bSg5x/rzGWkqGKfR7fzL0T9icnR9dxS iQVT39KqR/WoLEorCRZMeauYaAvtNMXB0wCqvLcUeSS2lViXXY8UrX0ZruRabiwjf2RXfPIp bT/X3Jz4TP4qsc/MeIsGqVngnpUAwJy73nuPAAAAAAAA --------------ms030402080000000100060105-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 14:59:58 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15250 for ; Wed, 13 Nov 2002 14:59:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADJmvP03090 for ietf-calendar-bks; Wed, 13 Nov 2002 11:48:57 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADJmrg03085 for ; Wed, 13 Nov 2002 11:48:54 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gADJmpIR000761 for ; Wed, 13 Nov 2002 11:48:52 -0800 Message-ID: <3DD2AC9F.5050302@Royer.com> Date: Wed, 13 Nov 2002 12:48:47 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: Repeating iCalendar ABNF mistakes References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020903030709000003030309" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020903030709000003030309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In trying to build a full ABNF tree from the 09-submitted draft I note > that we are forgetting the mistakes of RFC 2445 when we have ABNF like: > > create-cmd = createparam ":" "CREATE" > > createparam = *( > > ; the following are optional, > ; but MUST NOT occur more than once > > id-param > / localize-param > / latency-param > > ; the following MUST occur exactly once and only > ; when the latency-param has been supplied and > ; MUST NOT be supplied if the latency-param is > ; not supplied. > > / action-param > > ; the following is optional, > ; and MAY occur more than once > > / (";" xparam) > ) > > To save time for those who dont recall the issue: The ABNF does not > allow non-'X-" params on this command. I agree - I have added a '...iana-token ; as defined in RFC2445...' to CAP. > That is, if we later define a > new parameter for the CREATE command an older parser would treat the > line as invalid as the new iana-token (or iana-prop if you prefer) is > NOT valid in the older ABNF. We noted this last year in iCalendar and > vowed to fix it. However we made the same mistake on all our CAP > commands... I can not find the discussion. What was wrong with 'iana-token' in 2445? > We can either define an iana-param (ie: iana-param = iana-token '=' > iana-token / x-token) and add it or we can use some other proper > "iana-..." component in the ABNF. > > Related Note: I see that iana-prop is used in the ABNF often but is > NEVER defined. It is NOT inherited from RFC 2445 so its just missing... I added text saying '...as defined in [iCAL]...' > 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... -- 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 --------------ms020903030709000003030309 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzE5NDg0N1owIwYJKoZIhvcNAQkEMRYEFAQVu8z1 lLMwaLULsqXvGIxNs5ulMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBAuzR1Smss8yfcXzfi two4doRcMPcTvd6koAfOoROW012mi2f1KekfCCpVJwyslXuUd224G8hPJLswvDkPuScWHhhP tmSJEIKX7zqEhG+DgwZuYLfFIwlGx7WXji3ZI8XROxWyROLjHao4g8P2LKdrlUMMfFKS+EPw vR0XlE9zFgxLjG2xYDdFrhMARKDJ2PgeuHCZY0hcRGtYHJAGHJxe2z1Clln1Br8gUeM85sST 1w5NaZ8ZxtWuW9UksIZUFw5+37HsnKo/uu7I6qhsIFLgAYgGIoO2vDrqt3bpQPQNgsyseCdC vHu8sDlPpYOyTSCv/TygFRhqsd+nQZwjV9ERAAAAAAAA --------------ms020903030709000003030309-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 15:06:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15524 for ; Wed, 13 Nov 2002 15:06:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADJtIP03226 for ietf-calendar-bks; Wed, 13 Nov 2002 11:55:18 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADJtGg03216 for ; Wed, 13 Nov 2002 11:55:16 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gADJtFIR000821 for ; Wed, 13 Nov 2002 11:55:16 -0800 Message-ID: <3DD2AE1F.8030603@Royer.com> Date: Wed, 13 Nov 2002 12:55:11 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP ABNF and external references References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020606040808050004080509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020606040808050004080509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks - I added '; As defined in [iCAL]' Bruce_Kahn@notesdev.ibm.com wrote: > > The ABNF in a draft should be fully self contained or at best note what > other RFCs it is inheriting content from. RFC 2234 is assumed because > it defines the ABNF notation. Other RFCs are not assumed normally and I > can see no text that says "ABNF components from RFC 2445 and 3080 are > used in some cases below". Mainly because I dont see much inheritance > to note. > > I do see some that do require you to be very familiar w/the ABNF of 2445 > to fully parse: > > latency-sec = integer > [Snip] > option-value = paramtext -- 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 --------------ms020606040808050004080509 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzE5NTUxMVowIwYJKoZIhvcNAQkEMRYEFJkX+xMA nKSLzmqlT4vyhv3GGmCJMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCThkm95gFu0EbqtNtd mSOVMbXkx8lI5WQCKzVYTYgUbgjDnpzIKPUxrLWQFY9mjhB0bm0RrCTO++q7YFgTdmoHjwAh RW58mjz9nv33D8wrCjYjh5esayC1+bOEjbQlB6Rd8bQSu23AY9uw6ciSXuyTromUL3nZ93Ee z5DTuYEDW6i4E7tkS8NrfCAFmQLbzG6viCV9J5x2loJT51T7OvAmudVeYu4juwWg3jTziJAG f7CIKt1F7UFMv6qKefdF/t+14lBtkk37+hZb4RnADCAdpek57ytdcsw8IpZ35VFQ2lof0z+X X+aD2Z9MbWFDXCKE2wVgtgUQKhGYE48CcrvtAAAAAAAA --------------ms020606040808050004080509-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 15:17:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15930 for ; Wed, 13 Nov 2002 15:17:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADK9eY04055 for ietf-calendar-bks; Wed, 13 Nov 2002 12:09:40 -0800 (PST) Received: from carwash.centivinc.com (carwash.centivinc.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id gADK9cg04051 for ; Wed, 13 Nov 2002 12:09:38 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2002111315211625184 for ; Wed, 13 Nov 2002 15:21:16 -0500 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 15:07:37 -0500 Message-ID: <3DD2B109.3020803@centivinc.com> Date: Wed, 13 Nov 2002 15:07:37 -0500 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? References: <41E12C33-F1EA-11D6-A048-003065A8EEFC@inet.it> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2002 20:07:37.0395 (UTC) FILETIME=[4FE69030:01C28B50] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: > It's true that this doesn't improve interoperability at all, but it > allows matching CUA and CS to do very powerful queries with minimum > effort. But such nonstandard implementations could just make up their own mechanisms to do those nonstandard queries. -- /===============================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |===============================================================| |If you're going to walk on thin ice, you might as well *dance*!| \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Nov 13 15:19:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15974 for ; Wed, 13 Nov 2002 15:19:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADKA5Y04077 for ietf-calendar-bks; Wed, 13 Nov 2002 12:10:05 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADKA1g04070 for ; Wed, 13 Nov 2002 12:10:01 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gADK9vIR000956 for ; Wed, 13 Nov 2002 12:09:58 -0800 Message-ID: <3DD2B192.6080904@Royer.com> Date: Wed, 13 Nov 2002 13:09:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: integer in ABNF References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070501050508060009030901" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070501050508060009030901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yep - your right - also note that in iCAL, the REPEAT value is integer allowing for (-12) instances :-) So I added 'integer' to CAP to the text and say as defined in iCAL. p-integer = 1*DIGIT ; Where DIGIT is defined in [iCAL] And I changed both latency-sec and alarm-seq to use p-integer. Bruce_Kahn@notesdev.ibm.com wrote: > > The ABNF in CAP 09-submitted has several references to integer in it: > > latency-param = ";" "LATENCY" "=" latency-sec > ; The value supplied in the time in seconds. > ; If latency is supplied then action MUST BE > ; supplied. > > latency-sec = integer > > and > > alarm-seq = "SEQUENCE" alarmseqparam ":" integer CRLF > > however there is no definition of 'integer' in the CAP ABNF. There is > no integer defined in the ABNF RFC so Im guessing that perhaps the > definition from 2445 was assumed/intended? Is this correct? > > If it was then I think its wrong as the ABNF in 2445 defines it as: > > integer = (["+"] / "-") 1*DIGIT > [Snip] > The valid range for "integer" is -2147483648 to > 2147483647. If the sign is not specified, then the value is assumed > to be positive. > > so that would allow a negative value for nodes like latency-sec and > alarm-seq. Clearly this is not what we want. > > I think that CAP should take a more proactive approach to defining the > ABNF bits much like BEEP did with channel or seqno: > > seqno = 0..4294967295 > > This approach clearly delimits the upper and lower allowable values and > prevents negatives where they should not be allowed. > > 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... -- 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 --------------ms070501050508060009030901 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzIwMDk1NVowIwYJKoZIhvcNAQkEMRYEFMLfhy/U JS0jbXsXLmF+iBM08CygMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCdqtjA7XCgja6IXxig V0D+kMsJcpSVchZompWySyWgeytPEzyqag1cwzpj+MNrPcLQjnI/qbGFLSsMvVbw0T0LQKfB hGG40aEvy+ljbKWUMybl3ZZN93ifHiUBg3iTWbUCLGQHj3q/dH5q1csmdP81jlyRta3XdoHo Db+5PvkNBAtX+AiheH71OlmwYFExt4ikBbwgsTqMj1VO3S/7rpzPOdnfNZL5NFtZVNfkdGCF D6n941brxOAhOk1xU/OYt58T0NYOTiTbvO1cIXPufqLyAW96A4YyKf5EmQFaFaonJiE9Q4vZ scR3LvIbcq1m1mLaVPPRBlqvxbdwq7eXAM7/AAAAAAAA --------------ms070501050508060009030901-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 17:07:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19814 for ; Wed, 13 Nov 2002 17:07:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADLroP10037 for ietf-calendar-bks; Wed, 13 Nov 2002 13:53:50 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADLrhg10031 for ; Wed, 13 Nov 2002 13:53:44 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP: Unused ABNF / Restriction tables MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 14:21:23 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 04:53:50 PM, Serialize complete at 11/13/2002 04:53:50 PM Content-Type: multipart/alternative; boundary="=_alternative 006A493485256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A493485256C70_= Content-Type: text/plain; charset="US-ASCII" As part of my ABNF analysis I ran across this in the 09-submitted draft: Restriction table for the "CREATE" command: create-minimum = "BEGIN" ":" "VCALENDAR" CRLF calprops *(iana-prop) *(x-prop) 1*(create-comp) "END" ":" "VCALENDAR" CRLF ; If The following contain the "METHOD" ; property they MUST conform to [iTIP]. ; create-comp = agendac / carc / queryc / timezonec / freebusyc / eventc / todoc / journalc / iana-comp / x-component and I have 3 questions/issues: 1: The snippet is not a restriction table, its an ABNF bit so the text is misleading. 2: The ABNF is NEVER referenced anywhere in the draft so either its stale or it got disconnected in some edit. Either way it needs fixing or removing. 3: The comment in the ABNF says that the component contains the METHOD property but thats illegal; the METHOD property is part of calprops, NOT inside a component like an eventc, todoc, etc! It should say something like: ; If the 'calprops' contains the "METHOD" ; property then the 'create-comp' component MUST ; conform to [iTIP] restrictions. (I think that references to other ABNF actual parts must be single quoted in the comment or at least we did it in 2445...) Of course iTIP does not have tables for 'carc' components so that last bit could use a bit of weasle wording to say "conform to iTIP if defined in iTIP or subsequent revisions...." 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 006A493485256C70_= Content-Type: text/html; charset="US-ASCII"
As part of my ABNF analysis I ran across this in the 09-submitted draft:

   Restriction table for the "CREATE" command:

  create-minimum = "BEGIN" ":" "VCALENDAR" CRLF
                   calprops
                   *(iana-prop)
                   *(x-prop)
                   1*(create-comp)
                   "END" ":" "VCALENDAR" CRLF

                 ; If The following  contain the "METHOD"
                 ; property they MUST conform to [iTIP].
                 ;
   create-comp = agendac / carc / queryc
                 / timezonec / freebusyc
                 / eventc / todoc / journalc
                 / iana-comp / x-component

and I have 3 questions/issues:

1: The snippet is not a restriction table, its an ABNF bit so the text is misleading.  
2: The ABNF is NEVER referenced anywhere in the draft so either its stale or it got disconnected in some edit.  Either way it needs fixing or removing.
3: The comment in the ABNF says that the component contains the METHOD property but thats illegal; the METHOD property is part of calprops, NOT inside a component like an eventc, todoc, etc! It should say something like:

                  ; If the 'calprops' contains the "METHOD"
                 ; property then the 'create-comp' component MUST
                  ; conform to [iTIP] restrictions.
(I think that references to other ABNF actual parts must be single quoted in the comment or at least we did it in 2445...)  Of course iTIP does not have tables for 'carc' components so that last bit could use a bit of weasle wording to say "conform to iTIP if defined in iTIP or subsequent revisions...."

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 006A493485256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 17:08:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19905 for ; Wed, 13 Nov 2002 17:08:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADLrr510043 for ietf-calendar-bks; Wed, 13 Nov 2002 13:53:53 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADLrng10039 for ; Wed, 13 Nov 2002 13:53:50 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP: To delete or not to... MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 13 Nov 2002 14:41:06 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/13/2002 04:53:55 PM, Serialize complete at 11/13/2002 04:53:55 PM Content-Type: multipart/alternative; boundary="=_alternative 006C16FA85256C70_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C16FA85256C70_= Content-Type: text/plain; charset="US-ASCII" The issue of actual deletion vs 'marked for deletion' never got resolved. I think its something that absolutely MUST be resolved and in a very unambiguous way before we can pass WG Last Call. The 09-submitted draft implys that actual deletes are performed by the CUA with text like: 2.2 Relationship of RFC-2446 (ITIP) and CAP ... Other CAP commands such as "DELETE", "MODIFY" and "MOVE" command values provide direct manipulation of components. ... followed by a "DELETE" command to remove any related old [iTIP] objects from the CS. ... Finally, the CUA could do a "DELETE" command to remove the related "UNPROCESSED" state objects. and 10.1.5 DELETE Command CMD: DELETE Purpose: The "DELETE" command physically removes the QUERY result from the store or marks it for deletion. ... The "DELETE" command is used to delete calendars or components. The included "VQUERY" component(s) specifies the container(s) to delete. If a component is to be marked for delete and not physically removed, then include the "OPTIONS" parameter with its value set to the "MARK" value in order to alter its state to "DELETED". In some citations you will note the clear distinction between actual deletion and marking for deletion. However no where is there any text dealing with what can be done on entries marked for deletion but not actually removed. As such the essentially go into limbo. This is not good unless you are a storage manufacturer. The possible choices for dealing w/marked for deletion entries is to: 1) Allow some way to restore them to full health (aka "Undelete" them) or 2) Clearly state that they are as good as actually removed, can never be restored and will be actually removed at some point later at the CS discression (its an administration issue now...) There are technical hurdles taking either approach we can dive on later but I think we need to reach WG concensus about deletions and if these "marked for deletion" (aka soft-deletes in my dB world) are something we want/need and then we can address the hurdles based on that choice. If folks think that knowing the hurdles first is important we can lay them out first... In any case, I think that having actual deletions and 'marked for deletion' requires more than 3 states we have defined in Section 1.3 now (Booked/Unprocessed/Deleted) since some text implys that any kind of deleted entry can be read. For example: 3. A "DELETED" state entry is created by sending a "DELETE" command with the "OPTION" parameter value set to "MARK". To retrieve any deleted object, simply do a query asking for any objects that were stored in the "DELETED" state. As the new text says the "DELETED" state is if OPTION=MARK is set then the entry is DELETEd. It does not define the state of the entry when the CMD:DELETE is used w/o OPTION=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... --=_alternative 006C16FA85256C70_= Content-Type: text/html; charset="US-ASCII"
The issue of actual deletion vs 'marked for deletion' never got resolved.  I think its something that absolutely MUST be resolved and in a very unambiguous way before we can pass WG Last Call.

The 09-submitted draft implys that actual deletes are performed by the CUA with text like:

2.2 Relationship of RFC-2446 (ITIP) and CAP
...
                                  Other CAP commands such as
  "DELETE", "MODIFY" and "MOVE" command values provide direct
  manipulation of components.
...
  followed by a "DELETE" command to remove any related old [iTIP]
  objects from the CS.
...
                                          Finally, the CUA could do a
  "DELETE" command to remove the related "UNPROCESSED" state objects.

and

10.1.5 DELETE Command

  CMD: DELETE

  Purpose: The "DELETE" command physically removes the QUERY result
  from the store or marks it for deletion.
...
   The "DELETE" command is used to delete calendars or components.  The
  included "VQUERY" component(s) specifies the container(s) to delete.

  If a component is to be marked for delete and not physically removed,
  then include the "OPTIONS" parameter with its value set to the "MARK"
  value in order to alter its state to "DELETED".
In some citations you will note the clear distinction between actual deletion and marking for deletion.

However no where is there any text dealing with what can be done on entries marked for deletion but not actually removed.  As such the essentially go into limbo.  This is not good unless you are a storage manufacturer.  

The possible choices for dealing w/marked for deletion entries is to:

1) Allow some way to restore them to full health (aka "Undelete" them) or
2) Clearly state that they are as good as actually removed, can never be restored and will be actually removed at some point later at the CS discression (its an administration issue now...)

There are technical hurdles taking either approach we can dive on later but I think we need to reach WG concensus about deletions and if these "marked for deletion" (aka soft-deletes in my dB world) are something we want/need and then we can address the hurdles based on that choice.  If folks think that knowing the hurdles first is important we can lay them out first...

In any case, I think that having actual deletions and 'marked for deletion' requires more than 3 states we have defined in Section 1.3 now (Booked/Unprocessed/Deleted) since some text implys that any kind of deleted entry can be read.  For example:

      3.  A "DELETED" state entry is created by sending a "DELETE"
         command with the "OPTION" parameter value set to "MARK".  To
         retrieve any deleted object, simply do a query asking for any
         objects that were stored in the "DELETED" state.

As the new text says the "DELETED" state is if OPTION=MARK is set then the entry is DELETEd.  It does not define the state of the entry when the CMD:DELETE is used w/o OPTION=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... --=_alternative 006C16FA85256C70_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 17:42:51 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20782 for ; Wed, 13 Nov 2002 17:42:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADMWU011569 for ietf-calendar-bks; Wed, 13 Nov 2002 14:32:30 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADMWRg11565 for ; Wed, 13 Nov 2002 14:32:28 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gADMWSIR002082 for ; Wed, 13 Nov 2002 14:32:28 -0800 Message-ID: <3DD2D2F9.1070508@Royer.com> Date: Wed, 13 Nov 2002 15:32:25 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: To delete or not to... References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050902030006090702030707" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050902030006090702030707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > However no where is there any text dealing with what can be done on > entries marked for deletion but not actually removed. As such the > essentially go into limbo. This is not good unless you are a storage > manufacturer. You can remove them. Why do you think that you can not? > The possible choices for dealing w/marked for deletion entries is to: > > 1) Allow some way to restore them to full health (aka "Undelete" them) or That was covered in my e-mail. What did you think of my comments? > 2) Clearly state that they are as good as actually removed, can never be > restored and will be actually removed at some point later at the CS > discression (its an administration issue now...) It is up to the CUA to remove them from the CS. > 3. A "DELETED" state entry is created by sending a "DELETE" > command with the "OPTION" parameter value set to "MARK". To > retrieve any deleted object, simply do a query asking for any > objects that were stored in the "DELETED" state. > > As the new text says the "DELETED" state is if OPTION=MARK is set then > the entry is DELETEd. It does not define the state of the entry when > the CMD:DELETE is used w/o OPTION=MARK... Yes it does: If a component is to be marked for delete and not physically removed, then include the "OPTIONS" parameter with its value set to the "MARK" value in order to alter its state to "DELETED". If MARK is not set - it is physically removed. -- 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 --------------ms050902030006090702030707 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzIyMzIyNVowIwYJKoZIhvcNAQkEMRYEFJqP17ov J6AqDUtQy7A2VunN5ZmkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAm2mcA2MAW2saJ2DMU nEIIrO47hhLAohpmqUXecWZtBEQnFLAUuKEWc97579jKuaLZRUjEmLX/tvC0/+yUdThAlP4p xiVPmn9arOxJfUFoedD8aNm4b6XypZyHtCQ8hJKXwH8W/XlImJKET9GNX+tIa8cu8CxuU/73 t2gUFuXLCimAqsh61jdrT9YnmoibOVB4r2zmj6Vm5DmgQyA4x7qp49qtl7yavXXBCl3JHHFV iMzAWWGGO6FXGjmVpHDFnL+jyf7QLOpyLkZR+nNI2gfJXbR7nw2XsfLb7JN8H5bATk5S84so JMcluPkdmjfMi7UP7z2K3ho206whVkxvXJb8AAAAAAAA --------------ms050902030006090702030707-- From owner-ietf-calendar@mail.imc.org Wed Nov 13 18:34:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21736 for ; Wed, 13 Nov 2002 18:34:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADNMgO14002 for ietf-calendar-bks; Wed, 13 Nov 2002 15:22:42 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADNMdg13995 for ; Wed, 13 Nov 2002 15:22:39 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gADNMeIR002469 for ; Wed, 13 Nov 2002 15:22:40 -0800 Message-ID: <3DD2DEBD.1050704@Royer.com> Date: Wed, 13 Nov 2002 16:22:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: Unused ABNF / Restriction tables References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040806000704000808010906" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040806000704000808010906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > As part of my ABNF analysis I ran across this in the 09-submitted draft: > > ... > > and I have 3 questions/issues: > > 1: The snippet is not a restriction table, its an ABNF bit so the text > is misleading. Fixed thanks. > 2: The ABNF is NEVER referenced anywhere in the draft so either its > stale or it got disconnected in some edit. Either way it needs fixing > or removing. I'll add the missing links - thanks for catching that. I'll check the other commands - they may have the same issue. > 3: The comment in the ABNF says that the component contains the METHOD > property but thats illegal; the METHOD property is part of calprops, NOT > inside a component like an eventc, todoc, etc! It should say something > like: > > ; If the 'calprops' contains the "METHOD" > ; property then the 'create-comp' component MUST > ; conform to [iTIP] restrictions. Fixed - 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 --------------ms040806000704000808010906 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzIzMjIzN1owIwYJKoZIhvcNAQkEMRYEFB2vs5+D JEfks6x6zT4tsHndhwI+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB1r3addH8+pXLkzNMt BDLff3JTbTJmmcWpzSIINaNlsz6sniZT6tbQgqpOMNd2v6GoxvVKq5d1pGIhrqkw0O91loLf Wag1BmcW7Ramlhe+V3+PIM7ZVaCo7zdnyE3jONFDjtADEjZh4c7CkDULia1dQ5nS5fVM+G8z /uwNOSpH8gH5Tb6KhTCcc6Hq0zD9mRFXZbappwXEKcH/1ocgPpAkaLIK+8vEgeeluTMs+R6+ KfuTO2hYqRu43QExnpCG+7/Mu+SZsPSEYKA+D0dmX44cGm0oqgwGls8/MtuyBIb0DTNsZJpo TqNOvtWmI3rCcOuoV8tTtwMtcryVUmTwmaEgAAAAAAAA --------------ms040806000704000808010906-- From owner-ietf-calendar@mail.imc.org Thu Nov 14 12:32:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25003 for ; Thu, 14 Nov 2002 12:32:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEHJjO18145 for ietf-calendar-bks; Thu, 14 Nov 2002 09:19:45 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEHJgg18140 for ; Thu, 14 Nov 2002 09:19:43 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 5AEDE155D1; Thu, 14 Nov 2002 18:19:40 +0100 (CET) Date: Thu, 14 Nov 2002 18:19:40 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command Message-ID: <20021114171940.GA99121@inet.it> References: 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.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 11, 2002 at 11:05:03AM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Andrea Campi wrote on 11/06/2002 07:50:40 PM: > > Sorry but I don't get your point. After all, we do use SASL, so we have > > separate autentication and authorization information available. > > CUA. That is, there is no clear proscribed way for the CUA to "discover" > what credentials they may use as inputs for the IDENTIFY command. A long > time ago a suggestion was made about resolving this disjoin. [...] > Does this make it clearer? [I just came back from a few days' vacation and I'm slowly catching up] Yes now it's clear. I agree some mechanism for discovering allowed identities would be useful, but I also see Doug has some reason in calling this 'administration' - as in CUA, not CS, administration. After all, this comes into play when you authorize somebody to act as your attendee; since the way you do this is out of scope for CAP, it could be argued that anything more complex than you telling your attendee what the right identity is, is out of scope too. Also, your argument would also extend to: once you are authenticated, how do you discover which UPNs you are authorized to access? Should your CUA search for them and apply VCAR (I hope not) or will it try accessing all of them and see what the CS replies? IMHO, some amount of client administration will be needed no matter what. This is not to say I'm against adding such a mechanism; on the contrary, I think it would be great (and in fact we need it or everybody will implement something like this in different ways). It's just that I don't think we MUST do it NOW (maybe we can start right now to prepare a separate RFC? I have no idea). 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 Nov 14 14:00:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27094 for ; Thu, 14 Nov 2002 14:00:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEIm0o23876 for ietf-calendar-bks; Thu, 14 Nov 2002 10:48:00 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEIlwg23870 for ; Thu, 14 Nov 2002 10:47:58 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 561A7155D1; Thu, 14 Nov 2002 19:47:59 +0100 (CET) Date: Thu, 14 Nov 2002 19:47:59 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: CAP: integer in ABNF Message-ID: <20021114184759.GA99436@inet.it> References: <3DD2B192.6080904@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD2B192.6080904@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Nov 13, 2002 at 01:09:54PM -0700, Doug Royer wrote: > So I added 'integer' to CAP to the text and say as defined in iCAL. > > p-integer = 1*DIGIT ; Where DIGIT is defined in [iCAL] > > And I changed both latency-sec and alarm-seq to use p-integer. This is just a small pet peeve... p-integer is ugly (IMHO), why not use unsigned or uint? 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 Nov 14 14:08:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27321 for ; Thu, 14 Nov 2002 14:08:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEJ2mU25895 for ietf-calendar-bks; Thu, 14 Nov 2002 11:02:48 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEJ2kg25891 for ; Thu, 14 Nov 2002 11:02:46 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 71B56155D1; Thu, 14 Nov 2002 20:02:47 +0100 (CET) Date: Thu, 14 Nov 2002 20:02:47 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: CAP: Cleanly disconnecting Message-ID: <20021114190247.GB99436@inet.it> References: <3DD003E2.4080408@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD003E2.4080408@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 11, 2002 at 12:24:18PM -0700, Doug Royer wrote: > > > Bruce_Kahn@notesdev.ibm.com wrote: > > > >In the latest CAP draft I notice that there is still no command to allow > >a CUA to cleanly disconnect from the CAP server. > > Section 2.4 of BEEP describes how to close a connection by > sending a close on channel zero (0). > > A CAP 'BUY' command would be superfluous. > I don't agree. OK, BEEP is the chosen transport; but I still think that this is a break of network layering. I definitely agree with Bruce - we should have a 'BYE' command of sort. 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 Nov 14 14:32:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27919 for ; Thu, 14 Nov 2002 14:32:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEJLbx26329 for ietf-calendar-bks; Thu, 14 Nov 2002 11:21:37 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEJLZg26324 for ; Thu, 14 Nov 2002 11:21:36 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id DD398155D1; Thu, 14 Nov 2002 20:21:34 +0100 (CET) Date: Thu, 14 Nov 2002 20:21:34 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II Message-ID: <20021114192134.GC99436@inet.it> References: <3DD00A04.3000206@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD00A04.3000206@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 11, 2002 at 12:50:28PM -0700, Doug Royer wrote: > So - you can only authenticate once per BEEP session. Agreed (and this is correct from a security point of view). > So the question to answer is: does the CAP IDENTIFY command > effect one channel - or is it global? > > If per channel - then we need to add text like: > > An IDENTIFY command is per BEEP channel. The IDENTIFY > command does not effect other channels. The new identity > only effects new commands issued by the CUA and after > receiving an IDENTIFY success reply code (x.x) from the CS > on that channel. Yes please; also Bruce seems to be in agreement. > > If a CS considers the "IDENTIFY" command an attempt to violate > > security, the CS MAY terminate the BEEP session without any further > > notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. > > > > No that is not what it says. It does NOT say 'if the IDENTIFY command > fails...', it says 'If a CS considers the "IDENTIFY" command an attempt to > violate security...'. > > And I agree. What about: If a CS detects a sequence of failures in response to one or more "IDENTIFY" commands it considers an attempt to violate security, the CS MAY terminate the BEEP session without any further notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. It is a good idea to trigger this behavior after n failures. Does this satisfy everybody? Bruce, note that you are still guaranteed to get a REQUEST-STATUS. We could even state more explicitely: The REQUEST-STATUS value SHOULD indicate this is a security violation disconnection. What do you say? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Nov 15 08:22:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07647 for ; Fri, 15 Nov 2002 08:22:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAFDEFS28032 for ietf-calendar-bks; Fri, 15 Nov 2002 05:14:15 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFDECg28028 for ; Fri, 15 Nov 2002 05:14:12 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 75CEA1556B; Fri, 15 Nov 2002 14:14:12 +0100 (CET) Date: Fri, 15 Nov 2002 14:14:12 +0100 From: Andrea Campi To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? Message-ID: <20021115131412.GB2149@inet.it> References: <41E12C33-F1EA-11D6-A048-003065A8EEFC@inet.it> <3DD2B109.3020803@centivinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD2B109.3020803@centivinc.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Nov 13, 2002 at 03:07:37PM -0500, John Stracke wrote: > > Andrea Campi wrote: > > >It's true that this doesn't improve interoperability at all, but it > >allows matching CUA and CS to do very powerful queries with minimum > >effort. > > But such nonstandard implementations could just make up their own > mechanisms to do those nonstandard queries. What part of the standard does it violate? Where is text to the effect that a CUA MUST have stored the query before calling it? If the CUA finds the query there, and is permitted to call it, and it knows what to do with the results, I see nothing nonstandard. Yes, a CUA would either need to fallback to using normal queries or end up being tied to a CS. This could be a reasonable tradeoff for special purpose CUAs where space or time are limiting factors. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Nov 15 08:23:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07666 for ; Fri, 15 Nov 2002 08:23:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAFD9kh27680 for ietf-calendar-bks; Fri, 15 Nov 2002 05:09:46 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFD9hg27672 for ; Fri, 15 Nov 2002 05:09:43 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id C36DA1556B; Fri, 15 Nov 2002 14:09:40 +0100 (CET) Date: Fri, 15 Nov 2002 14:09:40 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? Message-ID: <20021115130940.GA2149@inet.it> References: <41E12C33-F1EA-11D6-A048-003065A8EEFC@inet.it> 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.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 11, 2002 at 10:27:45AM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Since the query has to be encoded in CAP-QL and there is no way to > interpret what cannot be encoded in CAP-QL I dont see how a CS can > transcode a 'fixed' query into one that means "All events on my calendar > for today". Should the CS somehow infer it from the explicit CAP-QL > language? Uhm no, I meant some kind of "synthetic" VQUERY - the CS put it there itself. > Oh, are you suggesting that there is some Out-of-band mechanism to place > non-CAP-QL encodable queries into the CS and then the CUA just references > them? Seems like kind of a wishfull thing given CAP-QL and the robustness > of it. I can understand if you questioned the usefulness or the interoperability of such a thing, but I don't understand your objection. A CUA and a CS would have no problem; heck, you could even write an RFC to standardize an "opaque" VQUERY. As long as the CUA knows how the VQUERY is named and what it returns, I think it would be both realistic and robust. > Also, there is now way for the CUA to actually pull the VQUERY from the CS > to check it or modify it. After all my CUA should be able to check all > VQUERYs in the CS so just how would the CS encode the unencodable VQUERY > that is stored?? Would the CS just say "Sorry, you cant have that > VQUERY!"? Why not tell the truth? The CS would reply: BEGIN:VQUERY QUERYID:All VEVENTs for today END:VQUERY If the CUA and CS adhere to a common convention, the CUA would know what to expect as a reply if it called this query. > as is. There are 2 possible paths to take here: > > 1: Extend CAP-QL so that wildcarding is possible OR Uhm... ok. But I don't see anything in the draft that forbids what I was talking about. So I'd say, extending CAP-QL is good, but it won't remove the usefullness of my example nor would outlaw it. > 2: Remove the concept of stored VQUERYs > > I dont say remove named VQUERYs since I can have more than 1 VQUERY 'in > use' at any given time. I'm getting lost now. What use would named query be if they can't be stored? I don't see how having more than one in use, whatever that means, affects what we are discussing. If the CUA issues more than one query at once, it will use cmd-id to find the answers, not the queryid. > Im just for simplifying the model a bit. If there is strong enough desire > for #1 then some new ABNF and prose is in order and then we can discuss > the impact of that change. We may also need a way for the CS to respond > "I dont support query storage" in GET-CAPABILITY for those more > lightweight CS's (a comment I posted a year or so ago I think). Sure. > > It's true that this doesn't improve interoperability at all, but it > > allows matching CUA and CS to do very powerful queries with minimum > > effort. > > But CAP-QL was supposed to be so rich that we could craft any query in it. > (Ok a bit of sarcasm on a Monday AM...) It's also a question of workload split. For a very very simple example, not meant to support the idea by itself, think about a query for "all events in this week". The client needs to compute them by itself, then create a vquery and send it (or possibly call a stored query with the right arguments). Depending on the client architecture, the number of times the user quits and restarts its CUA, etc this can be done a number of times. OTOH, since everybody is going to use the same query, the server will probably have this information (when does this week start and end?) cached. This is a trivial example, but multiply it by a number of similar cases and then by thousands of CUAs connected to the server at the same time... it saves power on the CUA, on the CS (no need to parse the VQUERY again and again) and network traffic. Oh and by the way, this is one of the reasons why I like your idea of views - the CUA would send the query and then ask the server to refresh it from time to time... > > Now, if we extended CAP-QL to allow parameters in stored query > > invocation, I'd be even happier. However, allowing the syntax now and > > building on it later on is better than nothing... > > Care to propose the new ABNF and prose then? > I am not familiar enough with ABNF and I have no idea ATM if I have enough time. I will try to come up with an informal proposal to see if we are agree. OK? But I, for one, will not stop using stored queries as I explained. 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 Sun Nov 17 10:25:22 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19727 for ; Sun, 17 Nov 2002 10:25:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAHF1H211804 for ietf-calendar-bks; Sun, 17 Nov 2002 07:01:17 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAHF1Fg11800 for ; Sun, 17 Nov 2002 07:01:15 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA28814 for ; Sun, 17 Nov 2002 10:01:15 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA22244 for ; Sun, 17 Nov 2002 10:01:12 -0500 (EST) Received: from [66.92.67.186] (airport.bobmah.com [66.92.67.186]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA17969 for ; Sun, 17 Nov 2002 10:01:12 -0500 (EST) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: Date: Sun, 17 Nov 2002 10:01:07 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: CALSCH dinner Monday night Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For those at the meeting and interested, I'll be in the lobby of the meeting hotel at 6 pm Monday, near the registration desk, and then heading off to our traditional group dinner. Exact destination to be worked out at the very last minute, as always... :-) (I'm open to change here, but thought I'd put a stake in the ground. I will be in route the rest of today.) I will be at the apps area meeting Monday morning. Also, Pat will not be able to attend this meeting. -Bob From owner-ietf-calendar@mail.imc.org Mon Nov 18 09:38:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22094 for ; Mon, 18 Nov 2002 09:38:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIEG1o26499 for ietf-calendar-bks; Mon, 18 Nov 2002 06:16:01 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIEFwg26495 for ; Mon, 18 Nov 2002 06:15:58 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA14579; Mon, 18 Nov 2002 09:15:57 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA23244; Mon, 18 Nov 2002 09:15:56 -0500 (EST) Received: from [204.42.65.194] (dhcp-204-42-73-93.ietf55.ops.ietf.org [204.42.73.93]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA21067; Mon, 18 Nov 2002 09:15:46 -0500 (EST) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: In-Reply-To: References: Date: Mon, 18 Nov 2002 09:03:05 -0500 To: pregen@egenconsulting.com From: Bob Mahoney Subject: Re: Remote access to the CALSCH meeting in Atlanta Cc: ietf-calendar@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Gentle poke: providing remote text access will require a "scribe" (in addition to the minutes scribe), willing to fill the role below. Please drop me a note if you're here in Atlanta and interested in volunteering... -Bob >2.1. What the Chair does > >When a session starts, the chair asks if someone in the room is willing to >act as "scribe". If no one volunteers, read no further, we're done! > >Otherwise, the scribe should do a "Join Group Chat" with their Jabber >client, e.g., > > Group/Room: foobar > Server: conference.ietf.jabber.com > > >2.2. What the Scribe does > >The scribe types in a running commentary as to what's going on in the room. >For example, if a speaker makes a presentation, the scribe types >in the URL for the presentation (more on this in a bit). > >Simlarly, during question time, a remote participant can type a question >into the room and the scribe can pass it on to the speaker. From owner-ietf-calendar@mail.imc.org Mon Nov 18 11:24:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25692 for ; Mon, 18 Nov 2002 11:24:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIG90804140 for ietf-calendar-bks; Mon, 18 Nov 2002 08:09:00 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIG8pg04129 for ; Mon, 18 Nov 2002 08:08:55 -0800 (PST) In-Reply-To: <3DD2AE1F.8030603@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP ABNF and external references MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 11:08:40 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 11:08:57 AM, Serialize complete at 11/18/2002 11:08:57 AM Content-Type: multipart/alternative; boundary="=_alternative 0058891E85256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058891E85256C75_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/13/2002 02:55:11 PM: > Thanks - I added '; As defined in [iCAL]' Im sorry I wasnt a bit more clear in my original posting; this change is probably not sufficient. The definition/ABNF for integer in RFC 2445 is: integer = (["+"] / "-") 1*DIGIT Description: If the property permits, multiple "integer" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. The valid range for "integer" is -2147483648 to 2147483647. If the sign is not specified, then the value is assumed to be positive. As such it is valid to have negative or "0" LATENCY. I think CAP should adopt the BEEP approach of expressly defining a range of allowed values ala: msgno = 0..2147483647 so that the allowed range is non-negative at least. In the latency-seg case we may want to use something like: latency-sec = 0..2147483647 and then expressly define that a value of "0" means "Never times out" or some other exact definition. We could make the maximum value much smaller while we are at it since 2147483647 seconds is ~24855.13 days or ~68 years. I dont know about other implementors but I dont expect my users to make 1 command that needs that long to complete... I guess this raises some questions about LATENCY since its not clearly defined in the draft (there is only some ABNF but no prose about limitations, etc): 1) If there is no LATENCY= (and ACTION=) params on a command, does it ever time out? A) If not then we need to clearly say this in the draft and provide the CS some clear way to 'error out' after processing the command ("You have exceeded the maximum allowable time for a single command, try again later or simplify the command and arguments.") B) If it does then we need to clearly say when, actions taken, etc. 2) What good is LATENCY=0 on a command if the lack of the LATENCY parameter effectively means "Never times out"? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0058891E85256C75_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/13/2002 02:55:11 PM:
> Thanks - I added '; As defined in [iCAL]'
Im sorry I wasnt a bit more clear in my original posting; this change is probably not sufficient.  The definition/ABNF for integer in RFC 2445 is:

     integer    = (["+"] / "-") 1*DIGIT

    Description: If the property permits, multiple "integer" values are
    specified by a COMMA character (US-ASCII decimal 44) separated list
    of values. The valid range for "integer" is -2147483648 to
    2147483647. If the sign is not specified, then the value is assumed
    to be positive.

As such it is valid to have negative or "0" LATENCY.  I think CAP should adopt the BEEP approach of expressly defining a range of allowed values ala:

   msgno      = 0..2147483647

so that the allowed range is non-negative at least.  In the latency-seg case we may want to use something like:

   latency-sec = 0..2147483647

and then expressly define that a value of "0" means "Never times out" or some other exact definition.  

We could make the maximum value much smaller while we are at it since 2147483647 seconds is ~24855.13 days or ~68 years.  I dont know about other implementors but I dont expect my users to make 1 command that needs that long to complete...

I guess this raises some questions about LATENCY since its not clearly defined in the draft (there is only some ABNF but no prose about limitations, etc):

1) If there is no LATENCY= (and ACTION=) params on a command, does it ever time out?
    A) If not then we need to clearly say this in the draft and provide the CS some clear way to 'error out' after processing the command ("You have exceeded the maximum allowable time for a single command, try again later or simplify the command and arguments.")
    B) If it does then we need to clearly say when, actions taken, etc.

2) What good is LATENCY=0 on a command if the lack of the LATENCY parameter effectively means "Never times out"?

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

--=_alternative 0058891E85256C75_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 11:30:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25873 for ; Mon, 18 Nov 2002 11:30:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIGIR105960 for ietf-calendar-bks; Mon, 18 Nov 2002 08:18:27 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIGINg05946 for ; Mon, 18 Nov 2002 08:18:25 -0800 (PST) In-Reply-To: <3DD2A931.605@Royer.com> To: ietf-calendar@imc.org Subject: Re: RDATE question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 11:18:16 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 11:18:28 AM, Serialize complete at 11/18/2002 11:18:28 AM Content-Type: multipart/alternative; boundary="=_alternative 00596A1385256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00596A1385256C75_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/13/2002 02:34:09 PM: > That's one reason for the ADD method. > > You can ADD a VEVENT to a repeating set of instances. It has the same > UID as the associated repeating events. ADDing is only the initial action to consider. There is also how to send updates to a range of instances that can include the 'different place' entry. Its now no longer possible to use the RECURRENCE-ID;RANGE=THISANDFUTURE w/o adversely affecting the LOCATION of the instance that is at a different place. The problem gets much more complex/painful in this scenario since the recipient would treat the update/reschedule as a LOCATION change for the ADDed event too unless you take steps to prevent that. Actually the ADD method is orthogonal to the need as I read it. If I want to create the new event at the new LOCATION then ADD is the way to go. If I want to create it differently from the start then ADD does not come into play. Although the startup case and the range update case appear differently the solution to both is probably the same; crafting the right iCalendar stream at the Organizers end of things. 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 00596A1385256C75_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/13/2002 02:34:09 PM:
> That's one reason for the ADD method.
>
> You can ADD a VEVENT to a repeating set of instances. It has the same
> UID as the associated repeating events.
ADDing is only the initial action to consider.  There is also how to send updates to a range of instances that can include the 'different place' entry.  Its now no longer possible to use the RECURRENCE-ID;RANGE=THISANDFUTURE w/o adversely affecting the LOCATION of the instance that is at a different place.

The problem gets much more complex/painful in this scenario since the recipient would treat the update/reschedule as a LOCATION change for the ADDed event too unless you take steps to prevent that.

Actually the ADD method is orthogonal to the need as I read it.  If I want to create the new event at the new LOCATION then ADD is the way to go.  If I want to create it differently from the start then ADD does not come into play.   Although the startup case and the range update case appear differently the solution to both is probably the same; crafting the right iCalendar stream at the Organizers end of things.

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 00596A1385256C75_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 11:36:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26032 for ; Mon, 18 Nov 2002 11:36:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIGNP406340 for ietf-calendar-bks; Mon, 18 Nov 2002 08:23:25 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIGNNg06335 for ; Mon, 18 Nov 2002 08:23:23 -0800 (PST) In-Reply-To: <3DD2AA2B.4030004@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP: ABNF is incomplete MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 11:23:14 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 11:23:26 AM, Serialize complete at 11/18/2002 11:23:26 AM Content-Type: multipart/alternative; boundary="=_alternative 0059DE7785256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059DE7785256C75_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/13/2002 02:38:19 PM: > Sorry - I maybe missing you point. > > Are you saying add the comment ';Some reference to 'localize' values from' to > 'beep-locaize' describing its usage? Im saying the ABNF is incomplete and thus not evaulatable as expected. For example, if I have: unique-id = ; text then what values can any unique-id node have? There is a NULL value so it can be nothing which is not what I think was intended. I was asking if it should have been: unique-id = text ;Some useful comment... instead. In the beep-localize case I was asking if it was intended to be the same as the 'localize' value defined in BEEP. 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 0059DE7785256C75_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/13/2002 02:38:19 PM:
> Sorry - I maybe missing you point.
>
> Are you saying add the comment ';Some reference to 'localize' values from' to
> 'beep-locaize' describing its usage?
Im saying the ABNF is incomplete and thus not evaulatable as expected.  For example, if I have:

   unique-id        = ; text
then what values can any unique-id node have?  There is a NULL value so it can be nothing which is not what I think was intended.  I was asking if it should have been:

   unique-id        = text ;Some useful comment...
instead.  

In the beep-localize case I was asking if it was intended to be the same as the 'localize' value defined in BEEP.

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 0059DE7785256C75_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 12:00:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26559 for ; Mon, 18 Nov 2002 12:00:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIGnu407158 for ietf-calendar-bks; Mon, 18 Nov 2002 08:49:56 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIGnsg07154 for ; Mon, 18 Nov 2002 08:49:54 -0800 (PST) In-Reply-To: <3DD28B99.507@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 11:49:28 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 11:49:57 AM, Serialize complete at 11/18/2002 11:49:57 AM Content-Type: multipart/alternative; boundary="=_alternative 005C451785256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C451785256C75_= Content-Type: text/plain; charset="US-ASCII" Doug contended on 11/13/2002 12:27:53 PM: > > So even if the IDENTIFY is a success the CS could "consider the > > "IDENTIFY" command an attempt to violate security" and shut down my BEEP > > session "without any further notice" so I have no clue why the hell the > > CS just punted me for doing an IDENTIFY command that I should be able to > > do...??? > > Feel free to implement your security that way - I will not be doing that. > I feel that other will not do that. However if your implementations > considers that a security violation, then this current wording makes > it work for both of us and in a compatible way. I dislike the design that basically cuts me off from the CS (yours or mine) w/o any notice even if a command succeeds. Kinda illogical to me. If the command succeeded then I should be allowed in. If it failed then I should be told so in order to take some appropriate action or logging action. The CS should _at_least_ send back some info before slamming the entire BEEP session. Otherwise the CUA has NO way to determine why the connection to the CS was lost: 1: Network failure 2: CS crash/shutdown 3: "Im a bad boy" 4: "Im not allowed to be the CFO of the company" 5: "Sorry C&S Team AA, you are still not allowed to assume Bruces identity" ... Knowing _why_ allows me to build a more robust CUA. Also, the CAP design precludes my CS from sending back some helpful info before dropping the connection. It therefore makes it impossible for me to build a friendlier CS/CUA interaction for the failure case. I think this should be allowed/encouraged. After all BEEP encourages the logging of diagnostic entries/info in failure cases so why dont we allow it? > I for one do not need permission from a specification to terminate > a connection without notice for a whatever I consider a security > violation. So just how would you craft your awesome CUA so that it can distinguish between the cases listed above?? I dont see anything in the CAP draft that would allow it so you must have some pretty good mojo to do it w/o protocol support... > I think the current wording is correct. It is NOT per failure, it is > for when the implementation considers it a security violation. If a > specific implementation hangs up on your CUA without notice, call > the owner of the CS or go to another vendor, ISP, or whatever. You are assuming that the CS did some diagnostic logging at a minimum. That BEEP-like recomendation should be added to the draft since its not there now. Besides, only the admin of the CS may be able to help with the case I described. The vendor would be of no help unless they are hosting it for you. One thing to keep in mind in "Enterprise" environements or ISP sites is that the "Help Desk" folks are rarely the actual server admins and there is not always a simple linkage between the two. As such its not always a matter of a simple call gets you resolved quickly... Im NOT trying to nail down what criteria a CS uses to determine if the IDENTIFY command is an actual violation or not; Im just trying to nail down the behaviour so that its a bit more robust and allows for providing of diagnostic information when/if the implementation desires to send 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 005C451785256C75_= Content-Type: text/html; charset="US-ASCII"
Doug contended on 11/13/2002 12:27:53 PM:
> > So even if the IDENTIFY is a success the CS could "consider the
> > "IDENTIFY" command an attempt to violate security" and shut down my BEEP
> > session "without any further notice" so I have no clue why the hell the
> > CS just punted me for doing an IDENTIFY command that I should be able to
> > do...???
>
> Feel free to implement your security that way - I will not be doing that.
> I feel that other will not do that. However if your implementations
> considers that a security violation, then this current wording makes
> it work for both of us and in a compatible way.
I dislike the design that basically cuts me off from the CS (yours or mine) w/o any notice even if a command succeeds.  Kinda illogical to me.  If the command succeeded then I should be allowed in.  If it failed then I should be told so in order to take some appropriate action or logging action.

The CS should _at_least_ send back some info before slamming the entire BEEP session.  Otherwise the CUA has NO way to determine why the connection to the CS was lost:

1: Network failure
2: CS crash/shutdown
3: "Im a bad boy"
4: "Im not allowed to be the CFO of the company"
5: "Sorry C&S Team AA, you are still not allowed to assume Bruces identity"
...

Knowing _why_ allows me to build a more robust CUA.  Also, the CAP design precludes my CS from sending back some helpful info before dropping the connection.  It therefore makes it impossible for me to build a friendlier CS/CUA interaction for the failure case.  I think this should be allowed/encouraged.  After all BEEP encourages the logging of diagnostic entries/info in failure cases so why dont we allow it?

> I for one do not need permission from a specification to terminate
> a connection without notice for a whatever I consider a security
> violation.
So just how would you craft your awesome CUA so that it can distinguish between the cases listed above??  I dont see anything in the CAP draft that would allow it so you must have some pretty good mojo to do it w/o protocol support...
       
> I think the current wording is correct. It is NOT per failure, it is
> for when the implementation considers it a security violation. If a
> specific implementation hangs up on your CUA without notice, call
> the owner of the CS or go to another vendor, ISP, or whatever.
You are assuming that the CS did some diagnostic logging at a minimum.  That BEEP-like recomendation should be added to the draft since its not there now.

Besides, only the admin of the CS may be able to help with the case I described.  The vendor would be of no help unless they are hosting it for you.  One thing to keep in mind in "Enterprise" environements or ISP sites is that the "Help Desk" folks are rarely the actual server admins and there is not always a simple linkage between the two.  As such its not always a matter of a simple call gets you resolved quickly...

Im NOT trying to nail down what criteria a CS uses to determine if the IDENTIFY command is an actual violation or not; Im just trying to nail down the behaviour so that its a bit more robust and allows for providing of diagnostic information when/if the implementation desires to send 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 005C451785256C75_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 12:08:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26739 for ; Mon, 18 Nov 2002 12:08:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIGw7l07396 for ietf-calendar-bks; Mon, 18 Nov 2002 08:58:07 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIGw5g07392 for ; Mon, 18 Nov 2002 08:58:05 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gAIGw4IR007821 for ; Mon, 18 Nov 2002 08:58:04 -0800 Message-ID: <3DD91C19.4000903@Royer.com> Date: Mon, 18 Nov 2002 09:58:01 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP ABNF and external references References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080102010209000707090804" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080102010209000707090804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 11/13/2002 02:55:11 PM: > > Thanks - I added '; As defined in [iCAL]' > > Im sorry I wasnt a bit more clear in my original posting; this change is > probably not sufficient. The definition/ABNF for integer in RFC 2445 is: > > integer = (["+"] / "-") 1*DIGIT > > Description: If the property permits, multiple "integer" values are > specified by a COMMA character (US-ASCII decimal 44) separated list > of values. The valid range for "integer" is -2147483648 to > 2147483647. If the sign is not specified, then the value is assumed > to be positive. > > As such it is valid to have negative or "0" LATENCY. I think CAP should > adopt the BEEP approach of expressly defining a range of allowed values > ala: And how does a positive integer like the following that I sent go negative? p-integer = 1*DIGIT ; Where DIGIT is defined in [iCAL] > I guess this raises some questions about LATENCY since its not clearly > defined in the draft (there is only some ABNF but no prose about > limitations, etc): > > 1) If there is no LATENCY= (and ACTION=) params on a command, does it > ever time out? > A) If not then we need to clearly say this in the draft and provide > the CS some clear way to 'error out' after processing the command ("You > have exceeded the maximum allowable time for a single command, try again > later or simplify the command and arguments.") We do - send a VREPLY with an error. The entire argument for LATENCY way back in the iRIP time frame was so that you could specify a timeout. The presumption being that you have no timeout if you do not sent one. I see NO need to have LATENCY to specify timeout and ANOTHER-LATENCY to specify the timeout when LATENCY is not specified. > B) If it does then we need to clearly say when, actions taken, etc. > > 2) What good is LATENCY=0 on a command if the lack of the LATENCY > parameter effectively means "Never times out"? I could argue that it is a good way to perform a DOS on a CS :-) I agree - lets disallow LATENCY of zero, as '1' would never be a 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 --------------ms080102010209000707090804 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExODE2NTgwMVowIwYJKoZIhvcNAQkEMRYEFLZE12Wn 7FWu8tl1wm19q5uHF91hMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAvf/Os3n4+B7j+0RYW iP5z+2XYnbJt+iDVajlS5x/owxT5wCEiu+8PKHdgU6XyLBZfE+KWBztq9hisnV1SzmoCpR/h gZJHXecitgIPsEgtw3AP+E81CsBwgOWLw3jBqaPIYmuPFTDzayB7S6vEP1mGYr396pj67Iw2 O4lJ8ux0qkmvuocO5eTFu0X8cxz8Xkq1QctMPopJyjlcHIC1icl7yhngQrhZY1MJIYsH7Uzn XkycCn2Ee685QrrD+YWPCzzY/ikt2SnDkmEd7PSd+K8qkCvv6B2Ak7SB5xXjT5glZCVRhdid VY+9Ey4zY9s6MOdEWbRGozTvPCJXa43PUqCAAAAAAAAA --------------ms080102010209000707090804-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 12:14:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26910 for ; Mon, 18 Nov 2002 12:14:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIH42c07766 for ietf-calendar-bks; Mon, 18 Nov 2002 09:04:02 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIH40g07757 for ; Mon, 18 Nov 2002 09:04:00 -0800 (PST) In-Reply-To: <3DD2B192.6080904@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP: integer in ABNF MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 12:03:58 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 12:04:03 PM, Serialize complete at 11/18/2002 12:04:03 PM Content-Type: multipart/alternative; boundary="=_alternative 005D991585256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005D991585256C75_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/13/2002 03:09:54 PM: > Yep - your right - also note that in iCAL, the REPEAT value is integer > allowing for (-12) instances :-) > > So I added 'integer' to CAP to the text and say as defined in iCAL. > > p-integer = 1*DIGIT ; Where DIGIT is defined in [iCAL] > > And I changed both latency-sec and alarm-seq to use p-integer. This is crossing the threads a bit but that still allows for a LATENCY=0 which means?? How about we use the "1..###" approach of BEEP and fix the maximum allowed at some reasonable value.??... 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 005D991585256C75_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/13/2002 03:09:54 PM:
> Yep - your right - also note that in iCAL, the REPEAT value is integer
> allowing for (-12) instances :-)
>
> So I added 'integer' to CAP to the text and say as defined in iCAL.
>
>     p-integer   = 1*DIGIT  ; Where DIGIT is defined in [iCAL]
>
> And I changed both latency-sec and alarm-seq to use p-integer.
This is crossing the threads a bit but that still allows for a LATENCY=0 which means??

How about we use the "1..###" approach of BEEP and fix the maximum allowed at some reasonable value.??...

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 005D991585256C75_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 12:21:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27125 for ; Mon, 18 Nov 2002 12:21:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIHAUO08707 for ietf-calendar-bks; Mon, 18 Nov 2002 09:10:30 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIHARg08700 for ; Mon, 18 Nov 2002 09:10:27 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gAIHARIR007935 for ; Mon, 18 Nov 2002 09:10:28 -0800 Message-ID: <3DD91F01.3040508@Royer.com> Date: Mon, 18 Nov 2002 10:10:25 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: ABNF is incomplete References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000801070702010004060209" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000801070702010004060209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 11/13/2002 02:38:19 PM: > > Sorry - I maybe missing you point. > > > > Are you saying add the comment ';Some reference to 'localize' values > from' to > > 'beep-locaize' describing its usage? > > Im saying the ABNF is incomplete and thus not evaulatable as expected. > For example, if I have: > > unique-id = ; text > > then what values can any unique-id node have? There is a NULL value so > it can be nothing which is not what I think was intended. I was asking > if it should have been: > > unique-id = text ;Some useful comment... > > instead. Yep - I'll make it: unique-id = paramtext ; At least one 'SAFE-CHAR' MUST BE supplied. ; Where 'paramtext' and 'SAVE-CHAR' are ; defined in [iCAL] > In the beep-localize case I was asking if it was intended to be the same > as the 'localize' value defined in BEEP. And I'll change: beep-localize = ; A single 'localize' value. Where 'localize' is ; defined in 2.3.1.1 of [BEEP] And I'll review the other usages of 'text' to see if they should be 'paramtext' or something else. -- 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 --------------ms000801070702010004060209 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExODE3MTAyNVowIwYJKoZIhvcNAQkEMRYEFLcHK3u2 Cy2ulYfFYLtf3H0M/RKTMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBCuUjaTbg1bh/yB5ST 9Ga3Qds6YxHGKD5lXAmi69tI1vj3JjVlVRVljazm45ajISmcjnIgACCnh4itBlarGE4I3bCX a+GDy36QjbrREmejD2392w2cGsM6hLjxuScTMSsA0f8J7nrRlx9WPIY6cc+XXMbqxaAjXQ4g 00Yq3Oixe292Kf0L3bo18E4C0b2JlOLK59n38FaMNo69imNWWqjYT0JvsCr6bNH8h2IPGbHK XBlZsv8onZ6zuuF7QH2SG2g8/kcchAR8aG9Fx/VTRurAyaMq6WaSxaCZXnYdxjRuRyYCOIqL qxr+89LiyG3RB9vdYCMGksYCp3qRSVQ1mLLNAAAAAAAA --------------ms000801070702010004060209-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 12:39:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27508 for ; Mon, 18 Nov 2002 12:39:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIHQqE10499 for ietf-calendar-bks; Mon, 18 Nov 2002 09:26:52 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIHQog10495 for ; Mon, 18 Nov 2002 09:26:50 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gAIHQoIR008061 for ; Mon, 18 Nov 2002 09:26:50 -0800 Message-ID: <3DD922D7.8070902@Royer.com> Date: Mon, 18 Nov 2002 10:26:47 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: 10.4 IDENTIFY Command II References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050807040906000004020107" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050807040906000004020107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug contended on 11/13/2002 12:27:53 PM: > > > So even if the IDENTIFY is a success the CS could "consider the > > > "IDENTIFY" command an attempt to violate security" and shut down my > BEEP > > > session "without any further notice" so I have no clue why the hell > the > > > CS just punted me for doing an IDENTIFY command that I should be > able to > > > do...??? > > > > Feel free to implement your security that way - I will not be doing that. > > I feel that other will not do that. However if your implementations > > considers that a security violation, then this current wording makes > > it work for both of us and in a compatible way. > > I dislike the design that basically cuts me off from the CS (yours or > mine) w/o any notice even if a command succeeds. Do you feel that 'security violation' == 'succeeds? I do not. > Kinda illogical to me. > If the command succeeded then I should be allowed in. Where does the draft say that if it succeeds that you are not allowed in? > If it failed > then I should be told so in order to take some appropriate action or > logging action > The CS should _at_least_ send back some info before slamming the entire > BEEP session. Otherwise the CUA has NO way to determine why the > connection to the CS was lost: If you determined that a hacker was attacking your system, would you first inform them: > 1: Network failure > 2: CS crash/shutdown > 3: "Im a bad boy" > 4: "Im not allowed to be the CFO of the company" > 5: "Sorry C&S Team AA, you are still not allowed to assume Bruces identity" > ... Or would you just block them? I block them and let them wonder why they failed. I would not inform them of the specifics. And we are talking about a 'security violation' and NOT a failed login attempt. > Knowing _why_ allows me to build a more robust CUA. Also, the CAP > design precludes my CS from sending back some helpful info before > dropping the connection. It therefore makes it impossible for me to > build a friendlier CS/CUA interaction for the failure case. I think > this should be allowed/encouraged. After all BEEP encourages the > logging of diagnostic entries/info in failure cases so why dont we allow > it? > > > I for one do not need permission from a specification to terminate > > a connection without notice for a whatever I consider a security > > violation. > > So just how would you craft your awesome CUA so that it can distinguish > between the cases listed above?? I dont see anything in the CAP draft > that would allow it so you must have some pretty good mojo to do it w/o > protocol support... If a CUA attempts to hack my system - I would not care about the error messages it displayed. > > I think the current wording is correct. It is NOT per failure, it is > > for when the implementation considers it a security violation. If a > > specific implementation hangs up on your CUA without notice, call > > the owner of the CS or go to another vendor, ISP, or whatever. > > You are assuming that the CS did some diagnostic logging at a minimum. > That BEEP-like recomendation should be added to the draft since its not > there now. Where does it say that the CS may not perform logging as specified and recommended in BEEP? > Besides, only the admin of the CS may be able to help with the case I > described. The vendor would be of no help unless they are hosting it > for you. One thing to keep in mind in "Enterprise" environements or ISP > sites is that the "Help Desk" folks are rarely the actual server admins > and there is not always a simple linkage between the two. As such its > not always a matter of a simple call gets you resolved quickly... Yes - I will also log failures and security violations. > Im NOT trying to nail down what criteria a CS uses to determine if the > IDENTIFY command is an actual violation or not; Im just trying to nail > down the behaviour so that its a bit more robust and allows for > providing of diagnostic information when/if the implementation desires > to send it. I will never tell a hacker or malicious software why attempts failed. -- 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 --------------ms050807040906000004020107 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExODE3MjY0N1owIwYJKoZIhvcNAQkEMRYEFMz0F/Nt pvToymtSKn0ov2SST8XXMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCt9cUM37WVyWAiPavq f4cd3Hhd5nTBO99rQghUDlk4sivPLA1JChywE59bS2JUjdUQ3hD2uGU2aXQM//AcuiSSzR0X NhdkDwdIdwS35n5zYNyhWvYhsHXYq4uHVMj8VE/IuwPa+P/9rkyonELxqHIaWiaVaWj9AhR3 +895WoYQxWK4/lz9F9+im0u6T1zGnv8jo0bpiILkUmxgg31C9HG2Xb3CvytFklufaaS1+w8r 0eV8nEFJosRP5cjT1W4QtygRq0MssJg/mpTWzV2WjKVoeIHD98NsXUh5c5Ow+5m/eLNFFy7A cjdbM10M27nWupTkIqgGTHtiuzcNbfZhICXcAAAAAAAA --------------ms050807040906000004020107-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 12:52:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28065 for ; Mon, 18 Nov 2002 12:52:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIHkXp11256 for ietf-calendar-bks; Mon, 18 Nov 2002 09:46:33 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIHkVg11251 for ; Mon, 18 Nov 2002 09:46:32 -0800 (PST) In-Reply-To: <3DD2AC9F.5050302@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP: Repeating iCalendar ABNF mistakes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 12:46:29 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 12:46:34 PM, Serialize complete at 11/18/2002 12:46:34 PM Content-Type: multipart/alternative; boundary="=_alternative 00617D9785256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00617D9785256C75_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 11/13/2002 02:48:47 PM: > > To save time for those who dont recall the issue: The ABNF does not > > allow non-'X-" params on this command. > > I agree - I have added a '...iana-token ; as defined in RFC2445...' to CAP. Thanks. > > That is, if we later define a > > new parameter for the CREATE command an older parser would treat the > > line as invalid as the new iana-token (or iana-prop if you prefer) is > > NOT valid in the older ABNF. We noted this last year in iCalendar and > > vowed to fix it. However we made the same mistake on all our CAP > > commands... > > I can not find the discussion. What was wrong with 'iana-token' in 2445? The problem is in the root ABNF in RFC 2445: icalbody = calprops component calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once prodid /version / ; 'calscale' and 'method' are optional, ; but MUST NOT occur more than once calscale / method / x-prop ) According to this ABNF, there can be no iana-tokens in the VCALENDAR component, only those already defined and X- properties! We noticed this a long time ago and vowed to fix it in our next iCalendar revision. If the actual thread is needed I would search for any discussions that have iana-token in them (Im too backlogged to do it given its obviously a problem we know about already.) 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 00617D9785256C75_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 11/13/2002 02:48:47 PM:
> > To save time for those who dont recall the issue: The ABNF does not
> > allow non-'X-" params on this command.
>
> I agree - I have added a '...iana-token ; as defined in RFC2445...' to CAP.
Thanks.

> > That is, if we later define a
> > new parameter for the CREATE command an older parser would treat the
> > line as invalid as the new iana-token (or iana-prop if you prefer) is
> > NOT valid in the older ABNF.  We noted this last year in iCalendar and
> > vowed to fix it.  However we made the same mistake on all our CAP
> > commands...
>
> I can not find the discussion. What was wrong with 'iana-token' in 2445?
The problem is in the root ABNF in RFC 2445:

     icalbody   = calprops component

    calprops   = 2*(

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

               prodid /version /

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

               calscale        /
               method          /

               x-prop
               )

According to this ABNF, there can be no iana-tokens in the VCALENDAR component, only those already defined and X- properties!

We noticed this a long time ago and vowed to fix it in our next iCalendar revision.  If the actual thread is needed I would search for any discussions that have iana-token in them (Im too backlogged to do it given its obviously a problem we know about already.)

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 00617D9785256C75_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 13:25:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29145 for ; Mon, 18 Nov 2002 13:25:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIIBCc12492 for ietf-calendar-bks; Mon, 18 Nov 2002 10:11:12 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIIB9g12483 for ; Mon, 18 Nov 2002 10:11:09 -0800 (PST) In-Reply-To: <3DD2D2F9.1070508@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP: To delete or not to... MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 13:11:05 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 01:11:12 PM, Serialize complete at 11/18/2002 01:11:12 PM Content-Type: multipart/alternative; boundary="=_alternative 0063BE4E85256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063BE4E85256C75_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/13/2002 05:32:25 PM: > > However no where is there any text dealing with what can be done on > > entries marked for deletion but not actually removed. As such the > > essentially go into limbo. This is not good unless you are a storage > > manufacturer. > > You can remove them. Why do you think that you can not? Its very vague how you actually remove them. Given the defition of "DELETED": To retrieve any deleted object, simply do a query asking for any objects that were stored in the "DELETED" state. Im guessing that the only way to actualy delete them after marking them as deleted is to: 1: Query for any entry in the DELETED state and 2: Re-DELETE them using a second DELETE command w/o the OPTION=MARK but this is only my guess. Its totally undefined how this happens or when it happens. Taking a step back, I think that part of my issue is that a CUA can mark entries as DELETED but not actually remove them. The entries that get DELETEed can be marked as "DELETED" but their behaviour/impact as entries is still totally undefined. Examples of the vagaries: Should a "DELETED" entry still affect my busytime? Since the entry is not actually deleted is it possible to "undelete" them by simply querying the entry out and then resaving it w/a CREATE or other command? Once a CUA markes an VEVENT for deletion then what response should it get back on a query like "Give me the ATTENDEEs for the VEVENT with UID:123456789@blech" if the entry is deleted? Will there be some way to know that it needs to include a "AND STATE() = 'DELETED'" or will it have to guess if there is a failure? It is a failure to re-DELETE an entry thats already DELETED? I can see the use of the DELETE command in a, shudder, sync process that is to be built later on but its current behaviour needs to better codify what the expected behaviour/results are for entries that are only marked for deletion, etc. > > The possible choices for dealing w/marked for deletion entries is to: > > > > 1) Allow some way to restore them to full health (aka "Undelete" them) or > > That was covered in my e-mail. What did you think of my comments? Im sorry, I must have missed them. Ill try to go and find them... > > > 2) Clearly state that they are as good as actually removed, can never be > > restored and will be actually removed at some point later at the CS > > discression (its an administration issue now...) > > It is up to the CUA to remove them from the CS. Again, exactly _how_ does the CUA find and remove said entries? Also, why is it not something the CS can do per some CS policy (ie: "Deleted entries are automagically removed from the system 14 days after being marked for deletion.")?? > If MARK is not set - it is physically removed. Ugh, my bad. I was looking for text that said expressly that the DELETE command would physically remove the entry by default. I didnt make the inference based on the cited 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... --=_alternative 0063BE4E85256C75_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/13/2002 05:32:25 PM:
> > However no where is there any text dealing with what can be done on
> > entries marked for deletion but not actually removed.  As such the
> > essentially go into limbo.  This is not good unless you are a storage
> > manufacturer.  
>
> You can remove them. Why do you think that you can not?
Its very vague how you actually remove them.  Given the defition of "DELETED":

                                                                    To
         retrieve any deleted object, simply do a query asking for any
         objects that were stored in the "DELETED" state.

Im guessing that the only way to actualy delete them after marking them as deleted is to:

1: Query for any entry in the DELETED state and
2: Re-DELETE them using a second DELETE command w/o the OPTION=MARK

but this is only my guess.  Its totally undefined how this happens or when it happens.

Taking a step back, I think that part of my issue is that a CUA can mark entries as DELETED but not actually remove them.  The entries that get DELETEed can be marked as "DELETED" but their behaviour/impact as entries is still totally undefined.  

Examples of the vagaries:

Should a "DELETED" entry still affect my busytime?
Since the entry is not actually deleted is it possible to "undelete" them by simply querying the entry out and then resaving it w/a CREATE or other command?  
Once a CUA markes an VEVENT for deletion then what response should it get back on a query like "Give me the ATTENDEEs for the VEVENT with UID:123456789@blech" if the entry is deleted?  
Will there be some way to know that it needs to include a "AND STATE() = 'DELETED'" or will it have to guess if there is a failure?
It is a failure to re-DELETE an entry thats already DELETED?

I can see the use of the DELETE command in a, shudder, sync process that is to be built later on but its current behaviour needs to better codify what the expected behaviour/results are for entries that are only marked for deletion, etc.

> > The possible choices for dealing w/marked for deletion entries is to:
> >
> > 1) Allow some way to restore them to full health (aka "Undelete" them) or
>
> That was covered in my e-mail. What did you think of my comments?
Im sorry, I must have missed them.  Ill try to go and find them...

>
> > 2) Clearly state that they are as good as actually removed, can never be
> > restored and will be actually removed at some point later at the CS
> > discression (its an administration issue now...)
>
> It is up to the CUA to remove them from the CS.
Again, exactly _how_ does the CUA find and remove said entries?  Also, why is it not something the CS can do per some CS policy (ie: "Deleted entries are automagically removed from the system 14 days after being marked for deletion.")??

> If MARK is not set - it is physically removed.
Ugh, my bad.  I was looking for text that said expressly that the DELETE command would physically remove the entry by default.  I didnt make the inference based on the cited 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...

--=_alternative 0063BE4E85256C75_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 13:40:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29499 for ; Mon, 18 Nov 2002 13:40:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIIUG715379 for ietf-calendar-bks; Mon, 18 Nov 2002 10:30:16 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIIUEg15375 for ; Mon, 18 Nov 2002 10:30:15 -0800 (PST) In-Reply-To: <20021114171940.GA99121@inet.it> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 13:30:12 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 01:30:18 PM, Serialize complete at 11/18/2002 01:30:18 PM Content-Type: multipart/alternative; boundary="=_alternative 00657E0085256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00657E0085256C75_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 11/14/2002 12:19:40 PM: > Yes now it's clear. I agree some mechanism for discovering allowed > identities would be useful, but I also see Doug has some reason in > calling this 'administration' - as in CUA, not CS, administration. > > After all, this comes into play when you authorize somebody to act > as your attendee; since the way you do this is out of scope for CAP, Correct. Im NOT discussing that aspect of authentication/authorization. > it could be argued that anything more complex than you telling your > attendee what the right identity is, is out of scope too. Currently even that is not done (but used to in earlier drafts). Since the CUA is only reading the list from the CS I dont buy the argument that its Administration in that sense. If I were talking about modifying the list or suggesting a list to the CS then I would agree w/that but Im not. I also dont recall any WG traffic discussing this as Administration and thus dropable from CAP and I disagree w/it. Getting info like that from the CS is not administration any more than reading my calendar entries is administration... The CS has to have a list of acceptable identities that a CUA can assume based on the authentiation process (kinda sorta since authentication is not the same as that authorization but thats a digresson). As such I dont see a strong reason for the CS to _not_ be able to provide that to the CUA so that a CUA does not have to play guessing games when using the IDENTIFY command. As a matter of design simplicity I think its better to take a more structured approach as it makes building more robust CUAs possible. If given the option to either guess at which identities will work and which wont or get an accurate list from the other side, I know which is cleaner IMHO. > Also, your argument would also extend to: once you are authenticated, > how do you discover which UPNs you are authorized to access? The CS had determined the list it will allow and that is what Im trying to get it to return to the CUA if the CUA wants it. It was part of our earlier designs and Doug claims the WG agreed to remove it. I certainly didnt see that discussion nor do I agree w/its removal. > Should > your CUA search for them and apply VCAR (I hope not) or will it try > accessing all of them and see what the CS replies? IMHO, some amount > of client administration will be needed no matter what. Not sure what your VCAR question is but I can address the CUA bit. Sure, the CU may configure their CUA w/a list of identies that they expect to be able to assume using the IDENTIFY command. However this list may or may not match what the CS determines to be allowed. My CUA can try try to assume all the assorted identities configured in it with the CS accepting or failing the command. My argument is that instead of having my CUA try identities the CS will not allow (w/o even any response way to say why it was rejected) it would be simpler if my CUA could ask the CS for the list and then do something nifty in the UI like gray out those that are not allowed, etc. That way no failed IDENTIFY commands happen; no playing guessing games between the CUA and CS. The CUA may know what the CU _wants_ and it can find out what the CS _will_allow_ and thus bridge the discrepancy in some nice or easy manner. > This is not to say I'm against adding such a mechanism; on the > contrary, I think it would be great (and in fact we need it or > everybody will implement something like this in different ways). Great. > It's just that I don't think we MUST do it NOW (maybe we can start > right now to prepare a separate RFC? I have no idea). I would really like to see it in CAP 1.0 since it was in earlier so restoring the appropriate text should not be that difficult. 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 00657E0085256C75_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 11/14/2002 12:19:40 PM:
> Yes now it's clear. I agree some mechanism for discovering allowed
> identities would be useful, but I also see Doug has some reason in
> calling this 'administration' - as in CUA, not CS, administration.
>
> After all, this comes into play when you authorize somebody to act
> as your attendee; since the way you do this is out of scope for CAP,
Correct.  Im NOT discussing that aspect of authentication/authorization.

> it could be argued that anything more complex than you telling your
> attendee what the right identity is, is out of scope too.
Currently even that is not done (but used to in earlier drafts).

Since the CUA is only reading the list from the CS I dont buy the argument that its Administration in that sense.  If I were talking about modifying the list or suggesting a list to the CS then I would agree w/that but Im not.  

I also dont recall any WG traffic discussing this as Administration and thus dropable from CAP and I disagree w/it.  Getting info like that from the CS is not administration any more than reading my calendar entries is administration...

The CS has to have a list of acceptable identities that a CUA can assume based on the authentiation process (kinda sorta since authentication is not the same as that authorization but thats a digresson).  As such I dont see a strong reason for the CS to _not_ be able to provide that to the CUA so that a CUA does not have to play guessing games when using the IDENTIFY command.  

As a matter of design simplicity I think its better to take a more structured approach as it makes building more robust CUAs possible.  If given the option to either guess at which identities will work and which wont or get an accurate list from the other side, I know which is cleaner IMHO.

> Also, your argument would also extend to: once you are authenticated,
> how do you discover which UPNs you are authorized to access?

The CS had determined the list it will allow and that is what Im trying to get it to return to the CUA if the CUA wants it.  It was part of our earlier designs and Doug claims the WG agreed to remove it.  I certainly didnt see that discussion nor do I agree w/its removal.

>                                                             Should
> your CUA search for them and apply VCAR (I hope not) or will it try
> accessing all of them and see what the CS replies? IMHO, some amount
> of client administration will be needed no matter what.
Not sure what your VCAR question is but I can address the CUA bit.  

Sure, the CU may configure their CUA w/a list of identies that they expect to be able to assume using the IDENTIFY command.  However this list may or may not match what the CS determines to be allowed.  My CUA can try try to assume all the assorted identities configured in it with the CS accepting or failing the command.  My argument is that instead of having my CUA try identities the CS will not allow (w/o even any response way to say why it was rejected) it would be simpler if my CUA could ask the CS for the list and then do something nifty in the UI like gray out those that are not allowed, etc.  That way no failed IDENTIFY commands happen; no playing guessing games between the CUA and CS.  The CUA may know what the CU _wants_ and it can find out what the CS _will_allow_ and thus bridge the discrepancy in some nice or easy manner.

> This is not to say I'm against adding such a mechanism; on the
> contrary, I think it would be great (and in fact we need it or
> everybody will implement something like this in different ways).
Great.

> It's just that I don't think we MUST do it NOW (maybe we can start
> right now to prepare a separate RFC? I have no idea).
I would really like to see it in CAP 1.0 since it was in earlier so restoring the appropriate text should not be that difficult.  

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 00657E0085256C75_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 13:47:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29722 for ; Mon, 18 Nov 2002 13:47:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIIXkP15490 for ietf-calendar-bks; Mon, 18 Nov 2002 10:33:46 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIIXig15486 for ; Mon, 18 Nov 2002 10:33:44 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id EE6871550E; Mon, 18 Nov 2002 19:33:41 +0100 (CET) Date: Mon, 18 Nov 2002 19:33:41 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II Message-ID: <20021118183341.GF74436@inet.it> References: <3DD922D7.8070902@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD922D7.8070902@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Doug, On Mon, Nov 18, 2002 at 10:26:47AM -0700, Doug Royer wrote: > If you determined that a hacker was attacking your system, would > you first inform them: [...] > > Or would you just block them? I block them and let them wonder why they > failed. I would not inform them of the specifics. And we are talking > about a 'security violation' and NOT a failed login attempt. > The current text still says: If a CS considers the "IDENTIFY" command an attempt to violate security, the CS MAY terminate the BEEP session without any further notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. I interpret this as mandating a failure message, even if a generic one. If I am missing something, could you please send an example conversation showing what happens (with BEEP layer if needed)? The more I think about it, the more I think an explicit BYE command would be beneficial. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Nov 18 13:52:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29852 for ; Mon, 18 Nov 2002 13:52:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIIjhR15791 for ietf-calendar-bks; Mon, 18 Nov 2002 10:45:43 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIIjfg15787 for ; Mon, 18 Nov 2002 10:45:41 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 28CA11550E; Mon, 18 Nov 2002 19:45:42 +0100 (CET) Date: Mon, 18 Nov 2002 19:45:42 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: 1.3 Definitions: Calendar Policy Message-ID: <20021118184542.GI74436@inet.it> References: 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.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Nov 06, 2002 at 05:47:31PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Shouldn't components be included in the description of a Calendar Policy? > That is, should: > > Calendar Policy - A CAP operational restriction on the access or > manipulation of a calendar. These may be outside of the scope of > the CAP protocol. An example of an implementation or site policy > is, "events MUST BE scheduled in unit intervals of one hour". > > be changed to: > > Calendar Policy - A CAP operational restriction on the access or > manipulation of a calendar or components in that calendar. These > may be outside of the scope of the CAP protocol. An example of > an implementation or site policy is, "events MUST BE scheduled > in unit intervals of one hour". > > After all a policy could be that only some UPNs can only read from the > calendar and only special UPNs can read and write to it. Another example > is that some UPNs may read and write events but they may not change the > Calendar Access Rights lists.... FWIW, I agree to this change (and the reason given). Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Nov 18 13:57:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29934 for ; Mon, 18 Nov 2002 13:56:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIIn3j15905 for ietf-calendar-bks; Mon, 18 Nov 2002 10:49:03 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIIn0g15901 for ; Mon, 18 Nov 2002 10:49:01 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 57B5E1550E; Mon, 18 Nov 2002 19:49:01 +0100 (CET) Date: Mon, 18 Nov 2002 19:49:01 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: 1.3 Definitions: Calendar Store Properties Message-ID: <20021118184901.GJ74436@inet.it> References: 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.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Nov 06, 2002 at 05:50:51PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Im confused by the definition: > > Calendar Store Properties - Properties maintained in a Calendar > Store calendar store-wide information. > > The last bit seems redundant or cyclical to say the least. Perhaps its > missing some text to make it express the desired defintion or maybe Im > just loosing my grasp of English. Anyone else think so? Looking at the previous item (Calendar Store Components), I guess it's just missing some text, but since you asked - yes I think so ;-) -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Nov 18 14:19:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00538 for ; Mon, 18 Nov 2002 14:19:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIJ9Co16505 for ietf-calendar-bks; Mon, 18 Nov 2002 11:09:12 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIJ9Ag16501 for ; Mon, 18 Nov 2002 11:09:10 -0800 (PST) In-Reply-To: <20021114192134.GC99436@inet.it> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 14:09:07 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 02:09:14 PM, Serialize complete at 11/18/2002 02:09:14 PM Content-Type: multipart/alternative; boundary="=_alternative 00690E3A85256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00690E3A85256C75_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 11/14/2002 02:21:34 PM: > Yes please; also Bruce seems to be in agreement. Sure. > What about: > > If a CS detects a sequence of failures in response to one or more > "IDENTIFY" commands it considers an attempt to violate security, > the CS MAY terminate the BEEP session without any further > notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. > It is a good idea to trigger this behavior after n failures. > > Does this satisfy everybody? Bruce, note that you are still > guaranteed to get a REQUEST-STATUS. We could even state more > explicitely: > > The REQUEST-STATUS value SHOULD indicate this is a security > violation disconnection. > > What do you say? This sound good to me (the last statment is a bonus really but I dont mind). The biggest concern I have is the no response back rather than the actual "_when_ does it happen" 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 00690E3A85256C75_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 11/14/2002 02:21:34 PM:
> Yes please; also Bruce seems to be in agreement.
Sure.

> What about:
>
> If a CS detects a sequence of failures in response to one or more
> "IDENTIFY" commands it considers an attempt to violate security,
> the CS MAY terminate the BEEP session without any further
> notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply.
> It is a good idea to trigger this behavior after n failures.
>
> Does this satisfy everybody? Bruce, note that you are still
> guaranteed to get a REQUEST-STATUS. We could even state more
> explicitely:
>
> The REQUEST-STATUS value SHOULD indicate this is a security
> violation disconnection.
>
> What do you say?
This sound good to me (the last statment is a bonus really but I dont mind).  The biggest concern I have is the no response back rather than the actual "_when_ does it happen" 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 00690E3A85256C75_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 18 17:29:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06014 for ; Mon, 18 Nov 2002 17:29:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIMK2825908 for ietf-calendar-bks; Mon, 18 Nov 2002 14:20:02 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIMJxg25898 for ; Mon, 18 Nov 2002 14:20:00 -0800 (PST) In-Reply-To: <20021115130940.GA2149@inet.it> To: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Nov 2002 17:19:55 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/18/2002 05:20:04 PM, Serialize complete at 11/18/2002 05:20:04 PM Content-Type: multipart/alternative; boundary="=_alternative 007A85F985256C75_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007A85F985256C75_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 11/15/2002 08:09:40 AM: > > Since the query has to be encoded in CAP-QL and there is no way to > > interpret what cannot be encoded in CAP-QL I dont see how a CS can > > transcode a 'fixed' query into one that means "All events on my calendar > > for today". Should the CS somehow infer it from the explicit CAP-QL > > language? > > Uhm no, I meant some kind of "synthetic" VQUERY - the CS put it there > itself. I got that part. What I have a problem with is that if a CUA tried to actually retrieve the actual VQUERY from the CS then it would have to fail since the CS has no way (in CAP 1.0) to encode the non-CAP-QL-able query in CAP-QL. So if a CUA cannot retrieve a VQUERY then should it try to use it in a query?? Its very unclear and vague to say the least and I think VQUERY storage as for CAP 1.0 is not needed. Stored VQUERYs like you describe could be stored/retrieved in a subsequent draft if we make sure that CAP allows for storing of any components and the newer draft can encode up the non-CAP-QL query. The System Model in Section 3.1 does not expressly show this (no IANA-Components in the tree) but I think the intent is there. In the mean time I still think that building in VQUERY storage is a waste of cycles. At a very minimum it should be a CS response to GET-CAPABILITY since I for one dont want to have to build it in when I cant see a strong usage for it given the current query model... > > Oh, are you suggesting that there is some Out-of-band mechanism to place > > non-CAP-QL encodable queries into the CS and then the CUA just references > > them? Seems like kind of a wishfull thing given CAP-QL and the robustness > > of it. > > I can understand if you questioned the usefulness or the interoperability > of such a thing, but I don't understand your objection. A CUA and a CS would > have no problem; heck, you could even write an RFC to standardize an "opaque" > VQUERY. As long as the CUA knows how the VQUERY is named and what it > returns, I think it would be both realistic and robust. Actually part of my objection to your scenario is that unless all CUAs know that the VQUERY with "NAME=Magic01" is a special VQUERY that cannot be retrieved (since its not CAP-QL encodable) then when any CUA that tries to "SELECT VQUERY FROM VAGNEDA WHERE NAME = 'MAGIC01'" they will get some kind of failure response. As such they will/should treat the named VQUERY as 'bad' or 'unusable'. IMHO there should be no data put into the CS by ANY means (Administrative or not) that cannot be retrieved and/or encoded using the CAP 1.0 or updated iCalendar specs. Otherwise it just becomes a recipe for disaster. > > Also, there is now way for the CUA to actually pull the VQUERY from the CS > > to check it or modify it. After all my CUA should be able to check all > > VQUERYs in the CS so just how would the CS encode the unencodable VQUERY > > that is stored?? Would the CS just say "Sorry, you cant have that > > VQUERY!"? > > Why not tell the truth? The CS would reply: > > BEGIN:VQUERY > QUERYID:All VEVENTs for today > END:VQUERY Thats not what I asked. I didnt _use_ the VQUERY, I tried to SELECT it. What should be the response from the CS "Sorry, you cannot read the VQUERY but you can use it in a VQUERY command..." > If the CUA and CS adhere to a common convention, the CUA would know what to > expect as a reply if it called this query. Where in the CAP draft does it deal with this kind of response code? I cannot find any text that describes a "You cannot read it but you can use it." kind of response. The closest I can find would be a general failure response to the "SELECT VQUERY FROM VAGENDA ..." command. I would not expect a CUA to use a VQUERY that it cannot read from the CS, would you?? (I like to practice Save Hex...) > > 2: Remove the concept of stored VQUERYs > > > > I dont say remove named VQUERYs since I can have more than 1 VQUERY 'in > > use' at any given time. > > I'm getting lost now. What use would named query be if they can't be stored? My bad. I mistakenly mixed the concepts of cmd-id and NAME when I was thinking this over. We no longer need the concept of a named VQUERY with this simplification. > > But CAP-QL was supposed to be so rich that we could craft any query in it. > > (Ok a bit of sarcasm on a Monday AM...) > > It's also a question of workload split. Actually its also an issue of CS design as well as performance and scalability. Since I cant seem to craft any kind of meaningful VQUERY in CAP-QL that I would expect to store I question the need to require all CS's to implement it. Currently in CAP-QL the CUA is going to have to recraft the VQUERY every time it wants to do that "What events are on the calendar for this week" since "this week" changes. This inability to wildcard makes stored VQUERYs less than useful for CAP 1.0. As such I am strongly questioning why we do not remove it from CAP 1.0 and simplify the draft accordingly... I have no qualms w/you or anyeone else coming up with a follow-on draft to use named queries (VQUERY2?) that can be stored, etc but I dislike all this baggage that has no current benefit. > OTOH, since everybody is going to > use the same query, the server will probably have this information (when does > this week start and end?) cached. CS caching of results is not the same thing as caching of the query too. > This is a trivial example, but multiply it by a number of similar cases and > then by thousands of CUAs connected to the server at the same time... it saves > power on the CUA, on the CS (no need to parse the VQUERY again and again) and > network traffic. The only benefit for this case is really at the network packet level, maybe some at the CS processing level. The CUA is still going to have to craft the VQUERY command to send to the CS on the already established session. So there is some octet savings there but not that radical really. The CS will still have to locate the stored VQUERY, parse it, perform the propery internal query work and then send back the results. Depending on how the CS implements VQUERY storage it may or may not have to reparse it; odds are it will have to reparse it so it can replace the 'wildcards' with the right stuff before it can do the actual query. So again there is work to be done either in decoding the CUAs VQUERY or the stored VQUERY before the actual query can be done. Depending on how the CS is designed this may be signficiant or it may be marginal (Im guessing marginal for the first release or so). In any case there will still have to be CUA -> CS traffic followed by CS work of some kind and then CS -> CUA traffic so Im not sure we buy ourselves that much with VQUERY storage. Especially since CAP-QL is the only codified search schema and it has no demonstratable benefits for this model. > Oh and by the way, this is one of the reasons why I like your idea of views - > the CUA would send the query and then ask the server to refresh it from time > to time... I dont think I sent that to the WG at large so I think you just confused some folks... Seems like Im arguing against myself then does it?... I could consider views a kind of stored, named VQUERY but I usually dont as I can typically search a view and the results may vary depending on the views content criteria (ala the SELECT of a VQUERY). > I am not familiar enough with ABNF and I have no idea ATM if I have enough > time. I will try to come up with an informal proposal to see if we are > agree. OK? Works for me. Ill be happy to work on an ABNF after the dust settles. > But I, for one, will not stop using stored queries as I explained. I wont try to stop you but Im very curious how the CS is going to react to the CUA trying to read that VQUERY from the CS... I think that no CUA should try to use something that it cannot read out of the CS myself; its just not safe. 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 007A85F985256C75_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 11/15/2002 08:09:40 AM:
> > Since the query has to be encoded in CAP-QL and there is no way to
> > interpret what cannot be encoded in CAP-QL I dont see how a CS can
> > transcode a 'fixed' query into one that means "All events on my calendar
> > for today".   Should the CS somehow infer it from the explicit CAP-QL
> > language?
>
> Uhm no, I meant some kind of "synthetic" VQUERY - the CS put it there
> itself.
I got that part.  What I have a problem with is that if a CUA tried to actually retrieve the actual VQUERY from the CS then it would have to fail since the CS has no way (in CAP 1.0) to encode the non-CAP-QL-able query in CAP-QL.  So if a CUA cannot retrieve a VQUERY then should it try to use it in a query??  Its very unclear and vague to say the least and I think VQUERY storage as for CAP 1.0 is not needed.

Stored VQUERYs like you describe could be stored/retrieved in a subsequent draft if we make sure that CAP allows for storing of any components and the newer draft can encode up the non-CAP-QL query.  The System Model in Section 3.1 does not expressly show this (no IANA-Components in the tree) but I think the intent is there.

In the mean time I still think that building in VQUERY storage is a waste of cycles.  At a very minimum it should be a CS response to GET-CAPABILITY since I for one dont want to have to build it in when I cant see a strong usage for it given the current query model...

> > Oh, are you suggesting that there is some Out-of-band mechanism to place
> > non-CAP-QL encodable queries into the CS and then the CUA just references
> > them?  Seems like kind of a wishfull thing given CAP-QL and the robustness
> > of it.
>
> I can understand if you questioned the usefulness or the interoperability
> of such a thing, but I don't understand your objection. A CUA and a CS would
> have no problem; heck, you could even write an RFC to standardize an "opaque"
> VQUERY. As long as the CUA knows how the VQUERY is named and what it
> returns, I think it would be both realistic and robust.
Actually part of my objection to your scenario is that unless all CUAs know that the VQUERY with "NAME=Magic01" is a special VQUERY that cannot be retrieved (since its not CAP-QL encodable) then when any CUA that tries to "SELECT VQUERY FROM VAGNEDA WHERE NAME = 'MAGIC01'" they will get some kind of failure response.  As such they will/should treat the named VQUERY as 'bad' or 'unusable'.  

IMHO there should be no data put into the CS by ANY means (Administrative or not) that cannot be retrieved and/or encoded using the CAP 1.0 or updated iCalendar specs.  Otherwise it just becomes a recipe for disaster.

> > Also, there is now way for the CUA to actually pull the VQUERY from the CS
> > to check it or modify it.  After all my CUA should be able to check all
> > VQUERYs in the CS so just how would the CS encode the unencodable VQUERY
> > that is stored??  Would the CS just say "Sorry, you cant have that
> > VQUERY!"?
>
> Why not tell the truth? The CS would reply:
>
> BEGIN:VQUERY
> QUERYID:All VEVENTs for today
> END:VQUERY
Thats not what I asked.  I didnt _use_ the VQUERY, I tried to SELECT it.  What should be the response from the CS "Sorry, you cannot read the VQUERY but you can use it in a VQUERY command..."

> If the CUA and CS adhere to a common convention, the CUA would know what to
> expect as a reply if it called this query.
Where in the CAP draft does it deal with this kind of response code?  I cannot find any text that describes a "You cannot read it but you can use it." kind of response.  The closest I can find would be a general failure response to the "SELECT VQUERY FROM VAGENDA ..." command.  I would not expect a CUA to use a VQUERY that it cannot read from the CS, would you??  (I like to practice Save Hex...)

> > 2: Remove the concept of stored VQUERYs
> >
> > I dont say remove named VQUERYs since I can have more than 1 VQUERY 'in
> > use' at any given time.
>
> I'm getting lost now. What use would named query be if they can't be stored?
My bad.  I mistakenly mixed the concepts of cmd-id and NAME when I was thinking this over.  We no longer need the concept of a named VQUERY with this simplification.

> > But CAP-QL was supposed to be so rich that we could craft any query in it.
> > (Ok a bit of sarcasm on a Monday AM...)
>
> It's also a question of workload split.

Actually its also an issue of CS design as well as performance and scalability.  Since I cant seem to craft any kind of meaningful VQUERY in CAP-QL that I would expect to store I question the need to require all CS's to implement it.  Currently in CAP-QL the CUA is going to have to recraft the VQUERY every time it wants to do that "What events are on the calendar for this week" since "this week" changes.  This inability to wildcard makes stored VQUERYs less than useful for CAP 1.0. As such I am strongly questioning why we do not remove it from CAP 1.0 and simplify the draft accordingly...

I have no qualms w/you or anyeone else coming up with a follow-on draft to use named queries (VQUERY2?) that can be stored, etc but I dislike all this baggage that has no current benefit.

>                                              OTOH, since everybody is going to
> use the same query, the server will probably have this information (when does
> this week start and end?) cached.
CS caching of results is not the same thing as caching of the query too.

> This is a trivial example, but multiply it by a number of similar cases and
> then by thousands of CUAs connected to the server at the same time... it saves
> power on the CUA, on the CS (no need to parse the VQUERY again and again) and
> network traffic.
The only benefit for this case is really at the network packet level, maybe some at the CS processing level.  

The CUA is still going to have to craft the VQUERY command to send to the CS on the already established session.  So there is some octet savings there but not that radical really.  

The CS will still have to locate the stored VQUERY, parse it, perform the propery internal query work and then send back the results.  Depending on how the CS implements VQUERY storage it may or may not have to reparse it; odds are it will have to reparse it so it can replace the 'wildcards' with the right stuff before it can do the actual query.  So again there is work to be done either in decoding the CUAs VQUERY or the stored VQUERY before the actual query can be done.  Depending on how the CS is designed this may be signficiant or it may be marginal (Im guessing marginal for the first release or so).

In any case there will still have to be CUA -> CS traffic followed by CS work of some kind and then CS -> CUA traffic so Im not sure we buy ourselves that much with VQUERY storage.  Especially since CAP-QL is the only codified search schema and it has no demonstratable benefits for this model.

> Oh and by the way, this is one of the reasons why I like your idea of views -
> the CUA would send the query and then ask the server to refresh it from time
> to time...
I dont think I sent that to the WG at large so I think you just confused some folks...

Seems like Im arguing against myself then does it?...  I could consider views a kind of stored, named VQUERY but I usually dont as I can typically search a view and the results may vary depending on the views content criteria (ala the SELECT of a VQUERY).  

> I am not familiar enough with ABNF and I have no idea ATM if I have enough
> time. I will try to come up with an informal proposal to see if we are
> agree. OK?
Works for me.  Ill be happy to work on an ABNF after the dust settles.

> But I, for one, will not stop using stored queries as I explained.
I wont try to stop you but Im very curious how the CS is going to react to the CUA trying to read that VQUERY from the CS...   I think that no CUA should try to use something that it cannot read out of the CS myself; its just not safe.

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 007A85F985256C75_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 19 06:57:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02574 for ; Tue, 19 Nov 2002 06:57:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJBnZP06197 for ietf-calendar-bks; Tue, 19 Nov 2002 03:49:35 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJBnWg06186 for ; Tue, 19 Nov 2002 03:49:32 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 745571550E; Tue, 19 Nov 2002 12:49:29 +0100 (CET) Date: Tue, 19 Nov 2002 12:49:29 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? Message-ID: <20021119114928.GM96286@inet.it> References: <20021115130940.GA2149@inet.it> 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.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, On Mon, Nov 18, 2002 at 05:19:55PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > I got that part. What I have a problem with is that if a CUA tried to > actually retrieve the actual VQUERY from the CS then it would have to fail > since the CS has no way (in CAP 1.0) to encode the non-CAP-QL-able query > in CAP-QL. So if a CUA cannot retrieve a VQUERY then should it try to use > it in a query?? Its very unclear and vague to say the least and I think > VQUERY storage as for CAP 1.0 is not needed. Once again, I don't see the problem. If the CUA sends: BEGIN:VQUERY QUERY:SELECT VQUERY FROM VAGNEDA WHERE NAME = 'MAGIC01' ENV:VQUERY The CS replies: BEGIN:VQUERY QUERYID:MAGIC01 END:VQUERY I don't see why you think it should be an error (although it would require an ABNF change) - the CS has the query so it sends what it has. It just happens to be unable to represent it in CAP-QL. Incidentally, that's the reason why a few months ago I proposed we added a way to specify the VQUERY is hardcoded in the CS and can't be represented in CAP-QL. BEGIN:VQUERY QUERYID:MAGIC01 NATIVE:YES (NATIVE is just an example, you can choose a better name) END:VQUERY This would make clear to a CUA that it is looking at a valid VQUERY, but nothing is know about its implementation - so the CUA had better know what to do with it or leave it alone. Also, do you really expect all CUAs to retrieve the VQUERY before calling it? Then what, do a string compare of the QUERY? It would be even less useful then. > Stored VQUERYs like you describe could be stored/retrieved in a subsequent > draft if we make sure that CAP allows for storing of any components and > the newer draft can encode up the non-CAP-QL query. The System Model in > Section 3.1 does not expressly show this (no IANA-Components in the tree) > but I think the intent is there. I agree that CAP should allow storing any component. Of course, an actual CUA implementation should not expect to be able to store components the server doesn't list as supported in GET-CAPABILITY. > In the mean time I still think that building in VQUERY storage is a waste > of cycles. At a very minimum it should be a CS response to GET-CAPABILITY > since I for one dont want to have to build it in when I cant see a strong > usage for it given the current query model... I agree it should be in GET-CAPABILITY. > IMHO there should be no data put into the CS by ANY means (Administrative > or not) that cannot be retrieved and/or encoded using the CAP 1.0 or > updated iCalendar specs. Otherwise it just becomes a recipe for disaster. I agree. It just happens to have no QUERY property, so what? It's still legal, so you can retrieve it. > response to the "SELECT VQUERY FROM VAGENDA ..." command. I would not > expect a CUA to use a VQUERY that it cannot read from the CS, would you?? > (I like to practice Save Hex...) That's a CUA choice. In controlled environments (the CUA knows it can trust the CS), it would be safe. Remember that I'm talking about hardcoded VQUERY, so no malicious CUA could change them. > CS's to implement it. Currently in CAP-QL the CUA is going to have to > recraft the VQUERY every time it wants to do that "What events are on the > calendar for this week" since "this week" changes. This inability to > wildcard makes stored VQUERYs less than useful for CAP 1.0. As such I am > strongly questioning why we do not remove it from CAP 1.0 and simplify the > draft accordingly... I agree that CAP-QL is currently not powerful enough to write generically useful store queries. I will also admit that what I have in mind could be not generally useful. > I have no qualms w/you or anyeone else coming up with a follow-on draft to > use named queries (VQUERY2?) that can be stored, etc but I dislike all > this baggage that has no current benefit. I guess I have to agree with you that there are some issues that need to be addressed for stored queries to be really useful; among these are parameters and security. I don't think I agree about the no benefit part, since I can do my stuff without violating the draft, but this is a personal opinion. Since I seem to be the only one to defend it, I have no problem with taking stored queries away and doing it properly in another draft. However, this requires thinking NOW about how the new draft will extend the current model. Will it change or extend VQUERY? Then we might need to check VQUERY ABNF (I think QUERY should be optional). Will it introduce a new component? But all commands take VQUERY, so I won't be able to send a SEARCH using VQUERY2... 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 Nov 21 09:53:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04657 for ; Thu, 21 Nov 2002 09:53:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALEcWb05144 for ietf-calendar-bks; Thu, 21 Nov 2002 06:38:32 -0800 (PST) Received: from atpop.smtp.stsn.com (p105.n-atpop03.stsn.com [12.129.82.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALEcSg05133 for ; Thu, 21 Nov 2002 06:38:28 -0800 (PST) Received: from [10.0.174.240] ([10.0.174.240]) by atpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 21 Nov 2002 09:37:34 -0500 Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: Date: Thu, 21 Nov 2002 09:38:21 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Minutes from Wednesday's meeting Cc: Bob Mahoney , Pat Egen Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 21 Nov 2002 14:37:35.0000 (UTC) FILETIME=[880EE180:01C2916B] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Calendar & Scheduling Working Group minutes, Wed Nov 20 reported by Larry Greenfield Bob Mahoney is chairing. . Chair, introduction & agenda bashing . Chair, status of drafts CAP is very long lived and still changing. More eyeballs are needed and encouraged! xCal has been in and out of the working group. We didn't want to get distracted from our major goal (CAP) but maybe it's possible for us to do work on xCal without getting too distracted. . Chair, interop results Novell intended to hold a physical interop, but not enough participants would have been able to come. Instead a virtual interop was held with IBM/Lotus, Oracle/Steltor, Novell, and KOrganizer participating: exchanging calendar objects and participating in conference calls. We need a better feature matrix if we want to move iCal to draft; anyone interested in doing so should volunteer. Drop a note to the chairs if you would like info on how to help. . Chair, point of information There's a Java iCal parser at http://www.sourceforge.net/project/jical/. . Pekka Pessi, iTIP SIP binding "iSIP" draft-pessi-calsch-isip-00.txt iSIP currently uses xCal ("it seemed like a good idea at the time") but the iCal format might actually be more extendable and more suited for our purposes. iSIP doesn't conflict with the current calsch work. Should it be part of calsch? What interesting applications are enabled by iSIP? The chair pointed out that the WG is already way overdue on some milestones so it might not be that wise to take more stuff on. Paul Hill asked why this wasn't being done in SIPPING; Pekka replied that SIPPING is very crowded and has many requirements and the calendar expertise is here. Aki Niemi thought that SIPPING had shown some interest. Chris Newman pointed out that there needs to be applicability of when to use iSIP instead of or in addition to iMIP and iRIP. . Chair, mailing list The mailing list can seem unfriendly or imposing but don't let us old bitter people scare you. Please participate! . Chris Newman, some issues with CAP Issue #1: How are calendars named and how do clients discover calendars available. Clients need to be able to find out what calendars it can access: private, shared, and public calendars. Larry Greenfield and Paul Hill discussed that this was brought up some time ago, and Paul talked about how the various subscription models of the calendars can be fairly confusing. Disagreements about what the namespace is makes coming to consensus hard. Chris pointed out that the mailbox namespace is one of the worst parts of IMAP interoperability, and committed himself to drawing an analogy between IMAP and CAP namespace on the mailing list. Issue #2: What should the mandatory to implement security be? Chris recommends requiring implementations support TLS with the SASL mechanism PLAIN, since it deploys much better than DIGEST-MD5. Kurt Zeilenga agrees. Issue #3: Multiple connections versus BEEP channels. The current draft doesn't discuss whether servers have to process channels in parallel or if processing on one channel can block the other channels. If clients only make a single TCP connection, rate limiting and other accounting is much easier---but if clients have to open multiple connections to keep long running operations from blocking, they will. Larry Greenfield said that requiring parallel processing of channels is a barrier to implementation and it isn't clear how to write an on-the-wire specification requiring it. Some discussion on Jabber with Marshall Rose and Larry Greenfield. Patrick Falstrom said that understanding congestion control/resource allocation on the application layer is a general concern for the IETF but no one has any good ideas. Issue #4: Round trips are very expensive; pipelining should be mandatory. . meeting adjourns From owner-ietf-calendar@mail.imc.org Thu Nov 21 11:45:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10011 for ; Thu, 21 Nov 2002 11:45:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALGUbN16125 for ietf-calendar-bks; Thu, 21 Nov 2002 08:30:37 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALGUZg16120 for ; Thu, 21 Nov 2002 08:30:35 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gALGUXIR005563; Thu, 21 Nov 2002 08:30:33 -0800 Message-ID: <3DDD0A27.70403@Royer.com> Date: Thu, 21 Nov 2002 09:30:31 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Minutes from Wednesday's meeting (xCal) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030806010003060501000809" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030806010003060501000809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bob Mahoney wrote: > > . Chair, status of drafts > > CAP is very long lived and still changing. More eyeballs are needed > and encouraged! xCal has been in and out of the working group. We > didn't want to get distracted from our major goal (CAP) but maybe it's > possible for us to do work on xCal without getting too distracted. To subscribe send email to 'majordomo@inet-consulting.com' with a subject of 'subscribe xcal-dev'. -Doug --------------ms030806010003060501000809 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyMTE2MzAzMVowIwYJKoZIhvcNAQkEMRYEFHGRZxie k2M5+PWYrcwar2ROmKjzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB3fJkCwh5pfg9rtaV1 ZztbKVDzf/MryjkpvHsJt9+1vtX9wHNSv2DNItn2jlpW9n63vpka5ix5hB979c9pkT78S9Tv m/nDw0Py6pNOUQR23upmUICjZbt5r0fQJzM8DZYKy+7CfScscQsnMMgsypC5vvVPUyQ0Khnw 18Y3winkizvAjh8G8oOrOcbh/xLpSUG1Zn0ugfpqdcD8tx2mUBSazy7MFwGG7F6fB0MgdMPk 0takLweVr8jSm7RPYPl63D0MR4iB0qdqb2x2vSu8hJ5+JsvbfR6paeIKc8S+l4SmQfYt+WfO TO0UYi+HIGL8SizcYogZVHxLfHI98GRmnTEwAAAAAAAA --------------ms030806010003060501000809-- From owner-ietf-calendar@mail.imc.org Thu Nov 21 11:52:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10169 for ; Thu, 21 Nov 2002 11:52:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALGbts16259 for ietf-calendar-bks; Thu, 21 Nov 2002 08:37:55 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALGbrg16255 for ; Thu, 21 Nov 2002 08:37:53 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gALGbrIR005635 for ; Thu, 21 Nov 2002 08:37:53 -0800 Message-ID: <3DDD0BDE.7020907@Royer.com> Date: Thu, 21 Nov 2002 09:37:50 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Minutes from Wednesday's meeting (calendar naming/locating References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000307060505060503050306" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000307060505060503050306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bob Mahoney wrote: > . Chris Newman, some issues with CAP > > Issue #1: How are calendars named and how do clients discover > calendars available. Clients need to be able to find out what > calendars it can access: private, shared, and public calendars. I think that the IMAP model and CAP model differ in this way. With IMAP - the spec specifies that INBOX will always exist (I think). There is also RFC-2739 ( Calendar Attributes for vCard and LDAP ) > Larry Greenfield and Paul Hill discussed that this was brought up some > time ago, and Paul talked about how the various subscription models of > the calendars can be fairly confusing. Disagreements about what the > namespace is makes coming to consensus hard. Chris pointed out that > the mailbox namespace is one of the worst parts of IMAP > interoperability, and committed himself to drawing an analogy between > IMAP and CAP namespace on the mailing 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 --------------ms000307060505060503050306 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyMTE2Mzc1MFowIwYJKoZIhvcNAQkEMRYEFHVOSq4J G780N1G/JlQkRUcIoM5GMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCMxZ8PI14pyhoc+Cbv 41pMGAKv2xyqjOVEdcwBatR9Ms/oQDRlf28GQ48k/O+Ntgm3A9Rb+1IsQWEQYlKNADD1B1R2 VQrnlLipX9HfZCp+72bV5/wd82oxDYHEPImYQEkrLmONyOG4kZJkzsUoZZhSzpXvambfb1I7 oNuvYzWhHNBxk5sr3jiov3wOsC+omsvpBwVzgmCdqy6r6apts70U78Vydf6Z7+NLLWCEhXi9 WA8GQxG0VIeDCJ8A7x+aQPiTMHecbLZPUK/BRrywePfZUynQTvmyi4A6X2YltuFPBLyfMr0u pQFNQDm3X+BuflLTls7IM1h0H/Yap5oeeVnCAAAAAAAA --------------ms000307060505060503050306-- From owner-ietf-calendar@mail.imc.org Thu Nov 21 11:55:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10323 for ; Thu, 21 Nov 2002 11:55:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALGgwj16358 for ietf-calendar-bks; Thu, 21 Nov 2002 08:42:58 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALGgtg16354 for ; Thu, 21 Nov 2002 08:42:55 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gALGgtIR005689 for ; Thu, 21 Nov 2002 08:42:56 -0800 Message-ID: <3DDD0D0D.4060209@Royer.com> Date: Thu, 21 Nov 2002 09:42:53 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Minutes from Wednesday's meeting (SASL/PLAIN) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010205010704080006070903" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010205010704080006070903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > Issue #2: What should the mandatory to implement security be? Chris > recommends requiring implementations support TLS with the SASL > mechanism PLAIN, since it deploys much better than DIGEST-MD5. Kurt > Zeilenga agrees. I thought that we were told by the IESG that we MAY NOT use PLAN as the default. We used to have SASL/PLAIN - and were told NO by the IESG. Then we migrated to BEEP - and PLAIN was still out. Has the IESG changed the policy? The IMAP WG reciently had a request from the IESG NOT to use plain in one of its newer drafts that they wanted to go to proposed standard status. As I recall the discussion, the only reason that the IESG said yes to IMAP-PLAIN - was that it would break all (many?) existing IMAP implementaitons and that they needed more time to transisition. CAP - does not need any transistion time as there is nothing to transistion from. -- 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 --------------ms010205010704080006070903 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyMTE2NDI1M1owIwYJKoZIhvcNAQkEMRYEFB9ObJqV H7m9NWaFEd6d4fMuJLu8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBsiB8/pTDLFhYAeU88 4bFWExVRq1enz0Xmch+tkh9HYAmTMyUyzembOHNh0536xJw0SuAp3m0m6/M9wFLP0U6hHnmc YAfz8GDvigFPNU+irb8UcTtBhFm5TotsBs4o1tyzmrGroFc1N32BCQNZlCi+beIssfYeVj15 W3GdlBUKU0U22RtsRqkmVIw8LYWXPSoZbqLyIzWBaRro98D0ho7Bzg6CwV2tP5qrL1zwlINH B+G4rhYH6W5m3lQbKI6rbA1SDW2g9UNUjt0AupLpMl6wfWfV0re34+RLL/ilCQ45LB7Oir05 DPWrQTe7nicrC2ui/0tclClm4Uk0Zq9mwXm6AAAAAAAA --------------ms010205010704080006070903-- From owner-ietf-calendar@mail.imc.org Thu Nov 21 12:02:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10541 for ; Thu, 21 Nov 2002 12:02:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALGpVh16496 for ietf-calendar-bks; Thu, 21 Nov 2002 08:51:31 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALGpSg16491 for ; Thu, 21 Nov 2002 08:51:28 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gALGpSIR005778 for ; Thu, 21 Nov 2002 08:51:29 -0800 Message-ID: <3DDD0F0E.30108@Royer.com> Date: Thu, 21 Nov 2002 09:51:26 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Minutes from Wednesday's meeting References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070008040705090000040801" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070008040705090000040801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > Issue #3: Multiple connections versus BEEP channels. The current draft > doesn't discuss whether servers have to process channels in parallel > or if processing on one channel can block the other channels. If > clients only make a single TCP connection, rate limiting and other > accounting is much easier---but if clients have to open multiple > connections to keep long running operations from blocking, they > will. Larry Greenfield said that requiring parallel processing of > channels is a barrier to implementation and it isn't clear how to > write an on-the-wire specification requiring it. Some discussion on > Jabber with Marshall Rose and Larry Greenfield. We DID have this discussion - when we moved from pre-BEEP to BEEP. We used to have some kind of parallel processing and we had an attribute of CAPABILITY to specify how many parallel operations were possible. Then we changed to BEEP - simply allow or do not allow a new channel. > Issue #4: Round trips are very expensive; pipelining should be > mandatory. That is the advantage of BEEP. If the CS (for example) can handle multiple parallel commands - then the CUA can send multiple in parallel each on a separate channel. If the CS can not handle those parallel commands then it should not accept the new channel open request. I think we have already addressed this 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 --------------ms070008040705090000040801 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyMTE2NTEyNlowIwYJKoZIhvcNAQkEMRYEFDMzJXcD DQ+dIKvUD8tQ0TUDlMVQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB2s0uMYLlHDoMalGrS tK9JQ7RD+PNz7eCh5JMurRUsxwmtua39nqBZhL9U8swDE/34B57sFHoc6/hdLpPdW8a7x11H dGA/BpABm3sFcTdcoj6WGvUjFqznDgdHVRFc24fFUuHqjQRbr7EBc2HQUHWFdp/not4YyQJ5 bDBFdzRR7xRkR9OPTBgqlD5HZdbLItWtD8T0vQXWCX/OsYmvhCJC0b0vAfNdPZW0gLIyA/TJ MXFJTRcidHcjlySjrVVSt04L6hrWelSMJG1ThOVV7ylMsjghbs9ZG6IDVB5p6sFraV1LPXFK 4H67ddqfDx3CUPEECHYdDWCTEtrsvgMYh/tCAAAAAAAA --------------ms070008040705090000040801-- From owner-ietf-calendar@mail.imc.org Thu Nov 21 12:16:15 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11110 for ; Thu, 21 Nov 2002 12:16:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALH32G16823 for ietf-calendar-bks; Thu, 21 Nov 2002 09:03:02 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALH2xg16819 for ; Thu, 21 Nov 2002 09:03:00 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA09028 for ; Thu, 21 Nov 2002 12:02:59 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA06586 for ; Thu, 21 Nov 2002 12:02:58 -0500 (EST) Received: from TABLET (TABLET.ietf55.ops.ietf.org [204.42.71.193]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id MAA13438 for ; Thu, 21 Nov 2002 12:02:58 -0500 (EST) Message-ID: <004101c2917f$d7d74a40$c1472acc@TABLET> From: "Paul B. Hill" To: References: <3DDD0D0D.4060209@Royer.com> Subject: Re: Minutes from Wednesday's meeting (SASL/PLAIN) Date: Thu, 21 Nov 2002 12:02:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The issue is that PLAIN is not in isolation. TLS gets started, and then a username/password can be sent over the encyrpted channel. If we specify digest, sites that have existing authentication systems still have a problem on how to adapt their existing systems. ----- Original Message ----- From: "Doug Royer" To: Sent: Thursday, November 21, 2002 11:42 AM Subject: Re: Minutes from Wednesday's meeting (SASL/PLAIN) > > > > > > > Issue #2: What should the mandatory to implement security be? Chris > > recommends requiring implementations support TLS with the SASL > > mechanism PLAIN, since it deploys much better than DIGEST-MD5. Kurt > > Zeilenga agrees. > > I thought that we were told by the IESG that we MAY NOT use PLAN > as the default. > > We used to have SASL/PLAIN - and were told NO by the IESG. > Then we migrated to BEEP - and PLAIN was still out. > > Has the IESG changed the policy? > > The IMAP WG reciently had a request from the IESG NOT to use > plain in one of its newer drafts that they wanted to go to > proposed standard status. As I recall the discussion, the only reason > that the IESG said yes to IMAP-PLAIN - was that it would break all (many?) > existing IMAP implementaitons and that they needed more time to transisition. > > CAP - does not need any transistion time as there is nothing > to transistion from. > > -- > > 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 Nov 21 12:18:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11204 for ; Thu, 21 Nov 2002 12:18:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALH7Ce16903 for ietf-calendar-bks; Thu, 21 Nov 2002 09:07:12 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALH79g16899 for ; Thu, 21 Nov 2002 09:07:09 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA10997 for ; Thu, 21 Nov 2002 12:07:10 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA07526 for ; Thu, 21 Nov 2002 12:07:09 -0500 (EST) Received: from TABLET (TABLET.ietf55.ops.ietf.org [204.42.71.193]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id MAA15464 for ; Thu, 21 Nov 2002 12:07:09 -0500 (EST) Message-ID: <004701c29180$6d58e920$c1472acc@TABLET> From: "Paul B. Hill" To: References: <3DDD0F0E.30108@Royer.com> Subject: Re: Minutes from Wednesday's meeting Date: Thu, 21 Nov 2002 12:07:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Chris pointed out that although BEEP provides for mutliple channels over a single connection, nothing mandates it. If a client implementor decides to use only a single BEEP channel and then open up a new connection for each operation that they want to perform in parallel, we loose much of the benefit of BEEP. The draft should have some langauge about this. We really don't want clients that open up a large number of parrallel connections. Chris offered to take a stab at some suggested text. ----- Original Message ----- From: "Doug Royer" To: Sent: Thursday, November 21, 2002 11:51 AM Subject: Re: Minutes from Wednesday's meeting > > > Issue #3: Multiple connections versus BEEP channels. The current draft > > doesn't discuss whether servers have to process channels in parallel > > or if processing on one channel can block the other channels. If > > clients only make a single TCP connection, rate limiting and other > > accounting is much easier---but if clients have to open multiple > > connections to keep long running operations from blocking, they > > will. Larry Greenfield said that requiring parallel processing of > > channels is a barrier to implementation and it isn't clear how to > > write an on-the-wire specification requiring it. Some discussion on > > Jabber with Marshall Rose and Larry Greenfield. > > We DID have this discussion - when we moved from pre-BEEP to BEEP. > We used to have some kind of parallel processing and we had an attribute > of CAPABILITY to specify how many parallel operations were possible. > Then we changed to BEEP - simply allow or do not allow a new channel. > > > Issue #4: Round trips are very expensive; pipelining should be > > mandatory. > > That is the advantage of BEEP. If the CS (for example) can handle > multiple parallel commands - then the CUA can send multiple in parallel > each on a separate channel. If the CS can not handle those parallel > commands then it should not accept the new channel open request. > > I think we have already addressed this 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 Thu Nov 21 17:29:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23941 for ; Thu, 21 Nov 2002 17:29:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALMCwr08547 for ietf-calendar-bks; Thu, 21 Nov 2002 14:12:58 -0800 (PST) Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALMCtg08543 for ; Thu, 21 Nov 2002 14:12:55 -0800 (PST) Received: from majormajor.ietf55.ops.ietf.org (majormajor.ietf55.ops.ietf.org [204.42.70.190]) (user=leg mech=GSSAPI (0 bits)) by smtp7.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id gALMCtBI022513 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 21 Nov 2002 17:12:55 -0500 Date: Thu, 21 Nov 2002 17:12:51 -0500 From: Lawrence Greenfield To: ietf-calendar@imc.org Subject: Re: Minutes from Wednesday's meeting Message-ID: <29545594.1037898771@majormajor.ietf55.ops.ietf.org> In-Reply-To: <3DDD0F0E.30108@Royer.com> References: <3DDD0F0E.30108@Royer.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Thursday, November 21, 2002 9:51 AM -0700 Doug Royer wrote: > We DID have this discussion - when we moved from pre-BEEP to BEEP. > We used to have some kind of parallel processing and we had an attribute > of CAPABILITY to specify how many parallel operations were possible. > Then we changed to BEEP - simply allow or do not allow a new channel. Right, the question is whether we can require high quality implementations of BEEP that will correctly parallize different operations. > > Issue #4: Round trips are very expensive; pipelining should be > > mandatory. > > That is the advantage of BEEP. If the CS (for example) can handle > multiple parallel commands - then the CUA can send multiple in parallel > each on a separate channel. If the CS can not handle those parallel > commands then it should not accept the new channel open request. > > I think we have already addressed this issue. It's mostly an issue to make sure that common operations won't have the client make a query, wait for the response, then based on that information make another request. If there are obvious synchronization points that can be removed it's always a good thing to do so. I'll try to look for this on my next reading of the draft. Larry From owner-ietf-calendar@mail.imc.org Thu Nov 21 18:41:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26444 for ; Thu, 21 Nov 2002 18:41:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALNVLZ13231 for ietf-calendar-bks; Thu, 21 Nov 2002 15:31:21 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALNVJg13227 for ; Thu, 21 Nov 2002 15:31:19 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gALNVKIR008978 for ; Thu, 21 Nov 2002 15:31:20 -0800 Message-ID: <3DDD6CC5.7040408@Royer.com> Date: Thu, 21 Nov 2002 16:31:17 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Minutes from Wednesday's meeting References: <3DDD0F0E.30108@Royer.com> <29545594.1037898771@majormajor.ietf55.ops.ietf.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050202040601050604000103" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050202040601050604000103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lawrence Greenfield wrote: > > --On Thursday, November 21, 2002 9:51 AM -0700 Doug Royer > wrote: > >> We DID have this discussion - when we moved from pre-BEEP to BEEP. >> We used to have some kind of parallel processing and we had an attribute >> of CAPABILITY to specify how many parallel operations were possible. >> Then we changed to BEEP - simply allow or do not allow a new channel. > > > Right, the question is whether we can require high quality > implementations of BEEP that will correctly parallize different operations. If a CS can only do one thing at a time, it should not open up the other channels. If it does allow multiple channels to be opened up and then performs them in first come basis. Then the there is no way that I can think of for a CUA to send a 2nd command which had results in it from a 1st command that has not yet returned. I do not see that that problem can ever exist. The only way that parallel operations can be performed and not serialized by the CUA is when the commands from the CUA are independent of each other from the CUA's point of view. I do not think it is a protocol limitation or issue. I will depend on the CUA implementation. >> > Issue #4: Round trips are very expensive; pipelining should be >> > mandatory. >> >> That is the advantage of BEEP. If the CS (for example) can handle >> multiple parallel commands - then the CUA can send multiple in parallel >> each on a separate channel. If the CS can not handle those parallel >> commands then it should not accept the new channel open request. >> >> I think we have already addressed this issue. > > > It's mostly an issue to make sure that common operations won't have the > client make a query, wait for the response, then based on that > information make another request. That would be a CUA implementation issue, not a protocol issue. If a CUA needs the results of one operation in order to start another operation then it will need to wait for the data no matter if the CS can performs parallel commands or not. There are common operations where the CUA will have to wait. An Example is looking for a time slot to book a VEVENT. The CUA is going to have to get the VFREEBUSY and then deposit a BOOKED or UNPROCESSED entry into the CS. I am sure there are many more examples. Parallel example: If a CUA were to search for available time slots common to multiple calendars, then the CUA can perform multiple queries, each to a separate calendar, process the results, then do parallel store operations in multiple calendars. If the CS can only do one thing at a time, then the CUA is simply going to get the results one at a time. If a CS does not allow a new channel to be opened, then the CUA is already going to have to wait for an already opened channel to finish so that the command can be sent. As I understand BEEP - that is what BEEP does for us. It gives us a predefined way to do (or not do) parallel operations. The CS will or will not perform those operations in parallel. The CAP protocol does not need to change. Pipelining will not have any advantage if you can already perform multiple commands each in a separate channel. And when the CS can not do parallel commands, then BEEP still works, its just that the responses will always be in the order the CUA sent the commands independent of the channel. > If there are obvious synchronization > points that can be removed it's always a good thing to do so. I'll try > to look for this on my next reading 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 --------------ms050202040601050604000103 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyMTIzMzExN1owIwYJKoZIhvcNAQkEMRYEFCMFCVi5 s8C8Gj1EP8pmo+hTOU6ZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB5FdfU4B2Do6PDjAJr 0IMAO3c9UMb3tP1zpWfmfZxs30hXDpLxiv5aSXH7uZLlCm2ts2d9lKHcslaLpp37TSRNRSBD bAwSQIgE8KvNaxaOwHakIWSXJ/GKDHAr4pkFkXRB+v9DynFojD3X8/QanrtgVUiLt+GzcpOA 5qBx9gXrMR8+ffpAv5xDeb0Q2hWHbHuqME36mP6xFn4PTF+9Xn4Qca0gfY+KjS+QJq7ww6g/ Cloawy8QcmKYtio4Pd8jmPFPKq2YJ9MxoHhAf9coSBKbAIuOUbav7Gp1Gwgm6Q6SBaeAwQWD Tq3XFSXrkNk3aiUFvq7kOtYRBJWYJHTEw2HUAAAAAAAA --------------ms050202040601050604000103-- From owner-ietf-calendar@mail.imc.org Fri Nov 22 12:21:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29701 for ; Fri, 22 Nov 2002 12:21:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMH6nr05840 for ietf-calendar-bks; Fri, 22 Nov 2002 09:06:49 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMH6kg05836 for ; Fri, 22 Nov 2002 09:06:47 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id gAMH6kQ9024685; Fri, 22 Nov 2002 12:06:47 -0500 Date: Fri, 22 Nov 2002 12:06:46 -0500 Message-Id: <200211221706.gAMH6kQ9024685@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: "ietf-calendar@imc.org" In-reply-to: <3DDD6CC5.7040408@Royer.com> Subject: Re: Minutes from Wednesday's meeting References: <3DDD0F0E.30108@Royer.com> <29545594.1037898771@majormajor.ietf55.ops.ietf.org> <3DDD6CC5.7040408@Royer.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Thu, 21 Nov 2002 16:31:17 -0700 From: Doug Royer [...] That would be a CUA implementation issue, not a protocol issue. If a CUA needs the results of one operation in order to start another operation then it will need to wait for the data no matter if the CS can performs parallel commands or not. There are obviously protocol designs that can exacerbate or minimize the roundtrip problem. The feedback in the WG meeting is merely that, when possible, CAP should attempt to minimize roundtrips needed for common operations. This is not specific criticism of the protocol as written, just general guidance of things that have bitten us in IMAP. Larry From owner-ietf-calendar@mail.imc.org Fri Nov 22 13:48:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01042 for ; Fri, 22 Nov 2002 13:48:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMISHU10236 for ietf-calendar-bks; Fri, 22 Nov 2002 10:28:17 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMISEg10232 for ; Fri, 22 Nov 2002 10:28:14 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gAMISFIR017131 for ; Fri, 22 Nov 2002 10:28:15 -0800 Message-ID: <3DDE773C.1090304@Royer.com> Date: Fri, 22 Nov 2002 11:28:12 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Minutes from Wednesday's meeting References: <3DDD0F0E.30108@Royer.com> <29545594.1037898771@majormajor.ietf55.ops.ietf.org> <3DDD6CC5.7040408@Royer.com> <200211221706.gAMH6kQ9024685@smtp6.andrew.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030609040601020303000203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030609040601020303000203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lawrence Greenfield wrote: > Date: Thu, 21 Nov 2002 16:31:17 -0700 > From: Doug Royer > [...] > That would be a CUA implementation issue, not a protocol issue. If > a CUA needs the results of one operation in order to start another > operation then it will need to wait for the data no matter if the > CS can performs parallel commands or not. > > There are obviously protocol designs that can exacerbate or minimize > the roundtrip problem. The feedback in the WG meeting is merely that, > when possible, CAP should attempt to minimize roundtrips needed for > common operations. Thanks - What are these obvious design issues in CAP? > This is not specific criticism of the protocol as written, just > general guidance of things that have bitten us in IMAP. That fine - but posting that you think that there might be some obvious issues with no instances cited - only leads me to think that you are not sure if your are correct with respect to CAP. -- 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 --------------ms030609040601020303000203 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+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyMjE4MjgxMlowIwYJKoZIhvcNAQkEMRYEFI7VQND9 B83MKWBen5VDRbumZuChMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCrlONmV9bZAyO410Jl DgmkotZ3b2cDWRX9mcsCuVlECMLgH5N/Tqyr4B6F1/ujddCTRH2xZwEMFVX6EnWAy1k1oRYi /S3cqg+BOTaWG9Mk5/m95DDViN3DlKyyzn3OqSQpZm287XyK+b/+HNC8agPXbPyUvDjbn4zt peyemRbhpL0SB4bmp8NZUJBJ6P6n6EDdA18NxlGYxlDPPlSOHxjMRl9IqyZXzOYgL8EpM1Yu IP0RLio3KG/LH/LoSO3beiBZ/0zHOTYWlx66IV3xKP9DCou8UtNJmZU2h9A6KG4nbTs4jtVa XDciUXZpGdwbBsnsH1sttF2d5gmajdSm5u3KAAAAAAAA --------------ms030609040601020303000203-- From owner-ietf-calendar@mail.imc.org Wed Nov 27 08:16:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08443 for ; Wed, 27 Nov 2002 08:16:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gARD64o14809 for ietf-calendar-bks; Wed, 27 Nov 2002 05:06:04 -0800 (PST) Received: from eeyore.jsoft.com (24-240-234-245.charter.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gARD60g14804 for ; Wed, 27 Nov 2002 05:06:01 -0800 (PST) Received: from jsoft.com (IDENT:JGaqCP4i46g/DKf4Rx2kz6l0OkAiSUz4@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id gARD3Lk08772; Wed, 27 Nov 2002 07:03:21 -0600 Message-ID: <3DE4C298.2090702@jsoft.com> Date: Wed, 27 Nov 2002 07:03:20 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Mahoney , ietf-calendar@imc.org, Pat Egen Subject: Re: Minutes from Wednesday's meeting References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit FYI Bob Mahoney wrote: > > Calendar & Scheduling Working Group minutes, Wed Nov 20 > reported by Larry Greenfield > > Bob Mahoney is chairing. > > . Chair, introduction & agenda bashing > > . Chair, status of drafts > > CAP is very long lived and still changing. More eyeballs are needed > and encouraged! xCal has been in and out of the working group. We > didn't want to get distracted from our major goal (CAP) but maybe it's > possible for us to do work on xCal without getting too distracted. trim The Mozilla Calendar uses a version of xCal in the import/export filters. Works well, easy to dance with, will be on more and more desktops as time passes. Gary