From owner-ietf-calendar@mail.imc.org Sun Aug 1 18:38:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29266 for ; Sun, 1 Aug 2004 18:38:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71MS285082074; Sun, 1 Aug 2004 15:28:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71MS2P1082073; Sun, 1 Aug 2004 15:28:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71MS2br082058 for ; Sun, 1 Aug 2004 15:28:02 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from [130.129.128.215] [130.129.128.215] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A887453601B0; Sun, 01 Aug 2004 15:02:47 -0700 In-Reply-To: <410AD4E2.2030209@Royer.com> References: <410AD4E2.2030209@Royer.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Nathaniel Borenstein Subject: Re: proposed revised charter for IETF calsch WG Date: Sat, 31 Jul 2004 04:07:31 -0400 To: IETF calsch WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Jul 30, 2004, at 7:08 PM, Doug Royer wrote: > I do not think that RFC02445-7 have significant changes. Alas, I disagree. RFC 2026 spells out in detail the requirements for advancing a protocol to Draft Standard status, and the current RFCs don't even come close to fulfilling them. A couple of relevant excerpts from Section 4.1.2: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. ......... The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. The just-concluded-today Interop of the Calendaring and Scheduling Consortium was interesting in many ways (as will be reported at the WG on Tuesday and to this list) but if there's one thing it showed very clearly, it was that there are multiple "options and features" that have not been demonstrated to interoperate, and possibly some that haven't yet been implemented once. I hate to bear the gloomy message, but I think there is a lot of accumulated wisdom embedded in the IETF process. We've got some serious work to do before iCal is worthy of Draft status, which (according to RFC 2026, same section) indicates "a strong belief that the specification is mature and will be useful." As long as vendors are still writing new adapters to deal with each others' varying flavors of iCal, I find "mature and useful" to be a bit of a stretch. The good news is that we can probably improve iCal greatly by simplifying it, rather than making it more complex. More on that Tuesday, if not sooner. I must sleep before yet another spam conference in the morning... -- Nathaniel From owner-ietf-calendar@mail.imc.org Sun Aug 1 19:25:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01776 for ; Sun, 1 Aug 2004 19:25:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71NJA23084703; Sun, 1 Aug 2004 16:19:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71NJAgJ084702; Sun, 1 Aug 2004 16:19:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71NJ98p084694 for ; Sun, 1 Aug 2004 16:19:09 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i71NJ6Jd012645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 1 Aug 2004 16:19:07 -0700 Message-ID: <410D7A6A.1050604@Royer.com> Date: Sun, 01 Aug 2004 17:19:06 -0600 From: Doug Royer Reply-To: IETF calsch WG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: proposed revised charter for IETF calsch WG References: <410AD4E2.2030209@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050109080102020202040709" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050109080102020202040709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes, I agree. However I did not read 'some features were not implemented' to mean '(substantial) revisions' :-) Nathaniel Borenstein wrote: > > On Jul 30, 2004, at 7:08 PM, Doug Royer wrote: > >> I do not think that RFC02445-7 have significant changes. > > > Alas, I disagree. RFC 2026 spells out in detail the requirements for > advancing a protocol to Draft Standard status, and the current RFCs > don't even come close to fulfilling them. A couple of relevant > excerpts from Section 4.1.2: > > A specification from which at least two independent and interoperable > implementations from different code bases have been developed, and > for which sufficient successful operational experience has been > obtained, may be elevated to the "Draft Standard" level. > ......... > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. In cases in which one or more options or features > have not been demonstrated in at least two interoperable > implementations, the specification may advance to the Draft Standard > level only if those options or features are removed. > > The just-concluded-today Interop of the Calendaring and Scheduling > Consortium was interesting in many ways (as will be reported at the WG > on Tuesday and to this list) but if there's one thing it showed very > clearly, it was that there are multiple "options and features" that > have not been demonstrated to interoperate, and possibly some that > haven't yet been implemented once. > > I hate to bear the gloomy message, but I think there is a lot of > accumulated wisdom embedded in the IETF process. We've got some > serious work to do before iCal is worthy of Draft status, which > (according to RFC 2026, same section) indicates "a strong belief that > the specification is mature and will be useful." As long as vendors > are still writing new adapters to deal with each others' varying > flavors of iCal, I find "mature and useful" to be a bit of a stretch. > > The good news is that we can probably improve iCal greatly by > simplifying it, rather than making it more complex. More on that > Tuesday, if not sooner. I must sleep before yet another spam > conference in the morning... -- Nathaniel -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050109080102020202040709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODAxMjMxOTA2WjAjBgkqhkiG9w0BCQQxFgQUz3UYRDd+V8PHHG1hjEIJ lNoA1EAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEACSDFAhUPCUvVP6y25jJGqcgo7u975RaRys+VTQkRn7VQEi89EjEGEjLx8J1UyQNc mtUcYK3vnoCif/sLOCgy/mKJB3DekxAhEXg74XZ/iL0FYEDHaVgJ7mCRQ0BEiGDQNiPg4LLC U1CCKcPDFA7xmanu8k+B/5AKd41xcuEvWrsxvv2QvQi8Qjr1mkUD4m4/uDUU+1KQJfY2iThn f+OQjnzXb/18HRPeUqOIUK4VT8aPiHNn+lZYVTKP2dRSTu3W2lBU02ThAZMZ6sg37M0sR7B4 m+6s0FEZ+jWySgLvz9zo4E5YXvvWpfpLkj+v6En+3GfqmVTzuty3muW2njyfNQAAAAAAAA== --------------ms050109080102020202040709-- From owner-ietf-calendar@mail.imc.org Mon Aug 2 18:00:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08423 for ; Mon, 2 Aug 2004 18:00:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LqwHY096161; Mon, 2 Aug 2004 14:52:58 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72Lqwha096160; Mon, 2 Aug 2004 14:52:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LqvbN096153 for ; Mon, 2 Aug 2004 14:52:57 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i72Lqf9B001464; Mon, 2 Aug 2004 14:52:42 -0700 Received: from opene-130-129-131-201.ietf60.ietf.org (opene-130-129-131-201.ietf60.ietf.org [130.129.131.201] (may be forged)) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i72LqeaI019565 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Aug 2004 14:52:41 -0700 Date: Mon, 2 Aug 2004 14:52:35 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: Nathaniel Borenstein cc: IETF calsch WG , Ted Hardie , Scott Hollenbeck Subject: Re: proposed revised charter for IETF calsch WG In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 30 Jul 2004, Nathaniel Borenstein wrote: > I am opposed to rechartering the calsch group. My preference would be > to shut down the group entirely, and then start a new WG that is > narrowly focused on revisions to RFCs 2445-7. I am particularly > skeptical that work on CAP or any similar protocol based on those RFC's > should be done in the same group that is in the middle of revising them. > I think progress will be much faster if we divide and conquer, and that > the (substantial) revisions that are necessary in the base RFC's > justifies a new group of its own. -- Nathaniel Nathaniel: just to be clear, the proposed charter I submitted has just the one item, completing CAP, and updates the several-year-old calsch charter which is now entirely obsolete. I might interpret your comment as saying that this WG should not even adopt this amended minimal charter, should not complete CAP, and should close immediately. Or you might be just disagreeing with the idea that 2445-7 revisions be in scope. Can you clarify? - RL "Bob" From owner-ietf-calendar@mail.imc.org Mon Aug 2 18:53:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12167 for ; Mon, 2 Aug 2004 18:53:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Mk7de000150; Mon, 2 Aug 2004 15:46:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72Mk7tH000149; Mon, 2 Aug 2004 15:46:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Mk6gn000138 for ; Mon, 2 Aug 2004 15:46:07 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from [130.129.128.215] [130.129.128.215] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id AE4233A024E; Mon, 02 Aug 2004 15:20:50 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF calsch WG , Ted Hardie , Scott Hollenbeck From: Nathaniel Borenstein Subject: Re: proposed revised charter for IETF calsch WG Date: Mon, 2 Aug 2004 18:46:16 -0400 To: "RL 'Bob' Morgan" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I suppose I wouldn't have a major problem with the existing group staying around to finish CAP *if* there is critical mass to do so. What I myself am interested in doing, however, is starting a new group to revise iCal. For my part, I am skeptical that CAP can succeed until iCal is cleaned up, and I believe that said cleanup would have a major effect on the design of CAP. For that reason, I just don't see a lot of point to trying to finalize CAP now. I wouldn't care to argue that others don't have the right to try, but I'm not sure that a WG is necessary even for that. -- Nathaniel On Aug 2, 2004, at 5:52 PM, RL 'Bob' Morgan wrote: > > > On Fri, 30 Jul 2004, Nathaniel Borenstein wrote: > >> I am opposed to rechartering the calsch group. My preference would be >> to shut down the group entirely, and then start a new WG that is >> narrowly focused on revisions to RFCs 2445-7. I am particularly >> skeptical that work on CAP or any similar protocol based on those >> RFC's >> should be done in the same group that is in the middle of revising >> them. >> I think progress will be much faster if we divide and conquer, and >> that >> the (substantial) revisions that are necessary in the base RFC's >> justifies a new group of its own. -- Nathaniel > > Nathaniel: just to be clear, the proposed charter I submitted has just > the one item, completing CAP, and updates the several-year-old calsch > charter which is now entirely obsolete. I might interpret your > comment as > saying that this WG should not even adopt this amended minimal charter, > should not complete CAP, and should close immediately. Or you might be > just disagreeing with the idea that 2445-7 revisions be in scope. Can > you > clarify? > > - RL "Bob" > > > From owner-ietf-calendar@mail.imc.org Mon Aug 2 19:46:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15279 for ; Mon, 2 Aug 2004 19:46:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72NctGa003330; Mon, 2 Aug 2004 16:38:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72NctGI003329; Mon, 2 Aug 2004 16:38:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Ncri2003317 for ; Mon, 2 Aug 2004 16:38:53 -0700 (PDT) (envelope-from pregen@egenconsulting.com) In-Reply-To: To: Nathaniel Borenstein Cc: Ted Hardie , IETF calsch WG , owner-ietf-calendar@mail.imc.org, "RL 'Bob' Morgan" , Scott Hollenbeck Subject: Re: proposed revised charter for IETF calsch WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Mon, 2 Aug 2004 19:38:58 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 08/02/2004 07:38:59 PM, Serialize complete at 08/02/2004 07:38:59 PM Content-Type: multipart/alternative; boundary="=_alternative 0081E94985256EE4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0081E94985256EE4_= Content-Type: text/plain; charset="US-ASCII" Ah, this clarifies his position. figures that as soon as I send out my note a reply comes back from Nathaniel. 8-) Nathaniel Borenstein Sent by: owner-ietf-calendar@mail.imc.org 08/02/2004 18:46 To "RL 'Bob' Morgan" cc IETF calsch WG , Ted Hardie , Scott Hollenbeck Subject Re: proposed revised charter for IETF calsch WG I suppose I wouldn't have a major problem with the existing group staying around to finish CAP *if* there is critical mass to do so. What I myself am interested in doing, however, is starting a new group to revise iCal. For my part, I am skeptical that CAP can succeed until iCal is cleaned up, and I believe that said cleanup would have a major effect on the design of CAP. For that reason, I just don't see a lot of point to trying to finalize CAP now. I wouldn't care to argue that others don't have the right to try, but I'm not sure that a WG is necessary even for that. -- Nathaniel On Aug 2, 2004, at 5:52 PM, RL 'Bob' Morgan wrote: > > > On Fri, 30 Jul 2004, Nathaniel Borenstein wrote: > >> I am opposed to rechartering the calsch group. My preference would be >> to shut down the group entirely, and then start a new WG that is >> narrowly focused on revisions to RFCs 2445-7. I am particularly >> skeptical that work on CAP or any similar protocol based on those >> RFC's >> should be done in the same group that is in the middle of revising >> them. >> I think progress will be much faster if we divide and conquer, and >> that >> the (substantial) revisions that are necessary in the base RFC's >> justifies a new group of its own. -- Nathaniel > > Nathaniel: just to be clear, the proposed charter I submitted has just > the one item, completing CAP, and updates the several-year-old calsch > charter which is now entirely obsolete. I might interpret your > comment as > saying that this WG should not even adopt this amended minimal charter, > should not complete CAP, and should close immediately. Or you might be > just disagreeing with the idea that 2445-7 revisions be in scope. Can > you > clarify? > > - RL "Bob" > > > --=_alternative 0081E94985256EE4_= Content-Type: text/html; charset="US-ASCII"
Ah, this clarifies his position.  figures that as soon as I send out my note a reply comes back from Nathaniel.  8-)



Nathaniel Borenstein <nsb@guppylake.com>
Sent by: owner-ietf-calendar@mail.imc.org

08/02/2004 18:46

To
"RL 'Bob' Morgan" <rlmorgan@washington.edu>
cc
IETF calsch WG <ietf-calendar@imc.org>, Ted Hardie <hardie@qualcomm.com>, Scott Hollenbeck <sah@428cobrajet.net>
Subject
Re: proposed revised charter for IETF calsch WG






I suppose I wouldn't have a major problem with the existing group
staying around to finish CAP *if* there is critical mass to do so.  
What I myself am interested in doing, however, is starting a new group
to revise iCal.

For my part, I am skeptical that CAP can succeed until iCal is cleaned
up, and I believe that said cleanup would have a major effect on the
design of CAP.  For that reason, I just don't see a lot of point to
trying to finalize CAP now.  I wouldn't care to argue that others don't
have the right to try, but I'm not sure that a WG is necessary even for
that.  -- Nathaniel

On Aug 2, 2004, at 5:52 PM, RL 'Bob' Morgan wrote:

>
>
> On Fri, 30 Jul 2004, Nathaniel Borenstein wrote:
>
>> I am opposed to rechartering the calsch group.  My preference would be
>> to shut down the group entirely, and then start a new WG that is
>> narrowly focused on revisions to RFCs 2445-7.  I am particularly
>> skeptical that work on CAP or any similar protocol based on those
>> RFC's
>> should be done in the same group that is in the middle of revising
>> them.
>> I think progress will be much faster if we divide and conquer, and
>> that
>> the (substantial) revisions that are necessary in the base RFC's
>> justifies a new group of its own.  -- Nathaniel
>
> Nathaniel:  just to be clear, the proposed charter I submitted has just
> the one item, completing CAP, and updates the several-year-old calsch
> charter which is now entirely obsolete.  I might interpret your
> comment as
> saying that this WG should not even adopt this amended minimal charter,
> should not complete CAP, and should close immediately.  Or you might be
> just disagreeing with the idea that 2445-7 revisions be in scope.  Can
> you
> clarify?
>
>  - RL "Bob"
>
>
>
--=_alternative 0081E94985256EE4_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 2 19:46:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15305 for ; Mon, 2 Aug 2004 19:46:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Nbi7x003268; Mon, 2 Aug 2004 16:37:44 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72NbikX003266; Mon, 2 Aug 2004 16:37:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Nbg3R003248 for ; Mon, 2 Aug 2004 16:37:43 -0700 (PDT) (envelope-from pregen@egenconsulting.com) In-Reply-To: To: "RL 'Bob' Morgan" Cc: Ted Hardie , IETF calsch WG , Nathaniel Borenstein , owner-ietf-calendar@mail.imc.org, Scott Hollenbeck Subject: Re: proposed revised charter for IETF calsch WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Mon, 2 Aug 2004 19:37:46 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 08/02/2004 07:37:48 PM, Serialize complete at 08/02/2004 07:37:48 PM Content-Type: multipart/alternative; boundary="=_alternative 0081CD2A85256EE4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0081CD2A85256EE4_= Content-Type: text/plain; charset="US-ASCII" Bob, I think Nathaniel is saying to keep CAP and the RFC revisions separate. I don't think he meant not finish the CAP issue and get it to last call (soon!) "RL 'Bob' Morgan" Sent by: owner-ietf-calendar@mail.imc.org 08/02/2004 17:52 To Nathaniel Borenstein cc IETF calsch WG , Ted Hardie , Scott Hollenbeck Subject Re: proposed revised charter for IETF calsch WG On Fri, 30 Jul 2004, Nathaniel Borenstein wrote: > I am opposed to rechartering the calsch group. My preference would be > to shut down the group entirely, and then start a new WG that is > narrowly focused on revisions to RFCs 2445-7. I am particularly > skeptical that work on CAP or any similar protocol based on those RFC's > should be done in the same group that is in the middle of revising them. > I think progress will be much faster if we divide and conquer, and that > the (substantial) revisions that are necessary in the base RFC's > justifies a new group of its own. -- Nathaniel Nathaniel: just to be clear, the proposed charter I submitted has just the one item, completing CAP, and updates the several-year-old calsch charter which is now entirely obsolete. I might interpret your comment as saying that this WG should not even adopt this amended minimal charter, should not complete CAP, and should close immediately. Or you might be just disagreeing with the idea that 2445-7 revisions be in scope. Can you clarify? - RL "Bob" --=_alternative 0081CD2A85256EE4_= Content-Type: text/html; charset="US-ASCII"
Bob, I think Nathaniel is saying to keep CAP and the RFC revisions separate.  I don't think he meant not finish the CAP issue and get it to last call (soon!)


"RL 'Bob' Morgan" <rlmorgan@washington.edu>
Sent by: owner-ietf-calendar@mail.imc.org

08/02/2004 17:52

To
Nathaniel Borenstein <nsb@guppylake.com>
cc
IETF calsch WG <ietf-calendar@imc.org>, Ted Hardie <hardie@qualcomm.com>, Scott Hollenbeck <sah@428cobrajet.net>
Subject
Re: proposed revised charter for IETF calsch WG







On Fri, 30 Jul 2004, Nathaniel Borenstein wrote:

> I am opposed to rechartering the calsch group.  My preference would be
> to shut down the group entirely, and then start a new WG that is
> narrowly focused on revisions to RFCs 2445-7.  I am particularly
> skeptical that work on CAP or any similar protocol based on those RFC's
> should be done in the same group that is in the middle of revising them.
> I think progress will be much faster if we divide and conquer, and that
> the (substantial) revisions that are necessary in the base RFC's
> justifies a new group of its own.  -- Nathaniel

Nathaniel:  just to be clear, the proposed charter I submitted has just
the one item, completing CAP, and updates the several-year-old calsch
charter which is now entirely obsolete.  I might interpret your comment as
saying that this WG should not even adopt this amended minimal charter,
should not complete CAP, and should close immediately.  Or you might be
just disagreeing with the idea that 2445-7 revisions be in scope.  Can you
clarify?

- RL "Bob"
--=_alternative 0081CD2A85256EE4_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 2 20:25:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17362 for ; Mon, 2 Aug 2004 20:25:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i730Fmd2005432; Mon, 2 Aug 2004 17:15:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i730Fmef005431; Mon, 2 Aug 2004 17:15:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i730Flb6005425 for ; Mon, 2 Aug 2004 17:15:47 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i730FqSs001297 for ; Mon, 2 Aug 2004 17:15:53 -0700 Received: from opene-130-129-134-134.ietf60.ietf.org (opene-130-129-134-134.ietf60.ietf.org [130.129.134.134]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i730FpNP005093 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 2 Aug 2004 17:15:52 -0700 Date: Mon, 2 Aug 2004 17:15:42 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG Subject: chatroom for calsch WG session at IETF 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As usual there will be a jabber chatroom running during the WG session tomorrow. General info on this is at: http://xmpp.org/ietf-chat.html So, the chatroom at the ietf.xmpp.org conference server will be "calsch". We'll do our best to have someone enter notes from the WG into the chatroom, and to take feedback from those in chat-land. - RL "Bob" From owner-ietf-calendar@mail.imc.org Tue Aug 3 16:59:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11420 for ; Tue, 3 Aug 2004 16:59:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73KoqE2099230; Tue, 3 Aug 2004 13:50:52 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Koqkw099229; Tue, 3 Aug 2004 13:50:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73KopMa099223 for ; Tue, 3 Aug 2004 13:50:51 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73Kotj4031313 for ; Tue, 3 Aug 2004 13:50:56 -0700 Received: from opene-130-129-132-254.ietf60.ietf.org (opene-130-129-132-254.ietf60.ietf.org [130.129.132.254]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73KosiK014674 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 Aug 2004 13:50:55 -0700 Date: Tue, 3 Aug 2004 13:50:49 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG Subject: CAP issue #657 (BEEP profile): closed? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This issue was filed by pstephenson@novell.com (Preston Stephenson). I believe it's the case that Doug modified the BEEP text in cap-13 to address this issue. I'd like to close this issue, so comments from Preston in particular, and others who are interested, would be helpful. I'll close the issue in a few days if no one comments. Note also that I'm trying to get some expert BEEPster review of the BEEP text in cap-13. - RL "Bob" From owner-ietf-calendar@mail.imc.org Tue Aug 3 16:59:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11443 for ; Tue, 3 Aug 2004 16:59:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Koeu7099214; Tue, 3 Aug 2004 13:50:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73KoeRY099213; Tue, 3 Aug 2004 13:50:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Koe5t099206 for ; Tue, 3 Aug 2004 13:50:40 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73KoiGN014153 for ; Tue, 3 Aug 2004 13:50:44 -0700 Received: from opene-130-129-132-254.ietf60.ietf.org (opene-130-129-132-254.ietf60.ietf.org [130.129.132.254]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73Kogc5006709 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 Aug 2004 13:50:44 -0700 Date: Tue, 3 Aug 2004 13:50:37 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG Subject: CAP issue resolution Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just to note I'll be sending several messages after this based on the issues in the CALSCH section of http://bugzilla.opengroupware.org/, addressing each of the open issues (ie, those not identified there as closed/resolved). The intent is to resolve each of these in the next few days so that a next revision of the CAP draft can be produced shortly that is ready for WG last call. As always, if anyone has any other outstanding issues, please file them there (or send to the list). - RL "Bob" From owner-ietf-calendar@mail.imc.org Tue Aug 3 17:01:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11616 for ; Tue, 3 Aug 2004 17:01:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73KpJHM099273; Tue, 3 Aug 2004 13:51:19 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73KpJEg099272; Tue, 3 Aug 2004 13:51:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73KpIBF099265 for ; Tue, 3 Aug 2004 13:51:18 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73KpNcX004935 for ; Tue, 3 Aug 2004 13:51:23 -0700 Received: from opene-130-129-132-254.ietf60.ietf.org (opene-130-129-132-254.ietf60.ietf.org [130.129.132.254]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73KpMBJ014767 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 Aug 2004 13:51:23 -0700 Date: Tue, 3 Aug 2004 13:51:17 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG Subject: CAP issue #773: All uses of "FALSE" should be fully capitalized Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This issue was filed by Bruce_Kahn@notesdev.ibm.com (Bruce Kahn). The issue is that references to the FALSE value/setting should be consistently be in all caps. Doug's response is that this will be the case in the next rev of the CAP draft. So this issue can be closed when that draft appears. - RL "Bob" From owner-ietf-calendar@mail.imc.org Tue Aug 3 17:01:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11640 for ; Tue, 3 Aug 2004 17:01:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Kp5xW099252; Tue, 3 Aug 2004 13:51:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Kp5GZ099251; Tue, 3 Aug 2004 13:51:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Kp5aH099245 for ; Tue, 3 Aug 2004 13:51:05 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73Kp6vA012973 for ; Tue, 3 Aug 2004 13:51:06 -0700 Received: from opene-130-129-132-254.ietf60.ietf.org (opene-130-129-132-254.ietf60.ietf.org [130.129.132.254]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73Kp5U5014728 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 Aug 2004 13:51:06 -0700 Date: Tue, 3 Aug 2004 13:51:01 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG Subject: CAP issue #758: REQUEST-STATUS syntax Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This issue was filed by Bruce_Kahn@notesdev.ibm.com (Bruce Kahn). The REQUEST-STATUS message syntax differs between 2445 and CAP. There has been lots of discussion about this. The chairs are inclined to believe that the 2445 syntax should be preserved in CAP, hence that the CAP doc should be modified to use that. We think that Bruce's and Doug's opinions on this are clear, so we don't need to hear from them unless there is something new to be said. Opinions from others are solicited. In the absence of comment we will direct Doug to make this change in the next rev of the CAP draft. - RL "Bob" From owner-ietf-calendar@mail.imc.org Tue Aug 3 17:04:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11914 for ; Tue, 3 Aug 2004 17:04:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Kut4N099588; Tue, 3 Aug 2004 13:56:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Kutwg099587; Tue, 3 Aug 2004 13:56:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73KusbQ099581 for ; Tue, 3 Aug 2004 13:56:55 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73Kux9s014100 for ; Tue, 3 Aug 2004 13:56:59 -0700 Received: from opene-130-129-132-254.ietf60.ietf.org (opene-130-129-132-254.ietf60.ietf.org [130.129.132.254]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73KuvUk007490 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 Aug 2004 13:56:58 -0700 Date: Tue, 3 Aug 2004 13:56:52 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG Subject: CAP issue #794: need ABNF ADDED Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This issue was filed by Doug@Royer.com (Doug Royer), based on a message to the list from Bruce Kahn. The text of the issue is below. Comment is solicited. In the absence of comment, the chairs will direct Doug to make this change in the next rev of the CAP draft. - RL "Bob" --- Description of problem: In looking up the defintiion of "*" and "*.*" I tried to find it in the CAP-13 text or the ABNF and I cant find it actually defined anywhere really. I did find 1 defintion in relation to permissions: all = "*" and this bit related to UPNs in Section 9.3 VCAR Component: "All CUs and UGs" are specified by the UPN value "*". but I found no other text or ABNF that defined the use of "*" to mean "All sub-components and all properties" the way we use it in Section 6.1.1 CAL-QUERY Value Type and throughout CAP. I know we all take it to be "all matches" or "all items" as in a regexp match but we really should explicitly define what "*" means since we use it frequently in CAP. I propose we add the following line to Section 6.1.1 somewhere near the top: All contained properties and subcomponents are specified by the cap-cols value "*". From owner-ietf-calendar@mail.imc.org Tue Aug 3 17:13:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12409 for ; Tue, 3 Aug 2004 17:13:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73L2YRf099990; Tue, 3 Aug 2004 14:02:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73L2YAc099989; Tue, 3 Aug 2004 14:02:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73L2X0U099981 for ; Tue, 3 Aug 2004 14:02:33 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73L2bZ8024504 for ; Tue, 3 Aug 2004 14:02:37 -0700 Received: from opene-130-129-132-254.ietf60.ietf.org (opene-130-129-132-254.ietf60.ietf.org [130.129.132.254]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i73L2asJ008238 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 Aug 2004 14:02:37 -0700 Date: Tue, 3 Aug 2004 14:02:31 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG Subject: CAP issue #768: REQUEST-STATUS update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This issue was filed by Bruce_Kahn@notesdev.ibm.com (Bruce Kahn). He made a suggestion in Feb 2003 about structuring of REQUEST-STATUS codes, some of which may be reflected in the current CAP draft, but most of which apparently isn't. The chairs suggest that if Bruce wants to promote this approach he recast/resend the proposal (to the list) suggesting proposed modifications to CAP-13. In the absence of this, or of comment from others supporting the suggested changes, the chairs will not recommend any changes to the CAP spec based on this issue. - RL "Bob" From owner-ietf-calendar@mail.imc.org Tue Aug 3 17:40:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14385 for ; Tue, 3 Aug 2004 17:40:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73LVJvr002450; Tue, 3 Aug 2004 14:31:19 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73LVJtY002449; Tue, 3 Aug 2004 14:31:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73LVIGD002424 for ; Tue, 3 Aug 2004 14:31:18 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: "RL 'Bob' Morgan" Cc: IETF calsch WG Subject: Re: CAP issue #768: REQUEST-STATUS update MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M2_06302004NP June 30, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 3 Aug 2004 17:31:09 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 08/03/2004 05:28:16 PM, Serialize complete at 08/03/2004 05:28:16 PM Content-Type: multipart/alternative; boundary="=_alternative 0076028D85256EE5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076028D85256EE5_= Content-Type: text/plain; charset="US-ASCII" Bob wrote on 08/03/2004 05:02:31 PM: > This issue was filed by Bruce_Kahn@notesdev.ibm.com (Bruce Kahn). He made > a suggestion in Feb 2003 about structuring of REQUEST-STATUS codes, some > of which may be reflected in the current CAP draft, but most of which > apparently isn't. Actually this is not correct. The proposal was posted on 02/23/2003 12:29:44 PM MST by Doug Royer under the Subject of "CAP REQUEST-STATUS - update and proposals". This was just after the last CAP-10 draft was released and before CAP-11. I was not the original author but I did agree (along with WG) that it was a good thing to do. Unfortunately that never happened and so I simply noted this as an incomplete item/issue. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0076028D85256EE5_= Content-Type: text/html; charset="US-ASCII"
Bob wrote on 08/03/2004 05:02:31 PM:
> This issue was filed by Bruce_Kahn@notesdev.ibm.com (Bruce Kahn).  He made
> a suggestion in Feb 2003 about structuring of REQUEST-STATUS codes, some
> of which may be reflected in the current CAP draft, but most of which
> apparently isn't.

Actually this is not correct.  The proposal was posted on 02/23/2003 12:29:44 PM MST by Doug Royer under the Subject of "CAP REQUEST-STATUS - update and proposals".  This was just after the last CAP-10 draft was released and before CAP-11.  I was not the original author but I did agree (along with WG) that it was a good thing to do.  Unfortunately that never happened and so I simply noted this as an incomplete item/issue.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0076028D85256EE5_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 3 18:46:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19115 for ; Tue, 3 Aug 2004 18:46:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73McOt4007520; Tue, 3 Aug 2004 15:38:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73McOW4007519; Tue, 3 Aug 2004 15:38:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73McNQf007511 for ; Tue, 3 Aug 2004 15:38:23 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i73McJJd023980 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 3 Aug 2004 15:38:20 -0700 Message-ID: <411013DA.8090302@Royer.com> Date: Tue, 03 Aug 2004 16:38:18 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CalDav rev 01 - for those that missed it. Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090207030608070109010305" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090207030608070109010305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I missed this notice. If you have also... draft-dusseault-caldav-01 http://www.ietf.org/internet-drafts/draft-dusseault-caldav-01.txt Abstract In the five years since WebDAV [3] was standardized, at least three groups have used WebDAV as a basis to provide Internet calendar access with a minimum of development effort. However, each group decided independently how the calendaring data model would map to the WebDAV data model and how to deal with features such as recurrance and queries for free-busy times. This draft proposes a standard data model mapping and a few extensions to WebDAV that make WebDAV-server-based calendaring work well for clients while requiring a minimum of new work (particularly on clients). ... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090207030608070109010305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODAzMjIzODE4WjAjBgkqhkiG9w0BCQQxFgQUNdD4LoWM4y7KRcA5+O2h Ur/G+bcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAE49NEntjfnGqeLAv8kzJp+H5XtCn7N+biXCbNZy0fEvKahtDP7hgLU9O+DGvarz+ AEo2C2nT+JLCViaAznJntntywZaZ8BOPBtz6JDkVWCCaknIHJk4H1UZ2R/sFcVMg3zyRXfib Ftg0V2cF0TMFQohJokAl7drSCjwGl3CGVRzKNvKfZLtSnJ18wliXzgStncjmW5PXHjMYM3qF z3cOYneu83zTIfZMzULFlD/pX2+eWRWb0aarlz82l160238dsudufLO1fnqCXbt/iIzS5LGu t3jz43DAsNH69MSn4wp2a8/e0ZOoWXtAGqxP/Xmn+MI2cBcJkq5aMT1NOJ8TEwAAAAAAAA== --------------ms090207030608070109010305-- From owner-ietf-calendar@mail.imc.org Tue Aug 3 18:48:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19234 for ; Tue, 3 Aug 2004 18:48:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73MabIF007427; Tue, 3 Aug 2004 15:36:37 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73MabsP007426; Tue, 3 Aug 2004 15:36:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73MaaC4007418 for ; Tue, 3 Aug 2004 15:36:37 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from [130.129.130.224] [130.129.130.224] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id AD9314BC019A; Tue, 03 Aug 2004 15:11:31 -0700 Mime-Version: 1.0 (Apple Message framework v618) Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: IETF calsch WG From: Nathaniel Borenstein Subject: Jabber log from calsch IETF meeting Date: Tue, 3 Aug 2004 18:36:59 -0400 X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i73MabC4007421 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit [17:16:49] *** chatroom for calsch working group [17:16:49] *** This room supports the MUC protocol. [14:24:29] Pardon my dust. IBMs firewalls are wreaking havoc on my Jabber connection [17:16:49] *** The topic has been set to: calsch working group [17:16:49] *** nsb has joined [17:18:29] Hi, I'll be your friendly jabber scribe today [17:19:00] Proposed Agenda: [17:19:03] 1. Preliminaries [17:19:05] *** andreas-b has joined [17:19:11] 2. WG status, proposed charter revision [17:19:15] 3. CAP [17:19:19] 4. Calconnect interop report [17:19:23] 5. Caldav draft [17:19:26] 6. Other issues [17:19:47] Preliminaries done. [17:19:52] (blue sheets, etc.) [17:20:11] Any comments on the revised proposed charter that Bob posted recently? [17:21:04] Note that the new charter doesn't include ical revisions; that is envisioned for another WG. [17:21:05] I agree - keep CALSCH until CAP is out, then new WG for new issues. [17:21:33] *** lisa has joined [17:21:50] NSB agrees, notes that they don't have to be sequential [17:22:05] Ted: Should recharter be in this WG, or new WG? [17:22:11] *** waynet has joined [17:22:19] Anyone want to advocate re-using this WG? [17:22:20] CAP in this WG [17:22:39] *** leg has joined [17:23:07] NSB: Goal of new WG would be revision of existing (1998) ical++ specs [17:23:36] Martin from Oracle agrees w/new group [17:23:47] Bob says it seems like consensus [17:24:11] Does there have to be a BOF or can it just be started? [17:24:14] and obviously individuals can start working on docs any time; new WG is not a prerequisite. [17:24:51] Ted: Clarify -- there will be a target date for CAP, right? And it will be clear to the community that this WG is not undertaking additional tasks. [17:25:18] Bob: Ted, is it true that RFC revisions may be done by individuals? [17:25:35] Ted: Yes, but my sense of the scope of the task is that you'll probably need a big enough team to make a WG useful. [17:26:18] (yes to BOF or yes to ted?) [17:26:28] Ted: (answering Doug): A BOF isn't really necessary. He recommends setting up a new list and announcing it on the existing list [17:26:44] and working on a new charter for the new group there. [17:26:52] Great! [17:27:32] (Ted's Yes was to Bob's question; the later answer was to Doug's) [17:28:04] Are there any CAP-related discussions we should be having today??? [17:28:49] Bob recently posted a summary of remaining issues from bugzilla, mostly minor. [17:29:01] There is going to be cleanup work that should be wording and typos, and such. No technical changes (other than those posted on WG today by Bob) [17:29:09] Bob is bringing the bugzilla stuff up on the screen [17:29:50] *** pbh has joined [17:30:16] They include: BEEP interaction issues -- incomplete sentences, etc. in the BEEP profile? Bob has asked for a BEEP-er to give it a look. [17:30:35] YES - BEEP experts needed [17:30:44] Any comments on that one? [17:31:37] Next issue: Longstanding issue of semicolon added to request-status [17:31:42] "World's most argued-over semicolon" [17:32:00] Chair position: retain consistency with 2445 syntax, pending any further comment. Any??? [17:33:12] EXPAND issue -- closed pending objection [17:33:13] *** hildjj has joined [17:33:45] Which was the EXPAND issue? Didnt see any email on that. [17:33:50] Bruce's comments about revising status code -- substantial changes, anyone want to argue? [17:34:09] The EXPAND was your issue, Bruce, from a while back [17:34:21] Clarification: The original Feb 03 proposal was Dougs, not mine. I simply remembered we forgot to actually do it [17:34:37] "The Use of EXPAND is still not sufficiently clear for all query cases" -- Bruce Kahn, 5/13 [17:34:54] Want to keep arguing, Bruce? [17:35:02] *** ohm has joined [17:35:10] I think the 1 new line in CAP-13 fixed it. Will recheck now. [17:36:08] Defining the use of "*" to mean everything in the CAP ABNF -- 6/24 from Bruce. Bob thinks this is a good idea. Anyone opposed? [17:36:32] Nobody seems to be opposed. That's the whole bugzilla list, folks! [17:36:32] Reading again... [17:36:44] EXPAND fixed by "The results will be bounded by any date range or other limits in the query." [17:37:29] Bob: Doug, any guesses how soon CAP 14 will be ready? [17:37:34] Use of '*', it looks to me to be missing ABNF only - correct? [17:37:43] Clarification: The original REQUEST-STATUS rework propsal (Feb 03) was Dougs, not mine. We had agreement on it I thought but never got done. [17:38:07] Depending on the changes decided today in a week or so. [17:38:24] Yes, the only issue with * is missing ABNF [17:38:49] Bruce -- clarifying your clarification -- there is still an issue here or not? [17:39:05] For "*" we should add at least 1 line of text that says something like "All components are specified by the special value "*"" [17:39:12] Bob: Hope that CAP 14 will be ready for last call soon. [17:39:21] Doug, I assume Bruce's * comment is OK? [17:39:28] Only still an issue if the issues the propsal was to fix are not resolved. [17:39:41] Huh? I don't understand your comment Bruce [17:39:44] CAP does not define what each "root level" REQUEST-STATUS class are. it should. [17:39:53] What is a 7.x value? [17:39:56] I think so. I'll comment on the list of that conflicts with anything ("*" issue) [17:40:08] etc. [17:40:48] Also: There are still 'gaps' in the numbering. For example, there is no 6.0 defined but we have a 6.1. There is no 10.0 thru 10.3 yet there is a 10.4. [17:41:07] Is that a problem? [17:41:11] These should be pretty straight forward to fix though. A few lines in the right place should do it. [17:41:15] Joe H: Space for future enhancements [17:41:15] What do you mean by "root level" ? [17:41:33] Well, gaps are not good if you are trying to make a general hierarchy of code like we did in iTIP. [17:41:42] *** hardie has joined [17:41:54] I think we called them "classes" in iTIP or iCalendar. [17:42:00] Bob nods sagely & inscrutably [17:42:18] We called 'em "classes" in iCalendar. [17:42:36] Section 4.8.8.2 Request Status, pp 134-135 [17:43:05] There is concern that there are only 2 people who have an opinion on this issue. [17:43:10] Any "1.xx " has a particular meaning as does any "2.xx", etc [17:43:53] Would at least like a definition for the 6.xx, 7.xx, 8.xx .. 10.xx classes CAP is adding so its clear where future changes shoudl go and what they mean as a class. [17:43:56] Roy Fielding, JSoftware: No way this will be a valid ABNF -- missing brackets, missing "or" characters. Asks authors to do formal BNF checking, follow appropriate references [17:44:16] There are formal tools for this -- Harald Alvestrand has an ABNF checker. [17:44:32] There's a web page where you paste the grammar, get back results. [17:44:42] www.apps.ietf.org has a validator, but that's a different one [17:45:04] alvestrand.no has a tool [17:45:18] www.apps.ietf.org/abnf.html [17:45:42] *** paf has joined [17:46:11] How hard will it be to clarify this? (nsb) [17:46:15] On the apps.ietf.org/abnf.html there are links to the abnf parser harald has. [17:47:06] Is there a well-formed proposal for the request-status changes? Doug, are you opposed to this or merely awaiting a more detailed proposal? [17:47:33] I am not opposed. [17:47:56] Bruce, are you willing to produce a more detailed proposal? [17:48:02] I'll make a X.y section like itip. I do not care if there a holes or gaps in the sequences. [17:48:12] That is, how it should be as opposed to what's wrong with the current v ersion. [17:48:14] Isnt the one from Dougs posting "Subject: CAP REQUEST-STATUS - update and proposals" sufficient? [17:48:23] Or do you mean the Class descriptions? [17:48:42] I'm not sure -- Doug, do you know? [17:49:18] I think that I went through all of the codes and looked for duplicated and added needed ones. [17:49:39] In the process I removed some duplicates may be the reason for the 'holes'. [17:49:56] So is this just a need for a simple "rationalization" of the codes, Bruce? [17:49:56] Part of that proposal was: [17:49:57] I also propose that we call all 6.x codes CMD or CS codes and renumber all 6.x, 7.x, 8.x, 9.x, and 10,x codes to be 6.x codes. [17:51:06] I can do that, does anyone care what the final numbers are (6.3 vs 6.12)? If so, submit a proposal. [17:51:35] NSB asks AD for clarification on how document status will be decided [17:51:45] No preference as to any ordering/values. [17:53:13] Ted explains the meaning of Proposed, Experimental, Informational [17:54:53] Ted: The WG really ought to decide what status it wants. Is there a community that finds this document & the ones it depends on ready to be implemented by multiple interested parties? [17:55:34] Barry Leiba: Another way of putting it: Is the WG proposing this as standard? [17:55:51] Its ready to try. Like 2445-7, I suspect there will be changes and issues. But we have to start [17:56:47] Poll: How many people have scrutinized the spec enough to have a strong understanding / assessment of the CAP protocol? [17:57:03] Two hands went up in the room, both from Oracle. [17:57:09] And half a hand from Cyrus Daboo. [17:57:18] Question:  Which finger was that?  [17:57:35] Obviously Doug, you are on that list. Anyone else on Jabber? [17:57:48] *** hardie has left: Disconnected [17:57:49] Me, Novel and INET in Italy in implementing. [17:58:27] Waffling... [17:58:43] Is Lotus/IBM doing cap? [17:59:25] Ted: It seems that despite the interest showed by the interop, there doesn't seem to be enough attention to the spec. [17:59:50] The interop never included CAP [18:00:24] Oracle: Can imagine CAP-26 before we finally get to RFC [18:00:45] Ted: Reiterating, there are only todays' 4 issues plus cleanup, right? [18:00:57] Roy's from Day Software, not Oracle [18:01:04] Oops, sorry Roy [18:01:27] ted makes all stand up [18:01:58] stay standing if you are willing to spend 5 hours on spec before Sept or currently have a CAP implementation or plan one. [18:02:04] Only people standing are two folks from Oracle. [18:02:23] Ted: This seems a strong statement [18:02:51] Ted: Q: Is ten hours from Oracle folks, plus Doug's efforts & Bruce's kibbitzing, enough to finish CAP with a high confidence level? [18:02:52] CAP is heavy. Wait until last call, that's when people will read it. [18:03:08] *** hildjj has left: Disconnected [18:03:11] Barry: If we think that what will come from next WG is better, we shouldn't make this a proposed standard. [18:04:03] NSB: Is "Informational" status more appropriate? [18:05:05] ted: you could do that, as a "this is how far we got" document. But he advises that we first go to the mailing list with the same question about willingness/interest to work on CAP. If we can't get enough people to seriously review the doc, we can/should go for informational or experimental. [18:05:14] Ted: This makes me think we *should* start with a BOF for the new effort. [18:05:42] Ted: I don't want to discourage anyone, but if we can't get the needed amount of effort... [18:07:25] Oracle: Everyone but MS is suffering from the poorstandardization [18:07:38] yes. [18:07:47] MS: We're suffering too. At least 5 different implementations of ical, all struggling to interoperate [18:09:37] Still in session? [18:09:45] Martin/Oracle: We're working hard to try to get a sense of what it will take to advance the state of the standards. Can we at least agree that an access protocol is important? Discussion focuses on the protocol rather than the problems the protocol is trying to solve [18:10:16] MS: Before we can get a protocol we all agree on, we may need a schema we all agree on, which is why it is hard to do CAP before fixing ical [18:11:11] I disagree, CAP transports iCal objects. No matter what their for. And CAP also transport scheduling (iTIP) iCal objects, not matter what their sequencing or content. [18:11:20] Cyrus: We're talking about ical problems, but we haven't yet heard the interop results. Can we hear about them? [18:11:49] Ted: Before that, please agree to repeat the "who will commit energy" question on the mailing list. [18:12:08] Ted: I think there has been a model shift, and that expectations have changed out from under ical. [18:12:12] Doug, from having looked at CAP's model earlier, which appears unchanged at core, I can't concur with your statement that CAP simply transports iCal objects. [18:13:30] nsb: Lotus definitelky wants a CAPpish protocol, but has much more u rgent need for ical cleanup [18:14:10] Martin/Oracle: It's a shame that we haven't been able to leverage the client efforts such as Mozilla, and that we get so many crappy PIM implementations [18:14:35] Martin: But don't forget how much the community has already benefitted from ical. [18:16:02] Ted exits. We're nearing the end. But Bob asks, and most of us are willing to stay a bit longer. [18:16:16] Dave Thewlis, head of C&S Consortium, will now report on the recent interop event. [18:16:36] Held interop last Thusday & Friday. Participants: IBM & Oracle. [18:16:53] Unlike previous interops, we tested EVERY MUST, MUST NOT, SHOULD, SHOULD NOT in the RFCs [18:17:10] Eye towards comprehensive review & their distance from Draft Status [18:17:30] Results: Seems pretty clear that new drafts of the three RFC's are needed. [18:17:48] Pat Egen has volunteered to be editor for new drafts, has several volunteers to help. [18:18:31] Detailed results/report will be posted on the calsch mailing list [18:18:45] With only two participating, the results are not that conclusive as to implemented features. [18:19:22] Results: we believe that new drafts can be written relatively easy that solve most of the open problems. [18:20:54] nsb: I think we mostly need to chop things out & remove ambiguities, correct a few errors [18:21:19] Dave: Pat has hopes of posting new drafts in Sept/Oct time frame. [18:21:30] ...and then another interop early next year. [18:22:17] nsb: Will we really need a working group? [18:22:33] Bob: Maybe not, if there's very little controersy. [18:22:46] Martin: Should really be a separate list, to avoid complicating the CAP discussion. [18:22:53] nsb, Dave, Bob all agree [18:23:02] Bob asks Lisa about status of Caldav [18:23:14] Lisa; Now that I work for OSAF, I have official sanction for working on caldav. [18:23:31] Lisa: I've started to get feedback on the proposal & design choices [18:23:46] Lisa; will not be just webdav, will have calendar-specific protocol logic [18:24:12] Lisa: Is there a new draft coming out soon? [18:24:41] Lisa did one just before the deadline, got a few comments. Available now. [18:25:05] *** waynet has left [18:25:07] Session ends. Thanks for playing! [18:25:07] I did not see it on the CALSCH WG list, did it make the WG list? [18:25:53] It didn't go to the WG list [18:25:54] *** ohm has left [18:25:54] Doug -- Better send emamil to Lisa and she will give you a copy [18:26:05] It's not a WG product and I didn't want to step on toes there [18:26:08] it wasn't posted to the list, but it is in the I-D repository [18:26:16] It's an individual submission and the I-D people wouldn't know who to notify [18:26:17] It's in the repository as draft-dusseault-caldav-01.txt [18:26:22] *** lisa has left: Disconnected [18:26:41] *** rlbob has left [18:28:04] *** pbh has left [18:31:05] *** andreas-b has left From owner-ietf-calendar@mail.imc.org Tue Aug 3 21:07:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28206 for ; Tue, 3 Aug 2004 21:07:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740s1A9017067; Tue, 3 Aug 2004 17:54:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i740s1XZ017066; Tue, 3 Aug 2004 17:54:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740s0I3017058 for ; Tue, 3 Aug 2004 17:54:00 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187638pcs.micske01.fl.comcast.net[68.46.236.129]) by comcast.net (sccrmhc11) with SMTP id <20040804005400011000bl2fe> (Authid: TimHare); Wed, 4 Aug 2004 00:54:01 +0000 Message-Id: <6.1.1.1.0.20040803204534.0283a970@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 03 Aug 2004 20:49:08 -0400 To: Ietf-calendar@imc.org From: TimHare@comcast.net Subject: Item missing from Bob's list of unresolved items in Bugzilla... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It's still may be a small issue - but I would still like to see the chairs call for consensus on whether or not CALSCALE should be a _required_ property returned by the GET-CAPABILITY command. This is issue 491 in the Bugzilla list - I believe the first one added after this new list was started. I strongly feel that this should be required, since CALSCALE could affect how other things work in a calendar. Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Tue Aug 3 21:16:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28802 for ; Tue, 3 Aug 2004 21:16:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7416jsO018089; Tue, 3 Aug 2004 18:06:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7416jcj018088; Tue, 3 Aug 2004 18:06:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7416iSx018081 for ; Tue, 3 Aug 2004 18:06:44 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i7416lHs013468 for ; Tue, 3 Aug 2004 18:06:47 -0700 Received: from opene-130-129-132-254.ietf60.ietf.org (opene-130-129-132-254.ietf60.ietf.org [130.129.132.254]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i7416iKl014110 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 Aug 2004 18:06:46 -0700 Date: Tue, 3 Aug 2004 18:06:39 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG Subject: calendaring BoF @ IETF, Thursday 1300-1500 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since we didn't quite finish chatting at the WG meeting this afternoon, some calsch-ers are going to meet Thursday afternoon and talk about things like iCal revisions, caldav, interop, etc. Let's meet by the registration desk at 1300 and find a place to sit (perhaps with beer). - RL "Bob" From owner-ietf-calendar@mail.imc.org Wed Aug 4 12:30:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16050 for ; Wed, 4 Aug 2004 12:30:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKGwI092818; Wed, 4 Aug 2004 09:20:16 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GKG0r092817; Wed, 4 Aug 2004 09:20:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.opengroupware.org (mail.opengroupware.org [213.211.192.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKFl6092808 for ; Wed, 4 Aug 2004 09:20:16 -0700 (PDT) (envelope-from www-data@bugzilla.opengroupware.org) Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 3FD513CEAA3 for ; Wed, 4 Aug 2004 18:20:11 +0200 (CEST) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 07522-08 for ; Wed, 4 Aug 2004 18:20:10 +0200 (CEST) Received: from bugzilla.opengroupware.org (bugzilla.opengroupware.org [213.211.192.146]) by mail.opengroupware.org (mail) with ESMTP id A04423CEA9D for ; Wed, 4 Aug 2004 18:20:10 +0200 (CEST) Received: by bugzilla.opengroupware.org (bugzilla, from userid 33) id 4B5F126C004; Wed, 4 Aug 2004 18:20:10 +0200 (CEST) From: bugzilla@bugzilla.opengroupware.org To: ietf-calendar@imc.org Subject: [Bug 657] CAP BEEP profile is missing Content-type: text/plain; charset=utf-8 X-Bugzilla-Reason: AssignedTo QAContact X-Bugzilla-Changed-Fields: Comment Message-Id: <20040804162010.4B5F126C004@bugzilla.opengroupware.org> Date: Wed, 4 Aug 2004 18:20:10 +0200 (CEST) X-Virus-Scanned: by a leet scanner. Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=657 ------- Additional Comments From Doug@Royer.com 2004-05-17 03:18 ------- I added text to -13, comments NEEDED. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are the QA contact for the bug, or are watching the QA contact. From owner-ietf-calendar@mail.imc.org Wed Aug 4 12:38:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16984 for ; Wed, 4 Aug 2004 12:38:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GTRxX093630; Wed, 4 Aug 2004 09:29:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GTRRP093629; Wed, 4 Aug 2004 09:29:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from xgate.provo.novell.com (xgate.provo.novell.com [137.65.47.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GTRs2093620 for ; Wed, 4 Aug 2004 09:29:27 -0700 (PDT) (envelope-from PStephenson@gw.novell.com) Received: from PROVO7-MTA by xgate.provo.novell.com with Novell_GroupWise; Wed, 04 Aug 2004 10:34:15 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 04 Aug 2004 10:32:54 -0600 From: "Preston Stephenson" To: Subject: re: CAP issue #657 (BEEP profile): closed? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Sorry I haven't been getting copied for some time. I still don't see how to start a BEEP channel for CAP in rev 13. At least with my understanding of BEEP. Preston CAP issue #657 (BEEP profile): closed? -------------------------------------------------------------------------------- To: IETF calsch WG Subject: CAP issue #657 (BEEP profile): closed? From: "RL 'Bob' Morgan" Date: Tue, 3 Aug 2004 13:50:49 -0700 (PDT) List-archive: List-id: List-unsubscribe: Sender: owner-ietf-calendar@xxxxxxxxxxxx -------------------------------------------------------------------------------- This issue was filed by pstephenson@xxxxxxxxxx (Preston Stephenson). I believe it's the case that Doug modified the BEEP text in cap-13 to address this issue. I'd like to close this issue, so comments from Preston in particular, and others who are interested, would be helpful. I'll close the issue in a few days if no one comments. Note also that I'm trying to get some expert BEEPster review of the BEEP text in cap-13. - RL "Bob" -------------------------------------------------------------------------------- Prev by Date: CAP issue resolution Next by Date: CAP issue #758: REQUEST-STATUS syntax Previous by thread: CAP issue resolution Next by thread: CAP issue #758: REQUEST-STATUS syntax Index(es): Date Thread From owner-ietf-calendar@mail.imc.org Wed Aug 4 12:40:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17119 for ; Wed, 4 Aug 2004 12:40:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GVQEx093796; Wed, 4 Aug 2004 09:31:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GVQJT093795; Wed, 4 Aug 2004 09:31:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GVQeK093785 for ; Wed, 4 Aug 2004 09:31:26 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from [130.129.131.194] [130.129.131.194] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A9769580278; Wed, 04 Aug 2004 09:06:14 -0700 In-Reply-To: <6.1.1.1.0.20040803204534.0283a970@mail.comcast.net> References: <6.1.1.1.0.20040803204534.0283a970@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Ietf-calendar@imc.org From: Nathaniel Borenstein Subject: Re: Item missing from Bob's list of unresolved items in Bugzilla... Date: Wed, 4 Aug 2004 12:31:44 -0400 To: TimHare@comcast.net X-Mailer: Apple Mail (2.618) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit While I have serious questions about the ongoing value of CALSCALE for the ical revisions, I completely support the idea that backward compatibility will be enhanced if all implementations report their CALSCALE capability (or, at the moment, obviously, their lack thereof). -- nathaniel On Aug 3, 2004, at 8:49 PM, TimHare@comcast.net wrote: > > It's still may be a small issue - but I would still like to see the > chairs call for consensus on whether or not CALSCALE should be a > _required_ property returned by the GET-CAPABILITY command. This is > issue 491 in the Bugzilla list - I believe the first one added after > this new list was started. I strongly feel that this should be > required, since CALSCALE could affect how other things work in a > calendar. > > > > Tim Hare > Interested Bystander, Non-Inc. > > > From owner-ietf-calendar@mail.imc.org Wed Aug 4 13:57:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23739 for ; Wed, 4 Aug 2004 13:57:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HkHgJ000682; Wed, 4 Aug 2004 10:46:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74HkHpL000681; Wed, 4 Aug 2004 10:46:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HkG4F000669 for ; Wed, 4 Aug 2004 10:46:16 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i74HkAJd007422 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 Aug 2004 10:46:12 -0700 Message-ID: <411120E1.2070206@Royer.com> Date: Wed, 04 Aug 2004 11:46:09 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP issue #657 (BEEP profile): closed? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040502020909000501020703" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040502020909000501020703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Is that not covered in "12.3 BEEP connection details" ? If not, what is missing? Preston Stephenson wrote: >Sorry I haven't been getting copied for some time. >I still don't see how to start a BEEP channel for CAP in rev 13. >At least with my understanding of BEEP. >Preston > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040502020909000501020703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODA0MTc0NjA5WjAjBgkqhkiG9w0BCQQxFgQUGnr9DAAvrZTRedGQNt6V PuAijDMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAJIK8L01Smw68zoSUp5NPJBwvvFe4LoyxYDQgZFQRCLVL/kJalnY+1P5fNdGUECbe 77gpYZGq7YEjP9JdGyZh+kiEV3JsoKY8W3nhS81rb2hCGdGqWrc2gqc1Lzy8S2cACwb9JRwL BoTYZseWhxqQnZL4beN19TXbe00aTFxdpuz7x/jvERwgCQHtCotNs4Fc89uxDC/ak1OrOVVv FhIqvmsK1xZCUJi5UVp78wYeaEgzzi/BoCZKikahttxGhMe+Cuy+Z78ukCY7j8isiLJncPPW MZOR5RoAW155kups5VgXqF/7EC2DAv8F5AuIHE57Q6n2Tpk1Tvw/Q94et6UHZwAAAAAAAA== --------------ms040502020909000501020703-- From owner-ietf-calendar@mail.imc.org Wed Aug 4 14:30:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26436 for ; Wed, 4 Aug 2004 14:30:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74IJtRe003614; Wed, 4 Aug 2004 11:19:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74IJt4H003613; Wed, 4 Aug 2004 11:19:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from xgate.provo.novell.com (xgate.provo.novell.com [137.65.47.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74IJsdB003605 for ; Wed, 4 Aug 2004 11:19:54 -0700 (PDT) (envelope-from PStephenson@gw.novell.com) Received: from PROVO7-MTA by xgate.provo.novell.com with Novell_GroupWise; Wed, 04 Aug 2004 12:24:43 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 04 Aug 2004 12:23:25 -0600 From: "Preston Stephenson" To: Subject: Re: CAP issue #657 (BEEP profile): closed? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 There is a greeting that says CAP is supported, but there is not a BEEP start channel for CAP. BEEP communicates on channels. What channel will be for CAP? The doc shows starting a channel for authentication, but that is for authentication not CAP. In the BEEP (RFC3080) spec it shows starting a channel to do TLS. >>> Doug@royer.com 08/04/04 11:46 AM >>> Is that not covered in "12.3 BEEP connection details" ? If not, what is missing? Preston Stephenson wrote: >Sorry I haven't been getting copied for some time. >I still don't see how to start a BEEP channel for CAP in rev 13. >At least with my understanding of BEEP. >Preston > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Wed Aug 4 16:43:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06870 for ; Wed, 4 Aug 2004 16:42:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74KXN2l013710; Wed, 4 Aug 2004 13:33:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74KXNOi013709; Wed, 4 Aug 2004 13:33:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74KXM57013701 for ; Wed, 4 Aug 2004 13:33:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i74KXFJd009975 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 Aug 2004 13:33:16 -0700 Message-ID: <4111480A.7070701@Royer.com> Date: Wed, 04 Aug 2004 14:33:14 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP issue #657 (BEEP profile): closed? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040201050102000206070804" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040201050102000206070804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: >There is a greeting that says CAP is supported, but there is not a BEEP >start channel for CAP. > Start one - per beep. You have the uri as specified in CAP: http://iana.org/beep/cap/1.0 And BEEP: "2.3.1.2 The Start Message" >BEEP communicates on channels. >What channel will be for CAP? > Any where you started the channel with the uri = http://iana.org/beep/cap/1.0 >The doc shows starting a channel for authentication, but that is for >authentication not CAP. > CAP does not have its own authentication. It uses the BEEP SASL profile for authentication. Once authentication is complete and valid, send a CAP greeting as described in CAP "12.3 BEEP connection details", paragraph that starts with "At this point ...". Once the greeting is accepted you can open as many channels as you wish providing the CAP uri for each channel. *** And again, I am not what I would call a beep expert. So if something is incorrect, please advice! *** >In the BEEP (RFC3080) spec it shows starting a channel to do TLS. > > > >>>>Doug@royer.com 08/04/04 11:46 AM >>> >>>> >>>> > >Is that not covered in "12.3 BEEP connection details" ? > >If not, what is missing? > > >Preston Stephenson wrote: > > > >>Sorry I haven't been getting copied for some time. >>I still don't see how to start a BEEP channel for CAP in rev 13. >>At least with my understanding of BEEP. >>Preston >> >> >> >> >> > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040201050102000206070804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODA0MjAzMzE0WjAjBgkqhkiG9w0BCQQxFgQUJEA6489Iz7mhja9OrPir tYjZ6dIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAEKLI6iZJ2tk3YsB5AUj62xI149wzi3be50M0bMptnNuNUJ+rfKEt1djheZ7DltUz Cb/NEyMToyXTnuTAEyb0L5BP4aD75FlT0RVLwVj2sU4+mLpnjBN+Ypon8uy55gsNwzWv4LlR w82ommgbY2ic4PVGvBUxzlgjD3+6gFz97z3GF1oPyGwi8vwclBPDoNFkq17+NRddv0b/YNTl FTMjIYejt3Lk3mN5ooH4kflEv64Y4yQa4oWG2o2K9KV1stxCKh1aZT08f/uLYd2KU6ZS1KFT oL3xJQR3LTm1H8e6k1YZjZ2+xoRzBypt2L2ctUOkESUdSUeBglwzHnst6T8dYQAAAAAAAA== --------------ms040201050102000206070804-- From owner-ietf-calendar@mail.imc.org Wed Aug 4 17:09:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08391 for ; Wed, 4 Aug 2004 17:09:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Kw7aT016498; Wed, 4 Aug 2004 13:58:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74Kw7n9016497; Wed, 4 Aug 2004 13:58:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from xgate.provo.novell.com (xgate.provo.novell.com [137.65.47.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Kw6hA016484 for ; Wed, 4 Aug 2004 13:58:06 -0700 (PDT) (envelope-from PStephenson@gw.novell.com) Received: from PROVO7-MTA by xgate.provo.novell.com with Novell_GroupWise; Wed, 04 Aug 2004 15:02:56 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 04 Aug 2004 15:01:34 -0600 From: "Preston Stephenson" To: Subject: Re: CAP issue #657 (BEEP profile): closed? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 The greeting message just says what is available. You have to send a start message for a channel. You have to have a channel to communicate. Channel 0 is reserved for channel management. For 2.3 of rfc3080 "When a BEEP session starts, only channel number zero is defined, which is used for channel management." C: C: C: Where is the example of starting a CAP channel? Again I need to see what the server responds to the start of a CAP channel. Thanks. Preston >>> Doug@royer.com 08/04/04 2:33 PM >>> Preston Stephenson wrote: >There is a greeting that says CAP is supported, but there is not a BEEP >start channel for CAP. > Start one - per beep. You have the uri as specified in CAP: http://iana.org/beep/cap/1.0 And BEEP: "2.3.1.2 The Start Message" >BEEP communicates on channels. >What channel will be for CAP? > Any where you started the channel with the uri = http://iana.org/beep/cap/1.0 >The doc shows starting a channel for authentication, but that is for >authentication not CAP. > CAP does not have its own authentication. It uses the BEEP SASL profile for authentication. Once authentication is complete and valid, send a CAP greeting as described in CAP "12.3 BEEP connection details", paragraph that starts with "At this point ...". Once the greeting is accepted you can open as many channels as you wish providing the CAP uri for each channel. *** And again, I am not what I would call a beep expert. So if something is incorrect, please advice! *** >In the BEEP (RFC3080) spec it shows starting a channel to do TLS. > > > >>>>Doug@royer.com 08/04/04 11:46 AM >>> >>>> >>>> > >Is that not covered in "12.3 BEEP connection details" ? > >If not, what is missing? > > >Preston Stephenson wrote: > > > >>Sorry I haven't been getting copied for some time. >>I still don't see how to start a BEEP channel for CAP in rev 13. >>At least with my understanding of BEEP. >>Preston >> >> >> >> >> > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Wed Aug 4 20:17:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23202 for ; Wed, 4 Aug 2004 20:17:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7506FEt032608; Wed, 4 Aug 2004 17:06:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7506FRb032607; Wed, 4 Aug 2004 17:06:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7506Eec032599 for ; Wed, 4 Aug 2004 17:06:14 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i7506BJd012821 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 Aug 2004 17:06:12 -0700 Message-ID: <411179F3.6000700@Royer.com> Date: Wed, 04 Aug 2004 18:06:11 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP issue #657 (BEEP profile): closed? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020600050907010009030709" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020600050907010009030709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: >The greeting message just says what is available. >You have to send a start message for a channel. >You have to have a channel to communicate. >Channel 0 is reserved for channel management. >For 2.3 of rfc3080 >"When a BEEP session starts, only channel number zero is defined, > which is used for channel management." > > C: > C: > C: > >Where is the example of starting a CAP channel? > I'll reword the text below to mention BEEP and the START command. CAP: "10.7 GET-CAPABILITY Command" CMD: GET-CAPABILITY Purpose: The "GET-CAPABILITY" command returns the capabilities of the other end point of the session. A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. A CS MUST send a "GET-CAPABILITY" command to a CUA after the initial connection. The "GET-CAPABILITY" command and reply MUST BE implemented by all CSs and CUAs. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020600050907010009030709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODA1MDAwNjExWjAjBgkqhkiG9w0BCQQxFgQUwIPmAedNrIbzqEiHft6i wNkcqrMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA4fkep/DRQ92HGy1HNcfgUqSp1TP4tg35qPDSdWe0JSTNOgwVva7OpzTnxa6CJQOV DkvOJZDbZJ5uVxmYFYKDzOBfrMwNXYx04NnQ1Hw2lVkih/dOXk541XZFakuR6HE92cCA+WuO 5DBtiXO4j4jFiyb7F6HdoMSXfTozTq+c0+kAGEOv9I9DsdsHPTsI1O+405l1chBOH10LR0Wg XfK4ykEBTuvG3rPZDxvU0VN54wWStI60R+YAQqIPatQ2GAOMlYndOX6RFsyd4WYwk7HQn51X bZ+StJShoEzmicfx3SVFA4BR4Nw2p2wWLk0fp5QKH9niC0EsilryS6DG+UPZ1AAAAAAAAA== --------------ms020600050907010009030709-- From owner-ietf-calendar@mail.imc.org Mon Aug 9 13:11:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14533 for ; Mon, 9 Aug 2004 13:11:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79GuC8H090201; Mon, 9 Aug 2004 09:56:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79GuC97090197; Mon, 9 Aug 2004 09:56:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from MARCPAUL.net (dsl-64-30-199-171.lcinet.net [64.30.199.171]) by above.proper.com (8.12.11/8.12.9) with SMTP id i79GuAwA090172 for ; Mon, 9 Aug 2004 09:56:10 -0700 (PDT) (envelope-from paf@cisco.com) Date: Mon, 09 Aug 2004 09:52:03 -0800 To: "Ietf-calendar" From: "Paf" Subject: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nbmycfukukvcbrcupxgy" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------nbmycfukukvcbrcupxgy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit price


----------nbmycfukukvcbrcupxgy Content-Type: application/octet-stream; name="price.zip" Content-Disposition: attachment; filename="price.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------nbmycfukukvcbrcupxgy-- From owner-ietf-calendar@mail.imc.org Mon Aug 9 15:07:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28708 for ; Mon, 9 Aug 2004 15:07:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79It8o4003101; Mon, 9 Aug 2004 11:55:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79It8YW003100; Mon, 9 Aug 2004 11:55:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79It5cT003086 for ; Mon, 9 Aug 2004 11:55:06 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i79It057016969 for ; Mon, 9 Aug 2004 11:55:00 -0700 (PDT) Received: from [67.161.18.242] (vpn-10-50-16-21.qualcomm.com [10.50.16.21]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i79IswtZ020056 for ; Mon, 9 Aug 2004 11:54:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Mon, 9 Aug 2004 11:54:57 -0700 To: ietf-calendar@imc.org From: Ted Hardie Subject: Fwd: beep in calsch-cap-13.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >From: David Blacka > >Ted, > >I've done a very quick scan of the document and nothing jumped out >at me as being obviously wrong. That is, it didn't look like BEEP >was being used in some impossible way. I did have a few initial >comments, however: > >* use of the "locales" attribute in the BEEP greeting to set the CAP >locale might not be the best thing. the "locales" attribute appears >to be for localizing BEEP error messages, and so I am unsure how >appropriate it would be to re-use it for the CAP protocol itself. I >am mainly unsure if implementations typically export that >information. > >* the one BEEP example needs work. For instance, the BEEP frame >isn't fully shown, and probably should be. > >I can spend a little be more time looking to see if there is >something else CAP needs to specify (like the message pattern). I >think it probably does, but I expect 3080 has something specific to >say about it. > >-- >David From owner-ietf-calendar@mail.imc.org Wed Aug 11 17:45:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21326 for ; Wed, 11 Aug 2004 17:45:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLYVGB092875; Wed, 11 Aug 2004 14:34:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BLYVlG092874; Wed, 11 Aug 2004 14:34:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLYUCR092865 for ; Wed, 11 Aug 2004 14:34:30 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7BLYUpp016064 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 11 Aug 2004 14:34:32 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <369943F0-EBDE-11D8-8EB5-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: " " From: Lisa Dusseault Subject: New mailing lists Date: Wed, 11 Aug 2004 14:34:23 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Having discussed calendaring work with a bunch of people last week, and agreed there was increased interest in both developing CalDAV and in taking iCalendar to draft standard, I've taken the liberty of creating two separate new mailing lists: http://lists.osafoundation.org/mailman/listinfo/ietf-caldav http://lists.osafoundation.org/mailman/listinfo/ietf-calsify The general intent of people I talked to was attempt to turn CALSIFY (CAL plus SImpliFY) into an official WG charted to bring iCalendar to draft standard, but not to attempt to bring CalDAV to a working group at this point. Both mailing lists are appropriate for discussion of the direction and venue in which to pursue standardization, as well as of course for technical discussions. Volunteers in either area would be highly appreciated! These mailing lists are of course open and intended to be disseminated widely, as one of the goals at this point is to increase participation and invigorate the work efforts. So tell your friends! Lisa From owner-ietf-calendar@mail.imc.org Mon Aug 16 16:29:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05896 for ; Mon, 16 Aug 2004 16:29:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GKH2xN091173; Mon, 16 Aug 2004 13:17:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GKH2JW091172; Mon, 16 Aug 2004 13:17:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GKGuml091161 for ; Mon, 16 Aug 2004 13:17:01 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i7GJXvMd023959 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 16 Aug 2004 12:34:21 -0700 Message-ID: <41210C25.2030607@Royer.com> Date: Mon, 16 Aug 2004 13:33:57 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: beep in calsch-cap-13.txt References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090201010805070100000201" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090201010805070100000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ted Hardie wrote: > >> >> From: David Blacka >> >> Ted, >> >> I've done a very quick scan of the document and nothing jumped out at >> me as being obviously wrong. That is, it didn't look like BEEP was >> being used in some impossible way. I did have a few initial >> comments, however: >> >> * use of the "locales" attribute in the BEEP greeting to set the CAP >> locale might not be the best thing. the "locales" attribute appears >> to be for localizing BEEP error messages, and so I am unsure how >> appropriate it would be to re-use it for the CAP protocol itself. I >> am mainly unsure if implementations typically export that information. > That is also its usage in CAP. For status and error messages. So I think it is valid to use them. >> >> >> * the one BEEP example needs work. For instance, the BEEP frame >> isn't fully shown, and probably should be. > Examples? >> >> I can spend a little be more time looking to see if there is >> something else CAP needs to specify (like the message pattern). I >> think it probably does, but I expect 3080 has something specific to >> say about it. > THANKS! -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090201010805070100000201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODE2MTkzMzU3WjAjBgkqhkiG9w0BCQQxFgQUa54QDhhM6+y3U7b4yeEd NVJNocAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAA6bauWnM1RBYdJNjs+K1Ta+vnPXUG5pXlggsT00yJB4PZ4SYQIdOetoz6DL7u0/9 gZo74mOJQ/ALuFFuu9vV+0HRniMsDhvb4dyEHvUUrGw/1Yn8C8ScQNi2O5RLqTDNNWsh701o OU2cN8eF/qn23noy2Y8xQ1SoEfcMYdJ012CK+oAlAH4huwq/grxWQ5mZPgVvRn6OzjQniDT3 MU5JidEZmIwPgbK0BI3aopVMkgCcOeKmZ9WFjWCP3WMPIGHIKX77Uwe3G0xZlI7bfkw30z/l jfwkOKEGDw7lGzQbBzwB6GmEXpatTLbzm8/ZNub93oF0Mr2MiZ9laBof9MBnIgAAAAAAAA== --------------ms090201010805070100000201-- From owner-ietf-calendar@mail.imc.org Mon Aug 16 18:18:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16638 for ; Mon, 16 Aug 2004 18:18:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GM5Z95000254; Mon, 16 Aug 2004 15:05:35 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GM5ZcU000253; Mon, 16 Aug 2004 15:05:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GM5ZFl000241 for ; Mon, 16 Aug 2004 15:05:35 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 16 Aug 2004 18:05:32 -0400 id 002DC940.41212FAC.00007197 From: David Blacka Organization: VeriSign, Inc. To: Doug@royer.com Subject: Re: Fwd: beep in calsch-cap-13.txt Date: Mon, 16 Aug 2004 18:05:13 -0400 User-Agent: KMail/1.6.2 Cc: ietf-calendar@imc.org, Ted Hardie MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200408161805.13961.davidb@verisignlabs.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >>>* use of the "locales"[sic] attribute in the BEEP greeting to set the >>>CAP locale might not be the best thing. the "locales"[sic] attribute >>>appears to be for localizing BEEP error messages, and so I am >>>unsure how appropriate it would be to re-use it for the CAP >>>protocol itself. I am mainly unsure if implementations typically >>>export that information. >That is also its usage in CAP. For status and error messages. So I >think it is valid to use them. I'm not trying to say that the use of the "localize" attribute isn't valid, what I'm trying to say is that it might not be a good idea from an implementation standpoint. From a theoretical perspective, since the "localize" attribute is for the BEEP layer, BEEP implementers may not be aware that the application layer might want that information. That being said, the BEEP implementation that I use most often appears to export the localization string. There may be a layering argument that using the "localize" attribute isn't valid, but I don't feel particularly strongly about it. >>>* the one BEEP example needs work. For instance, the BEEP frame >>>isn't fully shown, and probably should be. >> >Examples? Well, in particular, the existing example (in section 3.3.1) shows the frame header, but not the footer. Not a big change, but: C: MSG 1 2 . 432 62\r\n C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//someone's prodid C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID C: END:VCALENDAR C: END\r\n is more correct. >>>I can spend a little be more time looking to see if there is >>>something else CAP needs to specify (like the message pattern). I >>>think it probably does, but I expect 3080 has something specific >>>to say about it. I will admit that in my initial response, I had utterly failed to read section 12, which contains the meat of the BEEP information. (sorry about that :)) The draft does state what the messages patterns are and when you would use each pattern, which is good. It was not clear to me if the draft is clear about the distinctions between Listener, Initiator, Client, and Server. Some of the examples use the I:/L: pair, and some use the C:/S: pair. Normally, when talking about BEEP, the distinction between I/L and C/S is only really apparent when talking about channel creation. When talking about what the application does, generally you should stick to C/S, and specify when I or L can equal C or S (that is, when which side gets to act as the client or server). To try and say this in a more accessible way: does CAP always equate the Listener with the Server and the Initiator with the Client? If so, say so, if not, describe under what situations the Client/Server pair reverses, and warn folks that it will. Having the Listener act as a client is normal for BEEP, but it might surprise non-BEEP experts. Looking at section 12: The initial message after authentication each direction MUST BE single "text/calendar" object containing a CAP "CAPABILITY" CMD and must not be part of a MIME multipart message. Note that if CAP relies on the BEEP layer for authentication, then, technically, the authentication messages are not part of your profile. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-calendar@mail.imc.org Fri Aug 20 23:24:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03612 for ; Fri, 20 Aug 2004 23:24:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L3AO21036489; Fri, 20 Aug 2004 20:10:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L3AOX1036488; Fri, 20 Aug 2004 20:10:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L3AN4F036468 for ; Fri, 20 Aug 2004 20:10:23 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc12) with SMTP id <2004082103102201200p2iuqe> (Authid: TimHare); Sat, 21 Aug 2004 03:10:22 +0000 Message-Id: <6.1.1.1.0.20040820225941.027d3c80@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 20 Aug 2004 23:03:36 -0400 To: Ietf-calendar@imc.org From: TimHare@comcast.net Subject: draft-hare-xcalendar-01 has been posted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've revised my draft on using XML with iCal. There are some cleanups, some corrections, and one major change: the xcal2ics stylesheet in the draft now wraps the iCalendar lines properly at 75 characters. The link is: http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt If anyone has questions not relevant to this list, feel free to send them to my e-mail address. Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Sat Aug 21 13:17:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22488 for ; Sat, 21 Aug 2004 13:17:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LH6j6B068513; Sat, 21 Aug 2004 10:06:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LH6jeV068512; Sat, 21 Aug 2004 10:06:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LH6j7Q068506 for ; Sat, 21 Aug 2004 10:06:45 -0700 (PDT) (envelope-from camerost@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 21 Aug 2004 10:06:48 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 21 Aug 2004 10:06:47 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 21 Aug 2004 10:06:45 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 21 Aug 2004 10:06:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-hare-xcalendar-01 has been posted Date: Sat, 21 Aug 2004 10:06:30 -0700 Message-ID: <1198328AFDBF5841B27E40C40C331537CF35DE@df-chewy-msg.exchange.corp.microsoft.com> Thread-Topic: draft-hare-xcalendar-01 has been posted thread-index: AcSHLc74acEJb90mQXW/5Tpt2HBPtwAZdWxA From: "Cameron Stillion" To: , X-OriginalArrivalTime: 21 Aug 2004 17:06:44.0418 (UTC) FILETIME=[3C49F220:01C487A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7LH6j7Q068507 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I have only one comment really: It seems premature to create an XML-standard variation of a schema/format that has not yet reached the coveted approval of "standard". Some of the changes suggested by the working group on the ietf-calsify list will potentially have huge implications on this and other dependent RFCs. Regards, cameron -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of TimHare@comcast.net Sent: Friday, August 20, 2004 8:04 PM To: Ietf-calendar@imc.org Subject: draft-hare-xcalendar-01 has been posted I've revised my draft on using XML with iCal. There are some cleanups, some corrections, and one major change: the xcal2ics stylesheet in the draft now wraps the iCalendar lines properly at 75 characters. The link is: http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt If anyone has questions not relevant to this list, feel free to send them to my e-mail address. Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Sun Aug 22 22:49:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17629 for ; Sun, 22 Aug 2004 22:49:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7N2RrG9078399; Sun, 22 Aug 2004 19:27:53 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7N2Rrk6078398; Sun, 22 Aug 2004 19:27:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7N2RqOY078384 for ; Sun, 22 Aug 2004 19:27:52 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i7N2RnMd025056 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 22 Aug 2004 19:27:51 -0700 Message-ID: <41295624.1000708@Royer.com> Date: Sun, 22 Aug 2004 20:27:48 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: ABNF DIFF - pass 1 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040307040306040603070108" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040307040306040603070108 Content-Type: multipart/mixed; boundary="------------020502090201070001090402" This is a multi-part message in MIME format. --------------020502090201070001090402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Attached is the 1st pass at fixing the ABNF. In a day or two I'll update it with the changes posted during the last IETF. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------020502090201070001090402 Content-Type: text/plain; name="abnf.diff" Content-Disposition: inline; filename="abnf.diff" Content-Transfer-Encoding: 7bit Index: cap.xml =================================================================== RCS file: /home/cvs/INET-Consulting/ietf/CAP-draft/cap/cap.xml,v retrieving revision 1.4 diff -r1.4 cap.xml 520a521,526 > methodp = ; As defined in [iCAL] > > prodid = ; As defined in [iCAL] > > calscale = ; As defined in [iCAL] > 530a537 > 537a545,546 > component = ; As defined in [iCAL] > 558a568,575 > emailprop = ; As definded in [iCAL] > > procprop = ; As definded in [iCAL] > > dispprop = ; As definded in [iCAL] > > audioprop = ; As definded in [iCAL] > 572c589 < other-params = *(";" xparam) *(";" iana-params) *(";" other-param) --- > other-params = *(";" xparam) *(";" iana-params) *(";" other-params) 599a617,620 > trigrel = ; As defined in [iCAL] > > trigabs = ; As defined in [iCAL] > 1601a1623 > 1602a1625 > 2567a2591,2592 > dot-atom-text = ; As defined in [iCAL] > 2808a2834,2835 > boolean = ; As defined in [iCAL] > 3173c3200 < CALID = "CALID" other-params ":" relcalid CRLF --- > calid = "CALID" other-params ":" relcalid CRLF 3339c3366 < car-level = "CAR-LEVEL" ":" other-params : car-level-values --- > car-level = "CAR-LEVEL" ":" other-params ":" car-level-values 3407c3434 < ' "VRIGHT" must be supplied. --- > ; "VRIGHT" must be supplied. 3625c3652 < language = Text identifying a locale, as defined in [CHARPOL] --- > language = ; Text identifying a locale, as defined in [CHARPOL] 3694a3722,3723 > txidprefix = ; As defined in [iCAL] > 3739,3740c3768,3769 < def-vcars = "DEFAULT-VCARS" other-params ":" text < *( "," text ) CRLF --- > defautl-vcars = "DEFAULT-VCARS" other-params ":" text > *( "," text ) CRLF 4036a4066,4067 > date-time = ; As defined in [iCAL] > 4076c4107 < mname = "MULTIPART" other-params ":" text *( "," text) CRLF --- > multipart = "MULTIPART" other-params ":" text *( "," text) CRLF 4206c4237 < perm = "PERMISSION" other-params ":" permvalue CRLF --- > permmission = "PERMISSION" other-params ":" permvalue CRLF 4566c4597 < restrict = "RESTRICTION" other-params ":" cal-query CRLF --- > restriction = "RESTRICTION" other-params ":" cal-query CRLF 4752c4783 < transp = "TRANSP" other-params ":" transvalue CRLF --- > transp = "TRANSP" other-params ":" transvalue CRLF 4754,4766c4785,4796 < transvalue < = "OPAQUE" ;Blocks or opaque on busy time searches. < / "TRANSPARENT" ;Transparent on busy time searches. < < / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time < ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects < ; can overlap it. < < / "OPAQUE-NOCONFLICT" ; Opaque on busy time < ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects < ; can overlap it. < ; < ;Default value is OPAQUE --- > transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. > / "TRANSPARENT" ;Transparent on busy time searches. > > / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time > ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects > ; can overlap it. > > / "OPAQUE-NOCONFLICT" ; Opaque on busy time > ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects > ; can overlap it. > ; > ; Default value is OPAQUE 4841a4872,4877 > icalobject = ; As defined in [iCAL] > > created = ; As defined in [iCAL] > > related-to = ; As defined in [iCAL] > 4966a5003,5004 > vagendac = ; As defined in [iCAL]. > 5337c5375,5377 < option-value = paramtext ; As defined in [iCAL] --- > option-value = "OPTION" "=" paramtext > > paramtext ; As defined in [iCAL] 5534c5574 < request-status --- > rstatus 5590c5630 < request-status --- > rstatus 5668c5708 < request-status --- > rstatus 5681c5721 < ; x-component = x-id --- > ; x-comp = x-id 5685a5726,5731 > tzid = ; As defined in [iCAL] > > sequence = ; As defined in [iCAL] > > uid = ; As defined in [iCAL] > 5697c5743 < other-props --- > other-props ) 5743c5789,5799 < / iana-comp / x-component --- > / iana-comp / x-comp > > freebusyc = ; As defined in [iCAL] > > eventc = ; As defined in [iCAL] > > journalc = ; As defined in [iCAL] > > timezonec = ; As defined in [iCAL] > > todoc = ; As defined in [iCAL] 5962c6018 < request-status --- > rstatus 5974c6030 < ; x-component = x-id --- > ; x-comp = x-id 6084c6140 < request-status --- > rstatus 6736c6792 < request-status --- > rstatus 6748c6804 < ; x-component = x-id --- > ; x-comp = x-id 7093c7149 < / other-params --- > / other-params ) 7095c7151 < setlocal-option = option-param newlocale --- > setlocale-option = option-param newlocale 7103,7104d7158 < ) < 7132c7186 < request-status --- > rstatus --------------020502090201070001090402-- --------------ms040307040306040603070108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODIzMDIyNzQ5WjAjBgkqhkiG9w0BCQQxFgQUN6hciQq061bnWwdNJ/O8 GTNDnCcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEALXBOny5w3N2nQ05IRP86MybvTLALtgJhVRzqEb3IIZev4jHPpWfE+RxLh7au1cJ9 ylW0brExOI9NMbLmy2brVHk3YnBjEXUuuhMdUD+2vakWzdLgsZnIJxzC4hzaH2ArfTCoU96F jfV9foTUkCmGYoOT+8+ptaZXldmSgVwrBZFXyjXtWsjhi9ptIophZQdT6ebGdG+a/sNagFZh p8QxpwALAmC5+O/XqcAlCiw87fWJruQq+ev1AcN+ZP2n5LTD5gyJ72dpT311Rw9gdSOcm8O9 6tHc1V8cfZO7WtZSRNPKy74rp/zpzOwoRZ8Ox6h3hGR+6978SC5lVpvbySPOlQAAAAAAAA== --------------ms040307040306040603070108-- From owner-ietf-calendar@mail.imc.org Mon Aug 23 07:54:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01440 for ; Mon, 23 Aug 2004 07:54:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NBkKpI027319; Mon, 23 Aug 2004 04:46:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NBkK7x027318; Mon, 23 Aug 2004 04:46:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NBkKEB027279 for ; Mon, 23 Aug 2004 04:46:20 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <2004082311461401300rah2be> (Authid: TimHare); Mon, 23 Aug 2004 11:46:14 +0000 Message-Id: <6.1.1.1.0.20040823073425.02844790@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 23 Aug 2004 07:39:25 -0400 To: "Cameron Stillion" , ietf-calendar@imc.org From: TimHare@comcast.net Subject: RE: draft-hare-xcalendar-01 has been posted In-Reply-To: <1198328AFDBF5841B27E40C40C331537CF35DE@df-chewy-msg.exchan ge.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C331537CF35DE@df-chewy-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I appreciate the comments - but, I intentionally wrote this draft _not_ to re-do the xCalendar work precisely, but as a guideline for using XML with iCalendar data. This is not one-to-one, round-trippable with iCalendar - the relationship is that IF you want your XML to be "compliant" THEN you must supply an XSLT to take your calendar data and create iCalendar data. I wanted to allow for anyone to create xCalendar again, but also to include the RDFiCal work that's been done by the W3C folks, etc. The DTDs supplied, even though one came from the previous xCalendar draft, are examples only. At 01:06 PM 8/21/04, you wrote: >I have only one comment really: > >It seems premature to create an XML-standard variation of a >schema/format that has not yet reached the coveted approval of >"standard". Some of the changes suggested by the working group on the >ietf-calsify list will potentially have huge implications on this and >other dependent RFCs. > > >Regards, >cameron > > >-----Original Message----- >From: owner-ietf-calendar@mail.imc.org >[mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of >TimHare@comcast.net >Sent: Friday, August 20, 2004 8:04 PM >To: Ietf-calendar@imc.org >Subject: draft-hare-xcalendar-01 has been posted > > >I've revised my draft on using XML with iCal. There are some cleanups, >some corrections, and one major change: the xcal2ics stylesheet in the >draft now wraps the iCalendar lines properly at 75 characters. The link >is: >http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt > >If anyone has questions not relevant to this list, feel free to send >them to my e-mail address. > >Tim Hare >Interested Bystander, Non-Inc. Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Mon Aug 23 08:12:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02791 for ; Mon, 23 Aug 2004 08:12:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NBwpai030071; Mon, 23 Aug 2004 04:58:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NBwpb9030070; Mon, 23 Aug 2004 04:58:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NBwoiK030046 for ; Mon, 23 Aug 2004 04:58:50 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc12) with SMTP id <20040823115846014007pttge> (Authid: TimHare); Mon, 23 Aug 2004 11:58:47 +0000 Message-Id: <6.1.1.1.0.20040823074841.02832030@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 23 Aug 2004 07:51:54 -0400 To: "Cameron Stillion" , ietf-calendar@imc.org From: TimHare@comcast.net Subject: Re: [Ietf-calsify] VALARM In-Reply-To: <1198328AFDBF5841B27E40C40C331537C84B2F@df-chewy-msg.exchan ge.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C331537C84B2F@df-chewy-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Your idea makes the assumption that iCalendar is _only_ used for exchange between two calendaring endpoints. Some UAs use iCalendar as their "native" storage, I believe. That aside, the spec was certainly developed to support that use and that is why VALARMs are in the spec. If the simplification work results in multiple "levels" of the spec being supported, then perhaps VALARMs could be moved to an option-including level, but not eliminated entirely. At 12:30 PM 8/21/04, you wrote: >Content-Type: multipart/alternative; > boundary="----------=_1093105859-28996-122" >Content-Transfer-Encoding: binary >MIME-Version: 1.0 >X-Mailer: MIME-tools 5.411 (Entity 5.404) > >I would like to suggest the removal of VALARM from the iCal spec. > >I have yet to hear or come up with a good scenario that includes sending >alarm information from one client to another. Applications that have >implemented this end up with features that are annoying and useless. >Case in point : Mozilla imports a calendar and all of the valarms inside >of it. Many of them (all that are in the past) immediately go off after >import. The rest of the events are set to cause an alarm. The user has >not implied that they want to attend any of these events, but is already >being bothered about it. > >Sending REQUEST calendars that include valarms makes little sense as >well. you may accept my meeting, but it's up to you when you want to be >notified about its pending approach. You might need to travel further >than anyone else I send it to, so the valarm information is inherently >specific to the client. > >While the alarm information is useful to store and to use for a client >application, it seems pointless to transport. > >Can anyone express a scenario where sending a valarm from one client to >another makes sense? > >cameron > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Mon Aug 23 16:45:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11118 for ; Mon, 23 Aug 2004 16:45:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKZKgN031884; Mon, 23 Aug 2004 13:35:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NKZKWI031883; Mon, 23 Aug 2004 13:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKZHSF031876 for ; Mon, 23 Aug 2004 13:35:17 -0700 (PDT) (envelope-from camerost@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 23 Aug 2004 13:34:44 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Aug 2004 13:34:42 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Aug 2004 13:34:43 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 13:34:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ietf-calsify] VALARM Date: Mon, 23 Aug 2004 13:34:46 -0700 Message-ID: <1198328AFDBF5841B27E40C40C331537CF38A2@df-chewy-msg.exchange.corp.microsoft.com> Thread-Topic: [Ietf-calsify] VALARM thread-index: AcSJCIzhPl/aU2JHTtOqTLBvb/2tewAQB5WA From: "Cameron Stillion" To: , X-OriginalArrivalTime: 23 Aug 2004 20:34:47.0334 (UTC) FILETIME=[A1834460:01C48950] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7NKZHSF031877 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I see your point. I am a little surprised that UAs would choose to use iCal as a native storage format, but I understand the desire not to disallow it by design. Also, now that you mention it, I can imagine a thin client wanting to use caldav to access a user's data where the alarm information would need to be there too. Perhaps iMip can lend some weight here and if not disallow, then highly discourage the transport of VALARMs for any purposes other than backup/restore/etc. I would say that MIME transport is rarely used for the purposes we've identified for actually using VALARMS. cameron -----Original Message----- From: TimHare@comcast.net [mailto:TimHare@comcast.net] Sent: Monday, August 23, 2004 4:52 AM To: Cameron Stillion; ietf-calendar@imc.org Subject: Re: [Ietf-calsify] VALARM Your idea makes the assumption that iCalendar is _only_ used for exchange between two calendaring endpoints. Some UAs use iCalendar as their "native" storage, I believe. That aside, the spec was certainly developed to support that use and that is why VALARMs are in the spec. If the simplification work results in multiple "levels" of the spec being supported, then perhaps VALARMs could be moved to an option-including level, but not eliminated entirely. At 12:30 PM 8/21/04, you wrote: >Content-Type: multipart/alternative; > boundary="----------=_1093105859-28996-122" >Content-Transfer-Encoding: binary >MIME-Version: 1.0 >X-Mailer: MIME-tools 5.411 (Entity 5.404) > >I would like to suggest the removal of VALARM from the iCal spec. > >I have yet to hear or come up with a good scenario that includes >sending alarm information from one client to another. Applications >that have implemented this end up with features that are annoying and useless. >Case in point : Mozilla imports a calendar and all of the valarms >inside of it. Many of them (all that are in the past) immediately go >off after import. The rest of the events are set to cause an alarm. >The user has not implied that they want to attend any of these events, >but is already being bothered about it. > >Sending REQUEST calendars that include valarms makes little sense as >well. you may accept my meeting, but it's up to you when you want to >be notified about its pending approach. You might need to travel >further than anyone else I send it to, so the valarm information is >inherently specific to the client. > >While the alarm information is useful to store and to use for a client >application, it seems pointless to transport. > >Can anyone express a scenario where sending a valarm from one client to >another makes sense? > >cameron > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Sun Aug 29 11:37:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14404 for ; Sun, 29 Aug 2004 11:37:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TFM7ag088694; Sun, 29 Aug 2004 08:22:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TFM7S5088693; Sun, 29 Aug 2004 08:22:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TFM65t088669 for ; Sun, 29 Aug 2004 08:22:06 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id AE756DEF00C8; Sun, 29 Aug 2004 07:55:49 -0700 In-Reply-To: <1198328AFDBF5841B27E40C40C331537CF38A2@df-chewy-msg.exchange.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C331537CF38A2@df-chewy-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: , From: Nathaniel Borenstein Subject: Re: [Ietf-calsify] VALARM Date: Sat, 28 Aug 2004 12:46:03 -0400 To: "Cameron Stillion" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit As the officially-designated wild-eyed radical, I think Cameron has given up this argument too quickly. There is certainly no law against using iCal as your internal storage format. However I would conjecture that nearly anyone who does that will end up, more or less inevitably, adding non-standard private extensions to iCal, to take account of *some* kind of concept that isn't found in iCal. i haven't yet heard anyone claim that iCal is, or can be, a representation for all calendar-related information that you might possibly want to keep. Thus I would conjecture that any software using iCal for storage is likely to end up either A) mapping its representation to a more standard subset for transport, or B) sending non-standard data in transport. The former is clearly fine from a standards perspective, while the latter can probably be designed to be fine, through judicious use of X- fields, etc. Given this view, I find myself to reluctant to keep *any* feature in the iCal format for the reasons that Tim cites for keeping VALARM in the core spec. If there is a feature -- perhaps VALARM, perhaps something else -- that is not needed for transport, I would like to see it moved out of the base iCal standard and into another document, so that we can **simplify** the core standard that everyone needs to understand and implement. I have nothing against VALARM per se, but I am skeptical of including anything in the base standard that isn't needed for data interchange between heterogeneous systems, because such transport is the most important problem we are trying to solve. In the case of VALARM, the thin client CalDav example is fairly compelling, but even there I see it as belonging in a separate spec that describes user-side concepts. (Personally, I want to be able to set an alarm for myself, but I don't want anyone else to set an alarm for *me*.) -- Nathaniel On Aug 23, 2004, at 4:34 PM, Cameron Stillion wrote: > I see your point. > > I am a little surprised that UAs would choose to use iCal as a native > storage format, but I understand the desire not to disallow it by > design. Also, now that you mention it, I can imagine a thin client > wanting to use caldav to access a user's data where the alarm > information would need to be there too. > > Perhaps iMip can lend some weight here and if not disallow, then highly > discourage the transport of VALARMs for any purposes other than > backup/restore/etc. I would say that MIME transport is rarely used for > the purposes we've identified for actually using VALARMS. > > > cameron > > > -----Original Message----- > From: TimHare@comcast.net [mailto:TimHare@comcast.net] > Sent: Monday, August 23, 2004 4:52 AM > To: Cameron Stillion; ietf-calendar@imc.org > Subject: Re: [Ietf-calsify] VALARM > > Your idea makes the assumption that iCalendar is _only_ used for > exchange between two calendaring endpoints. Some UAs use iCalendar as > their "native" > storage, I believe. That aside, the spec was certainly developed to > support that use and that is why VALARMs are in the spec. If the > simplification work results in multiple "levels" of the spec being > supported, then perhaps VALARMs could be moved to an option-including > level, but not eliminated entirely. > > > At 12:30 PM 8/21/04, you wrote: >> Content-Type: multipart/alternative; >> boundary="----------=_1093105859-28996-122" >> Content-Transfer-Encoding: binary >> MIME-Version: 1.0 >> X-Mailer: MIME-tools 5.411 (Entity 5.404) >> >> I would like to suggest the removal of VALARM from the iCal spec. >> >> I have yet to hear or come up with a good scenario that includes >> sending alarm information from one client to another. Applications >> that have implemented this end up with features that are annoying and > useless. >> Case in point : Mozilla imports a calendar and all of the valarms >> inside of it. Many of them (all that are in the past) immediately go >> off after import. The rest of the events are set to cause an alarm. >> The user has not implied that they want to attend any of these events, >> but is already being bothered about it. >> >> Sending REQUEST calendars that include valarms makes little sense as >> well. you may accept my meeting, but it's up to you when you want to >> be notified about its pending approach. You might need to travel >> further than anyone else I send it to, so the valarm information is >> inherently specific to the client. >> >> While the alarm information is useful to store and to use for a client >> application, it seems pointless to transport. >> >> Can anyone express a scenario where sending a valarm from one client >> to > >> another makes sense? >> >> cameron >> >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > Tim Hare > Interested Bystander, Non-Inc. > > > > > From owner-ietf-calendar@mail.imc.org Sun Aug 29 18:32:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13416 for ; Sun, 29 Aug 2004 18:32:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TMNfD8012648; Sun, 29 Aug 2004 15:23:41 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TMNeRf012647; Sun, 29 Aug 2004 15:23:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TMNdUh012637 for ; Sun, 29 Aug 2004 15:23:40 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i7TMNZMd025829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 29 Aug 2004 15:23:37 -0700 Message-ID: <41325766.3020203@Royer.com> Date: Sun, 29 Aug 2004 16:23:34 -0600 From: Doug Royer Reply-To: ietf-calsify@osafoundation.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org CC: ietf-calendar@imc.org Subject: Re: [Ietf-calsify] VALARM References: <1198328AFDBF5841B27E40C40C331537CF38A2@df-chewy-msg.exchange.corp.microsoft.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080206040206070903020009" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080206040206070903020009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (On the CALSIFY mailing list we are talking about the next rev of 244[567].) Nathaniel Borenstein wrote: > .... > > I have nothing against VALARM per se, but I am skeptical of including > anything in the base standard that isn't needed for data interchange > between heterogeneous systems, because such transport is the most > important problem we are trying to solve. In the case of VALARM, the > thin client CalDav example is fairly compelling, but even there I see > it as belonging in a separate spec that describes user-side concepts. It is needed so CUA from vendor A can set an alarm in CS vendor B product. MANY implementations discard objects they do not know. Without a standardized VALARM, you can't set one. Your talking about access control on the VALARM objects. And it is needed so that CUA from vendor A can see an alarm in the CS. > (Personally, I want to be able to set an alarm for myself, but I don't > want anyone else to set an alarm for *me*.) -- Nathaniel Without VALARM - how would you set a VALARM in a CS were both the CUA and CS were not the same vendor, unless there was a standard way to set the alarm? Your talking about access control on the VALARM objects. I do not care if VALARM is a separate draft from the others or not. I do think many implementations will break if there is not a standardized alarm. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080206040206070903020009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI5MjIyMzM0WjAjBgkqhkiG9w0BCQQxFgQUvRWILh19HCLdvXl5tVLJ l1EHy6AwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA1UGkwO3husnrLOmROm4K7cAMrWj/6fzMQqVyrC3RexRl01Fft3x3N9C3aXM+6lL3 Tc1t7+h4wuEE9FpKeYJXzhnt0ZxYLJMVfN3RKyRLFIg9arAmLdVCcYJ7dXKFdyVY2NOpnBTE bAEO3YB3fRLSjYOalL/oziUGqsdYuLm/Ib4ndRlg1Avs3nCvlL0D5SUxBuDdHuUfo2Q+3fMi KAVdUjZDNYw/sQO/lVcts8EI27pz7gSMoohEApYLem/xmh2LcnZ7xcYE6dsqDUkBQyRvDISa qUEoTDqIfbhV/Tue3GHa4bTLTxW9BOvMmEqeqkF15bf+77rpoob4j7/NDaqTIQAAAAAAAA== --------------ms080206040206070903020009--