From owner-ietf-calendar@mail.imc.org Wed Oct 1 14:26:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26542 for ; Wed, 1 Oct 2003 14:26:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IAPKP095031 for ; Wed, 1 Oct 2003 11:10:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91IAOg0095030 for ietf-calendar-bks; Wed, 1 Oct 2003 11:10:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IANKP095025 for ; Wed, 1 Oct 2003 11:10:23 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h91IAMmL019955 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 1 Oct 2003 11:10:23 -0700 Message-ID: <3F7B1889.1070700@Royer.com> Date: Wed, 01 Oct 2003 12:10:17 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP-12 - interm version 'E' Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030301010906060800000700" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030301010906060800000700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have placed the latest edit of CAP for your review at: http://inet-consulting.com/draft-ietf-calsch-cap-12-e.txt http://inet-consulting.com/draft-ietf-calsch-cap-12-e.html http://inet-consulting.com/draft-ietf-calsch-cap-12-e.xml -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030301010906060800000700 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 9w0BCQUxDxcNMDMxMDAxMTgxMDE3WjAjBgkqhkiG9w0BCQQxFgQUFRhXWVBZ3o+BZWklxHWM 3tDn4JQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEADUZpXtzmRbH+WmkPDqrYLxR+wOXkplmNEDEgdJ/Phz3J7XKY9T1L+6DuXicEsKBO IukcaVgX5xPFzXqocmzpvaL9OrJCFD31QxaTSHyYB65DcKXl/e47QyNoWjfiLg6HyMFOdpuq rw44kw+Un/eHuRutrcMOswP0JMnG0h07KLQMSlf6XaXm1+UKu/XRclbZKyKN8k7rmPubEWo9 VFImHQf4gWl9bBaA2ItnVQo/G0Az43Onfp0Jom+Vgrif+wgiEhpO994QF/hS/GWQiMFWvhHN VxCVWqIrmg79OiEOxzg74zZg0wQFsQKX6bDPuSvXtWrmyaqedwc4tOOBjQsxZQAAAAAAAA== --------------ms030301010906060800000700-- From owner-ietf-calendar@mail.imc.org Wed Oct 1 17:09:37 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04842 for ; Wed, 1 Oct 2003 17:09:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91KquKP001723 for ; Wed, 1 Oct 2003 13:52:56 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91KqubL001722 for ietf-calendar-bks; Wed, 1 Oct 2003 13:52:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91KqtKP001714 for ; Wed, 1 Oct 2003 13:52:56 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F70B92D.9020101@Royer.com> To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: When to publish -12 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_09102003NP September 10, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 1 Oct 2003 16:49:10 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/01/2003 04:56:53 PM, Serialize complete at 10/01/2003 04:56:53 PM Content-Type: multipart/alternative; boundary="=_alternative 0071EBC585256DB2_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071EBC585256DB2_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 09/23/2003 05:20:45 PM: >> 1: Busytime in CAP > > So what is the issue? This was originally raised back ~ 31-Mar-2003 and briefly revisited in late July before the big digression and then we lost focus on it. CAP 12-e still claims: 1. Introduction This document specifies how a Calendar CUA interacts with a CS to manage calendar information. In particular, it specifies how to query, create, modify, and delete iCalendar components (e.g., events, to-dos, or daily journal entries). It further specifies how to search for available busy time information. However I can find NOTHING in CAP that actually "specifies how to search for available busy time information". In the process of researching this since I thought we had it covered at one time I found that it was in CAP-03 thru -05 but got removed in -06 for some reason. There was NO WG discussion on the removal and we never quite reached any agreement more recently on the proposals on how to directly address this in CAP. In searching CAP-12-e I find the word 'busy' only mentioned in the text above, as part of a response comment in Section 8.28 REQUEST-STATUS property and then in some text in Section 8.37 TRANSP Property but no actual specification I can find. Perhaps Im just missing it..?? > > 2: 'Scoping' concerns raised by Preson in April 2003. > > > > I know for one that I did not agree w/Dougs summary of what he thought > > Craig proposed (ie: 'Use existing CMD:CREATE to store VFREEBUSY > > objects." ) ... > > Do *YOU* have a proposal? Others did and their comments were incorporated. As Ive said before, just because you find an issue does not mean you have to propose a solution. I had to argue enough w/you on it originaly just to get you to recognize the problem (or at least I think you recognized it but I could be wrong). Ill look at CAP-12-e to see if there is text that deals with breaking scoping of the SEARCH command. Im quite interested in seeing what you wrote considering you never proposed any fixes for WG discussion yourself. > Not all of CAP is in ABNF. Read the text and you will find out when it > is used. > If you have ABNF proposals - please post them, if not it looks to me as > if CAP > explains when they can be used. For the base RFCs we had: The memo also includes a formal grammar for the content type based on the Internet ABNF defined in [RFC 2234]. This ABNF is required for the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the memo. but we dont seem to have anything like this in CAP. Why is that? What good is provding ABNF that is not accurate?? Text can be too imprecise and not useful for building systems on. Thats why we provided an ABNF so we can have a definitive way to interpret the text. I think the ABNF in CAP should be just like it was in iCalendar so we have something clear and precise to use. Relying on vague text is too error prone. Im not going to waste my time giving you new ABNF if you'll just ignore it. If I thought it would be useful I would do it but I wont waste my time otherwise. > I do not see any debate on dropping QUERYID, in fact the archive is full > of discussions on how to use it, and what to name it and how to describe > how to use it. If you are not storing querys in the CS then you certainly dont need a QUERYID property to find it do you? It belongs in the followon text that addresses stored queries, not in CAP 1.0 where it serves no use. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0071EBC585256DB2_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 09/23/2003 05:20:45 PM:
>> 1: Busytime in CAP
>
> So what is the issue?
This was originally raised back ~ 31-Mar-2003 and briefly revisited in late July before the big digression and then we lost focus on it.  CAP 12-e still claims:

1. Introduction

  This document specifies how a Calendar CUA interacts with a CS to
  manage calendar information. In particular, it specifies how to
  query, create, modify, and delete iCalendar components (e.g., events,
  to-dos, or daily journal entries). It further specifies how to search
  for available busy time information.

However I can find NOTHING in CAP that actually "specifies how to search for available busy time information".  In the process of researching this since I thought we had it covered at one time I found that it was in CAP-03 thru -05 but got removed in -06 for some reason.  There was NO WG discussion on the removal and we never quite reached any agreement more recently on the proposals on how to directly address this in CAP.

In searching CAP-12-e I find the word 'busy' only mentioned in the text above, as part of a response comment in Section 8.28 REQUEST-STATUS property and then in some text in Section 8.37 TRANSP Property but no actual specification I can find.  Perhaps Im just missing it..??

> > 2: 'Scoping' concerns raised by Preson in April 2003.
> >
> > I know for one that I did not agree w/Dougs summary of what he thought
> > Craig proposed (ie: 'Use existing CMD:CREATE to store VFREEBUSY
> > objects." ) ...
>
> Do *YOU* have  a proposal? Others did and their comments were incorporated.
As Ive said before, just because you find an issue does not mean you have to propose a solution.  I had to argue enough w/you on it originaly just to get you to recognize the problem (or at least I think you recognized it but I could be wrong).  Ill look at CAP-12-e to see if there is text that deals with breaking scoping of the SEARCH command.  Im quite interested in seeing what you wrote considering you never proposed any fixes for WG discussion yourself.

> Not all of CAP is in ABNF. Read the text and you will find out when it
> is used.
> If you have ABNF proposals - please post them, if not it looks to me as
> if CAP
> explains when they can be used.
For the base RFCs we had:

   The memo also includes a formal grammar for the content type based on
  the Internet ABNF defined in [RFC 2234]. This ABNF is required for
  the implementation of parsers and to serve as the definitive
  reference when ambiguities or questions arise in interpreting the
  descriptive prose definition of the memo.

but we dont seem to have anything like this in CAP.  Why is that?  What good is provding ABNF that is not accurate??  Text can be too imprecise and not useful for building systems on.  Thats why we provided an ABNF so we can have a definitive way to interpret the text.   I think the ABNF in CAP should be just like it was in iCalendar so we have something clear and precise to use.  Relying on vague text is too error prone.

Im not going to waste my time giving you new ABNF if you'll just ignore it.  If I thought it would be useful I would do it but I wont waste my time otherwise.

> I do not see any debate on dropping QUERYID, in fact the archive is full
> of discussions on how to use it, and what to name it and how to describe
> how to use it.
If you are not storing querys in the CS then you certainly dont need a QUERYID property to find it do you?  It belongs in the followon text that addresses stored queries, not in CAP 1.0 where it serves no use.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0071EBC585256DB2_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 1 18:13:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07687 for ; Wed, 1 Oct 2003 18:13:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91LvlKP004036 for ; Wed, 1 Oct 2003 14:57:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91LvlDp004035 for ietf-calendar-bks; Wed, 1 Oct 2003 14:57:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91LvkKP004030 for ; Wed, 1 Oct 2003 14:57:46 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h91LvkmL021837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 1 Oct 2003 14:57:47 -0700 Message-ID: <3F7B4DCB.1060907@Royer.com> Date: Wed, 01 Oct 2003 15:57:31 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - VFREEBUSY References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010502080302020402060708" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010502080302020402060708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 09/23/2003 05:20:45 PM: > >> 1: Busytime in CAP > > > > So what is the issue? > > This was originally raised back ~ 31-Mar-2003 and briefly revisited in > late July before the big digression and then we lost focus on it. CAP > 12-e still claims: > > 1. Introduction > > This document specifies how a Calendar CUA interacts with a CS to > manage calendar information. In particular, it specifies how to > query, create, modify, and delete iCalendar components (e.g., events, > to-dos, or daily journal entries). It further specifies how to search > for available busy time information. > > However I can find NOTHING in CAP that actually "specifies how to > search for available busy time information". ... How about the entire section named: "10.12.1 Searching for VFREEBUSY" ? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010502080302020402060708 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 9w0BCQUxDxcNMDMxMDAxMjE1NzMxWjAjBgkqhkiG9w0BCQQxFgQUU00mVKALP5qQ5T7nAE6B U1doAwkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAzpStUA2FdsoucSBgMCkjugJt4DkR8sOGaMgGWsglqc+lyb/M+lSM3JXeytwrzMc/ Oo4XTvp/UaaXlsR6gVPA8kWOnSEBPaxnuSxPAGwSLqix2BkAje9/p9ISwev1VFqbOGp5TWHS 1t++wDqlBY/b1TTodhK4xZClkW76au/Tw+9ivDf/baaEwwRamE/Fh6/KAftKBynbDM9UGNmw lGxExGC6RMLz/rrSOufpOr0lnU3cjsyhntHNOZ8fXq57l7AD6oPYmL9kPPBpDgFyuObTlJXc qXaeKe5qyraNJBONSHGpjkyb52xptyVJ/mlP/33KNcV1OUMSGEMHYk69zXcQbwAAAAAAAA== --------------ms010502080302020402060708-- From owner-ietf-calendar@mail.imc.org Wed Oct 1 18:19:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08133 for ; Wed, 1 Oct 2003 18:19:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91M0eKP004119 for ; Wed, 1 Oct 2003 15:00:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91M0e0w004118 for ietf-calendar-bks; Wed, 1 Oct 2003 15:00: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.9/8.12.8) with ESMTP id h91M0dKP004113 for ; Wed, 1 Oct 2003 15:00:39 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h91M0dmL021862 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 1 Oct 2003 15:00:40 -0700 Message-ID: <3F7B4E81.3050600@Royer.com> Date: Wed, 01 Oct 2003 16:00:33 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - SCOPING References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090008080502070007080704" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090008080502070007080704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > > 2: 'Scoping' concerns raised by Preson in April 2003. > > > > > > I know for one that I did not agree w/Dougs summary of what he > thought > > > Craig proposed (ie: 'Use existing CMD:CREATE to store VFREEBUSY > > > objects." ) ... > > > > Do *YOU* have a proposal? Others did and their comments were > incorporated. > > As Ive said before, just because you find an issue does not mean you > have to propose a solution. I had to argue enough w/you on it > originaly just to get you to recognize the problem (or at least I > think you recognized it but I could be wrong). Ill look at CAP-12-e > to see if there is text that deals with breaking scoping of the SEARCH > command. Im quite interested in seeing what you wrote considering you > never proposed any fixes for WG discussion yourself. I still have no clue what you are talking about when you say 'scoping' that have not been addressed. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090008080502070007080704 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 9w0BCQUxDxcNMDMxMDAxMjIwMDMzWjAjBgkqhkiG9w0BCQQxFgQUMgZOKR/pT/kiWxNcKgJf C6rQ7ZIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAEFFdQjHyFrc3bgWOmuG0xMhd/hc2ETgXa34fS2W/1Z/ZCL7cgDZqHvEe+mQhkD3R nGGBp2lXlAHLnhEoYYTY8lfyz90+3ZXfb5KpDbN5iWCAsfhE6Ny6rd+jdbQPtVQQuMgkIBmZ 10QEn5iEfUIz0aDGAU77epSiZbc7rDHCPg0uMMCT1aD2K5Su4b1Bnc3fT67VTFh++CZ6jtft pr9Q34IEX7/EBxcPbPyflBcW8kdQguSa1MxVhxpLDfwgi+0Y2oS8YXDYwj52MkndDWGNWdwk y9IlwZwgHdDAdjqUVsnsveapeJVBx+/soJUwwcZgAsY78doABqdnqjDQQ7qkPAAAAAAAAA== --------------ms090008080502070007080704-- From owner-ietf-calendar@mail.imc.org Wed Oct 1 18:23:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08203 for ; Wed, 1 Oct 2003 18:23:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91M8oKP004464 for ; Wed, 1 Oct 2003 15:08:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91M8oR9004463 for ietf-calendar-bks; Wed, 1 Oct 2003 15:08:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91M8nKP004458 for ; Wed, 1 Oct 2003 15:08:49 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h91M8nmL021928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 1 Oct 2003 15:08:50 -0700 Message-ID: <3F7B506B.1010508@Royer.com> Date: Wed, 01 Oct 2003 16:08:43 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - ABNF References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000400050604090002080904" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000400050604090002080904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > Not all of CAP is in ABNF. Read the text and you will find out when it > > is used. > > If you have ABNF proposals - please post them, if not it looks to me as > > if CAP > > explains when they can be used. > > For the base RFCs we had: > > The memo also includes a formal grammar for the content type based on > the Internet ABNF defined in [RFC 2234]. This ABNF is required for > the implementation of parsers and to serve as the definitive > reference when ambiguities or questions arise in interpreting the > descriptive prose definition of the memo. > > but we dont seem to have anything like this in CAP. No one believes that there is nothing like ABNF in CAP. > Why is that? What good is provding ABNF that is not accurate?? It it accurate. If you want 100% of CAP to be in ABNF - propose the ABNF to the list. Just like the query reply, some things just do not make good ABNF. > Im not going to waste my time giving you new ABNF if you'll just > ignore it. If I thought it would be useful I would do it but I wont > waste my time otherwise. Yea right. So, I am supposed to do 100% of this work with NO proposals at all. No, I would get hate mail if I were to do all of that with no proposal at all and then put it into CAP at this point. No proposal submitted means I am not going to add it to CAP without a proposal and then only if the chairs call consensus on that proposal. The only changes going into CAP are typos, clarifications, fixing text or ABNF that has issues unless the chairs call consensus for a proposal to be incorporated into CAP. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000400050604090002080904 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 9w0BCQUxDxcNMDMxMDAxMjIwODQzWjAjBgkqhkiG9w0BCQQxFgQU7rk4E5Yf3veIT8EXTdE9 LFZYaa4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAIrg8SO7voeu3qFkW8yTeJrK5fvzzDtlTPiAm9VQeDgdd6eYQNpAKAjgwMzSgP+75 re0r74Ryrtbwhno8PkbyXP8YNJQuyuvqojkDXBq5jubGiMpu+dzwK1mVYWFiIIx/nUTXwPDv ePo2jU917Qi6AHqiPDKrSGcYp8h3BXT5innjhLzqGpLXUb4fTZ4qxHYn9EuZ1u4E4B4tRoQU 5hHHgUiXJ21w0i9w7inDvfZk1wwOOYR6KFvKiyZe0/6CYAYAdHecpiNNH+Lef9/YTcHE92vh BDnu5+MM7mtvJ6ioebaD+u9/Iyfq2AizXlQUIZ0WRxHciE/Y0IvJv0Ce7/BsOAAAAAAAAA== --------------ms000400050604090002080904-- From owner-ietf-calendar@mail.imc.org Wed Oct 1 18:23:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08205 for ; Wed, 1 Oct 2003 18:23:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91MATKP004514 for ; Wed, 1 Oct 2003 15:10:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91MATwQ004513 for ietf-calendar-bks; Wed, 1 Oct 2003 15:10:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91MARKP004508 for ; Wed, 1 Oct 2003 15:10:27 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h91MARmL021954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 1 Oct 2003 15:10:29 -0700 Message-ID: <3F7B50CE.5080606@Royer.com> Date: Wed, 01 Oct 2003 16:10:22 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - QUERYID References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060605030005040905030303" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060605030005040905030303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > I do not see any debate on dropping QUERYID, in fact the archive is full > > of discussions on how to use it, and what to name it and how to describe > > how to use it. > > If you are not storing querys in the CS then you certainly dont need a > QUERYID property to find it do you? It belongs in the followon text > that addresses stored queries, not in CAP 1.0 where it serves no use. Again - the auto execution of stored queries was removed per the overwhelming WG discussion. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060605030005040905030303 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 9w0BCQUxDxcNMDMxMDAxMjIxMDIyWjAjBgkqhkiG9w0BCQQxFgQU/mI3lhk4h2ogRxkCvQ09 wjF8tL8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEATdziRnSJTDV45nrPnC4pQun9WlzUSUGCpnvlmgPcVNo9YO0efFCC/SZi6bdIUzBu z0g9ntZYlHGGfVyQsl7dVIyhGj2t+Rzkfp5pDS/fxeRNGB0ruiyP6vUX/8fivDGHp791BbHz V4hkfo5vSuHo8EHp4/t60/I2wp75BdAKV6bf7F3/pcoXl2J9dbrlwhu19qJ4x7xIOyKxcUq+ Ot6piw9Q22fcKj0k3lkoA8gTAkt+CUzxsNt94z2v/L3YR3MBJsOd3Gk5wchhjjhi2HFutC2O QwVtK3G9QQOaqOX9wZsUxi6axwNm83j2H7bu3dudHMyBUdFinPFGrhTqVB9PLQAAAAAAAA== --------------ms060605030005040905030303-- From owner-ietf-calendar@mail.imc.org Wed Oct 1 18:38:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08830 for ; Wed, 1 Oct 2003 18:38:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91MQ1KP005096 for ; Wed, 1 Oct 2003 15:26:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91MQ1p8005095 for ietf-calendar-bks; Wed, 1 Oct 2003 15:26:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91MQ0KP005087 for ; Wed, 1 Oct 2003 15:26:00 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h91MPus4013382 for ; Wed, 1 Oct 2003 16:25:57 -0600 (MDT) Message-ID: <3F7B5474.B8FD4F96@INET-Calendar.net> Date: Wed, 01 Oct 2003 16:25:56 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 09/23/2003 05:20:45 PM: > >> 1: Busytime in CAP > > > > So what is the issue? > > This was originally raised back ~ 31-Mar-2003 and briefly revisited in > late July before the big digression and then we lost focus on it. CAP > 12-e still claims: > > 1. Introduction > > This document specifies how a Calendar CUA interacts with a CS to > manage calendar information. In particular, it specifies how to > query, create, modify, and delete iCalendar components (e.g., > events, > to-dos, or daily journal entries). It further specifies how to > search > for available busy time information. > > However I can find NOTHING in CAP that actually "specifies how to > search for available busy time information". In the process of > researching this since I thought we had it covered at one time I found > that it was in CAP-03 thru -05 but got removed in -06 for some reason. > There was NO WG discussion on the removal and we never quite reached > any agreement more recently on the proposals on how to directly > address this in CAP. > > In searching CAP-12-e I find the word 'busy' only mentioned in the > text above, as part of a response comment in Section 8.28 > REQUEST-STATUS property and then in some text in Section 8.37 TRANSP > Property but no actual specification I can find. Perhaps Im just > missing it..?? See pages 124-125 From owner-ietf-calendar@mail.imc.org Thu Oct 2 07:53:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13526 for ; Thu, 2 Oct 2003 07:53:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92BZuKP090431 for ; Thu, 2 Oct 2003 04:35:56 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92BZudq090430 for ietf-calendar-bks; Thu, 2 Oct 2003 04:35:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92BZtKP090424 for ; Thu, 2 Oct 2003 04:35:55 -0700 (PDT) (envelope-from cjohnson@myrealbox.com) Received: from hp1 cjohnson@smtp-send.myrealbox.com [205.208.215.164] by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision: 3.42 $ on Novell NetWare; Thu, 02 Oct 2003 05:36:00 -0600 Message-ID: <003201c388d9$574200d0$0200000a@hp1> From: "Craig Johnson" To: Cc: Subject: Re: When to publish -12 - VFREEBUSY Date: Thu, 2 Oct 2003 05:35:54 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C388A7.0C2408F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C388A7.0C2408F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruce wrote (listing unresolved issues): > 1: Busytime in CAP Doug wrote: > So what's the issue? Bruce wrote > This was originally raised back ~ 31-Mar-2003 and briefly revisited in = late july > ... > ... I can find NOTHING in CAP that actually "specifies how to > search for available busy time information" Doug wrote: > How about the entire section named: "10.12.1 Searching for VFREEBUSY" = ? Now I write: The current CAP spec (12e), including section 10.12.1, does not reflect = the central issue and outcome of the VFREEBUSY discussion in late July = referred to by Bruce. Specifically: that a search for available busy = time information can, and preferably should, be accomplished using a = VFREEBUSY request (as in iTIP). For example, the following was proposed = in that discussion: C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//Prodid C: CMD:SEARCH C: TARGET:usera C: TARGET:userb C: BEGIN:VFREEBUSY C: DTSTART:startrange C: DTEND:endrange C: ORGANIZER:... C: ATTENDEE:... C: ATTENDEE:... C: DTSTAMP:... C: UID:... C: END:VFREEBUSY C: END:VCALENDAR The example uses the SEARCH command with an iTIP VFREEBUSY to make the = request. The advantages/benefits are: * It creates consistency and continuity between the WG standards for = making a free-busy requests. * It makes life easier and more consistent on both sides of the wire: * It makes it easier for CUAs because there is only one way the CUA must = formulate a search that works for both iMIP and CAP recipients (not a = scheme for iMIP and a different scheme for CAP). The CUA formulates the = "VFREEBUSY search" not caring if it is intended for recipients via CAP, = or iMIP or some other mechanism. * A Calendar Store would use the same code to respond to the VFREEBUSY = search request regardless of whether it came via CAP or iMIP. Again, = consistency and continuity! (Calendar Stores that support iTIP very = likely have code to handle VFREEBUSY requests. Adapting that code for = CAP is relatively simple.) * Using a VFREEBUSY request is a more straightforward, consistent, = stable, and established method for CUAs to rely on than other proposed = methods (e.g. VQUERY). <> Nevertheless, there is nothing in the spec from that discussion about = using VFREEBUSY to do a free-busy search. So, here is my updated proposal, with ABNF, that defines how to perform = a search for free-busy information via the SEARCH command. It goes in = section 10.12 "SEARCH Command." [[[ the following ABNF goes after the ABNF on page 122]]] ABNF for a "SEARCH" object is: search-object =3D "BEGIN" ":" "VCALENDAR" CRLF ; ; calprops MUST include 'search-cmd' ; calprops other-props 1*(search-comp) "END" ":" "VCALENDAR" CRLF search-comp =3D queryc / freebusyc / iana-comp / x-component freebusyc =3D (as defined in iTIP) [[[the following is a revised paragraph following the ABNF for = searchparam on p 122]]] The format of the request is the search command (search-cmd) followed by one or more (queryc) "VQUERY" components or (freebusyc) VFREEBUSY=20 components. [[[the following goes somewhere in section 10.12 or 10.12.1]]] When VFREEBUSY is used with the SEARCH command the CS should return=20 free-busy information defined by the VFREEBUSY request. The result=20 will contain one or more iCalendar components (one for each TARGET)=20 containing the VFREEBUSY response enclosed in a "VREPLY".=20 How a CS derives the response is an issue for the CS and not the CUA. To formulate the VFREEBUSY response the CS may need to derive the information from several sources depending on CS characteristics: (1) from VEVENTs that overlap the search period and having=20 TRANSP=3DOPAQUE or TRANSP=3DOPAQUE-NOCONFLICT; (2) if the CS has RECUR-EXPAND=3DTRUE, it should expand VEVENTs and=20 include instances which overlap the search period and have TRANSP=3DOPAQUE or TRANSP=3DOPAQUE-NOCONFLICT; (3) if the CS supports "Booked" VFREEBUSY objects, it must examine the FREEBUSY properties from these objects and include those that overlap the search period. After gathering the relevent FREEBUSY time periods, the CS SHOULD 'normalize' the FREEBUSY information as specified by iTIP (i.e.=20 remove duplicate busy time periods, ordering, etc.) The following is an example of request for free-busy information for=20 the week of August 4, 2003, 8:00am thru August 8, 2003, 5:00pm (gmt): C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//Prodid C: CMD:SEARCH C: TARGET:usera C: TARGET:userb C: BEGIN:VFREEBUSY C: DTSTART:20030804T080000Z C: DTEND:20030808T170000Z C: ORGANIZER:CAP://acme.com/UserX C: ATTENDEE:CAP://acme.com/usera C: ATTENDEE:CAP://acme.com/userb C: DTSTAMP:20031002T153207Z C: UID://acme.com/0001000300450 C: END:VFREEBUSY C: END:VCALENDAR S: BEGIN:VCALENDAR S: VERSION:2.0 S: PRODID:-//Some Calendar Store S: CMD;ID=3DFB001:REPLY S: TARGET:userA S: BEGIN:VREPLY S: BEGIN:VFREEBUSY S: ORGANIZER:CAP://acme.com/UserX S: ATTENDEE:CAP://acme.com/usera S: UID://acme.com/0001000300450 S: DTSTART:20030804T080000Z S: DTEND:20030808T170000Z S: DTSTAMP:20030710T131103Z S: FREEBUSY:20030805T100000Z/20030805T110000Z S: FREEBUSY:20030805T140000Z/20030805T150000Z S: END:VFREEBUSY S: END:VREPLY S: END:VCALENDAR S: BEGIN:VCALENDAR S: VERSION:2.0 S: PRODID:-//Some Calendar Store S: CMD;ID=3DFB001:REPLY S: TARGET:userB S: BEGIN:VREPLY S: BEGIN:VFREEBUSY S: ORGANIZER:CAP://acme.com/UserX S: ATTENDEE:CAP://acme.com/userb S: UID://acme.com/0001000300450 S: DTSTART:20030804T080000Z S: DTEND:20030808T170000Z S: DTSTAMP:20030710T131103Z S: FREEBUSY:20030806T130000Z/20030805T150000Z S: END:VFREEBUSY S: END:VREPLY S: END:VCALENDAR ---------------------- C Johnson ------=_NextPart_000_002F_01C388A7.0C2408F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bruce wrote (listing unresolved issues):
> 1: Busytime in CAP
 
Doug wrote:
> So what's the issue?
 
Bruce wrote
> This was originally raised back ~ 31-Mar-2003 and briefly = revisited in=20 late july
>  ...
>  ... I can find NOTHING in CAP that actually = "specifies how=20 to
> search for available busy time information"
 
Doug wrote:
> How about the entire section named: "10.12.1 Searching for = VFREEBUSY"=20 ?
 
Now I write:
 
The current CAP spec (12e), including section 10.12.1, does not = reflect the=20 central issue and outcome of the VFREEBUSY discussion in late July = referred to=20 by Bruce.  Specifically: that a search for available busy time = information=20 can, and preferably should, be accomplished using a VFREEBUSY = request (as=20 in iTIP).  For example, the following was proposed in that=20 discussion:

C: BEGIN:VCALENDAR
C: VERSION:2.0
C: = PRODID:-//Prodid
C: CMD:SEARCH
C: TARGET:usera
C: = TARGET:userb
C:=20 BEGIN:VFREEBUSY
C: DTSTART:startrange
C: DTEND:endrange
C:=20 ORGANIZER:...
C: ATTENDEE:...
C: ATTENDEE:...
C: = DTSTAMP:...
C:=20 UID:...
C: END:VFREEBUSY
C: END:VCALENDAR

The example uses the SEARCH command with = an iTIP=20 VFREEBUSY to make the request. The advantages/benefits are:
* It = creates=20 consistency and continuity between the WG standards for making a = free-busy=20 requests.
* It makes life easier and more consistent on both sides of = the=20 wire:
* It makes it easier for CUAs because there is only one way the = CUA must formulate a search that works for both iMIP and CAP = recipients=20 (not a scheme for iMIP and a different scheme for CAP). The CUA = formulates the=20 "VFREEBUSY search" not caring if it is intended for recipients via CAP, = or iMIP=20 or some other mechanism.
* A Calendar Store would use the same code = to=20 respond to the VFREEBUSY search request regardless of whether it came = via CAP or=20 iMIP. Again, consistency and continuity! (Calendar Stores that support = iTIP very=20 likely have code to handle VFREEBUSY requests. Adapting that code = for CAP=20 is relatively simple.)
* Using a VFREEBUSY request is a more straightforward,=20 consistent, stable, and established method for CUAs to rely on = than=20 other proposed methods (e.g. VQUERY).

<<Begin:Digression
Rather than using the SEARCH command (as shown above) somewhere (in = the=20 July discussion) it was suggested that we modify CAP's iTIP behavior to=20 accommodate this VFREEBUSY search. Specifically: using CMD:CREATE with=20 METHOD:REQUEST as follows:

C:=20 BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Prodid
C: = CMD:CREATE
C:=20 METHOD:REQUEST
C: TARGET:usera
C: TARGET:userb
C: = BEGIN:VFREEBUSY
C:=20 DTSTART:startrange
C: DTEND:endrange
C: ORGANIZER:...
C:=20 ATTENDEE:...
C: ATTENDEE:...
C: DTSTAMP:...
C: = UID:...
C: END:VFREEBUSY
C:=20 END:VCALENDAR

Normally, when=20 CMD:CREATE - METHOD:REQUEST is used with a calendar object (VEVENT, = VTODO,=20 etc.), the CS stores the object in the "UNPROCESSED" state and replies = with a=20 successful REQUEST-STATUS to the CUA (basically saying: "I got it"). It = was=20 argued that an implementation which did this for a "VFREEBUSY search" = implies=20 some degree of latency in the free-busy search process... which is not = good...=20 so, instead, the CS should reply with the VFREEBUSY results instead of = just an=20 "I got it" ... and this would be the way CAP does a real-time = request/response=20 for free-busy information. I capitulated to this idea [but I have since = become=20 increasingly uncomfortable with this compromise along with some others = mentioned=20 in section 10.12.1.  But that=92s for another thread].
End:Digression>>

Nevertheless, there is = nothing in the=20 spec from that discussion about using VFREEBUSY to do a free-busy = search.

So,=20 here is my updated proposal, with ABNF, that defines how to perform a = search for=20 free-busy information via the SEARCH command. It goes in section 10.12 = "SEARCH=20 Command."

[[[ the following ABNF goes after the = ABNF on page=20 122]]]

ABNF=20 for a "SEARCH" object is:

search-object =3D=20 "BEGIN" ":" "VCALENDAR"=20 CRLF
           = ;  =20 ;
           &n= bsp; =20 ; calprops MUST include=20 'search-cmd'
         &nb= sp;    ;
       = ;        =20 calprops
          &= nbsp;    =20 other-props
         &nbs= p;     =20 1*(search-comp)
         =       =20 "END" ":" "VCALENDAR" CRLF

search-comp   =3D queryc / = freebusyc
          =      =20 / iana-comp / x-component

freebusyc     = =3D (as=20 defined in iTIP)

[[[the following is a revised = paragraph=20 following the ABNF for searchparam on p 122]]]

The format of the request is the search = command=20 (search-cmd) followed
by one or more (queryc) "VQUERY" components or=20 (freebusyc) VFREEBUSY
components.

[[[the following goes somewhere in = section 10.12=20 or 10.12.1]]]

When VFREEBUSY is used with = the SEARCH=20 command the CS should return
free-busy information defined by the = VFREEBUSY=20 request. The result
will contain one or more iCalendar components = (one for=20 each TARGET)
containing the VFREEBUSY response enclosed in a = "VREPLY".=20

How a CS derives the = response is=20 an issue for the CS and not the CUA.
To formulate the VFREEBUSY = response the=20 CS may need to derive the
information from several sources depending = on CS=20 characteristics:
 (1) from VEVENTs that overlap the search = period and=20 having 
     = TRANSP=3DOPAQUE or=20 TRANSP=3DOPAQUE-NOCONFLICT;
 (2) if the CS has = RECUR-EXPAND=3DTRUE, it=20 should expand VEVENTs and
     include instances = which=20 overlap the search period and
     have=20 TRANSP=3DOPAQUE or TRANSP=3DOPAQUE-NOCONFLICT;
 (3) if the CS = supports=20 "Booked" VFREEBUSY objects, it must examine
     = the=20 FREEBUSY properties from these objects and include=20 those
     that overlap the search = period.
After gathering the = relevent FREEBUSY=20 time periods, the CS SHOULD
'normalize' the FREEBUSY = information=20 as specified by iTIP (i.e.=20
remove duplicate busy = time periods,=20 ordering, etc.)
The following is an example of = request for=20 free-busy information for
the week of August 4, 2003, 8:00am thru = August 8,=20 2003, 5:00pm (gmt):

C: BEGIN:VCALENDAR
C:=20 VERSION:2.0
C: PRODID:-//Prodid
C: CMD:SEARCH
C: = TARGET:usera
C:=20 TARGET:userb
C: BEGIN:VFREEBUSY
C: DTSTART:20030804T080000Z
C:=20 DTEND:20030808T170000Z
C: ORGANIZER:CAP://acme.com/UserX
C:=20 ATTENDEE:CAP://acme.com/usera
C: ATTENDEE:CAP://acme.com/userb
C:=20 DTSTAMP:20031002T153207Z
C: UID://acme.com/0001000300450
C:=20 END:VFREEBUSY
C: END:VCALENDAR

S: BEGIN:VCALENDAR
S: VERSION:2.0
S: = PRODID:-//Some=20 Calendar Store
S: CMD;ID=3DFB001:REPLY
S: TARGET:userA
S:=20 BEGIN:VREPLY
S: BEGIN:VFREEBUSY
S: = ORGANIZER:CAP://acme.com/UserX
S:=20 ATTENDEE:CAP://acme.com/usera
S: UID://acme.com/0001000300450
S:=20 DTSTART:20030804T080000Z
S: DTEND:20030808T170000Z
S:=20 DTSTAMP:20030710T131103Z
S: = FREEBUSY:20030805T100000Z/20030805T110000Z
S:=20 FREEBUSY:20030805T140000Z/20030805T150000Z
S: END:VFREEBUSY
S:=20 END:VREPLY
S: END:VCALENDAR

S:=20 BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//Some Calendar = Store
S:=20 CMD;ID=3DFB001:REPLY
S: TARGET:userB
S: BEGIN:VREPLY
S:=20 BEGIN:VFREEBUSY
S: ORGANIZER:CAP://acme.com/UserX
S:=20 ATTENDEE:CAP://acme.com/userb
S: UID://acme.com/0001000300450
S:=20 DTSTART:20030804T080000Z
S: DTEND:20030808T170000Z
S:=20 DTSTAMP:20030710T131103Z
S: = FREEBUSY:20030806T130000Z/20030805T150000Z
S:=20 END:VFREEBUSY
S: END:VREPLY
S:=20 END:VCALENDAR

----------------------
C Johnson
------=_NextPart_000_002F_01C388A7.0C2408F0-- From owner-ietf-calendar@mail.imc.org Thu Oct 2 11:43:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27497 for ; Thu, 2 Oct 2003 11:43:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92FS1KP000518 for ; Thu, 2 Oct 2003 08:28:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92FS1gS000517 for ietf-calendar-bks; Thu, 2 Oct 2003 08:28:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92FS0KP000512 for ; Thu, 2 Oct 2003 08:28:00 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F7B5474.B8FD4F96@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: When to publish -12 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_09102003NP September 10, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 2 Oct 2003 11:19:02 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/02/2003 11:27:46 AM, Serialize complete at 10/02/2003 11:27:46 AM Content-Type: multipart/alternative; boundary="=_alternative 00540D0785256DB3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00540D0785256DB3_= Content-Type: text/plain; charset="US-ASCII" Mark replied on 10/01/2003 06:25:56 PM: > > In searching CAP-12-e I find the word 'busy' only mentioned in the > > text above, as part of a response comment in Section 8.28 > > REQUEST-STATUS property and then in some text in Section 8.37 TRANSP > > Property but no actual specification I can find. Perhaps Im just > > missing it..?? > > See pages 124-125 Thanks for the poniter. Perhaps it is just a labeling thing now, perhaps not. You are referring to Section 10.12.1 Searching for VFREEBUSY yes? Thats actually on pages 125-126, at least in the TXT version. May I suggest we retitle Section 10.12.1 to be "Searching for busy time" since that makes finding it easier when just searching for phrases like "busy time" (to match the text in the ? This section is better than what we had before (which was nothing really) but its not complete or what I would consider totally correct (a different matter for discussion though). For example the text in 12-e says: If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the "VFREEBUSY" component in the "COMPONENTS" value in a reply to the "GET-CAPABILITY" command, then it is the CS's responsibility and not the CUA's responsibility to provide the correct "VFREEBUSY" information for a calendar. Therefore, Umm, where is the rest of the last sentence? Did it get cut off by the XML Conversion tool or was the thought not finished? Ill read this section over and create a new thread for it accordingly since I see some other things to comment on. Thanks again for the pointer. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00540D0785256DB3_= Content-Type: text/html; charset="US-ASCII"
Mark replied on 10/01/2003 06:25:56 PM:
> > In searching CAP-12-e I find the word 'busy' only mentioned in the
> > text above, as part of a response comment in Section 8.28
> > REQUEST-STATUS property and then in some text in Section 8.37 TRANSP
> > Property but no actual specification I can find.  Perhaps Im just
> > missing it..??
>
> See pages 124-125
Thanks for the poniter.  Perhaps it is just a labeling thing now, perhaps not.  You are referring to Section 10.12.1 Searching for VFREEBUSY yes?  Thats actually on pages 125-126, at least in the TXT version.  

May I suggest we retitle Section 10.12.1 to be "Searching for busy time" since that makes finding it easier when just searching for phrases like "busy time" (to match the text in the ?  

This section is better than what we had before (which was nothing really) but its not complete or what I would consider totally correct (a different matter for discussion though).  For example the text in 12-e says:

   If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the
   "VFREEBUSY" component in the "COMPONENTS" value in a reply to the
   "GET-CAPABILITY" command, then it is the CS's responsibility and not
   the CUA's responsibility to provide the correct "VFREEBUSY"
   information for a calendar.  Therefore,

Umm, where is the rest of the last sentence?  Did it get cut off by the XML Conversion tool or was the thought not finished?

Ill read this section over and create a new thread for it accordingly since I see some other things to comment on.  Thanks again for the pointer.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00540D0785256DB3_=-- From owner-ietf-calendar@mail.imc.org Thu Oct 2 14:03:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17044 for ; Thu, 2 Oct 2003 14:03:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92HiBKP006536 for ; Thu, 2 Oct 2003 10:44:11 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92HiBE7006535 for ietf-calendar-bks; Thu, 2 Oct 2003 10:44:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Hi9KP006530 for ; Thu, 2 Oct 2003 10:44:09 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h92Hi8mL030513 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 2 Oct 2003 10:44:09 -0700 Message-ID: <3F7C63E2.7020002@Royer.com> Date: Thu, 02 Oct 2003 11:44:02 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: When to publish -12 - VFREEBUSY References: <003201c388d9$574200d0$0200000a@hp1> In-Reply-To: <003201c388d9$574200d0$0200000a@hp1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040203080503000905010405" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040203080503000905010405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Craig Johnson wrote: > > The current CAP spec (12e), including section 10.12.1, does not > reflect the central issue and outcome of the VFREEBUSY discussion in > late July referred to by Bruce. Specifically: that a search for > available busy time information can, and preferably should, be > accomplished using a VFREEBUSY request (as in iTIP). For example, the > following was proposed in that discussion: > ... > > The example uses the SEARCH command with an iTIP VFREEBUSY to make the > request. The advantages/benefits are: > * It creates consistency and continuity between the WG standards for > making a free-busy requests. > * It makes life easier and more consistent on both sides of the wire: > * It makes it easier for CUAs because there is only one way the > CUA must formulate a search that works for both iMIP and CAP > recipients (not a scheme for iMIP and a different scheme for CAP). The > CUA formulates the "VFREEBUSY search" not caring if it is intended for > recipients via CAP, or iMIP or some other mechanism. Currently - Pre-CAP: (a.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA responds and the CU MAY be in the loop. (a.2)There is NO VFREEBUSY/CREATE in iMIP so the CUA will never see those. In CAP-12-e: (b.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA responds and the CU MAY be in the loop. VFREEBUSY/REQUEST processed exactly like pre-CAP -- by the CUA. (b.2) There is still NO VFREEBUSY/CREATE in iMIP. (b.3) If CS has RECUR-EXPAND:TRUE : (VFREEBUSY/REQUEST) New but reacts the same way to VFREEBUSY/REQUEST as currently done pre-CAP: The CUA may find a VFREEBUSY/REQUEST in the CS that was deposited by another CUA and the CUA responds and the CU MAY be in the loop. Just another way a CUA can process a request that may have originally been an iMIP request. Same latency issue as pre-CAP - allows CU in the loop. VFREEBUSY/REQUET processed exactly like pre-CAP - by the CUA. And there is consistency with all other iTIP methods, they are stored in the UNPROCESSED state until acted upon by a CUA. (b.4) If CS has RECUR-EXPAND:FALSE : : (VFREEBUSY/REQUEST) New but reacts the same way to VFREEBUSY/REQUEST as currently done pre-CAP: The CUA may find a VFREEBUSY/REQUEST in the CS that was deposited by another CUA and the CUA responds and the CU MAY be in the loop. Just another way a CUA can process a request that may have originally been an iMIP request. Same latency issue as pre-CAP - allows CU in the loop. VFREEBUSY/REQUET processed exactly like pre-CAP - by the CUA. And there is consistency with all other iTIP methods, they are stored in the UNPROCESSED state until acted upon by a CUA. (b.5) If the CS has RECUR-EXPAND:TRUE : (VFREEBUSY/CREATE) As the VFREEBUSY REPLY components are created dynamically these are useless and have no value and will never be used so they should be tossed. (b.6) If the CS has RECUR-EXPAND:FALSE : (VFREEBUSY/CREATE) As the VFREEBUSY REPLY components are computed based on the stored values, they will be used in the SEARCH results. (b.7) For CS with RECUR-EXPAND:TRUE (SEARCH) The CUA gets auto generated VFREEBUSY/REPLY. (b.8) For CS with RECUR-EXPAND:TRUE (SEARCH) The CUA gets computed results from previously stored VFREBUSY/CREATE components or if none were stored the results are the same as no busy time. I *think* you are proposing: (c.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA responds and the CU MAY be in the loop. (c.2) There is still NO VFREEBUSY/CREATE in iMIP. (c.3) If CS has RECUR-EXPAND:TRUE : (VFREEBUSY/REQUEST) The are auto processed by the CS. VFREEBUSY/REQUET NOT processed exactly like pre-CAP so the CU can not be in the loop. And there is NOT consistency with all other iTIP methods, they are not stored and never acted upon by a CUA. (c.4) If CS has RECUR-EXPAND:FALSE : : (VFREEBUSY/REQUEST) (c.5) If the CS has RECUR-EXPAND:TRUE : (VFREEBUSY/CREATE) (c.6) If the CS has RECUR-EXPAND:FALSE : (VFREEBUSY/CREATE) Looks as if you proposing that you can never search for VFREEBUSY? If so, you just broke RECUR-EXPAND:FALSE CSs. (c.7) For CS with RECUR-EXPAND:TRUE (SEARCH) I think you are saying do not allow. (c.8) For CS with RECUR-EXPAND:TRUE (SEARCH) I think you are saying do not allow. > > * A Calendar Store would use the same code to respond to the VFREEBUSY > search request regardless of whether it came via CAP or iMIP. Again, > consistency and continuity! (Calendar Stores that support iTIP very > likely have code to handle VFREEBUSY requests. Adapting that code for > CAP is relatively simple.) Except that is not how iMIP requests are always processed, so it is introducing an inconsistency. > * Using a VFREEBUSY request is a more straightforward, > consistent, stable, and established method for CUAs to rely on than > other proposed methods (e.g. VQUERY). As pointed out above, your proposal is currently incomplete, breaks EXPAND-RECUR:FALSE CSs and treats some iTIP objects inconsistently with other iTIP objects in CAP. The process described in 12-e allows for exactly the same as pre-CAP processing (with CU/CUA intervention when wanted and its associated latency). (REQUEST/REPLY) Plus the process described in 12-e allows for latency free replies. (CREATE/SEARCH). It looks to me as if you want to remove the ability for the CU to process some REQUEST/REPLY operations, and I see no new feature you are proposing. Perhaps if you address issues above c.4, c.5, c.6, c.7, c.8 and why you want to disallow the CU in the loop I'll understand why you think this is an improvement. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040203080503000905010405 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 9w0BCQUxDxcNMDMxMDAyMTc0NDAzWjAjBgkqhkiG9w0BCQQxFgQUYl7UWKPltlsjzXKt2hgq CSqCe2gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAZ4ENe20u4MZBKAMEDdFhd1o246foahhr609hIxpIE4T/Oy4F5EXv/yaqMMLll8Oq n3NxN3LZDZ8dQwLKPu6rLd5FiU0VUPCR//WKpyha0hxX2HxeBYfTcmCtgT0GaCDwWrjKz4lF tDK/a53GbDSi1Hi1SfpmpZGzatUWk9BsvBxVdmhAO9soe+FzSgaq5HNeYsVoL+L+5QooaG88 FR8iTFm6n5MCFjL8l5rFAIe9MgIA3J33RqQaIlve9wIquVCmDuYPhseBMWy7ukTt2ChjtiUq kTGo40aZ8KRc3fNLE87z4OYxtWs9t/WEvmETv+cInGjsrOpjM8trUFQ34TKJ6wAAAAAAAA== --------------ms040203080503000905010405-- From owner-ietf-calendar@mail.imc.org Thu Oct 2 14:05:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17184 for ; Thu, 2 Oct 2003 14:05:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Hn0KP006840 for ; Thu, 2 Oct 2003 10:49:00 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92Hn0CA006838 for ietf-calendar-bks; Thu, 2 Oct 2003 10:49:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92HmxKP006833 for ; Thu, 2 Oct 2003 10:48:59 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h92HmxmL030555 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 2 Oct 2003 10:49:00 -0700 Message-ID: <3F7C6505.9060107@Royer.com> Date: Thu, 02 Oct 2003 11:48:53 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: When to publish -12 References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070509040506030806000408" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070509040506030806000408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the > "VFREEBUSY" component in the "COMPONENTS" value in a reply to the > "GET-CAPABILITY" command, then it is the CS's responsibility and not > the CUA's responsibility to provide the correct "VFREEBUSY" > information for a calendar. Therefore, > > Umm, where is the rest of the last sentence? Did it get cut off by > the XML Conversion tool or was the thought not finished? 'Therefore,' - removed. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070509040506030806000408 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 9w0BCQUxDxcNMDMxMDAyMTc0ODUzWjAjBgkqhkiG9w0BCQQxFgQUGl+a6/UPZj5mdBL0qr+s iwOYHXgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAtdBdT3GXhZORAVaQaPy8s+PDDzzIHVfo9HWc7WKjR4p4yDBWt29rS8JMb5eZ7TOi YvfSdDLv+FBGXybYwFjWZ6p4ZbSzI5Jza2FfGY8Xo3Lsz7EkjBKG/Ub6W8I6W+Xv+tjQWQRG J5M/dV+IhLoTlOTAiB/LUX6FVTLBSsdaX+3F87NpCibupn+HhXzTp5VCODjwAKcG2cRFHyt+ F5xrSKLj1Quscx7tMrdbfkQSB/tBT2WQxE+vTiqVB7zSUBtjlB6kVTYX2Joedbr9Sud/2m1z L9fPG4YI7mvKmpqZgKt79P37rPEOXMfO0RGjvYV9+g6pAlXi3Hh+Kspi2EGqbgAAAAAAAA== --------------ms070509040506030806000408-- From owner-ietf-calendar@mail.imc.org Thu Oct 2 14:28:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18597 for ; Thu, 2 Oct 2003 14:28:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92IBrKP008097 for ; Thu, 2 Oct 2003 11:11:53 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92IBrhq008096 for ietf-calendar-bks; Thu, 2 Oct 2003 11:11: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.9/8.12.8) with ESMTP id h92IBqKP008091 for ; Thu, 2 Oct 2003 11:11:52 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h92IBnmL030793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 2 Oct 2003 11:11:51 -0700 Message-ID: <3F7C6A60.2060203@Royer.com> Date: Thu, 02 Oct 2003 12:11:44 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-calsch-dynamic-upn-02.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090807050400050202090003" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090807050400050202090003 Content-Type: multipart/mixed; boundary="------------080709090706060303040405" This is a multi-part message in MIME format. --------------080709090706060303040405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : How to create dynamic UPNs for invited ATTENDEEs Author(s) : D. Royer Filename : draft-royer-calsch-dynamic-upn-02.txt Pages : 12 Date : 2003-10-2 This is an extension to the [CAP] protocol and can be used within [iTIP] objects. A CU may wish to invite a UPN to an event where the UPN does not have a account on the CU's CS. This memo describes two methods to dynamically create UPNs in order for those UPNs to gain access to the 'Organizers' CS. This memo also includes a description of how to include an [OTP] challenge in an object directed to a CU. The CUA must compute the password in order to respond to the object. This challenge and its response can be sent in the clear as the values are computed using a secret that would not be known to anyone snooping the line. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-calsch-dynamic-upn-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-calsch-dynamic-upn-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-calsch-dynamic-upn-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------080709090706060303040405 Content-Type: Message/External-body; name="draft-royer-calsch-dynamic-upn-02.txt" Content-Disposition: inline; filename="draft-royer-calsch-dynamic-upn-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-2105737.I-D@ietf.org> --------------080709090706060303040405-- --------------ms090807050400050202090003 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 9w0BCQUxDxcNMDMxMDAyMTgxMTQ0WjAjBgkqhkiG9w0BCQQxFgQUFCcyqS22cNs7qNZJBY2E GFm7ObwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAgeK1A2hBjIQrzc0J0lVzyS5rUALpNn+PM73bYvsACF9ulhmPZheqlFyD4kizMe3F 2M7LdrdV810x3hEiQsBgcrlzIXjBJrhLQQFfc3znXjreRw6+5Fzxg8PIwvgo+F6r/CJqipLc RXgyzZcg5+1c8ec6daQ9CghLWlj8Rsus5EIEb6icZgjE81o1fc7jyYcJGFgNMg2pzkQ0KSlA Ods2pGm0ymAyocT70RSZGMxi5+40xK9VElgX5jkmXCXDTe3C4ovUuLEIg1jCTPzoo1QyX/mI L9pUYS400oJt5HaQ62OpXIE1gKQqP43RjQ3xHTBeKiUR/NvJwwN4xun/pJd60wAAAAAAAA== --------------ms090807050400050202090003-- From owner-ietf-calendar@mail.imc.org Thu Oct 2 14:31:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18764 for ; Thu, 2 Oct 2003 14:31:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92ICPKP008117 for ; Thu, 2 Oct 2003 11:12:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92ICPAf008116 for ietf-calendar-bks; Thu, 2 Oct 2003 11:12:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92ICNKP008108 for ; Thu, 2 Oct 2003 11:12:23 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h92ICKmL030798 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 2 Oct 2003 11:12:24 -0700 Message-ID: <3F7C6A7F.1030208@Royer.com> Date: Thu, 02 Oct 2003 12:12:15 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-cap-notify-02.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060105060102030804080007" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060105060102030804080007 Content-Type: multipart/mixed; boundary="------------090102080803070602050107" This is a multi-part message in MIME format. --------------090102080803070602050107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : iCalendar notification of upcoming VEVENTs, VTODOs, VALARMs or any changes Author(s) : D. Royer Filename : draft-royer-cap-notify-02.txt Pages : 11 Date : 2003-10-2 This memo describes a method used to ask for and receive notifications. These notifications will be the direct result of a stored components and the notifications or changes to components or the store and are represented in iCalendar format. This is an extensions to iCalendar objects. This memo has been updated to include non-CAP notificaitons. This memo includes a new CAP command types of 'REQUEST-NOTIFY', 'NOTIFICATION', and 'CANCEL-NOTIFY', a new property of 'OBSERVER', a new iCalendar component 'NOTIFICATION', CAP capabilities of 'CAN-NOTIFY', 'NOTIFY-UPDATES', and 'ALLOW-NOTIFY-BOT'. A 'REQUEST-NOTIFY' command is a request to add an observer to an component in the 'TARGET' calendar. In addition the 'REQUEST-NOTIFY' command can alert the CUA of changes to specific components or in the calendar or calendar store. Everything is subject to VCAR restrictions. These are asynchronous notifications must be advertised by the CS and requested by the CUA. This memo discusses how to transport these iCalendar objects and using them with CAP. In addition if the CS and CUA support the 'NOTIFY-UPDATES' capability, then the CS will send 'NOTIFICATION' components to the CUA describing the UIDs or TARGETS that have changed since the currently authenticated CU was last connected allowing for easier synchronization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-cap-notify-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-cap-notify-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-cap-notify-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------090102080803070602050107 Content-Type: Message/External-body; name="draft-royer-cap-notify-02.txt" Content-Disposition: inline; filename="draft-royer-cap-notify-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-2105748.I-D@ietf.org> --------------090102080803070602050107-- --------------ms060105060102030804080007 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 9w0BCQUxDxcNMDMxMDAyMTgxMjE1WjAjBgkqhkiG9w0BCQQxFgQUKDd1exv6tWebWpF7AcBn zanvXrswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA0vDsgiIF+DvooNdfewyPeYl58R1+6sVHNtVwYCAsQ7gRhrvN8wn+HHPS7nMZkBv0 pGCXU+Ur3OSgdBRYMEGqKj9E/JZFg91Z1gQFlNKKN7Y3K/nVZKl+d43Kxvq/vtctL2LdanxN 0K+lKW0wHDGybS9TRscnykR46KeOaBu8ZAGDsC/GDf36jLpVrqknKUgqv+Hry+3RypvOtSDe CcKRxXImfVlJmkVLhMBWOO4vlBG8fZkSEXpnNNHCuTjZfplq+pVYs4Klzez9sngGZCQoEemp 2EY7oY5JWimLNrOHAPasJuHTzZ0C02QBH/NLgnogLCZ22J0HJtxzDWgNwqr61gAAAAAAAA== --------------ms060105060102030804080007-- From owner-ietf-calendar@mail.imc.org Thu Oct 2 18:29:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29073 for ; Thu, 2 Oct 2003 18:29:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92M3FKP016785 for ; Thu, 2 Oct 2003 15:03:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92M3Fji016784 for ietf-calendar-bks; Thu, 2 Oct 2003 15:03:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from gw.provo.novell.com (gw.provo.novell.com [137.65.47.29]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92M3EKP016779 for ; Thu, 2 Oct 2003 15:03:14 -0700 (PDT) (envelope-from cjohnson@gw.novell.com) Received: from PROVO7-MTA by gw.provo.novell.com with Novell_GroupWise; Thu, 02 Oct 2003 16:02:36 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Thu, 02 Oct 2003 16:04:20 -0600 From: "Craig Johnson" To: Subject: Re: When to publish -12 - VFREEBUSY Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part7F2131F4.0__=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=__Part7F2131F4.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Doug, It will take awhile to digest the notes and details in your last post... and give you a response. In the meantime, it would be helpful to understand where you are at with a fundamental issue. Would you please respond to a couple of questions... One of the results of the previous discussion thread (in July) was that CAP should support the use of the VFREEBUSY object to obtain free-busy information. (Let's not haggle here whether its done with a SEARCH command, a CMD:CREATE -METHOD:REQUEST, or some other command.) Do you still agree or do you now disagree with that outcome? If you agree, where is this found in the CAP spec? If you disagree . . . why? C Johnson --=__Part7F2131F4.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
Doug,
 
It will take awhile to digest the notes and details in your = last post... and give you a response.  In the meantime, it would = be helpful to understand where you are at with a fundamental issue. &n= bsp;Would you please respond to a couple of questions...
 
One of the results of the previous discussion thread (in = July) was that CAP should support the use of the VFREEBUSY = object to obtain free-busy information.  (Let's not haggle = here whether its done with a SEARCH command, a CMD:CREATE = -METHOD:REQUEST, or some other command.) 
 
Do you still agree or do you now disagree with that outcome?
 
If you agree, where is this found in the CAP spec?
 
If you disagree . . .  why?
 
C Johnson
--=__Part7F2131F4.0__=-- From owner-ietf-calendar@mail.imc.org Thu Oct 2 19:29:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00666 for ; Thu, 2 Oct 2003 19:29:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92NCcKP019500 for ; Thu, 2 Oct 2003 16:12:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92NCcC2019498 for ietf-calendar-bks; Thu, 2 Oct 2003 16:12:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92NCaKP019488 for ; Thu, 2 Oct 2003 16:12:37 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h92NCbmL000936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 2 Oct 2003 16:12:38 -0700 Message-ID: <3F7CB0DF.9030501@Royer.com> Date: Thu, 02 Oct 2003 17:12:31 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - VFREEBUSY References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090802050908030102060909" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090802050908030102060909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Craig Johnson wrote: > ...where is this found in the CAP spec? Section 10.12.1 describes how the CUA gets dynamic VFREEBUSY information. The email post describes the side effects of that section. The rest of CAP describes as you have pointed out that iTIP methods are stored UNPROCESSED. And -- An error in my previous post in b.8 and c.8 where they should be RECUR-EXPAND:FALSE not TRUE. I should have said: (b.8) For CS with RECUR-EXPAND:FALSE (SEARCH) (c.8) For CS with RECUR-EXPAND:FALSE (SEARCH) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090802050908030102060909 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 9w0BCQUxDxcNMDMxMDAyMjMxMjMxWjAjBgkqhkiG9w0BCQQxFgQUzKFHCl0U8USbhbstWrKv bvG28bMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAUkj4cKOVt6L0ltjVL67vACMuQR8OtWwmINzAXdjxvR3athXQpkWnkoGep8+ovYjJ BOz01pCvRVYNOVAxNPTsAZIygIsUvHW9tdimXmgkb90qgbDM8AHcTs1hZvIGFfkh+T6qh+Cg tFARumu5njEeiZd1W0d/Ec0dG7DbZnzGARoy3d3+RBvrkYd6/JSEgtPS27Ec5Bok55yOM37M +tOmiBTI/E3nz19+R3AVSyflhHlzYLLxXwKvT5Rl3WomDYMhUFt2GZHRWLw3b0/LdigrkI+e QmD9Hn3tHh9mQvJZgzjxxQ043uNkXOYtYueRWL9WpQTb4bJR3UC9akiJmT9lsAAAAAAAAA== --------------ms090802050908030102060909-- From owner-ietf-calendar@mail.imc.org Mon Oct 6 14:10:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15260 for ; Mon, 6 Oct 2003 14:10:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HwKKP063670 for ; Mon, 6 Oct 2003 10:58:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96HwK3q063669 for ietf-calendar-bks; Mon, 6 Oct 2003 10:58:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HwIKP063663 for ; Mon, 6 Oct 2003 10:58:19 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h96HwGmL028333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 6 Oct 2003 10:58:18 -0700 Message-ID: <3F81AD32.7040405@Royer.com> Date: Mon, 06 Oct 2003 11:58:10 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-ical-vcard-01.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040909080209020002040708" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040909080209020002040708 Content-Type: multipart/mixed; boundary="------------060803000905050705030902" This is a multi-part message in MIME format. --------------060803000905050705030902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI ------------------------------------------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using VCARDs with iCalendar Author(s) : D. Royer Filename : draft-royer-ical-vcard-01.txt Pages : 6 Date : 2003-10-6 This memo is a registration of a [iCAL] component called 'VCARD'. And defines that the 'VCARD' component as the 'vcard entity' object as defined in [vCARD] and [LDAPVCARD]. This memo describes a way to include contact information in [iCAL] objects. The contact information is included by the insertion of [vCARD] objects into [iCAL] objects. Also included is an extension to [LDAPVCARD] to allow [CAP] URLs. This memo does not define [iCAL] or [vCARD] objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-ical-vcard-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-ical-vcard-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-ical-vcard-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------060803000905050705030902 Content-Type: Message/External-body; name="draft-royer-ical-vcard-01.txt" Content-Disposition: inline; filename="draft-royer-ical-vcard-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-6113621.I-D@ietf.org> --------------060803000905050705030902-- --------------ms040909080209020002040708 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 9w0BCQUxDxcNMDMxMDA2MTc1ODExWjAjBgkqhkiG9w0BCQQxFgQUzuw5M5rTeDOTNhl1CP7W nXA+0mAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAwTgkHyntUg6g10o1sbWuJjHNY0dKT0789gmVvOw/3NO4j4CxeAZmKPl3ggF/NUEK Drn25ZhNUtd3TSlwW+Cam0whzkB/cxmmPxNvihuyhofSkuTHbTmYLTq/vfvFNy5QXFdqqHwn mvJlpe2pzO4VCb6sTf46ilO4mTAauQxaeTgfDCbf1mAvxF5sLphZ+Ye5ZLRuuhya4+hRwnPR X94CV28hUqd5i/qLn47TC2o0YCFPzBchXbSdhvdgGXkNqtmLxl+pFA/0Pe6FY4vBQjd3CLx2 GGS7je7EhSDhRgwkkthRm9Uq1r8NN3anEjyUXIufF2AmkGB/0C7pPP8eoSU14gAAAAAAAA== --------------ms040909080209020002040708-- From owner-ietf-calendar@mail.imc.org Mon Oct 6 14:12:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15394 for ; Mon, 6 Oct 2003 14:12:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96Hv4KP063635 for ; Mon, 6 Oct 2003 10:57:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96Hv4Kc063634 for ietf-calendar-bks; Mon, 6 Oct 2003 10:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96Hv2KP063624 for ; Mon, 6 Oct 2003 10:57:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h96Hv1mL028326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 6 Oct 2003 10:57:02 -0700 Message-ID: <3F81ACE4.6050709@Royer.com> Date: Mon, 06 Oct 2003 11:56:52 -0600 From: Doug Royer Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-cap-sort-02.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020308030603020406090102" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020308030603020406090102 Content-Type: multipart/mixed; boundary="------------040102050608060905080104" This is a multi-part message in MIME format. --------------040102050608060905080104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI ================= A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CAP (Calendar Access Protocol) sorting extension Author(s) : D. Royer Filename : draft-royer-cap-sort-02.txt Pages : 13 Date : 2003-10-6 Small devices may not have sufficient memory to store and then sort query results from a CAP server. This memo suggests an expendable CAP CAPABILITY extension called 'CAP-SORT' and a new parameters 'SORT' and 'LOCALE'. This memo specifies an optional minimum sort order and and locale sort extension. These extensions will only effect CUA's that have specifically requested these extensions be used in the session or for specific queries. The reader should be familiar with the CAP protocol prior to reading this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-cap-sort-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-cap-sort-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-cap-sort-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------040102050608060905080104 Content-Type: Message/External-body; name="draft-royer-cap-sort-02.txt" Content-Disposition: inline; filename="draft-royer-cap-sort-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-6105655.I-D@ietf.org> --------------040102050608060905080104-- --------------ms020308030603020406090102 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 9w0BCQUxDxcNMDMxMDA2MTc1NjUyWjAjBgkqhkiG9w0BCQQxFgQUfulIzHB3DUdRdPR8hJ2+ R6dQvsswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAifXo08pEfNq/qRETZ54wE4Sw5X6sUi2wH7l4357H+lz7FzwPv8ElnciUhx+G6gsb 5MWotHqsCPBpQrPuicpsaN/XB0K71edALTyXZF4lRDOQOkWBmH6/KNiz4iwDfmrue+IfW1gA yrCjzpi8bYHaG8BnDmYV6yxBW4EhC1Hi6exLQtad7DFH/exJJN7OoVaxcWaCZ0B9xWesZKJR IA+8S8aFjYcdfXS9Qb07dRJKWiAY30n0RzhLryCV12jlSSFD/UJOx43tkAUadkM6y0TMm4rM pFGw5JR7h3UIgLeHIrEyj6qdOQlsPhr2gjcGguedGUMZ5ImsIjzwU+OCFNL8zAAAAAAAAA== --------------ms020308030603020406090102-- From subs-reminder@imc.org Mon Oct 6 22:14:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02045 for ; Mon, 6 Oct 2003 22:14:06 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h972EBKP089175 for ; Mon, 6 Oct 2003 19:14:11 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h972EAQ1089174; Mon, 6 Oct 2003 19:14:10 -0700 (PDT) Date: Mon, 6 Oct 2003 19:14:10 -0700 (PDT) Message-Id: <200310070214.h972EAQ1089174@above.proper.com> To: calsch-archive@ietf.org Subject: [[218345701]] Subscription to ietf-calendar for calsch-archive@lists.ietf.org Greetings. This message is a periodic reminder that calsch-archive@lists.ietf.org is subscribed to the ietf-calendar mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-calendar mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-calendar-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "calsch-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-calendar@mail.imc.org Tue Oct 7 04:44:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23529 for ; Tue, 7 Oct 2003 04:44:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h978TgKP013624 for ; Tue, 7 Oct 2003 01:29:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h978TgZO013623 for ietf-calendar-bks; Tue, 7 Oct 2003 01:29:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.lisanza.net (harrie.inet.it [213.92.1.193]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h978TeKP013608 for ; Tue, 7 Oct 2003 01:29:41 -0700 (PDT) (envelope-from harrie@inet.it) Received: from inet.it (localhost [127.0.0.1]) by localhost.lisanza.net (8.12.9/8.12.6) with ESMTP id h978UGUe001130 for ; Tue, 7 Oct 2003 10:30:21 +0200 (CEST) Date: Tue, 7 Oct 2003 10:30:14 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: RFC 2445 From: Harrie Hazewinkel To: "ietf-calendar@imc.org" Content-Transfer-Encoding: 7bit Message-Id: <793A8A7C-F8A0-11D7-9B2B-0003934A5A7E@inet.it> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit HI, I was wondering if there will be also an update of RFC 2445? I noted for instance that the UID property on page 111 says, "The property MUST be specified in the "VEVENT", "VTODO",...." While page 55 specifies a list of properties for the VTODO that "MUST NOT occur more than once". OK, it is technically correct and not in contradiction, but the RFC could be fixed to specify which properties (todoprop) MUST be specified once. Harrie From owner-ietf-calendar@mail.imc.org Tue Oct 7 05:33:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24469 for ; Tue, 7 Oct 2003 05:33:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h979GQKP015305 for ; Tue, 7 Oct 2003 02:16:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h979GPPH015304 for ietf-calendar-bks; Tue, 7 Oct 2003 02:16:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.lisanza.net (harrie.inet.it [213.92.1.193]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h979GOKP015292 for ; Tue, 7 Oct 2003 02:16:24 -0700 (PDT) (envelope-from harrie@inet.it) Received: from inet.it (localhost [127.0.0.1]) by localhost.lisanza.net (8.12.9/8.12.6) with ESMTP id h979HAUe001138; Tue, 7 Oct 2003 11:17:10 +0200 (CEST) Date: Tue, 7 Oct 2003 11:17:09 +0200 Subject: Re: CAP-12 - interm version 'E' Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel To: "ietf-calendar@imc.org" From: Harrie Hazewinkel In-Reply-To: <3F7B1889.1070700@Royer.com> Message-Id: <07466FEC-F8A7-11D7-9B2B-0003934A5A7E@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, On Wednesday, October 1, 2003, at 08:10 PM, Doug Royer wrote: > I have placed the latest edit of CAP for your review at: > http://inet-consulting.com/draft-ietf-calsch-cap-12-e.txt While reading this draft, some comments (so far). I apolagize if it opens old discussions. 1) Why is the BEEP profile defined in this draft. Would it not be better to seperate it? Maybe it is also useful advancement of the standard. 2) Section 1.2, Related documents could be a bit extended in explaining the way this draft uses those other RFCs. Now they just specify what they are. 3) The first definition of section 1.3 seems od to me. The definition is "BOOKED", but than it is actually a state which may have three values, "UNPROCESSED", "BOOKED", "DELETED". IMHO, on should define the definition state. Now I can simply wonder why "UNPROCESSED" is not a definition either. The part "marked for delete" I would restate as "deleted". First thought was now, is 'marked' also a state? I am neither sure if one already needs to specify here the part of 'A "BOOKED" state entry is stored with the "CREATE" command.', since there is nothing explained about command that would help the reader here. 4) Calendar Store Identifier (CSID) is defined by 'A CSID consists of the host and port portions of a "Common Internet Scheme Syntax" part of a URL, as defined by [URL]' However, section 8.9 has in the example also the scheme (protocol) part. This looks to me a mixture with Calendar Identifier (CALID) that start with "cap:". With respect the the "cap:" part we are aware that then CAP is the only method to access a calender. Not like 'ftp' and 'http' that are different protocols but could access the same resource. 5) NIT The reference of the RFCs have a URL not of http://www.ietf.org/rfc/ I am not fully sure what IETF policy is here. Harrie From owner-ietf-calendar@mail.imc.org Tue Oct 7 13:17:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12273 for ; Tue, 7 Oct 2003 13:17:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97GxNKP035478 for ; Tue, 7 Oct 2003 09:59:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97GxMob035477 for ietf-calendar-bks; Tue, 7 Oct 2003 09:59:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97GxLKP035471 for ; Tue, 7 Oct 2003 09:59:21 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h97GxJmL006263 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 7 Oct 2003 09:59:21 -0700 Message-ID: <3F82F0E2.5020709@Royer.com> Date: Tue, 07 Oct 2003 10:59:14 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'E' References: <07466FEC-F8A7-11D7-9B2B-0003934A5A7E@inet.it> In-Reply-To: <07466FEC-F8A7-11D7-9B2B-0003934A5A7E@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070505070202060905070108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070505070202060905070108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: > 1) > Why is the BEEP profile defined in this draft. Would it not be better > to separate it? > Maybe it is also useful advancement of the standard. There was a decision to use BEEP. In order for a protocol to use BEEP it requires that the protocol define the BEEP profile. I do not think we can separate them. > > 2) > Section 1.2, Related documents could be a bit extended in explaining > the way this draft uses those other RFCs. Now they just specify what > they are. Trying to explain without repeating or accidentally redefining text is difficult. [GUIDE] ties them together. > 3) The first definition of section 1.3 seems od to me. The definition > is "BOOKED", but than it is actually a state which may have three > values, "UNPROCESSED", "BOOKED", "DELETED". IMHO, on should define > the definition state. An object has 3 states, one of which is booked. I'll update the text to be more clear. > 4) > Calendar Store Identifier (CSID) is defined by > 'A CSID consists of the host and port portions of a "Common Internet > Scheme Syntax" part of a URL, as defined by [URL]' > However, section 8.9 has in the example also the scheme (protocol) part. I'll update the text to say and the scheme is included as .... > > > This looks to me a mixture with Calendar Identifier (CALID) that > start with "cap:". With respect the the "cap:" part we are aware that > then CAP is the only method to access a calendar. Not like 'ftp' and > 'http' > that are different protocols but could access the same resource. I do not follow your point. > > > 5) NIT > The reference of the RFCs have a URL not of http://www.ietf.org/rfc/ > I am not fully sure what IETF policy is here. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070505070202060905070108 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 9w0BCQUxDxcNMDMxMDA3MTY1OTE0WjAjBgkqhkiG9w0BCQQxFgQU6TDSMqMsk5tI7cfZ9u0f uVJJs/0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEADnIg3RmK9S5iaxbwd/YHTrTLHciH6dHw/+Iq4nj/jbAWAib8r4TCABowqtnL2H66 9GJ7WxJj6JhkkY4Jg9fKeVO+G7RYnIufu6rVsnIB3HxJJy4xFVWa9ZzGej9mge0CXqi//GEo 2WOBp+uxoI9NjMN6qFk/A9I7qR0TZCCiU0RLRsCh4xNfERjqtSAgGYNS5fcdV6y46PYV8xgv wQklzrks400CwxSIvFE+oX3i58+B+/9dfCprVTsWXmHCaAaiFQTLVksBQBf4kspVtWoUk6IK miE5VbzMvP5l6tzGlGDXANeqUGcSj7QABahTRU30uvWoXYBlukVHoqolC9UNdQAAAAAAAA== --------------ms070505070202060905070108-- From owner-ietf-calendar@mail.imc.org Tue Oct 7 19:50:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28236 for ; Tue, 7 Oct 2003 19:50:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NYwKP052060 for ; Tue, 7 Oct 2003 16:34:58 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97NYwb7052059 for ietf-calendar-bks; Tue, 7 Oct 2003 16:34:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from bikini.cac.washington.edu (bikini.cac.washington.edu [128.208.94.28]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NYuKP052046 for ; Tue, 7 Oct 2003 16:34:57 -0700 (PDT) (envelope-from slh@bikini.cac.washington.edu) Received: (from slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) id h97NYJo04888; Tue, 7 Oct 2003 16:34:19 -0700 (PDT) Date: Tue, 7 Oct 2003 16:34:19 -0700 (PDT) From: slh@bikini.cac.washington.edu Message-Id: <200310072334.h97NYJo04888@bikini.cac.washington.edu> To: ietf-calendar@imc.org Subject: 2445: DTSTART and DTEND (and DUE) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: if DTSTART is of type DATE then DTEND must be also be of type DATE; is the reverse true (must these two always match in type)? none of these rules are stated for DTSTART and DUE (for VTODO), are the rules that apply to DTSTART/DTEND meant to apply to DTSTART/DUE? From owner-ietf-calendar@mail.imc.org Tue Oct 7 20:44:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29661 for ; Tue, 7 Oct 2003 20:44:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h980V9KP053875 for ; Tue, 7 Oct 2003 17:31:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h980V9Vl053874 for ietf-calendar-bks; Tue, 7 Oct 2003 17:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h980V8KP053869 for ; Tue, 7 Oct 2003 17:31:08 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h980V8mL010245 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 7 Oct 2003 17:31:09 -0700 Message-ID: <3F835AC7.4030506@Royer.com> Date: Tue, 07 Oct 2003 18:31:03 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: 2445: DTSTART and DTEND (and DUE) References: <200310072334.h97NYJo04888@bikini.cac.washington.edu> In-Reply-To: <200310072334.h97NYJo04888@bikini.cac.washington.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090005000506080905050607" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090005000506080905050607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit slh@bikini.cac.washington.edu wrote: >if DTSTART is of type DATE then DTEND must be also be of type DATE; >is the reverse true (must these two always match in type)? > If it is not an anniversary or daily reminder - I think that they do not have to match. >none of these rules are stated for DTSTART and DUE (for VTODO), >are the rules that apply to DTSTART/DTEND meant to apply to DTSTART/DUE? > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090005000506080905050607 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 9w0BCQUxDxcNMDMxMDA4MDAzMTAzWjAjBgkqhkiG9w0BCQQxFgQUSr4/AE7dOamJpuK0xTEo LQPHSbwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAbUxqsGnzYpM7KHFxr3N3+XZu4wiDGPE+IyEZMSgE6i9WW4bHMZx5ddkqL/74Is3o JfhI2ztiKWzOeWtqUGm7LWeVB4XGlcGmfAbpHhW9SB6xS5Y9tUCeYXgoiQIy7qltQko76cCZ wzoRKHPCK+Y6U5M9H3t5UmJ4hPQ2tUGPk038/taCqHSzc2DuwJO8zZ8Hr82GK1nzvpQ3T/uZ g0CUX6ttM30zp68fYO5+wRItIpWRLQxmipWNFobyV4LKGBH+wQNh6cdL2rRnoyDEOWnCdIvF rOGZCbb7wGErPXcJmYdLWvK1Rx6SbX50dr8KSdbCb3vxLuaABXXzyBjj8GY/OwAAAAAAAA== --------------ms090005000506080905050607-- From owner-ietf-calendar@mail.imc.org Wed Oct 8 00:06:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04125 for ; Wed, 8 Oct 2003 00:05:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h983kjKP059922 for ; Tue, 7 Oct 2003 20:46:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h983kjgm059921 for ietf-calendar-bks; Tue, 7 Oct 2003 20:46:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from bikini.cac.washington.edu (bikini.cac.washington.edu [128.208.94.28]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h983khKP059911 for ; Tue, 7 Oct 2003 20:46:43 -0700 (PDT) (envelope-from slh@bikini.cac.washington.edu) Received: from localhost (slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) with ESMTP id h983k9r05092 for ; Tue, 7 Oct 2003 20:46:09 -0700 (PDT) Date: Tue, 7 Oct 2003 20:46:09 -0700 From: slh@bikini.cac.washington.edu To: "ietf-calendar@imc.org" Subject: Re: 2445: DTSTART and DTEND (and DUE) In-Reply-To: <3F835AC7.4030506@Royer.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 7 Oct 2003, Doug Royer wrote: > > > > slh@bikini.cac.washington.edu wrote: > > >if DTSTART is of type DATE then DTEND must be also be of type DATE; > >is the reverse true (must these two always match in type)? > > > > If it is not an anniversary or daily reminder - I think that they do not > have to match. they at least have to match in the one direction: --- The "VEVENT" is also the calendar component used to specify an anniversary or daily reminder within a calendar. These events have a DATE value type for the "DTSTART" property instead of the default data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it MUST be specified as a DATE value also. The anniversary type of "VEVENT" can span more than one date (i.e, "DTEND" property value is set to a calendar date after the "DTSTART" property value). --- and even though this is in the context of an using a VEVENT to represent an anniversary, I would assume it always holds true, because among other things you don't know it's an anniversary (well, other than one might claim it is implied by DTSTART being of type DATE, but again, you'd be left with DTEND having to be DATE when DTSTART is a DATE). > > >none of these rules are stated for DTSTART and DUE (for VTODO), > >are the rules that apply to DTSTART/DTEND meant to apply to DTSTART/DUE? > > > > > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > > From owner-ietf-calendar@mail.imc.org Wed Oct 15 13:00:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09320 for ; Wed, 15 Oct 2003 13:00:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FGZuI7084403 for ; Wed, 15 Oct 2003 09:35:56 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FGZukM084402 for ietf-calendar-bks; Wed, 15 Oct 2003 09:35:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from gw.provo.novell.com (gw.provo.novell.com [137.65.47.29]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FGZtI7084395 for ; Wed, 15 Oct 2003 09:35:55 -0700 (PDT) (envelope-from cjohnson@gw.novell.com) Received: from PROVO7-MTA by gw.provo.novell.com with Novell_GroupWise; Wed, 15 Oct 2003 10:34:29 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Wed, 15 Oct 2003 10:37:11 -0600 From: "Craig Johnson" To: Subject: Restore iTIP Functionality Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part0A54B5A7.0__=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=__Part0A54B5A7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Before CAP-12, it was possible for a CUA to obtain 'UNPROCESSED' VFREEBUSY components from the Calendar Store. Now, however, a new section in CAP-12 explicitly prohibits this (Section 10.12.1, paragraph 4): If a CUA searches for "VFREEBUSY" components with STATE() = 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components. This undermines iTIP functionality for the VFREEBUSY component; it disallows a CUA from participating in iTIP based free-busy requests and responses. It also conflicts with other provisions in CAP that indicate iTIP is unaffected and fully supported. We believe this restriction must be removed to restore iTIP functionality and consistency to CAP. C. Johnson --=__Part0A54B5A7.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable Before CAP-12, it = was possible for a CUA to obtain 'UNPROCESSED' VFREEBUSY components from = the Calendar Store.  Now, however, a new section in&nbs= p;CAP-12 explicitly prohibits this (Section 10.12.1, paragraph 4):=20
 
   If a CUA searches for "VFREEBUSY" = components with STATE() =3D
   'UNPROCESSED', such a CS MUST = return a "VREPLY" with no components.
 
This undermines iTIP functionality for the VFREEBUSY component; = it disallows a CUA from participating in iTIP based = free-busy requests and responses.  It also conflicts with other = provisions in CAP that indicate iTIP is unaffected and fully = supported.  We believe this restriction must be = removed to restore iTIP functionality and consistency to CAP.
 
C. Johnson
--=__Part0A54B5A7.0__=-- From owner-ietf-calendar@mail.imc.org Wed Oct 15 15:50:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19137 for ; Wed, 15 Oct 2003 15:50:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FJWTI7089325 for ; Wed, 15 Oct 2003 12:32:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FJWTNS089324 for ietf-calendar-bks; Wed, 15 Oct 2003 12:32:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FJWSI7089315 for ; Wed, 15 Oct 2003 12:32:28 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9FJWRmL014754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 15 Oct 2003 12:32:29 -0700 Message-ID: <3F8DA0C3.5070203@Royer.com> Date: Wed, 15 Oct 2003 13:32:19 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Restore iTIP Functionality References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030009030203050405010009" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030009030203050405010009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I strongly agree with your. It is my understanding the WG wanted it out. Craig Johnson wrote: > Before CAP-12, it was possible for a CUA to obtain 'UNPROCESSED' > VFREEBUSY components from the Calendar Store. Now, however, a > new section in CAP-12 explicitly prohibits this (Section 10.12.1, > paragraph 4): > > If a CUA searches for "VFREEBUSY" components with STATE() = > 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components. > > This undermines iTIP functionality for the VFREEBUSY component; > it disallows a CUA from participating in iTIP based free-busy requests > and responses. It also conflicts with other provisions in CAP that > indicate iTIP is unaffected and fully supported. We believe this > restriction must be removed to restore iTIP functionality and > consistency to CAP. > > C. Johnson -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030009030203050405010009 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 9w0BCQUxDxcNMDMxMDE1MTkzMjE5WjAjBgkqhkiG9w0BCQQxFgQUijyjkPFRXJBXk8LJt6Qk QzWPp70wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA0rvTHvSliSsZcj2x6rss6qgbFTlWg276djWxA4TzGZHBOs1rIctvmEqYeDC28Kym aN34aG/h/l9jPXAB0kMTIEtOCB2yqK/+7oejfsg9Q2fyw0KjFz/EyQlHsuvqT5rxXIAE+lai 8M405Kw/CIn0mwaF0OydxuTp8qlyL+xtsRblB25FZH4xFVhjH75KGDmVmwg9GUi/j3h3Mfla lrNoeR/Lt3cTnEGbmFKHQ4X7Rr/DV1rOr5/F4G6NiKQnVTuLOHEL/o50Y4U39HVAHDr9yISA tLg1D9gq8gX/ihc0IiJVCWaufkFRAmvAuRF4syoXJtg3FTEbgw0sw6UpZSRFGQAAAAAAAA== --------------ms030009030203050405010009-- From owner-ietf-calendar@mail.imc.org Wed Oct 15 17:30:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24582 for ; Wed, 15 Oct 2003 17:30:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FLE7I7092087 for ; Wed, 15 Oct 2003 14:14:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FLE74t092085 for ietf-calendar-bks; Wed, 15 Oct 2003 14:14:07 -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.10/8.12.8) with ESMTP id h9FLE6I7092079 for ; Wed, 15 Oct 2003 14:14:06 -0700 (PDT) (envelope-from gsbarnes@u.washington.edu) Received: from mead11.u.washington.edu (mead11.u.washington.edu [140.142.12.175]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9FLE2aZ011352 for ; Wed, 15 Oct 2003 14:14:07 -0700 Received: from localhost (gsbarnes@localhost) by mead11.u.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9FLE2l4987386 for ; Wed, 15 Oct 2003 14:14:02 -0700 Date: Wed, 15 Oct 2003 14:14:02 -0700 (PDT) From: "G. Barnes" To: ietf-calendar@imc.org Subject: Re: Restore iTIP Functionality (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I meant to send this to the mailing list, not just Craig Johnson, but screwed up. ---------- Forwarded message ---------- Date: Wed, 15 Oct 2003 11:00:22 -0700 (PDT) From: G. Barnes To: Craig Johnson Subject: Re: Restore iTIP Functionality On Wed, 15 Oct 2003, Craig Johnson wrote: > Before CAP-12, it was possible for a CUA to obtain 'UNPROCESSED' > VFREEBUSY components from the Calendar Store. Now, however, a new > section in CAP-12 explicitly prohibits this (Section 10.12.1, paragraph > 4): > If a CUA searches for "VFREEBUSY" components with STATE() = > 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components. Just to be clear: Note the phrase 'such a CS'. This paragraph refers to a CS described in the first paragraph of 10.12.1, not all CS's. When I rewrote this text, paragraphs 2 and 5 in this section were indented to indicate that they were conclusions that follow from the first paragraph. This indenting has been eliminated, which to my mind makes things less clear, but maybe there's some IETF formatting rule I don't know about. Knowing that, if you don't agree with the logic in the first 5 paragraphs of this section, you can look at http://www.imc.org/ietf-calendar/mail-archive/msg08121.html which contains a discussion of what was there before, and why I thought it needing rewriting. In my mind, this is only a clarification of what was there before, so you'll have to search further back to figure out why RECUR-EXPAND=TRUE implies VFREEBUSY objects are never stored. Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Thu Oct 16 13:22:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11819 for ; Thu, 16 Oct 2003 13:22:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGx7I7095731 for ; Thu, 16 Oct 2003 09:59:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GGx7GA095730 for ietf-calendar-bks; Thu, 16 Oct 2003 09:59:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from gw.provo.novell.com (gw.provo.novell.com [137.65.47.29]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGx6I7095723 for ; Thu, 16 Oct 2003 09:59:06 -0700 (PDT) (envelope-from PStephenson@gw.novell.com) Received: from PROVO7-MTA by gw.provo.novell.com with Novell_GroupWise; Thu, 16 Oct 2003 10:57:25 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Thu, 16 Oct 2003 11:00:15 -0600 From: "Preston Stephenson" To: Subject: CAP BEEP channel question 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 if I missed this. Is there an example of starting the CAP BEEP profile? When I initially wrote my CAP server, I think I patterned my start exchange after the SASL profiles. Thus: C: Content-Type: application/beep+xml C: C: C: C: S: ]]> S: In section 12.1 BEEP Profile Registration, it talks about the initial message must be the GET-CAPABILITY command. It doesn't talk about the BEEP Start message exchange. In section 12.1 there is also a "URI[10]" reference. The "[10]" reference seems to have been taken from rfc3080. The reference should probably be changed to "[URI]" to be consistent. Thanks. Preston From owner-ietf-calendar@mail.imc.org Fri Oct 17 11:11:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05756 for ; Fri, 17 Oct 2003 11:11:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HEqTI7013146 for ; Fri, 17 Oct 2003 07:52:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HEqTQU013145 for ietf-calendar-bks; Fri, 17 Oct 2003 07:52:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.lisanza.net (harrie.inet.it [213.92.1.193]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HEqRI7013131 for ; Fri, 17 Oct 2003 07:52:27 -0700 (PDT) (envelope-from harrie@inet.it) Received: from inet.it (localhost [127.0.0.1]) by localhost.lisanza.net (8.12.9/8.12.6) with ESMTP id h9HErUUe006783; Fri, 17 Oct 2003 16:53:31 +0200 (CEST) Date: Fri, 17 Oct 2003 16:53:30 +0200 Subject: Re: CAP-12 - interm version 'E' Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel To: "ietf-calendar@imc.org" From: Harrie Hazewinkel In-Reply-To: <3F82F0E2.5020709@Royer.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit HI, With respect to section "10.9 MODIFY Command". 1) at the end of page 115: > The format of the request is two components inside of "VCALENDAR" > component: The example below looks to me to have 3 components, or is VQUERY not a component?? Section 9.6 makes believe it is a component and so is the text afterwards. I believe you are referin to the 2 components (1, old values and 2, new values) as those two. 2) The format explanation after the formal definition end with "END:CALENDAR" which must be "END:VCALENDAR" 3) The text also mixes upper and lower case for old-values and new values. Maybe all lower case?? Since it has only once "OLD-VALUES". 4) The first example misses the "END:VCALENDAR". The example als says "End of new data" which should be "Start of new data". regards, Harrie From owner-ietf-calendar@mail.imc.org Mon Oct 20 15:49:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23312 for ; Mon, 20 Oct 2003 15:49:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KJY4I7005962 for ; Mon, 20 Oct 2003 12:34:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KJY4Pi005961 for ietf-calendar-bks; Mon, 20 Oct 2003 12:34:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KJY2I7005956 for ; Mon, 20 Oct 2003 12:34:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9KJXwc0005032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 20 Oct 2003 12:34:00 -0700 Message-ID: <3F9438A1.9060409@Royer.com> Date: Mon, 20 Oct 2003 13:33:53 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12 - interm version 'E' References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070701080503060308060502" X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-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. --------------ms070701080503060308060502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: > > HI, > > With respect to section "10.9 MODIFY Command". > > 1) at the end of page 115: > >> The format of the request is two components inside of "VCALENDAR" >> component: > Your right, itis three - fixed. >> > The example below looks to me to have 3 components, or is VQUERY not > a component?? Section 9.6 makes believe it is a component and so is the > text afterwards. > > I believe you are referin to the 2 components (1, old values and 2, > new values) > as those two. > > 2) > The format explanation after the formal definition end > with "END:CALENDAR" which must be "END:VCALENDAR" thanks fixed. > > 3) > The text also mixes upper and lower case for old-values and new values. > Maybe all lower case?? Since it has only once "OLD-VALUES". Thanks fixed - lower case,. > > 4) > The first example misses the "END:VCALENDAR". > The example als says "End of new data" which should be "Start of new > data". Fixed - thanks. > > regards, > > Harrie -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070701080503060308060502 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 9w0BCQUxDxcNMDMxMDIwMTkzMzUzWjAjBgkqhkiG9w0BCQQxFgQUDzP8cHEF1O5ZmwSz75Y4 E6dxvlowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEASH8kYqa0C0WO1bC+D8ylKNTKUhxXDYTSpRrDoA7RQD5GJq3h+fw7auNCpgYHEpZA VUcUxQsTGuTbvvWxqtwTtIU4oX8No9cnhMTlBhR6Zk9na5oySdV/8srqg2uk5qTRG4u3K16r LtAZ/XrBgcrP/1TkiHXyzElLU265ham8hEZzuf1j4mPzsww8Yy4Nqppzt61Quba1Vj51NQFG mKsti3G7nP0lKgE1+PqdgsuP9t33nPdjB6P4pFzpizGYmrcVVQavsJe59r4xY2weXVAUJtsY iiocxuXgI6Wkqd0eQ49nMlA+TWMkdEK3EP71l5asiNWDSjAXuuukH8mqINR+sQAAAAAAAA== --------------ms070701080503060308060502-- From owner-ietf-calendar@mail.imc.org Mon Oct 20 17:48:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07467 for ; Mon, 20 Oct 2003 17:48:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KLZVI7010697 for ; Mon, 20 Oct 2003 14:35:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KLZVlj010696 for ietf-calendar-bks; Mon, 20 Oct 2003 14:35:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KLZUI7010691 for ; Mon, 20 Oct 2003 14:35:30 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12-e: Alarms and SEQUENCE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_09102003NP September 10, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 20 Oct 2003 17:27:42 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/20/2003 05:35:31 PM, Serialize complete at 10/20/2003 05:35:31 PM Content-Type: multipart/alternative; boundary="=_alternative 0075D1F285256DC5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075D1F285256DC5_= Content-Type: text/plain; charset="US-ASCII" Ok, I thought I asked about this before but maybe not. In CAP we added the SEQUENCE property to VALARMs: alarmc = "BEGIN" ":" "VALARM" CRLF alarm-seq other-props (audioprop / dispprop / emailprop / procprop) "END" ":" "VALARM" CRLF alarm-seq = "SEQUENCE" alarmseqparams ":" posint0 CRLF ... The CUA adds a "SEQUENCE" property to each "VALARM" component as it books the component. This property along with the "LOCAL" and "ENABLE" parameters allow the CUA to uniquely identify any VALARM in any component. The CUA should remove those before forwarding to non CAP aware CUAs. Ok, I have a few comments/questions about this text/concept: 1: First off, since VALARMs are embedded in other components, what use is adding SEQUENCE to any VALARM on any particular component? The workflow is done on the components the VALARM is embedded in, NOT on any separate VALARM so I see no benefit to tracking separate changes to the VALARM using SEQUENCE (what SEQUENCE is defined for). It appears that SEQUENCE (and LOCAL and ENABLE) are local to a specific copy of the VALARM which is in turn specific to the component that it appears in. Are we adding this to VALARMs solely to make it easier to find/change the VALARMs instead of using the mechanism already defined under Section 10.9 MODIFY Command that we use for all other components/subcomponents? 2: The SEQUENCE property is NOT a unique identifier type property so its a bad idea to use it to as such ("to uniquely identify any VALARM in any component."); its intended to track modifications or changes. If you want to perform an identification role then you should be using UID or some variant of that property instead. Again though I wonder if this is truely necessary to add to iCalendar. 3: Just how is a CUA to know if the recipient is a "to non CAP aware CUA"? Aren't all CAP clients CAP aware? Is the last line referring to things like sending over iMIP (or some other iTIP binding other than CAP) or am I missing something? The text in Section 2. Additions to iCalendar that says: These local alarms are not to be forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property and the "ENABLE" parameter. makes me wonder why an invitee would put a SEQUENCE on a VALARM they may have recieved from someone else (since it cannot be sent by the Organizer to any invitee per the text in CAP). If the recipient accepted the VALARM (by accepting the containing VEVENT for example) then I see no need for the SEQUENCE property to be added to it. All workflow happens at the VEVENT level and all changes still result in just 1 copy of the VEVENT in the calendar, what good is tracking changes to the VALARM subcomponent? If the sole reason is to be able to find it for modification, MODIFY already covers how to do this: The old-values is a component and the contents of that component are going to change and may contain information that helps uniquely identify the original component (SEQUENCE in the example below). If the CS can not find a component that matches the QUERY and does not have at least all of the OLD-VALUES, then a 6.1 error is returned. so if the CU wanted to change a particular VALARM, the CUA simply sends back the info to identify which VALARM the CU changed and then the new info. If its good enough for all other components/subcomponents it should be good enough for alarms. Unless a clear and compelling reason for adding SEQUENCE to VALARM can be shown and documented in CAP I propose we remove this change to iCalendar from CAP 1.0. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0075D1F285256DC5_= Content-Type: text/html; charset="US-ASCII"
Ok, I thought I asked about this before but maybe not.  In CAP we added the SEQUENCE property to VALARMs:

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

   alarm-seq   = "SEQUENCE" alarmseqparams ":" posint0 CRLF
...
   The CUA adds a "SEQUENCE" property to each "VALARM" component as it
  books the component. This property along with the "LOCAL" and
  "ENABLE" parameters allow the CUA to uniquely identify any VALARM in
  any component. The CUA should remove those before forwarding to non
  CAP aware CUAs.
Ok, I have a few comments/questions about this text/concept:

1: First off, since VALARMs are embedded in other components, what use is adding SEQUENCE to any VALARM on any particular component?  The workflow is done on the components the VALARM is embedded in, NOT on any separate VALARM so I see no benefit to tracking separate changes to the VALARM using SEQUENCE (what SEQUENCE is defined for).  It appears that SEQUENCE (and LOCAL and ENABLE) are local to a specific copy of the VALARM which is in turn specific to the component that it appears in.  Are we adding this to VALARMs solely to make it easier to find/change the VALARMs instead of using the mechanism already defined under Section 10.9 MODIFY Command that we use for all other components/subcomponents?

2: The SEQUENCE property is NOT a unique identifier type property so its a bad idea to use it to as such ("to uniquely identify any VALARM in any component."); its intended to track modifications or changes.  If you want to perform an identification role then you should be using UID or some variant of that property instead.  Again though I wonder if this is truely necessary to add to iCalendar.

3: Just how is a CUA to know if the recipient is a "to non CAP aware CUA"?  Aren't all CAP clients CAP aware?  Is the last line referring to things like sending over iMIP (or some other iTIP binding other than CAP) or am I missing something?

The text in Section 2. Additions to iCalendar that says:

                          These local alarms are not to be
  forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property
  and the "ENABLE" parameter.

makes me wonder why an invitee would put a SEQUENCE on a VALARM they may have recieved from someone else (since it cannot be sent by the Organizer to any invitee per the text in CAP).  If the recipient accepted the VALARM (by accepting the containing VEVENT for example) then I see no need for the SEQUENCE property to be added to it.  All workflow happens at the VEVENT level and all changes still result in just 1 copy of the VEVENT in the calendar, what good is tracking changes to the VALARM subcomponent?  

If the sole reason is to be able to find it for modification, MODIFY already covers how to do this:

   The old-values is a component and the contents of that component are
  going to change and may contain information that helps uniquely
  identify the original component (SEQUENCE in the example below). If
  the CS can not find a component that matches the QUERY and does not
  have at least all of the OLD-VALUES, then a 6.1 error is returned.

so if the CU wanted to change a particular VALARM, the CUA simply sends back the info to identify which VALARM the CU changed and then the new info.  If its good enough for all other components/subcomponents it should be good enough for alarms.

Unless a clear and compelling reason for adding SEQUENCE to VALARM can be shown and documented in CAP I propose we remove this change to iCalendar from CAP 1.0.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0075D1F285256DC5_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 20 19:12:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13238 for ; Mon, 20 Oct 2003 19:12:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KN1VI7013362 for ; Mon, 20 Oct 2003 16:01:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KN1VvR013360 for ietf-calendar-bks; Mon, 20 Oct 2003 16:01:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KN1TI7013351 for ; Mon, 20 Oct 2003 16:01:30 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h9KN1Gs4012255; Mon, 20 Oct 2003 17:01:17 -0600 (MDT) Message-ID: <3F94693C.220CAB32@INET-Calendar.net> Date: Mon, 20 Oct 2003 17:01:16 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@notesdev.ibm.com CC: ietf-calendar@imc.org Subject: Re: CAP-12-e: Alarms and SEQUENCE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Ok, I thought I asked about this before but maybe not. In CAP we > added the SEQUENCE property to VALARMs: So you say you do not understand, yet you quote text from CAP that answers your questions. Then in the next question you address the issue you just raised. I renew my belief that you are doing you best to stall CAP from being released. Your selective reading of CAP causes your underinformed or misinformed posts to cause debates that are not needed. Just searching for the word SEQUENCE I found several hits, including: A CUA may add the "LOCAL" parameter to the "SEQUENCE" property before booking the component. If the "LOCAL" parameter is set to "TRUE", then the alarm MUST NOT be forwarded to any other calender. If set to "FALSE", or if the "LOCAL" parameter is not in the "SEQUENCE" property, the alarm is global. and In addition a problem exists with the control of "VALARM" components and their "TRIGGER" properties. A CU may wish to set their own alarm (local alarms) on components. These local alarms are not to be forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property and the "ENABLE" parameter. So for the protocol between a CUA and a CS, the following changes apply to the CAP protocol from [iCAL] section 4.6.6 page 67: and The CUA adds a "SEQUENCE" property to each "VALARM" component as it books the component. This property along with the "LOCAL" and "ENABLE" parameters allow the CUA to uniquely identify any VALARM in any component. The CUA should remove those before forwarding to non CAP aware CUAs. and SEQUENCE - When the "SEQUENCE" property is used in a "VALARM" component it uniquely identifies the instances of the "VALARM" within that component. and The old-values is a component and the contents of that component are going to change and may contain information that helps uniquely identify the original component (SEQUENCE in the example below). If the CS can not find a component that matches the QUERY and does not have at least all of the OLD-VALUES, then a 6.1 error is returned. and Because "SEQUENCE" property is used to locate the "VALARM" component in this example, both the old-values and the new-values contain the "SEQUENCE" property with a value of "3" and if the "SEQUENCE" property were to be left out of new-values, it would have been deleted. and 2. If a contained component is changed inside of a selected component, and that contained component has multiple instances, then old-values MUST contain information that uniquely identifies the instance or instances that are changing. It is valid to change more than one. As all contained components that match old-values will be modified. In the first modify example above, if "SEQUENCE" properties were to be deleted from both the old-values and new-values, then all "TRIGGER" properties that matched the old-values in all "VALARM" components in the selected "VEVENT" components would be disabled. From owner-ietf-calendar@mail.imc.org Mon Oct 20 19:24:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13488 for ; Mon, 20 Oct 2003 19:24:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KNDrI7013764 for ; Mon, 20 Oct 2003 16:13:53 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KNDrUI013761 for ietf-calendar-bks; Mon, 20 Oct 2003 16:13: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.10/8.12.8) with ESMTP id h9KNDqI7013756 for ; Mon, 20 Oct 2003 16:13:52 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9KNDpc0008690 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 20 Oct 2003 16:13:52 -0700 Message-ID: <3F946C1A.4020008@Royer.com> Date: Mon, 20 Oct 2003 17:13:30 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Alarms and SEQUENCE References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080204010306050407000002" X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-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. --------------ms080204010306050407000002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Ok, I thought I asked about this before but maybe not. In CAP we > added the SEQUENCE property to VALARMs: > > alarmc = "BEGIN" ":" "VALARM" CRLF > alarm-seq > other-props > (audioprop / dispprop / emailprop / procprop) > "END" ":" "VALARM" CRLF > > alarm-seq = "SEQUENCE" alarmseqparams ":" posint0 CRLF > ... > The CUA adds a "SEQUENCE" property to each "VALARM" component as it > books the component. This property along with the "LOCAL" and > "ENABLE" parameters allow the CUA to uniquely identify any VALARM in > any component. The CUA should remove those before forwarding to non > CAP aware CUAs. > > Ok, I have a few comments/questions about this text/concept: > > 1: First off, since VALARMs are embedded in other components, what use > is adding SEQUENCE to any VALARM on any particular component? Please read the archives (which you participated in), in summary: Its to allow the CUA to uniquely identify any VALARM in any component. Read up on the MODIFY command debate. CAP also says: In addition a problem exists with the control of "VALARM" components and their "TRIGGER" properties. A CU may wish to set their own alarm (local alarms) on components. These local alarms are not to be forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property and the "ENABLE" parameter. So for the protocol between a CUA and a CS, the following changes apply to the CAP protocol from [iCAL] section 4.6.6 page 67: This was so you could add local VALARMs that are not to be forwarded. Read the debate on MODIFY and COUNTER where a CU wished to COUNTER an object and NOT have the VALARMs deleted or added that are local. > The workflow is done on the components the VALARM is embedded in, NOT > on any separate VALARM so I see no benefit to tracking separate > changes to the VALARM using SEQUENCE (what SEQUENCE is defined for). We have already had this debate. I see no new information in your post. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080204010306050407000002 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 9w0BCQUxDxcNMDMxMDIwMjMxMzMwWjAjBgkqhkiG9w0BCQQxFgQUsVqUicItSmRqkheSSzNr 619f54wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAcS1aFkUtDWqfK1tGgmvVsQ9sf3b9ZudQ7lYJ3IduLsx9N3Mqxphf9I6PgPaMSVim zwhYSq58zH59wGeN7SWc579f3YGQFCFrFjrIK+8vEiAgcGgkPNjTCEWlGje46kk6mfHfmNj5 dkCYl9wv+23KYrNWRodyHR+Ny3+bfurFsb654qQcxSUM3UGozGPkf5WNdp9eo9b0m1Z+KJP4 XWbPNuAmHB5nBPv5R8LV5GBb+UlUrVbTAsC6q2iLaMuRDIE416TH4bc104g0pBIAjz5J3Xbl IF60658tDakEIHGYsJBWUBa/0MyrPD9N/iC4Sdc89I6SAhoBTiyXYH0tJp7BCQAAAAAAAA== --------------ms080204010306050407000002-- From owner-ietf-calendar@mail.imc.org Tue Oct 21 10:52:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21583 for ; Tue, 21 Oct 2003 10:52:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LEZpI7026878 for ; Tue, 21 Oct 2003 07:35:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LEZpvB026877 for ietf-calendar-bks; Tue, 21 Oct 2003 07:35:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LEZnI7026872 for ; Tue, 21 Oct 2003 07:35:50 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F946C1A.4020008@Royer.com> To: ietf-calendar@imc.org Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: CAP-12-e: Alarms and SEQUENCE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_09102003NP September 10, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 21 Oct 2003 10:24:23 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/21/2003 10:35:38 AM, Serialize complete at 10/21/2003 10:35:38 AM Content-Type: multipart/alternative; boundary="=_alternative 0050160785256DC6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0050160785256DC6_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/20/2003 07:13:30 PM: > Please read the archives (which you participated in), in summary: Ok, that confirms that I did ask about it before. Guess I never got an answer that made sense to me... Searching for VALARM and SEQUENCE yeilds many matches so can you please reference the date of discussion or the subject of the thread where we actually resolved this? I see several cases of us discussing stuff under different topics but nothing specific where we discussed adding SEQUENCE to VALARMs. I found a proposal from Roger Dox under the Subject "Adding more unique identifiers" dated 07/13/2001 05:43:33 PM AST that got 0 WG discussion (but he correctly proposed using UID). I found a thread from Bernard under the Subject "Modifying VALARM (Was: VCAR: CARID Property)" dated 01/14/2002 11:00:48 AM that said in part: You lost me Doug. This thread is about *VCAR* not VALARM. If I'm not mistaken, you are re-opening the issue that was closed at the end of November 2001. http://www.imc.org/ietf-calendar/mail-archive/msg02442.html to which Doug replied (in part): Once a user changes the contents of a VALARM, the UID is BOGUS and does NOT uniquely identify anything. At that point you have two or more VALARMs with the same UID. Now UID means unique-but-not-really. We would then BUST UID. Now if that were true, making changes to any VEVENT or VTODO would also cause UID to "bust" and I think we all agree that isnt true. I found a subthread by Doug under the subject "Re: CAP Issues And To-Do List" dated 01/13/2002 10:55:12 AM MST that said in part: - Add a UID to VALARMs. (December 2001.) Add ALARMID or SEQUENCE to VALARMS. The idea is to uniquely identify a VALARM within a component. There is no need for it to be globally unique. I found a subthread by Doug under the subject "(#1) synchronization part 2, and identifying a components VALARM" dated 02/13/2002 10:32:51 PM MST that said in part: How do you identify which VALARM is being modified in a component when the CUA wishes to a VALARM in an existing component and that components contains two or more VALARMs. (See UID vs ALARMID debate.) Only Mark at Steltor and John Strack even responded to the proposal. Mark to correct an example and John to say he liked it so I doubt that this is the thread Doug was referring to. It appears that between 13-Jan-2002 and 13-Feb-2002 Doug had a change of heart on UID vs SEQUENCE but I can find no WG discussion or acceptance of this. Even tough the threads above all discuss ALARMID vs UID, I can find no WG discussion of opting for SEQUENCE as an identifier except for Dougs proposal that we did not discuss. It appears that after we changed editorship the change just happened or I cant find that thread. Im sure Doug or his sidkick Mark will yell otherwise but instead of doing that why not just provide an archive citation to the contrary and save everyone the cycles. In still trying to understand this need thats not clearly spelled out in the CAP draft I find the first reference to "ALARMID" in the archives is actually dated 04/02/2000 12:00:06 AM PST on Dougs "CALSCH Action Items" automated posting. It is merely: The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- ... I-4 Add ALARMID to VALARM ? Y So I backtracked even further. Waaay back on 07/10/2000 10:47:48 AM AST I actually questioned this item to which Doug kindly replied: It was on the list or at an IETF meeting - I forget which. ALARMID's are needed CAP because it would be impossible to modify an alarm without being able to identify which of multiple alarms in a component would be the target of the METHOD:MODIFY. Well, it does NOT appear in any posted meeting minutes NOR does it appear in the WG postings prior to 04/02/2000 12:00:06 AM PST so I still question it. MODIFY clearly describes how to identify a component to modify with: The old-values is a component and the contents of that component are going to change and may contain information that helps uniquely identify the original component (SEQUENCE in the example below). If the CS can not find a component that matches the QUERY and does not have at least all of the OLD-VALUES, then a 6.1 error is returned. The CUA is responsible for sending the old VALARM properties that uniquely identify the desired VALARM (among its peers, if any) just as it does for all other compontents. This works the same for all components so _why_ do we need to change VALARMs?? Or are you suggesting that MODIFY works for all other component / subcomponent types except VALARMs?... > Its to allow the CUA to uniquely identify any VALARM in > any component. Read up on the MODIFY command debate. Umm, SEQUENCE does not uniquely identify the VALARM the way its defined by iCalendar. iCalendar defines SEQUENCE as: Purpose: This property defines the revision sequence number of the calendar component within a sequence of revisions. so its clearly a revision tracking propery, not a identification type property like UID: Purpose: This property defines the persistent, globally unique identifier for the calendar component. CAP appears to be reusing SEQUENCE incorrectly and _implicitly_ assuming that every VALARM will have one that never changes no matter how often or when the VALARM is changed. Since a VALARM can repeat using iCalendar recurrence rules or dates, if you kept the current iCalendar specified behaviour for changing SEQUENCE on property changes like RRULEs or RDATEs then SEQUENCE would change on a VALARM which could make it NOT unique. Of course you could change the defined behaviour of SEQUENCE while you are at it but that is a totally separate discussion! > In addition a problem exists with the control of "VALARM" components > and their "TRIGGER" properties. A CU may wish to set their own alarm > (local alarms) on components. These local alarms are not to be > forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property > and the "ENABLE" parameter. So for the protocol between a CUA and a > CS, the following changes apply to the CAP protocol from [iCAL] > section 4.6.6 page 67: > > This was so you could add local VALARMs that are not to be > forwarded. Read the debate on MODIFY and COUNTER where > a CU wished to COUNTER an object and NOT have the VALARMs > deleted or added that are local. Local alarms are not relevant to this discussion. I grok the need and use for local alarms vs ones an Organizer may send. The line: These local alarms are not to be forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property and the "ENABLE" parameter. reads that neither local alarms NOR any SEQUENCE propery NOR any ENABLE parameter can be forwarded. This implys that SEQUENCE is locally maintained by the CUA for its own purpose. The stated intent was to uniquely identify the VALARMs but thats not how SEQUENCE is defined in iCalendar; that is how UID is defined though. So if anything, the property to add would be UID (or ALARMID as previously mentioned). > We have already had this debate. I see no new information in your post. Too bad you didnt provide the citation to the previous discussion on this to save some time avoiding rehashing any old concepts... Providing it would save us time and thrashing. Since Doug is reluctant to provide a reference that he appears to have found Ill ask again: _Why_ does the CUA need to have this identification mechanism for VALARMs since they do not exist outside other uniquely identified components nor are they sent alone via iTIP? If its for modification, the MODIFY command already provides text on how to do this for _any_ component type so I fail to see the need to (incorrectly) tweak VALARMs. If its for some other need, Id like to know what it is so we dont make unnecesary changes to iCalendar. Anyone? If there is a demonstratable need for adding an identifer to VALARMs then ok but if not, Im against adding it. So far I have seen no demonstratable need... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0050160785256DC6_= Content-Type: text/html; charset="US-ASCII"
<WARNING: This posting contains several historical references up front so may be a bit long before returning to the technical bits>

Doug replied on 10/20/2003 07:13:30 PM:
> Please read the archives (which you participated in), in summary:
Ok, that confirms that I did ask about it before.  Guess I never got an answer that made sense to me...  Searching for VALARM and SEQUENCE yeilds many matches so can you please reference the date of discussion or the subject of the thread where we actually resolved this?  

I see several cases of us discussing stuff under different topics but nothing specific where we discussed adding SEQUENCE to VALARMs.

I found a proposal from Roger Dox under the Subject "Adding more unique identifiers" dated 07/13/2001 05:43:33 PM AST that got 0 WG discussion (but he correctly proposed using UID).  

I found a thread from Bernard under the Subject "Modifying VALARM (Was: VCAR: CARID Property)" dated 01/14/2002 11:00:48 AM that said in part:

You lost me Doug.  This thread is about *VCAR* not VALARM.

If I'm not mistaken, you are re-opening the issue that
was closed at the end of November 2001.

http://www.imc.org/ietf-calendar/mail-archive/msg02442.html
to which Doug replied (in part):

Once a user changes the contents of a VALARM, the UID is BOGUS
and does NOT uniquely identify anything. At that point
you have two or more VALARMs with the same UID. Now UID
means unique-but-not-really. We would then BUST UID.
Now if that were true, making changes to any VEVENT or VTODO would also cause UID to "bust" and I think we all agree that isnt true.  

I found a subthread by Doug under the subject "Re: CAP Issues And To-Do List" dated 01/13/2002 10:55:12 AM MST that said in part:

- Add a UID to VALARMs. (December 2001.)

Add ALARMID or SEQUENCE to VALARMS. The idea is to uniquely
identify a VALARM within a component. There is no need for
it to be globally unique.

I found a subthread by Doug under the subject "(#1) synchronization part 2, and identifying a components VALARM" dated 02/13/2002 10:32:51 PM MST that said in part:

     How do you identify which VALARM is being modified
    in a component when the CUA wishes to <modify> a VALARM
    in an existing component and that components contains two
    or more VALARMs. (See UID vs ALARMID debate.)

Only Mark at Steltor and John Strack even responded to the proposal.  Mark to correct an example and John to say he liked it so I doubt that this is the thread Doug was referring to.  It appears that between 13-Jan-2002 and 13-Feb-2002 Doug had a change of heart on UID vs SEQUENCE but I can find no WG discussion or acceptance of this.

Even tough the threads above all discuss ALARMID vs UID, I can find no WG discussion of opting for SEQUENCE as an identifier except for Dougs proposal that we did not discuss.  It appears that after we changed editorship the change just happened or I cant find that thread.  Im sure Doug or his sidkick Mark will yell otherwise but instead of doing that why not just provide an archive citation to the contrary and save everyone the cycles.

In still trying to understand this need thats not clearly spelled out in the CAP draft I find the first reference to "ALARMID" in the archives is actually dated 04/02/2000 12:00:06 AM PST on Dougs "CALSCH Action Items" automated posting.  It is merely:

 The following are a list of action items for the iCalendar-2 draft:

Draft Action Item                                                                    Who                 Done (Y/N)
-----------------                                                                    ---                 ----------
...
I-4 Add ALARMID to VALARM ?                                                   Y

So I backtracked even further.  Waaay back on 07/10/2000 10:47:48 AM AST I actually questioned this item to which Doug kindly replied:

It was on the list or at an IETF meeting - I forget which.

ALARMID's are needed CAP because it would be impossible to
modify an alarm without being able to identify which of multiple
alarms in a component would be the target of the METHOD:MODIFY.

Well, it does NOT appear in any posted meeting minutes NOR does it appear in the WG postings prior to 04/02/2000 12:00:06 AM PST so I still question it.  MODIFY clearly describes how to identify a component to modify with:

   The old-values is a component and the contents of that component are
  going to change and may contain information that helps uniquely
  identify the original component (SEQUENCE in the example below). If
  the CS can not find a component that matches the QUERY and does not
  have at least all of the OLD-VALUES, then a 6.1 error is returned.

The CUA is responsible for sending the old VALARM properties that uniquely identify the desired VALARM (among its peers, if any) just as it does for all other compontents.  This works the same for all components so _why_ do we need to change VALARMs??   Or are you suggesting that MODIFY works for all other component / subcomponent types except VALARMs?...

</WARNING: Here endeth the historical research section>

> Its to allow the CUA to uniquely identify any VALARM in
> any component. Read up on the MODIFY command debate.
Umm, SEQUENCE does not uniquely identify the VALARM the way its defined by iCalendar.  iCalendar defines SEQUENCE as:

   Purpose: This property defines the revision sequence number of the
  calendar component within a sequence of revisions.

so its clearly a revision tracking propery, not a identification type property like UID:

   Purpose: This property defines the persistent, globally unique
  identifier for the calendar component.

CAP appears to be reusing SEQUENCE incorrectly and _implicitly_ assuming that every VALARM will have one that never changes no matter how often or when the VALARM is changed.  Since a VALARM can repeat using iCalendar recurrence rules or dates, if you kept the current iCalendar specified behaviour for changing SEQUENCE on property changes like RRULEs or RDATEs then SEQUENCE would change on a VALARM which could make it NOT unique.   Of course you could change the defined behaviour of SEQUENCE while you are at it but that is a totally separate discussion!

>    In addition a problem exists with the control of "VALARM" components
>    and their "TRIGGER" properties. A CU may wish to set their own alarm
>    (local alarms) on components. These local alarms are not to be
>    forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property
>    and the "ENABLE" parameter. So for the protocol between a CUA and a
>    CS, the following changes apply to the CAP protocol from [iCAL]
>    section 4.6.6 page 67:
>
> This was so you could add local VALARMs that are not to be
> forwarded. Read the debate on MODIFY and COUNTER where
> a CU wished to COUNTER an object and NOT have the VALARMs
> deleted or added that are local.
Local alarms are not relevant to this discussion.  I grok the need and use for local alarms vs ones an Organizer may send.  The line:

                                    These local alarms are not to be
   forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property
   and the "ENABLE" parameter.

reads that neither local alarms NOR any SEQUENCE propery NOR any ENABLE parameter can be forwarded.  This implys that SEQUENCE is locally maintained by the CUA for its own purpose.  The stated intent was to uniquely identify the VALARMs but thats not how SEQUENCE is defined in iCalendar; that is how UID is defined though.  So if anything, the property to add would be UID (or ALARMID as previously mentioned).

> We have already had this debate. I see no new information in your post.
Too bad you didnt provide the citation to the previous discussion on this to save some time avoiding rehashing any old concepts...  Providing it would save us time and thrashing.

Since Doug is reluctant to provide a reference that he appears to have found Ill ask again:

_Why_ does the CUA need to have this identification mechanism for VALARMs since they do not exist outside other uniquely identified components nor are they sent alone via iTIP?  

If its for modification, the MODIFY command already provides text on how to do this for _any_ component type so I fail to see the need to (incorrectly) tweak VALARMs.  If its for some other need, Id like to know what it is so we dont make unnecesary changes to iCalendar.  

Anyone?  If there is a demonstratable need for adding an identifer to VALARMs then ok but if not, Im against adding it.  So far I have seen no demonstratable need...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0050160785256DC6_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 21 14:08:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28524 for ; Tue, 21 Oct 2003 14:08:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHrlI7033473 for ; Tue, 21 Oct 2003 10:53:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LHrlOF033472 for ietf-calendar-bks; Tue, 21 Oct 2003 10:53:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHrjI7033461 for ; Tue, 21 Oct 2003 10:53:45 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h9LHrcs4016217 for ; Tue, 21 Oct 2003 11:53:39 -0600 (MDT) Message-ID: <3F957298.2538EB2@INET-Calendar.net> Date: Tue, 21 Oct 2003 11:53:29 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-e: Alarms and SEQUENCE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > Since Doug is reluctant to provide a reference that he appears to have found Ill ask again: > Why do you continue to blame others? Why do you not ask the chairs? Do they not track consensus? I for one do not want sequence to change. It seems obvious that it is used to uniquely track valarms in components. Even your own original post quoted that. And you posted no solution to the problems that your own email said sequence solved. I say please do not change it, cap (other than some typos that I found and rewording that others have requested) is technically ready. From owner-ietf-calendar@mail.imc.org Tue Oct 21 15:20:41 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02525 for ; Tue, 21 Oct 2003 15:20:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LJ36I7036004 for ; Tue, 21 Oct 2003 12:03:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LJ36Si036003 for ietf-calendar-bks; Tue, 21 Oct 2003 12:03:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LJ34I7035998 for ; Tue, 21 Oct 2003 12:03:05 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9LJ32c0022399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 21 Oct 2003 12:03:03 -0700 Message-ID: <3F9582E1.1050609@Royer.com> Date: Tue, 21 Oct 2003 13:02:57 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-e: Alarms and SEQUENCE References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000301000404000405030901" X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-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. --------------ms000301000404000405030901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > so may be a bit long before returning to the technical bits> > > Doug replied on 10/20/2003 07:13:30 PM: > > Please read the archives (which you participated in), in summary: > > Ok, that confirms that I did ask about it before. Guess I never got > an answer that made sense to me... Searching for VALARM and SEQUENCE > yeilds many matches so can you please reference the date of discussion > or the subject of the thread where we actually resolved this? > The archive is several megabytes in size. No I will not be posting it so that every thing is in context. That is why there is an archive on line. Yes you do seem to understand why removing SEQUENCE breaks MODIFY of VALARMS. So I too do not want to break MODIFY of VALARMS. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000301000404000405030901 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 9w0BCQUxDxcNMDMxMDIxMTkwMjU3WjAjBgkqhkiG9w0BCQQxFgQUJ1ESSDjd1dSd17miH+Wn nmzpAy4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAKDZDUq85D6i0sm7kENgNC7SlWIiA66xgaT3cG4gmFGBAkVhhyVJFTLaRat66FYl+ 71AVsbjc5Cvmo60XSP8+8kQc4ZZYUEmIezbHhVHtGTQ34C+LdgyFI5lfmmBxTs+E4BpCG4cq dXaeokerPP19kSSQK+kdNas/ndf4PvcAl1tjC4aYKYjdfEwXrN68Ba5o5twnkCB4Ybh+c+Xo l2pDA3ySB5Gh6J5g7vmANFOJ7e6CWtjPmp9rXoy1ESAnJIxyETVhslWI24YvAt5exu2RQdUT ajJHTOFV0Mx4LyGOoU5nFuQW6FcJdfjqw9igi/U6gbelbGrUfEPHr3tYOMjBpgAAAAAAAA== --------------ms000301000404000405030901-- From bloren@email.com Wed Oct 22 10:05:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09800 for ; Wed, 22 Oct 2003 10:05:55 -0400 (EDT) Received: from 0IJRIMXOOP0QMP3 ([61.48.72.19]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9MDrlI7041757 for ; Wed, 22 Oct 2003 06:54:00 -0700 (PDT) (envelope-from bloren@email.com) Message-Id: <200310221354.h9MDrlI7041757@above.proper.com> From: "bloren@email.com" To: "ietf-calendar-bks@above.proper.com" Subject: feel like you where 18 again Date: Wed, 22 Oct 2003 21:57:39 +0800 X-Priority: 3 (normal) Importance: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+PFRJVExFPnJhbmQ8L1RJVExFPjwvSEVBRD4NCjxCT0RZIGJnY29sb3I9ImJs dWVzIj48ZGl2IGFsaWduPSJjZW50ZXIiPg0KPHRhYmxlIHdpZHRoPTUwMHB4IGJnY29sb3I9ImJs YWNrIiBib3JkZXJjb2xvcmRhcms9IndoaXRlIiBib3JkZXJjb2xvcmxpZ2h0PSJ3aGl0ZSIgYm9y ZGVyPSIxIiBjZWxscGFkZGluZz0wIGNlbGxzcGFjaW5nPTA+PHRyPjx0ZCBhbGlnbj0iY2VudGVy Ij4NCjxmb250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEiIGNvbG9yPSJ3aGl0ZSI+PGI+TEFURVNU IEJSRUFLVEhST1VHSCAtIE5FV1MgRkxBU0g8L2I+PC9mb250Pg0KPC90ZD48L3RyPjwvdGFibGU+ DQo8YnI+DQo8dGFibGUgd2lkdGg9NTAwcHggYmdjb2xvcj0iYmxhY2siIGJvcmRlcmNvbG9yZGFy az0ieWVsbG93IiBib3JkZXJjb2xvcmxpZ2h0PSJ5ZWxsb3ciIGJvcmRlcj0iMSIgY2VsbHBhZGRp bmc9MCBjZWxsc3BhY2luZz0wPjx0cj48dGQgYWxpZ249ImNlbnRlciI+DQo8Zm9udCBzaXplPSIz IiBmYWNlPSJWZXJkYW5hIiBjb2xvcj0id2hpdGUiPjxiPjxicj4NClRoZSA8Zm9udCBjb2xvcj0i cmVkIj5CQUQ8L2ZvbnQ+IE5ld3M6IDxpPkFzIHlvdSBBZ2UgeW91ciBib2R5IHByb2R1Y2VzIGxl c3MgaG9ybW9uZXMgY2F1c2luZyB5b3UgdG8gbG9vayBvbGRlciwgZmVlbCBvbGRlciBhbmQgYmUg d2Vha2VyITwvaT4NCjxicj48YnI+DQombmJzcDtUaGUgPGZvbnQgY29sb3I9IiMwMENDNjYiPkdP T0Q8L2ZvbnQ+IE5ld3M6IDxpPkV4cGVydHMgaW4gdGhlIE5ldyBFbmdsYW5kIEpvdXJuYWwgb2Yg TWVkaWNpbmUsIHJlcG9ydCB0aGF0IEh1bWFuIEdyb3d0aCBIb3Jtb25lIHRoZXJhcHkgbWFrZXMg eW91IGxvb2sgYW5kIGZlZWwgMjAgWUVBUlMgWU9VTkdFUiE8L2k+PGJyPjxicj48L2I+PC9mb250 Pg0KPC90ZD48L3RyPjwvdGFibGU+DQo8YnI+DQo8dGFibGUgd2lkdGg9NTAwcHggYmdjb2xvcj0i d2hpdGUiIGJvcmRlcmNvbG9yZGFyaz0id2hpdGUiIGJvcmRlcmNvbG9ybGlnaHQ9IndoaXRlIiBi b3JkZXI9IjEiIGNlbGxwYWRkaW5nPTAgY2VsbHNwYWNpbmc9MD48dHI+PHRkIGFsaWduPSJjZW50 ZXIiPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmxhbmsuY29tLyI+PGZvbnQgc2l6ZT0iNSIg ZmFjZT0iVmVyZGFuYSIgY29sb3I9ImJsdWUiPjxiPkNsaWNrIEhlcmUgRm9yIE1vcmUgSW5mbzwv Yj48L2ZvbnQ+PC9hPjxicj48YnI+DQo8L3RkPjwvdHI+PC90YWJsZT4NCjwvZGl2PjwvQk9EWT48 L0hUTUw+DQo= From owner-ietf-calendar@mail.imc.org Wed Oct 22 10:48:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12675 for ; Wed, 22 Oct 2003 10:48:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEaAI7043690 for ; Wed, 22 Oct 2003 07:36:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MEaAZa043689 for ietf-calendar-bks; Wed, 22 Oct 2003 07:36:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEa9I7043684 for ; Wed, 22 Oct 2003 07:36:09 -0700 (PDT) (envelope-from damon@karuna.uklinux.net) Received: from [192.168.0.2] (unknown [81.86.72.204]) by pengo.systems.pipex.net (Postfix) with ESMTP id C95214C00718 for ; Wed, 22 Oct 2003 15:36:08 +0100 (BST) Subject: vzic Olson->iCalendar timezone converter update From: Damon Chaplin To: ietf-calendar@imc.org Content-Type: text/plain Message-Id: <1066833372.3861.19.camel@snowflake> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 22 Oct 2003 15:36:12 +0100 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I've recently updated the vzic timezone converter and the new version can be found at: http://www.dachaplin.dsl.pipex.com/vzic (The new version is basically the same version that was used to create Evolution's timezone files, but tidied up a bit.) Damon From owner-ietf-calendar@mail.imc.org Wed Oct 22 13:34:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18794 for ; Wed, 22 Oct 2003 13:34:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MHInI7051954 for ; Wed, 22 Oct 2003 10:18:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MHInFf051953 for ietf-calendar-bks; Wed, 22 Oct 2003 10:18:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MHImI7051948 for ; Wed, 22 Oct 2003 10:18:48 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9MHIjc0006802 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 10:18:46 -0700 Message-ID: <3F96BBEC.70705@Royer.com> Date: Wed, 22 Oct 2003 11:18:36 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: vzic Olson->iCalendar timezone converter update References: <1066833372.3861.19.camel@snowflake> In-Reply-To: <1066833372.3861.19.camel@snowflake> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000002000402040406010000" X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-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. --------------ms000002000402040406010000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit THANKS! I have been looking for that! I had one, but it belongs to a previous employer of mine and I could not make the sources public or comment on its implementation. I was just about to start with the zdump PD source and create a new one from scratch. THANKS! Damon Chaplin wrote: >Hi, > >I've recently updated the vzic timezone converter and the new version >can be found at: > > http://www.dachaplin.dsl.pipex.com/vzic > > >(The new version is basically the same version that was used to create >Evolution's timezone files, but tidied up a bit.) > >Damon > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000002000402040406010000 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 9w0BCQUxDxcNMDMxMDIyMTcxODM2WjAjBgkqhkiG9w0BCQQxFgQUg5mrswlBqq/CR9jrHmhk VLdnqK0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAf1A00S/xzXoDemLarNIM0sRsqP4ksKzehIfxbQaEgpOmOf7biyEZeTfxqboUlfAt nZl8SL7ZoHNYg4REXZ10KsYy7YIJ83CPNUzn8B2htzUSi4Tbdg1/FOH9ADwSdkh4IQ1pAk+C dOQqBDAdPOBQdu6MqWAkI4DV3wUdZL5YG8riWxQ187Q75dRko2hROcNBmlRkxDoF/6UMnLna SZW2GD0c1xdQmRuO1pezwJDNfhCdrcfMisViU5rxWQoVimR5dOEr3gkFyJj7stsLFf3yklwl 3YO/t4fYxgR/NVJOjtmtZvezpafA3KGcY27K3gzkyEDZmd5876TzQL18Vn3g4QAAAAAAAA== --------------ms000002000402040406010000-- From owner-ietf-calendar@mail.imc.org Wed Oct 22 14:22:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20853 for ; Wed, 22 Oct 2003 14:22:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MI91I7054110 for ; Wed, 22 Oct 2003 11:09:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MI916c054109 for ietf-calendar-bks; Wed, 22 Oct 2003 11:09:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MI90I7054104 for ; Wed, 22 Oct 2003 11:09:00 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F9582E1.1050609@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Alarms and SEQUENCE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 22 Oct 2003 14:02:53 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/22/2003 02:08:56 PM, Serialize complete at 10/22/2003 02:08:56 PM Content-Type: multipart/alternative; boundary="=_alternative 0063060A85256DC7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063060A85256DC7_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/21/2003 03:02:57 PM: > The archive is several megabytes in size. No I will not be posting it so > that every thing > is in context. That is why there is an archive on line. A simple citation with post, subject or date are sufficient. I found some going back as far as 2000 but I found NOTHING in the archives to support the _need_ for the change. > Yes you do seem to understand why removing SEQUENCE breaks MODIFY > of VALARMS. So I too do not want to break MODIFY of VALARMS. Umm, no. Given the text of MODIFY I see no demonstratable need to have a unique identifer on each alarm inside any component that already has a unique identifer. MODIFY already says how to uniquely identify the bits to be changed (ie the VALARM) so _why_ do we need to misuse SEQUENCE? Despite your previous assertions I did manage to find mention of ids on alarms dating back to 2000: I can find NO evidence of IETF meeting discussion of the need prior to you listing it as an issue starting ~April 2000 nor any WG mention (let alone discussion of it) until ~Nov 2001, nearly a year and a half after it first appeared on your CAP issues list. We did discuss using UID vs ALARMID (or ALARM-ID to some) in late 2001/ early 2002 and then you magically changed it to SEQUENCE ~Feb 2002. However I think that we have no _demonstratable_need_ to modify VALARMs to have unique identifiers. Or as you put it back on 07/10/2000: ALARMID's are needed CAP because it would be impossible to modify an alarm without being able to identify which of multiple alarms in a component would be the target of the METHOD:MODIFY. The MODIFY command is pretty clear on dealing with identification of data to be changed (see previous msg) so I again have to ask why we need to mis-reuse SEQUENCE by adding it to VALARMs? (The change from the WG agreed on UID is a different question...) Can you _please_ provide a simple example of a MODIFY command that needs to have SEQUENCE on the VALARM in order to work correctly?? Perhaps the ever enthusiastic Mark can do this for you if you are too busy... I think the MODIFY command does not need this change to VALARMs. If it really does not then Im against making the change to iCalendar. However if its there for non-demonstratable reasons then it should not be made to iCalendar. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0063060A85256DC7_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/21/2003 03:02:57 PM:
> The archive is several megabytes in size. No I will not be posting it so
> that every thing
> is in context. That is why there is an archive on line.
A simple citation with post, subject or date are sufficient.  I found some going back as far as 2000 but I found NOTHING in the archives to support the _need_ for the change.

> Yes you do seem to understand why removing SEQUENCE breaks MODIFY
> of VALARMS. So I too do not want to break MODIFY of VALARMS.
Umm, no.  Given the text of MODIFY I see no demonstratable need to have a unique identifer on each alarm inside any component that already has a unique identifer.  MODIFY already says how to uniquely identify the bits to be changed (ie the VALARM) so _why_ do we need to misuse SEQUENCE?

Despite your previous assertions I did manage to find mention of ids on alarms dating back to 2000: I can find NO evidence of IETF meeting discussion of the need prior to you listing it as an issue starting ~April 2000 nor any WG mention (let alone discussion of it) until ~Nov 2001, nearly a year and a half after it first appeared on your CAP issues list.  We did discuss using UID vs ALARMID (or ALARM-ID to some) in late 2001/ early 2002 and then you magically changed it to SEQUENCE ~Feb 2002.  

However I think that we have no _demonstratable_need_ to modify VALARMs to have unique identifiers.  Or as you put it back on 07/10/2000:

ALARMID's are needed CAP because it would be impossible to
modify an alarm without being able to identify which of multiple
alarms in a component would be the target of the METHOD:MODIFY.

The MODIFY command is pretty clear on dealing with identification of data to be changed (see previous msg) so I again have to ask why we need to mis-reuse SEQUENCE by adding it to VALARMs?  (The change from the WG agreed on UID is a different question...)

Can you _please_ provide a simple example of a MODIFY command that needs to have SEQUENCE on the VALARM in order to work correctly??  Perhaps the ever enthusiastic Mark can do this for you if you are too busy...

I think the MODIFY command does not need this change to VALARMs.  If it really does not then Im against making the change to iCalendar.  However if its there for non-demonstratable reasons then it should not be made to iCalendar.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0063060A85256DC7_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 22 15:13:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23101 for ; Wed, 22 Oct 2003 15:13:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MIrGI7056177 for ; Wed, 22 Oct 2003 11:53:16 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MIrGOL056176 for ietf-calendar-bks; Wed, 22 Oct 2003 11:53:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MIrEI7056167 for ; Wed, 22 Oct 2003 11:53:14 -0700 (PDT) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id h9MIr9Ar005447 for ; Wed, 22 Oct 2003 12:53:09 -0600 (MDT) Message-ID: <3F96D215.E2E13711@INET-Calendar.net> Date: Wed, 22 Oct 2003 12:53:09 -0600 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Alarms and SEQUENCE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > Umm, no. Given the text of MODIFY I see no demonstratable need to > have a unique identifer on each alarm inside any component that > already has a unique identifer. MODIFY already says how to uniquely > identify the bits to be changed (ie the VALARM) so _why_ do we need to > misuse SEQUENCE? You still propse to break MODIFY wihout any solution. No one wants to break modify. I do not know which version if any draft or published text you have been reading, but I can not find ANY other unique identifier for VALARMS. What is it? From owner-ietf-calendar@mail.imc.org Wed Oct 22 16:12:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25794 for ; Wed, 22 Oct 2003 16:12:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MJomI7058836 for ; Wed, 22 Oct 2003 12:50:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MJom24058835 for ietf-calendar-bks; Wed, 22 Oct 2003 12:50:48 -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.10/8.12.8) with ESMTP id h9MJolI7058830 for ; Wed, 22 Oct 2003 12:50:47 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9MJokc0008828 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 12:50:47 -0700 Message-ID: <3F96DF90.8030704@Royer.com> Date: Wed, 22 Oct 2003 13:50:41 -0600 From: Doug Royer Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: CAP-12 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090409080901000203010800" X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-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. --------------ms090409080901000203010800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have finished editing in the typos sent to me and the list. I have clarified the paragraphs that were sent to this list. The only open proposal is Bruce's proposal to break modify with no proposed solution which I do not see as having any support. Bruce's proposal at this time would need to have consensus called by the chairs to make that kind of changes. There are no more action items. I will post -12 to the IETF tomorrow if there are no more items posted. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090409080901000203010800 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 9w0BCQUxDxcNMDMxMDIyMTk1MDQxWjAjBgkqhkiG9w0BCQQxFgQU7ZkMNVqwVjlRFWfFQ/dQ 4tDgKKkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAPZKfUuoNAE1G5dqyhec3qFhaMAlTkNgoQcrVVhP6hkQK7xHj3mGzZ9J2/pcyErtS j9rwQiM7a1XMn/2TOkQpnfQj6SVw5xNwfXxhB+1svF420yRU/kkqLnvolSRVhPSiOxo4Fbbc YBJWx7CBM96nJW77STC66rXLSRV7UEo62YDFrWuCdhLPJDdJSdDnpi+hrADdhePdtt6BuoIP +9pTvXPgWObw6fsuws5mg48268m30VXO8zHHABndv2NwBdHzE50UxwRo3Thgcb9cIvEwbOcl Avq/E5qHmoL5t6N+mNS/Nc8gpWVeP5N20h2Tv6s6mGoRRzvnz+dvbEdk4upEwQAAAAAAAA== --------------ms090409080901000203010800-- From owner-ietf-calendar@mail.imc.org Wed Oct 22 16:34:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26859 for ; Wed, 22 Oct 2003 16:34:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKIxI7060216 for ; Wed, 22 Oct 2003 13:18:59 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MKIxE9060215 for ietf-calendar-bks; Wed, 22 Oct 2003 13:18:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKIwI7060209 for ; Wed, 22 Oct 2003 13:18:58 -0700 (PDT) (envelope-from damon@karuna.uklinux.net) Received: from [192.168.0.2] (81-86-87-12.dsl.pipex.com [81.86.87.12]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 50A141C00ECA for ; Wed, 22 Oct 2003 21:18:56 +0100 (BST) Subject: Re: vzic Olson->iCalendar timezone converter update From: Damon Chaplin To: ietf-calendar@imc.org In-Reply-To: <3F96BBEC.70705@Royer.com> References: <1066833372.3861.19.camel@snowflake> <3F96BBEC.70705@Royer.com> Content-Type: text/plain Message-Id: <1066853941.2706.6.camel@snowflake> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 22 Oct 2003 21:19:01 +0100 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit You're welcome. I've just released version 1.1, to fix the problem you found in the newer tzdata2003d. (They started using times of 24:00 in the files!) Damon On Wed, 2003-10-22 at 18:18, Doug Royer wrote: > THANKS! > > I have been looking for that! > > I had one, but it belongs to a previous employer of mine and I could not > make the sources public or comment on its implementation. I was just > about to start > with the zdump PD source and create a new one from scratch. > > THANKS! > > Damon Chaplin wrote: > > >Hi, > > > >I've recently updated the vzic timezone converter and the new version > >can be found at: > > > > http://www.dachaplin.dsl.pipex.com/vzic > > > > > >(The new version is basically the same version that was used to create > >Evolution's timezone files, but tidied up a bit.) > > > >Damon > > > > > > From owner-ietf-calendar@mail.imc.org Wed Oct 22 17:41:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28991 for ; Wed, 22 Oct 2003 17:41:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MLInI7062706 for ; Wed, 22 Oct 2003 14:18:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MLInCi062705 for ietf-calendar-bks; Wed, 22 Oct 2003 14:18:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MLIlI7062698 for ; Wed, 22 Oct 2003 14:18:47 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9MLIjc0010146 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 14:18:46 -0700 Message-ID: <3F96F42B.2050902@Royer.com> Date: Wed, 22 Oct 2003 15:18:35 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: vzic Olson->iCalendar timezone converter update References: <1066833372.3861.19.camel@snowflake> <3F96BBEC.70705@Royer.com> <1066853941.2706.6.camel@snowflake> In-Reply-To: <1066853941.2706.6.camel@snowflake> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010900030707010609060403" X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-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. --------------ms010900030707010609060403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If anyone wants to the see the output, I have run this tool and converted all of them to one MEGA .isc file: http://INET-Consulting.com/VTIMEZONE.ics Damon Chaplin wrote: >You're welcome. > >I've just released version 1.1, to fix the problem you found in the >newer tzdata2003d. (They started using times of 24:00 in the files!) > >Damon > > >On Wed, 2003-10-22 at 18:18, Doug Royer wrote: > > >>THANKS! >> >>I have been looking for that! >> >>I had one, but it belongs to a previous employer of mine and I could not >>make the sources public or comment on its implementation. I was just >>about to start >>with the zdump PD source and create a new one from scratch. >> >>THANKS! >> >>Damon Chaplin wrote: >> >> >> >>>Hi, >>> >>>I've recently updated the vzic timezone converter and the new version >>>can be found at: >>> >>> http://www.dachaplin.dsl.pipex.com/vzic >>> >>> >>>(The new version is basically the same version that was used to create >>>Evolution's timezone files, but tidied up a bit.) >>> >>>Damon >>> >>> >>> >>> >>> -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010900030707010609060403 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 9w0BCQUxDxcNMDMxMDIyMjExODM1WjAjBgkqhkiG9w0BCQQxFgQUjBySv4zQ5bGcQ/SaEYVA DNLJQnkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAU2GOBPpiq8Ep+kvKnCwyoftSiGiJYaKCu/5DBK+2CXQAOHoUlkmDp+LrpHgaYeiZ 8s9gkVJ6qvXsbC62gMf9i/yydORT629SExXOPETulntH5kJk0sz1FyyIgozJronMSDvDcxCb el99fEVFRfOKxDbUA6aqVb1P9Nop3xBK5svCQDWE6EgsnPTyFYxiR9KUMhckk1rHIcRWmQ2L EUQ6YbuQJHqpw7VMuI6kNv5uw85zl2rxngwaiJLFzem94YzA08DMXUEg1IQHQkG0MJvKn/ea AFE9p2cboqtc30Cstsdq9znm0EOiEEs7Un/tmnUTEZLOHyP0B0DLXZc5KDOaeAAAAAAAAA== --------------ms010900030707010609060403-- From owner-ietf-calendar@mail.imc.org Wed Oct 22 23:36:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16696 for ; Wed, 22 Oct 2003 23:36:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N3OoI7076853 for ; Wed, 22 Oct 2003 20:24:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9N3OooN076851 for ietf-calendar-bks; Wed, 22 Oct 2003 20:24:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N3OmI7076841 for ; Wed, 22 Oct 2003 20:24:48 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (rwcrmhc13) with SMTP id <2003102303244601500oikh6e> (Authid: TimHare); Thu, 23 Oct 2003 03:24:46 +0000 Message-Id: <5.2.1.1.0.20031022231534.00a28030@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 22 Oct 2003 23:17:17 -0400 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: vzic Olson->iCalendar timezone converter update In-Reply-To: <3F96F42B.2050902@Royer.com> References: <1066853941.2706.6.camel@snowflake> <1066833372.3861.19.camel@snowflake> <3F96BBEC.70705@Royer.com> <1066853941.2706.6.camel@snowflake> 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: Just a question: in the resultant output file, each timezone definition seems to be bracketed with BEGIN: VCALENDAR and END: VCALENDAR. Is it also legal to drop those and just have a BEGIN:VCALENDAR at the front and an END: VCALENDAR at the end, or am I reading RFC2445's description of timezones incorrectly? Tim At 03:18 PM 10/22/03 -0600, you wrote: >If anyone wants to the see the output, I have run this tool and converted all >of them to one MEGA .isc file: > > http://INET-Consulting.com/VTIMEZONE.ics > >Damon Chaplin wrote: > >>You're welcome. >> >>I've just released version 1.1, to fix the problem you found in the >>newer tzdata2003d. (They started using times of 24:00 in the files!) >> >>Damon >> >> >>On Wed, 2003-10-22 at 18:18, Doug Royer wrote: >> >> >>>THANKS! >>> >>>I have been looking for that! >>> >>>I had one, but it belongs to a previous employer of mine and I could not >>>make the sources public or comment on its implementation. I was just >>>about to start >>>with the zdump PD source and create a new one from scratch. >>> >>>THANKS! >>> >>>Damon Chaplin wrote: >>> >>> >>> >>>>Hi, >>>> >>>>I've recently updated the vzic timezone converter and the new version >>>>can be found at: >>>> >>>> http://www.dachaplin.dsl.pipex.com/vzic >>>> >>>> >>>>(The new version is basically the same version that was used to create >>>>Evolution's timezone files, but tidied up a bit.) >>>> >>>>Damon >>>> >>>> >>>> > >-- > >Doug Royer | http://INET-Consulting.com >-------------------------------|----------------------------- >Doug@Royer.com | Office: (208)612-INET >http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > > > From owner-ietf-calendar@mail.imc.org Wed Oct 22 23:38:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16804 for ; Wed, 22 Oct 2003 23:38:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N3OpI7076856 for ; Wed, 22 Oct 2003 20:24:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9N3Opwh076855 for ietf-calendar-bks; Wed, 22 Oct 2003 20:24:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N3OmI8076841 for ; Wed, 22 Oct 2003 20:24:49 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (rwcrmhc13) with SMTP id <2003102303244601500oikh7e> (Authid: TimHare); Thu, 23 Oct 2003 03:24:47 +0000 Message-Id: <5.2.1.1.0.20031022231726.00a28a20@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 22 Oct 2003 23:19:33 -0400 To: ietf-calendar@imc.org From: Tim Hare Subject: One more open issue (to me) In-Reply-To: <3F96F42B.2050902@Royer.com> References: <1066853941.2706.6.camel@snowflake> <1066833372.3861.19.camel@snowflake> <3F96BBEC.70705@Royer.com> <1066853941.2706.6.camel@snowflake> 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 don't know how one asks the chair to call consenus, but I would like to have that happen regarding my proposal of a few weeks ago to have calscale-prop be added as a required response to the GET-CAPABILITY command, to allow CUAs to determine which CALSCALEs another endpoint supports. Tim Hare Interested Bystander, non-inc. From owner-ietf-calendar@mail.imc.org Thu Oct 23 03:52:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07350 for ; Thu, 23 Oct 2003 03:52:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N7cMI7022456 for ; Thu, 23 Oct 2003 00:38:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9N7cMQU022455 for ietf-calendar-bks; Thu, 23 Oct 2003 00:38:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.lisanza.net (harrie.inet.it [213.92.1.193]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N7cKI7022396 for ; Thu, 23 Oct 2003 00:38:21 -0700 (PDT) (envelope-from harrie@inet.it) Received: from inet.it (localhost [127.0.0.1]) by localhost.lisanza.net (8.12.9/8.12.6) with ESMTP id h9N7dMIw002568; Thu, 23 Oct 2003 09:39:22 +0200 (CEST) Date: Thu, 23 Oct 2003 09:39:20 +0200 Subject: Re: CAP-12 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel To: ietf-calendar@imc.org, Doug Royer From: Harrie Hazewinkel In-Reply-To: <3F96DF90.8030704@Royer.com> Message-Id: <03ADA36E-052C-11D8-9485-0003934A5A7E@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, October 22, 2003, at 09:50 PM, Doug Royer wrote: > > I have finished editing in the typos sent to me and the list. a typo I found: MODIFY command section -> "one ore more" should be "one or more" > I have clarified the paragraphs that were sent to this list. > > The only open proposal is Bruce's proposal to break modify with > no proposed solution which I do not see as having any support. > Bruce's proposal at this time would need to have consensus > called by the chairs to make that kind of changes. > > There are no more action items. > > I will post -12 to the IETF tomorrow if there are no more items posted. I have a more general issue which is not real technical, but more editorial/ clarifying. In the section 10.1 Cap Commands. For all commands the formal definition of a command is given, but not for the associated request. This is in contrast to the responses which are provided. For a command the document only provides the CMD line defnition and the parameters allow in this CMD line. For the response the document specifies the complete 'BEGIN:VCALENDAR ..... END:VCALENDER' definition. And my impression is that, for instance, the modify command does this half way. OK, one can derive things from the examples, but that is not wished for I guess. harrie From owner-ietf-calendar@mail.imc.org Fri Oct 24 06:04:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23369 for ; Fri, 24 Oct 2003 06:04:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9O9mXI7070075 for ; Fri, 24 Oct 2003 02:48:33 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9O9mX0a070074 for ietf-calendar-bks; Fri, 24 Oct 2003 02:48:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.lisanza.net (host194-50.pool80117.interbusiness.it [80.117.50.194]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9O9mVI7070062 for ; Fri, 24 Oct 2003 02:48:32 -0700 (PDT) (envelope-from harrie@inet.it) Received: from inet.it (localhost [127.0.0.1]) by localhost.lisanza.net (8.12.9/8.12.6) with ESMTP id h9O9nfIw003405; Fri, 24 Oct 2003 11:49:41 +0200 (CEST) Date: Fri, 24 Oct 2003 11:49:39 +0200 Subject: DELETE command Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel To: calsch wg IETF From: Harrie Hazewinkel Content-Transfer-Encoding: 7bit Message-Id: <62C578EE-0607-11D8-8438-0003934A5A7E@inet.it> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I have some question of the DELETE command section. 1) As it is described the DELETE command section this command is used to delete calendars or components. Do I miss something if I say that the SELECT clause value of a VQUERY may only have the component names?? For example, valid queries are; SELECT VEVENT FROM VAGENDA WHERE UID='123' SELECT VALARM FROM VEVENT WHERE VEVENT.UID='456' For example, invalid queries are; SELECT DUE FROM VTODO WHERE UID='789' SELECT DTSTART FROM VEVENT WHERE VEVENT.UID='012' If this is correct I would suggest some text will be added to make this more explicit. ( personally, I believe that the first sentence under the formal definition of the command 'The "DELETE" command is used to delete calendars or components.' is more useful as the 'Purpose:'. then the current 'Purpose:'. Maybe it can be moved? ) 2) I do not understand what is ment by the last sentence of page 107 (cap draft 11) 'Restriction Table ....command.' reagrds, Harrie From owner-ietf-calendar@mail.imc.org Sat Oct 25 13:31:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10260 for ; Sat, 25 Oct 2003 13:31:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9PHH7I7005673 for ; Sat, 25 Oct 2003 10:17:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9PHH7wP005672 for ietf-calendar-bks; Sat, 25 Oct 2003 10:17:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9PHH6I7005667 for ; Sat, 25 Oct 2003 10:17:06 -0700 (PDT) (envelope-from damon@karuna.uklinux.net) Received: from [192.168.0.2] (81-178-247-124.dsl.pipex.com [81.178.247.124]) by colossus.systems.pipex.net (Postfix) with ESMTP id 68549160003DC; Sat, 25 Oct 2003 18:17:04 +0100 (BST) Subject: Re: vzic Olson->iCalendar timezone converter update From: Damon Chaplin To: Tim Hare Cc: ietf-calendar@imc.org In-Reply-To: <5.2.1.1.0.20031022231534.00a28030@mail.comcast.net> References: <1066853941.2706.6.camel@snowflake> <1066833372.3861.19.camel@snowflake> <3F96BBEC.70705@Royer.com> <1066853941.2706.6.camel@snowflake> <5.2.1.1.0.20031022231534.00a28030@mail.comcast.net> Content-Type: text/plain Message-Id: <1067102230.2588.49.camel@snowflake> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 25 Oct 2003 18:17:10 +0100 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes, you can drop the BEGIN/END VCALENDARs, and just leave 1 pair. That would probably be preferable in a real app. By the way, I've put another new version, 1.2, up at: http://www.dachaplin.dsl.pipex.com/vzic This has a few more minor changes. Damon On Thu, 2003-10-23 at 04:17, Tim Hare wrote: > Just a question: in the resultant output file, each timezone definition > seems to be bracketed with BEGIN: VCALENDAR and END: VCALENDAR. Is it also > legal to drop those and just have a BEGIN:VCALENDAR at the front and an > END: VCALENDAR at the end, or am I reading RFC2445's description of > timezones incorrectly? > From owner-ietf-calendar@mail.imc.org Fri Oct 31 14:10:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14006 for ; Fri, 31 Oct 2003 14:10:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIsWkT002274 for ; Fri, 31 Oct 2003 10:54:32 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIsWva002273 for ietf-calendar-bks; Fri, 31 Oct 2003 10:54:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIsTkT002263 for ; Fri, 31 Oct 2003 10:54:32 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F9582E1.1050609@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Alarms and SEQUENCE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 31 Oct 2003 13:42:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/31/2003 01:54:33 PM, Serialize complete at 10/31/2003 01:54:33 PM Content-Type: multipart/alternative; boundary="=_alternative 00667E9785256DD0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00667E9785256DD0_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/21/2003 03:02:57 PM: > Yes you do seem to understand why removing SEQUENCE breaks MODIFY > of VALARMS. So I too do not want to break MODIFY of VALARMS. Actually thats not what I said but Ive already pointed that out. In the interest of resovling this quicker I took time to go reread CAP-12-e, Section 10.9 MODIFY Command again to see if I had just missed something originally. After doing this I find that I still disagree with Dougs assertion that removing SEQUENCE from VALARMs breaks MODIFY. Lets take a look at the text and example to see why it does not break MODIFY. First off, the command says (in part): The old-values is a component and the contents of that component are going to change and may contain information that helps uniquely identify the original component (SEQUENCE in the example below). If the CS can not find a component that matches the QUERY and does not have at least all of the OLD-VALUES, then a 6.1 error is returned. so a CUA does _not_ need to have an identifier for VALARMs, it merely needs to send back a VALARM fragment that "contain[s] information that helps uniquely identify". That is, if there are multiple VALARMs such as 1 ACTION:DISPLAY and 1 ACTION:AUDIO then the CUA merely needs to send back the correct ACTION property and value to identify which alarm is being modified. If there is just 1 VALARM, any VALARM fragment should match uniquely. If you look at the example used, it is attempting to disable a VALARM on a particular VEVENT. The text currently states: Because "SEQUENCE" property is used to locate the "VALARM" component in this example, both the old-values and the new-values contain the "SEQUENCE" property with a value of "3" and if the "SEQUENCE" property were to be left out of new-values, it would have been deleted. However I contend that the use of SEQUENCE is unnecessary since its not changing nor is it necessary to identify the VALARM. The other VALARM properties in the example are equially sufficient to identify the VALARM without requiring the CUA to send SEQUENCE in both the old and new data blocks just to avoid deleting it. This MODIFY example can function equally well: C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//someone's prodid C: TARGET:my-cal C: CMD:ID=unique-mod:MODIFY C: BEGIN:VQUERY <- Query to select data set. C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58' C: END:VQUERY C: BEGIN:VEVENT <- Start of old data. C: LOCATION:building 3 C: LAST-MODIFIED:20020101T123456Z C: X-LOCAL:some private stuff C: BEGIN:VALARM C: TRIGGER;RELATED=END:PT5M C: END:VALARM C: END:VEVENT <- End of old data. C: BEGIN:VEVENT <- Start of new data. C: LOCATION:building 4 C: LAST-MODIFIED:20020202T010203Z C: COMMENT:Ignore global trigger. C: BEGIN:VALARM C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M C: END:VALARM C: END:VEVENT <- End of new data. for the single VALARM case and equally well for the multiple VALARM case where the TRIGGER value is unique per each VALARM. For the multiple VALARM case where TRIGGER (or whatever property is being modified) is not unique, you can use other properties like ACTION exactly the same way that SEQUENCE is currently used to correctly identify the VALARM in question. Another reason is that for other components (ie: VEVENTs, etc.) we do NOT use a unique identifier (ie: UID) as part of the old-data & new-data blocks when trying to indicate them for modification so there is no need to do so for VALARMs. The way the CS matches properties in the components works and Ive seen nothing to indicate that it would not work for subcomponents like VALARMs. Finally, the insistance that SEQUENCE be used to uniquely identify the VALARM implicitly says the use of old-data contents to match particular properties to change does not work when in fact it does. If I were to accept the "you need to have an identifier property for every component / sub-component you want to modify" argument then we would need to put some form of identifier into ALL components and subcomponents. For example to modify a particular VDAYLIGHT inside a given VTIMEZONE, you would have to have a unique identifer for every VDAYLIGHT inside the uniquely identified VTIMEZONE. For any X- type components / subcomponents, there would have to be some unique identifer as well but the CS will have no way of knowing exactly what is the 'unique identifier' property and which is just an experimental property thats being modified. The same goes for any IANA-components going forwards, you have no way to in advance know what the unique identifier property is going to be. So, since its not actually necssary to put an identifier on a VALARM to correctly find it for modification I again have to contest the need for this change to iCalendar. The _exact_ same result (modifying the correct VALARM) does not require adding SEQUENCE (or ALARMID as previously decided) to VALARM, it can simply and easily be done using the existing properties in the VALARM. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00667E9785256DD0_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/21/2003 03:02:57 PM:
> Yes you do seem to understand why removing SEQUENCE breaks MODIFY
> of VALARMS. So I too do not want to break MODIFY of VALARMS.
Actually thats not what I said but Ive already pointed that out.   In the interest of resovling this quicker I took time to go reread CAP-12-e, Section 10.9 MODIFY Command again to see if I had just missed something originally.  After doing this I find that I still disagree with Dougs assertion that removing SEQUENCE from VALARMs breaks MODIFY.

Lets take a look at the text and example to see why it does not break MODIFY.  First off, the command says (in part):

   The old-values is a component and the contents of that component are
  going to change and may contain information that helps uniquely
  identify the original component (SEQUENCE in the example below). If
  the CS can not find a component that matches the QUERY and does not
  have at least all of the OLD-VALUES, then a 6.1 error is returned.

so a CUA does _not_ need to have an identifier for VALARMs, it merely needs to send back a VALARM fragment that "contain[s] information that helps uniquely identify".  That is, if there are multiple VALARMs such as 1 ACTION:DISPLAY and 1 ACTION:AUDIO then the CUA merely needs to send back the correct ACTION property and value to identify which alarm is being modified.  If there is just 1 VALARM, any VALARM fragment should match uniquely.

If you look at the example used, it is attempting to disable a VALARM on a particular VEVENT.  The text currently states:

   Because "SEQUENCE" property is used to locate the "VALARM" component
  in this example,  both the old-values and the new-values contain the
  "SEQUENCE" property with a value of "3" and if the "SEQUENCE"
  property were to be left out of new-values, it would have been
  deleted.

However I contend that the use of SEQUENCE is unnecessary since its not changing nor is it necessary to identify the VALARM.  The other VALARM properties in the example are equially sufficient to identify the VALARM without requiring the CUA to send SEQUENCE in both the old and new data blocks just to avoid deleting it.  This MODIFY example can function equally well:

     C: Content-Type: text/calendar
    C:
    C: BEGIN:VCALENDAR
    C: VERSION:2.0
    C: PRODID:-//someone's prodid
    C: TARGET:my-cal
    C: CMD:ID=unique-mod:MODIFY
    C: BEGIN:VQUERY                   <- Query to select data set.
    C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58'
    C: END:VQUERY
    C: BEGIN:VEVENT                   <- Start of old data.
    C: LOCATION:building 3
    C: LAST-MODIFIED:20020101T123456Z
    C: X-LOCAL:some private stuff
    C: BEGIN:VALARM
    C: TRIGGER;RELATED=END:PT5M
    C: END:VALARM
    C: END:VEVENT                     <- End of old data.
    C: BEGIN:VEVENT                   <- Start of new data.
    C: LOCATION:building 4
    C: LAST-MODIFIED:20020202T010203Z
    C: COMMENT:Ignore global trigger.
    C: BEGIN:VALARM
    C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M
    C: END:VALARM
    C: END:VEVENT                     <- End of new data.

for the single VALARM case and equally well for the multiple VALARM case where the TRIGGER value is unique per each VALARM.  For the multiple VALARM case where TRIGGER (or whatever property is being modified) is not unique, you can use other properties like ACTION exactly the same way that SEQUENCE is currently used to correctly identify the VALARM in question.

Another reason is that for other components (ie: VEVENTs, etc.) we do NOT use a unique identifier (ie: UID) as part of the old-data & new-data blocks when trying to indicate them for modification so there is no need to do so for VALARMs.  The way the CS matches properties in the components works and Ive seen nothing to indicate that it would not work for subcomponents like VALARMs.

Finally, the insistance that SEQUENCE be used to uniquely identify the VALARM implicitly says the use of old-data contents to match particular properties to change does not work when in fact it does.  If I were to accept the "you need to have an identifier property for every component / sub-component you want to modify" argument then we would need to put some form of identifier into ALL components and subcomponents.  

For example to modify a particular VDAYLIGHT inside a given VTIMEZONE, you would have to have a unique identifer for every VDAYLIGHT inside the uniquely identified VTIMEZONE.  

For any X- type components / subcomponents, there would have to be some unique identifer as well but the CS will have no way of knowing exactly what is the 'unique identifier' property and which is just an experimental property thats being modified.  The same goes for any IANA-components going forwards, you have no way to in advance know what the unique identifier property is going to be.

So, since its not actually necssary to put an identifier on a VALARM to correctly find it for modification I again have to contest the need for this change to iCalendar.  The _exact_ same result (modifying the correct VALARM) does not require adding SEQUENCE (or ALARMID as previously decided) to VALARM, it can simply and easily be done using the existing properties in the VALARM.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00667E9785256DD0_=-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 14:12:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14176 for ; Fri, 31 Oct 2003 14:12:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIsbkT002277 for ; Fri, 31 Oct 2003 10:54:37 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIsb6V002276 for ietf-calendar-bks; Fri, 31 Oct 2003 10:54:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIsTkT002264 for ; Fri, 31 Oct 2003 10:54:32 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F7B50CE.5080606@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - QUERYID MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 31 Oct 2003 13:49:37 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/31/2003 01:54:33 PM, Serialize complete at 10/31/2003 01:54:33 PM Content-Type: multipart/alternative; boundary="=_alternative 00672E4985256DD0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00672E4985256DD0_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 10/01/2003 06:10:22 PM: > > If you are not storing querys in the CS then you certainly dont need a > > QUERYID property to find it do you? It belongs in the followon text > > that addresses stored queries, not in CAP 1.0 where it serves no use. > > Again - the auto execution of stored queries was removed per the > overwhelming > WG discussion. The proposal and agreement was on the removal of references to stored VQUERYs and that it be deferred to a later draft. QUERYID is ONLY useful for stored VQUERYs so as such it to should be removed from CAP 1.0. Its still in CAP-12-e. The reference under Section 2.1.2 New Properties (summary) needs to be removed along w/Section 8.27 entirely. They correctly belong to the draft that adds stored queries, not to CAP 1.0. Also, Section 3.2 Calendar Store Object Model shows stored VQUERYs in the Calendar Store diagram. This too should be deferred to the followon draft. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00672E4985256DD0_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 10/01/2003 06:10:22 PM:
> > If you are not storing querys in the CS then you certainly dont need a
> > QUERYID property to find it do you?  It belongs in the followon text
> > that addresses stored queries, not in CAP 1.0 where it serves no use.
>
> Again - the auto execution of stored queries was removed per the
> overwhelming
> WG discussion.
The proposal and agreement was on the removal of references to stored VQUERYs and that it be deferred to a later draft.   QUERYID is ONLY useful for stored VQUERYs so as such it to should be removed from CAP 1.0.  Its still in CAP-12-e.

The reference under Section 2.1.2 New Properties (summary) needs to be removed along w/Section 8.27 entirely.  They correctly belong to the draft that adds stored queries, not to CAP 1.0.  

Also, Section 3.2 Calendar Store Object Model shows stored VQUERYs in the Calendar Store diagram.  This too should be deferred to the followon draft.  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00672E4985256DD0_=-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 14:51:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15873 for ; Fri, 31 Oct 2003 14:51:02 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJc3kT003882 for ; Fri, 31 Oct 2003 11:38:03 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJc36i003881 for ietf-calendar-bks; Fri, 31 Oct 2003 11:38:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJc2kU003868 for ; Fri, 31 Oct 2003 11:38:02 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F7B4E81.3050600@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - SCOPING MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 31 Oct 2003 14:14:21 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/31/2003 02:38:02 PM, Serialize complete at 10/31/2003 02:38:02 PM Content-Type: multipart/alternative; boundary="=_alternative 006971E185256DD0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006971E185256DD0_= Content-Type: text/plain; charset="US-ASCII" Doug claimed 10/01/2003 06:00:33 PM: > I still have no clue what you are talking about when you say 'scoping' that > have not been addressed. Go check the archives for Presons posting on 04/03/2003 02:36:12 PM MST under the subject "How do you get the METHOD property on a SEARCH". There was a brief WG flurry about it but no actual resolution on it Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 006971E185256DD0_= Content-Type: text/html; charset="US-ASCII"
Doug claimed 10/01/2003 06:00:33 PM:
> I still have no clue what you are talking about when you say 'scoping' that
> have not been addressed.
Go check the archives for Presons posting on 04/03/2003 02:36:12 PM MST under the subject "How do you get the METHOD property on a SEARCH".   There was a brief WG flurry about it but no actual resolution on it

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 006971E185256DD0_=-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 15:13:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17901 for ; Fri, 31 Oct 2003 15:13:58 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJvRkT004730 for ; Fri, 31 Oct 2003 11:57:27 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJvRp8004729 for ietf-calendar-bks; Fri, 31 Oct 2003 11:57:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJvQkT004706 for ; Fri, 31 Oct 2003 11:57:26 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: EXPAND property: All instances? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 31 Oct 2003 14:56:33 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/31/2003 02:57:25 PM, Serialize complete at 10/31/2003 02:57:25 PM Content-Type: multipart/alternative; boundary="=_alternative 006D4F5585256DD0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D4F5585256DD0_= Content-Type: text/plain; charset="US-ASCII" I have a simple question regarding the EXPAND property. In CAP-12-e it is described as: Description: If a CUA wishes to see all of the instances of a recurring component the CUA sets EXPAND=TRUE in the "VQUERY" component. If not specified, the default is FALSE. Note that if the CS has its "RECUR-EXPAND" CS property value set to false then the "EXPAND" property will be ignored and the result will be as if the "EXPAND" value was set to false. My question is simply this: Is the CS supposed to return literally all instances of a repeating entry even if they fall outside the bounds of the parameters in the VQUERY? That is if I use: BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE DTEND >= '20031031T000000Z' AND DTSTART <= '20031031T235959Z' AND STATE() = 'BOOKED' END:VQUERY to see my calendar for today, would the CS literally return data that had a DTSTART of tomorrow or next week and even last week? It seems to me that this violates the constraints of the WHERE searching since those instances do NOT match the WHERE selection criteria. It seems to me that if I wanted ALL (or a particular bunch of) instances of a repeating entry there would be more appropriate ways to get it. That is, if I wanted to find all instances of a repeating meeting (I can tell its repeating by the fact it has a RECURRENCE-ID property) then I would simply use: BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = 'FrodoFailed' AND STATE() = 'BOOKED' END:VQUERY and I should get back all instances then and nothing would violate the WHERE search criteria. If I wanted to find just instances that occur this month then Id use something like: BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE RECURRENCE-ID >= '20031001T000000Z' AND RECURRENCE-ID <= '20031031T235959Z' AND STATE() = 'BOOKED' END:VQUERY and the CS would return only those instances for this past month. Can someone please explain the benefit of using EXPAND:TRUE to violate the WHERE search criteria (or am I just misreading it)?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D4F5585256DD0_= Content-Type: text/html; charset="US-ASCII"
I have a simple question regarding the EXPAND property.  In CAP-12-e it is described as:

   Description: If a CUA wishes to see all of the instances of a
  recurring component the CUA sets EXPAND=TRUE in the "VQUERY"
  component. If not specified, the default is FALSE. Note that if the
  CS has its "RECUR-EXPAND" CS property value set to false then the
  "EXPAND" property will be ignored and the result will be as if the
  "EXPAND" value was set to false.

My question is simply this:  Is the CS supposed to return literally all instances of a repeating entry even if they fall outside the bounds of the parameters in the VQUERY?

That is if I use:

   BEGIN:VQUERY
  EXPAND:TRUE
  QUERY:SELECT * FROM VEVENT
  WHERE DTEND >= '20031031T000000Z'
  AND DTSTART <= '20031031T235959Z'
  AND STATE() = 'BOOKED'
  END:VQUERY

to see my calendar for today, would the CS literally return data that  had a DTSTART of tomorrow or next week and even last week?  It seems to me that this violates the constraints of the WHERE searching since those instances do NOT match the WHERE selection criteria.  

It seems to me that if I wanted ALL (or a particular bunch of) instances of a repeating entry there would be more appropriate ways to get it.  That is, if I wanted to find all instances of a repeating meeting (I can tell its repeating by the fact it has a RECURRENCE-ID property) then I would simply use:

   BEGIN:VQUERY
  QUERY:SELECT * FROM VEVENT
  WHERE UID = 'FrodoFailed'
  AND STATE() = 'BOOKED'
  END:VQUERY

and I should get back all instances then and nothing would violate the WHERE search criteria.  If I wanted to find just instances that occur this month then Id use something like:

   BEGIN:VQUERY
  QUERY:SELECT * FROM VEVENT
  WHERE RECURRENCE-ID >= '20031001T000000Z'
  AND RECURRENCE-ID <= '20031031T235959Z'
  AND STATE() = 'BOOKED'
  END:VQUERY

and the CS would return only those instances for this past month.

Can someone please explain the benefit of using EXPAND:TRUE to violate the WHERE search criteria (or am I just misreading it)??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006D4F5585256DD0_=-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 15:35:37 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19142 for ; Fri, 31 Oct 2003 15:35:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKNIkT006557 for ; Fri, 31 Oct 2003 12:23:18 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VKNIGB006556 for ietf-calendar-bks; Fri, 31 Oct 2003 12:23:18 -0800 (PST) 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.10/8.12.8) with ESMTP id h9VKNGkT006549 for ; Fri, 31 Oct 2003 12:23:16 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9VKNEc0028937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 31 Oct 2003 12:23:16 -0800 Message-ID: <3FA2C4AD.5070206@Royer.com> Date: Fri, 31 Oct 2003 13:23:09 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - SCOPING References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040402010000040608090605" X-Royer.com-MailScanner-Information: Please contact the ISP 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. --------------ms040402010000040608090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed 10/01/2003 06:00:33 PM: > > I still have no clue what you are talking about when you say > 'scoping' that > > have not been addressed. > > Go check the archives for Presons posting on 04/03/2003 02:36:12 PM > MST under the subject "How do you get the METHOD property on a > SEARCH". There was a brief WG flurry about it but no actual > resolution on it Now go read the rest of the archives. you will find there was a solution sent to the list. Do you have another proposal? -- 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 --------------ms040402010000040608090605 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 9w0BCQUxDxcNMDMxMDMxMjAyMzA5WjAjBgkqhkiG9w0BCQQxFgQUj7v5kSeFH6VQy8QEWgWQ qCFD8JMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAZu45VS0Mqb7a9rFp2CWbK9qxmUiRT2K/lNOlR2eiPfWCjqeuYVMqbMepFPyu4YqK g54iGNRSeLxMKyRzc/3c1X771S25rgzxhslHP04thJ/Ef/3uRD9YNW4a28Y1dsPvAttQSzcL dPvRmodzfYBwyMxAri3UmnC9sRntgw+rK1GbZOj7TZ4xNC8iaKXkaw2hbLALed1WETWLvtEm cN+FtT+mWMOOXemhK8IfPpw+KjtotOGcizCtlvzAPOdDtPYPIHGhTm9tJMwgtFXelgXpWTCr tLv3Qoz+0qV2yGjpcVPsXe7fzh5eWY13E4KCIRaj87QvHTsXbtmVOOvsIPBkugAAAAAAAA== --------------ms040402010000040608090605-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 15:40:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15875 for ; Fri, 31 Oct 2003 14:51:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJc3kT003877 for ; Fri, 31 Oct 2003 11:38:03 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJc240003875 for ietf-calendar-bks; Fri, 31 Oct 2003 11:38:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJc2kT003868 for ; Fri, 31 Oct 2003 11:38:02 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F7B506B.1010508@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - ABNF MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 31 Oct 2003 14:09:25 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/31/2003 02:38:02 PM, Serialize complete at 10/31/2003 02:38:02 PM Content-Type: multipart/alternative; boundary="=_alternative 0068FE5E85256DD0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068FE5E85256DD0_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/01/2003 06:08:43 PM: > > For the base RFCs we had: > > > > The memo also includes a formal grammar for the content type based on > > the Internet ABNF defined in [RFC 2234]. This ABNF is required for > > the implementation of parsers and to serve as the definitive > > reference when ambiguities or questions arise in interpreting the > > descriptive prose definition of the memo. > > > > but we dont seem to have anything like this in CAP. > > No one believes that there is nothing like ABNF in CAP. Again I cant tell if you are purposely misreading what I said to draw things out or if you just didnt understand it. I noted that CAP has NO paragraph in it like the cited one from 2445 that says the ABNF is definfitive over the text when interpreting the CAP text. So when implementors try to implement CAP they have something to allow them to resolve issues. Unfortunately CAP has nothing like this nor is the ABNF consistantly organized/formatted. This means a CAP parser has nothing it can use to determine if the command / payload are properly constructed or not. To me this is not goodness but perhaps Im the only one who thinks this... > > Why is that? What good is provding ABNF that is not accurate?? > > It it accurate. If you want 100% of CAP to be in ABNF - propose the ABNF > to the list. Just like the query reply, some things just do not make > good ABNF. The ABNF is not considered more definitive ("accurate") than the prose when issues or questions arise. That was the main point. In reponse to your "If you want 100% of CAP to be in ABNF" quip, we all should want this. By that I mean that there is nothing described in prose that is NOT represented in ABNF somewhere in CAP. Otherwise you could have text with no ABNF that can be used in implementations to confirm validity. I dont see how that would be a good thing so perhaps you could explain how it would be. > Yea right. So, I am supposed to do 100% of this work with NO proposals > at all. If all you respond to is proposals or text that says "I propose" then Ill try that... I propose that CAP Section 1 Introduction be changed to, somewhere, include the text: The memo also includes a formal grammar for the content type based on the Internet ABNF defined in [RFC 2234]. This ABNF is required for the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the memo. I further propose that the ABNF currently in CAP be checked for consistancy of layout. The ABNF for commands seems to vary in style which is probably legacy from the multiple editors we've had. It is not that burdensome a think to ask of the editor given how prolific he is with spinning out additional CAP addon drafts is it? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0068FE5E85256DD0_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/01/2003 06:08:43 PM:
> > For the base RFCs we had:
> >
> >    The memo also includes a formal grammar for the content type based on
> >   the Internet ABNF defined in [RFC 2234]. This ABNF is required for
> >   the implementation of parsers and to serve as the definitive
> >   reference when ambiguities or questions arise in interpreting the
> >   descriptive prose definition of the memo.
> >
> > but we dont seem to have anything like this in CAP.
>
> No one believes that there is nothing like ABNF in CAP.
Again I cant tell if you are purposely misreading what I said to draw things out or if you just didnt understand it.  I noted that CAP has NO paragraph in it like the cited one from 2445 that says the ABNF is definfitive over the text when interpreting the CAP text.  So when implementors try to implement CAP they have something to allow them to resolve issues.

Unfortunately CAP has nothing like this nor is the ABNF consistantly organized/formatted.  This means a CAP parser has nothing it can use to determine if the command / payload are properly constructed or not.  To me this is not goodness but perhaps Im the only one who thinks this...

> >  Why is that?  What good is provding ABNF that is not accurate??
>
> It it accurate. If you want 100% of CAP to be in ABNF -  propose the ABNF
> to the list. Just like the query reply, some things just do not make
> good ABNF.
The ABNF is not considered more definitive ("accurate") than the prose when issues or questions arise.  That was the main point.

In reponse to your "If you want 100% of CAP to be in ABNF" quip, we all should want this.  By that I mean that there is nothing described in prose that is NOT represented in ABNF somewhere in CAP.  Otherwise you could have text with no ABNF that can be used in implementations to confirm validity.  I dont see how that would be a good thing so perhaps you could explain how it would be.

> Yea right. So, I am supposed to do 100% of this work with NO proposals
> at all.

If all you respond to is proposals or text that says "I propose" then Ill try that...

I propose that CAP Section 1 Introduction be changed to, somewhere, include the text:

   The memo also includes a formal grammar for the content type based on
  the Internet ABNF defined in [RFC 2234]. This ABNF is required for
  the implementation of parsers and to serve as the definitive
  reference when ambiguities or questions arise in interpreting the
  descriptive prose definition of the memo.

I further propose that the ABNF currently in CAP be checked for consistancy of layout.  The ABNF for commands seems to vary in style which is probably legacy from the multiple editors we've had.  It is not that burdensome a think to ask of the editor given how prolific he is with spinning out additional CAP addon drafts is it?  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0068FE5E85256DD0_=-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 15:44:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19435 for ; Fri, 31 Oct 2003 15:44:18 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKX9kT006871 for ; Fri, 31 Oct 2003 12:33:09 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VKX90P006870 for ietf-calendar-bks; Fri, 31 Oct 2003 12:33:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKX8kU006855 for ; Fri, 31 Oct 2003 12:33:08 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <003201c388d9$574200d0$0200000a@hp1> To: "Craig Johnson" Cc: cjohnson@novell.com, ietf-calendar@imc.org Subject: Re: When to publish -12 - VFREEBUSY MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 31 Oct 2003 15:19:59 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/31/2003 03:33:05 PM, Serialize complete at 10/31/2003 03:33:05 PM Content-Type: multipart/alternative; boundary="=_alternative 006F743C85256DD0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F743C85256DD0_= Content-Type: text/plain; charset="US-ASCII" Craig wrote on 10/02/2003 07:35:54 AM: > The example uses the SEARCH command with an iTIP VFREEBUSY to make > the request. The advantages/benefits are: > * It creates consistency and continuity between the WG standards for > making a free-busy requests. Umm, I have to disagree with a couple of your points here. iTIP currently defines how to do busytime lookups and thats with METHOD:REQUEST (iTIP, Section 3.3.2 REQUEST). As such, CAP is not consistant nor continuous from the existing standards since its using CMD:SEARCH and no METHOD property. > It was argued that an > implementation which did this for a "VFREEBUSY search" implies some > degree of latency in the free-busy search process... which is not > good... so, instead, the CS should reply with the VFREEBUSY results > instead of just an "I got it" ... and this would be the way CAP does > a real-time request/response for free-busy information. Latency in busytime is not a good idea. The busytime info should be as current as you can make it, not stale. After all, what good is it to know my availability for next week based on my calendar yesterday; I may have already added other entries to my calendar that impact your decision making process on when to meet. I dont have time to look at your proposal now but Ill try to soon. I see that Doug appears to have read it and responded though so Ill see what his take on it is first... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F743C85256DD0_= Content-Type: text/html; charset="US-ASCII"
Craig wrote on 10/02/2003 07:35:54 AM:
> The example uses the SEARCH command with an iTIP VFREEBUSY to make
> the request. The advantages/benefits are:
> * It creates consistency and continuity between the WG standards for
> making a free-busy requests.
Umm, I have to disagree with a couple of your points here.  iTIP currently defines how to do busytime lookups and thats with METHOD:REQUEST (iTIP, Section 3.3.2 REQUEST).  As such, CAP is not consistant nor continuous from the existing standards since its using CMD:SEARCH and no METHOD property.

>                                          It was argued that an
> implementation which did this for a "VFREEBUSY search" implies some
> degree of latency in the free-busy search process... which is not
> good... so, instead, the CS should reply with the VFREEBUSY results
> instead of just an "I got it" ... and this would be the way CAP does
> a real-time request/response for free-busy information.

Latency in busytime is not a good idea.  The busytime info should be as current as you can make it, not stale.  After all, what good is it to know my availability for next week based on my calendar yesterday; I may have already added other entries to my calendar that impact your decision making process on when to meet.

I dont have time to look at your proposal now but Ill try to soon.  I see that Doug appears to have read it and responded though so Ill see what his take on it is first...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006F743C85256DD0_=-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 15:48:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19616 for ; Fri, 31 Oct 2003 15:48:50 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKX8kT006864 for ; Fri, 31 Oct 2003 12:33:08 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VKX8Y3006863 for ietf-calendar-bks; Fri, 31 Oct 2003 12:33:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKX8kT006855 for ; Fri, 31 Oct 2003 12:33:08 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F7C63E2.7020002@Royer.com> To: ietf-calendar@imc.org Subject: Re: When to publish -12 - VFREEBUSY MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 31 Oct 2003 15:18:34 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 10/31/2003 03:33:05 PM, Serialize complete at 10/31/2003 03:33:05 PM Content-Type: multipart/alternative; boundary="=_alternative 006F531785256DD0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F531785256DD0_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/02/2003 01:44:02 PM: > Currently - Pre-CAP: > > (a.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA > responds > and the CU MAY be in the loop. > > (a.2)There is NO VFREEBUSY/CREATE in iMIP so the CUA will never see those. You are not making a valid comparison here Doug. REQUEST is the METHOD property value but CREATE is the CMD property value. I use CMD:CREATE with several different METHOD propety values (ie: METHOD:REQUEST to send an invitation/update, METHOD:REPLY to respond, etc) > In CAP-12-e: > > (b.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA > responds > and the CU MAY be in the loop. > > VFREEBUSY/REQUEST processed exactly like pre-CAP -- by the CUA. How this iMIP VFREEBUSY/REQUEST critter gets into the 'unprocessed' queue in the CS is 100% NOT defined in CAP 1.0 so your last bit is making an assumption not based on any CAP text. > (b.2) There is still NO VFREEBUSY/CREATE in iMIP. Still and apples to oranges comparison... > (b.3) If CS has RECUR-EXPAND:TRUE : (VFREEBUSY/REQUEST) [snip] > (b.4) If CS has RECUR-EXPAND:FALSE : : (VFREEBUSY/REQUEST) The RECUR-EXPAND has no releation to the discussion of VFREEBUSY requests. The request has a DTSTART and DTEND so ANY instance between those bounds should be reflected in the returned data. > VFREEBUSY/REQUET processed exactly like pre-CAP - by the CUA. > > And there is consistency with all other iTIP methods, they are > stored > in the UNPROCESSED state until acted upon by a CUA. In a real time system like CAP it does NOT make sense to have the requesting CUA wait for the invitees CUA to respond to the REQUEST. > (b.5) If the CS has RECUR-EXPAND:TRUE : (VFREEBUSY/CREATE) Another invalid comparison. (b.3) and (b.4) referred to the METHOD value (and no CMD value) but now you refer to the generic CMD:CREATE and no METHOD value. Again, the RECUR-EXPAND has no relationship to the discussion... > > * A Calendar Store would use the same code to respond to the VFREEBUSY > > search request regardless of whether it came via CAP or iMIP. Again, > > consistency and continuity! (Calendar Stores that support iTIP very > > likely have code to handle VFREEBUSY requests. Adapting that code for > > CAP is relatively simple.) > > Except that is not how iMIP requests are always processed, so it is > introducing an inconsistency. Where in iMIP does it say how its processed by the receiving end? Nowhere. Nor is there any text in iTIP that says how it is processed at the recieving end. The only text in iTIP regarding VFREEBUSY REQUEST handling is: If the originator of the "REQUEST" method is not authorized to make a busy time request on the recipient's calendar system, then an exception message SHOULD be returned in a "REPLY" method, but no busy time data need be returned. Thats it. So its not prohibited to do what Craig suggested. > As pointed out above, your proposal is currently incomplete, breaks > EXPAND-RECUR:FALSE EXPAND-RECUR is NOT related to busytime lookups, at least not the way its currently described in CAP-12-e. EXPAND-RECUR is a capability to say if the EXPAND property is observed. EXPAND is defined as: Purpose: This property is to notify the CS if it should or should not expand any component with recurrence rules into multiple instances in a query reply. So if you are saying that the VFREEBUSY results will vary based on if EXPAND is supported then I think you have seriously misunderstood how a VFREEBUSY REQUEST functions. iTIP clearly (Section 3.3.3 REQUEST): The "REQUEST" method in a "VFREEBUSY" calendar component is used to ask a "Calendar User" for their busy time information. The request may be for a busy time information bounded by a specific date and time interval. The restriction table shows that for VFREEBUSY you use DTSTART and DTEND to bound the busytime search. So data for instances outside that range should NOT be returned (although its not expressly written in iTIP as such). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F531785256DD0_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/02/2003 01:44:02 PM:
> Currently - Pre-CAP:
>
>    (a.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA
> responds
>            and the CU MAY be in the loop.
>
>   (a.2)There is NO VFREEBUSY/CREATE in iMIP so the CUA will never see those.
You are not making a valid comparison here Doug.  

REQUEST is the METHOD property value but CREATE is the CMD property value.  I use CMD:CREATE with several different METHOD propety values (ie: METHOD:REQUEST to send an invitation/update, METHOD:REPLY to respond, etc)

> In CAP-12-e:
>
>    (b.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA
> responds
>            and the CU MAY be in the loop.
>
>            VFREEBUSY/REQUEST processed exactly like pre-CAP -- by the CUA.
How this iMIP VFREEBUSY/REQUEST critter gets into the 'unprocessed' queue in the CS is 100% NOT defined in CAP 1.0 so your last bit is making an assumption not based on any CAP text.

>   (b.2) There is still NO VFREEBUSY/CREATE in iMIP.

Still and apples to oranges comparison...

>   (b.3) If CS has RECUR-EXPAND:TRUE :  (VFREEBUSY/REQUEST)
[snip]
>   (b.4) If CS has RECUR-EXPAND:FALSE : : (VFREEBUSY/REQUEST)
The RECUR-EXPAND has no releation to the discussion of VFREEBUSY requests.  The request has a DTSTART and DTEND so ANY instance between those bounds should be reflected in the returned data.

>          VFREEBUSY/REQUET processed exactly like pre-CAP - by the CUA.
>
>          And there is consistency with all other iTIP methods, they are
> stored
>          in the UNPROCESSED state until acted upon by a CUA.
In a real time system like CAP it does NOT make sense to have the requesting CUA wait for the invitees CUA to respond to the REQUEST.  

>   (b.5) If the CS has RECUR-EXPAND:TRUE  : (VFREEBUSY/CREATE)
Another invalid comparison.  (b.3) and (b.4) referred to the METHOD value (and no CMD value) but now you refer to the generic CMD:CREATE and no METHOD value.

Again, the RECUR-EXPAND has no relationship to the discussion...

> > * A Calendar Store would use the same code to respond to the VFREEBUSY
> > search request regardless of whether it came via CAP or iMIP. Again,
> > consistency and continuity! (Calendar Stores that support iTIP very
> > likely have code to handle VFREEBUSY requests. Adapting that code for
> > CAP is relatively simple.)
>
> Except that is not how iMIP requests are always processed, so it is
> introducing an inconsistency.
Where in iMIP does it say how its processed by the receiving end?  Nowhere.  Nor is there any text in iTIP that says how it is processed at the recieving end.  The only text in iTIP regarding VFREEBUSY REQUEST handling is:

   If the originator of the "REQUEST" method is not authorized to make a
  busy time request on the recipient's calendar system, then an
  exception message SHOULD be returned in a "REPLY" method, but no busy
  time data need be returned.

Thats it.  So its not prohibited to do what Craig suggested.

> As pointed out above, your proposal is currently incomplete, breaks
> EXPAND-RECUR:FALSE
EXPAND-RECUR is NOT related to busytime lookups, at least not the way its currently described in CAP-12-e.  EXPAND-RECUR is a capability to say if the EXPAND property is observed.  EXPAND is defined as:

   Purpose: This property is to notify the CS if it should or should not
  expand any component with recurrence rules into multiple instances in
  a query reply.
So if you are saying that the VFREEBUSY results will vary based on if EXPAND is supported then I think you have seriously misunderstood how a VFREEBUSY REQUEST functions.  iTIP clearly (Section 3.3.3 REQUEST):

   The "REQUEST" method in a "VFREEBUSY" calendar component is used to
  ask a "Calendar User" for their busy time information. The request
  may be for a busy time information bounded by a specific date and
  time interval.

The restriction table shows that for VFREEBUSY you use DTSTART and DTEND to bound the busytime search.  So data for instances outside that range should NOT be returned (although its not expressly written in iTIP as such).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006F531785256DD0_=-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 16:40:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21372 for ; Fri, 31 Oct 2003 16:40:52 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLSkkT009043 for ; Fri, 31 Oct 2003 13:28:46 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLSkhh009042 for ietf-calendar-bks; Fri, 31 Oct 2003 13:28:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from gw.provo.novell.com (gw.provo.novell.com [137.65.47.29]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLSgkT009037 for ; Fri, 31 Oct 2003 13:28:45 -0800 (PST) (envelope-from PStephenson@gw.novell.com) Received: from PROVO7-MTA by gw.provo.novell.com with Novell_GroupWise; Fri, 31 Oct 2003 14:26:06 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Fri, 31 Oct 2003 14:30:04 -0700 From: "Preston Stephenson" To: Subject: Re: When to publish -12 - SCOPING 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 Just for my two bits. The issue was resolved enough that I didn't need to pursue it further. As to the ABNF post, it would be nice to have a complete ABNF in one place. Thanks. Preston >>> Doug@royer.com 10/31/2003 1:23:09 PM >>> Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed 10/01/2003 06:00:33 PM: > > I still have no clue what you are talking about when you say > 'scoping' that > > have not been addressed. > > Go check the archives for Preston's posting on 04/03/2003 02:36:12 PM > MST under the subject "How do you get the METHOD property on a > SEARCH". There was a brief WG flurry about it but no actual > resolution on it Now go read the rest of the archives. you will find there was a solution sent to the list. Do you have another proposal? -- 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 Fri Oct 31 17:14:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22510 for ; Fri, 31 Oct 2003 17:14:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VM2ZkT010038 for ; Fri, 31 Oct 2003 14:02:36 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VM2ZBa010037 for ietf-calendar-bks; Fri, 31 Oct 2003 14:02:35 -0800 (PST) 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.10/8.12.8) with ESMTP id h9VM2YkT010032 for ; Fri, 31 Oct 2003 14:02:34 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9VM2Vc0030498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 31 Oct 2003 14:02:33 -0800 Message-ID: <3FA2DBF2.1070200@Royer.com> Date: Fri, 31 Oct 2003 15:02:26 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: When to publish -12 - VFREEBUSY References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060400000405050009080009" X-Royer.com-MailScanner-Information: Please contact the ISP 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. --------------ms060400000405050009080009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Craig wrote on 10/02/2003 07:35:54 AM: > > The example uses the SEARCH command with an iTIP VFREEBUSY to make > > the request. The advantages/benefits are: > > * It creates consistency and continuity between the WG standards for > > making a free-busy requests. > > Umm, I have to disagree with a couple of your points here. iTIP > currently defines how to do busytime lookups and thats with > METHOD:REQUEST (iTIP, Section 3.3.2 REQUEST). As such, CAP is not > consistent nor continuous from the existing standards since its using > CMD:SEARCH and no METHOD property. SEARCH for UNPROCESSED, it gets you the objects that have METHODs. So, not true. SELECT VFREEBUSY WHERE state = 'UNPROCESSED' To get the iTIP object stored. Or SELECT VFREEBUSY WHERE state = 'BOOKED' To get the iTIP object dynamically created (no latency). > > > It was argued that an > > implementation which did this for a "VFREEBUSY search" implies some > > degree of latency in the free-busy search process... which is not > > good... so, instead, the CS should reply with the VFREEBUSY results > > instead of just an "I got it" ... and this would be the way CAP does > > a real-time request/response for free-busy information. > > Latency in busytime is not a good idea. The busytime info should be > as current as you can make it, not stale. After all, what good is it > to know my availability for next week based on my calendar yesterday; > I may have already added other entries to my calendar that impact your > decision making process on when to meet. -- 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 --------------ms060400000405050009080009 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 9w0BCQUxDxcNMDMxMDMxMjIwMjI2WjAjBgkqhkiG9w0BCQQxFgQU0YTQc/VR8RXXQ8+fx/PL 6Wo7mEMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAR/djhqVeuu+NRUz37VEdvZBkUdlz0sJjDFo4A1fMCcvjZiaWMP2HvvYqKYN/fh7B laBI5D0CQKABnvmjgMjp3ficxUoTfY4qNK23kpiXOydEz+mey42qf3rhRw2fx2buXnqmFsIb 4NyZv5EQId8uGhO4jNGmMjb3VKJGTpTmx5S8P5GhtKTbOVP+chMKCeLam2mBMulmVonHTCi7 /QzQXxx1+zWZQ+AcKfwa+VUx04r1qcfTUdyR233ZagyG3Hyk5M4fUkhOP0OumJ8/2ZrK5fgs hHi9OHH7v6Xg44LFqOVsvIHQa22fo16alnHcNEWPDmwvPRa9+lg1FmhVDWAd3wAAAAAAAA== --------------ms060400000405050009080009-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 17:18:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22657 for ; Fri, 31 Oct 2003 17:18:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VM7QkT010130 for ; Fri, 31 Oct 2003 14:07:26 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VM7QI8010129 for ietf-calendar-bks; Fri, 31 Oct 2003 14:07:26 -0800 (PST) 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.10/8.12.8) with ESMTP id h9VM7OkT010124 for ; Fri, 31 Oct 2003 14:07:25 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9VM7Nc0030549 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 31 Oct 2003 14:07:25 -0800 Message-ID: <3FA2DD16.5010008@Royer.com> Date: Fri, 31 Oct 2003 15:07:18 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: When to publish -12 - VFREEBUSY References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070707080507030100090103" X-Royer.com-MailScanner-Information: Please contact the ISP 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. --------------ms070707080507030100090103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 10/02/2003 01:44:02 PM: > > Currently - Pre-CAP: > > > > (a.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA > > responds > > and the CU MAY be in the loop. > > > > (a.2)There is NO VFREEBUSY/CREATE in iMIP so the CUA will never > see those. > > You are not making a valid comparison here Doug. I did not make a comparison - I said it has none. > > REQUEST is the METHOD property value but CREATE is the CMD property > value. I use CMD:CREATE with several different METHOD propety values > (ie: METHOD:REQUEST to send an invitation/update, METHOD:REPLY to > respond, etc) Which has what to do with the topic? > > > In CAP-12-e: > > > > (b.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA > > responds > > and the CU MAY be in the loop. > > > > VFREEBUSY/REQUEST processed exactly like pre-CAP -- by > the CUA. > > How this iMIP VFREEBUSY/REQUEST critter gets into the 'unprocessed' > queue in the CS is 100% NOT defined in CAP 1.0 so your last bit is > making an assumption not based on any CAP text. How to get UNPROCESSED objects (which are only iTIP objects) is clearly defined in CAP. Why you think that VFREEBUSY does not apply to those sections of CAP you have yet to explain. -- 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 --------------ms070707080507030100090103 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 9w0BCQUxDxcNMDMxMDMxMjIwNzE4WjAjBgkqhkiG9w0BCQQxFgQU1L/hs7V02Xya7t2SfrkF I2/CM3swUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA3lLAm/FNKP7TF0lMvioi5QGEXNS3R/Kdq6nu0hBqOYPbccF23YIntoSaHMe+3qY/ 1Uxnf1SNVI5O2XnlrU1UYfIRzNMHc1vtKds9bo7QUzeZip8uY/lesjZcr8uX8velkXhWEadU 8v6I4tNHtajOkR487afN+vqcHprwOeoVzEDY2b/GWeXq4Kw7XxY+gM+WGl4UMR8U5GUublJJ OsCRQkgFxtmG1chti1gBTwcYncNkc+VH2Q6xmV9Cm+5y6TojQUhhuTcyPmWXKAIWcjCFNG3M m+2mvd2MKISh4MyXThtMGDNDauwIPu9psNOBaicWQWH2jYQtGNDv2AHT3xYcRgAAAAAAAA== --------------ms070707080507030100090103-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 17:21:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22722 for ; Fri, 31 Oct 2003 17:21:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMBWkT010231 for ; Fri, 31 Oct 2003 14:11:32 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VMBWCg010230 for ietf-calendar-bks; Fri, 31 Oct 2003 14:11:32 -0800 (PST) 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.10/8.12.8) with ESMTP id h9VMBUkT010220 for ; Fri, 31 Oct 2003 14:11:30 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9VMBTc0030598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 31 Oct 2003 14:11:30 -0800 Message-ID: <3FA2DE0B.5010509@Royer.com> Date: Fri, 31 Oct 2003 15:11:23 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: When to publish -12 - SCOPING References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070201040702030502050003" X-Royer.com-MailScanner-Information: Please contact the ISP 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. --------------ms070201040702030502050003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: >As to the ABNF post, it would be nice to have a complete ABNF in one >place. > They tried that with iCal/iTIP in the drafts, but people complained that the sections that defined each component (property...) was incomplete and it was a pain to go find the ABNF that matched. So they split it up. And it is not that hard to edit the text document and copy/paste them into one working file for review. It is nearly impossible to take one big ABNF and copy/paste them back into what ever section the reader thinks they go into. -- 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 --------------ms070201040702030502050003 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 9w0BCQUxDxcNMDMxMDMxMjIxMTIzWjAjBgkqhkiG9w0BCQQxFgQULnJFIAwiQyhoOKc51Szz g92g100wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAfhXAJTG7tubnAdgPRmZdy6Jhz2YUMlyfw7JuGZqesCLY18+b1sAc+W/fcANM7HMm RN/JuNAEqBtPIEpS6TxzE5OO50pPDSJT+hPvhUiZIHt84vHqF2yaKFKyCngQkyH0bJx+viPC Elx8VKREG03gahfwecDxmAb73Xn72Xz9dlzOqBlULC7Uj7w5nJl7OzSsfxuoS1tcsDZGP5jf +I8xSTyBeaST03/6ABgEDy6m/Q+/skUZ69DrQTajBx7+G7jFkkkSK3DNr8HqXXSxRaGu6C0M /BvmbxE/ZZTQFYRB/fDm0WEBBfI3d/IPPu33HeUdkapU15XzZpT0C1CrMCTAugAAAAAAAA== --------------ms070201040702030502050003-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 17:27:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22855 for ; Fri, 31 Oct 2003 17:27:39 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMGLkT010498 for ; Fri, 31 Oct 2003 14:16:21 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VMGLbF010497 for ietf-calendar-bks; Fri, 31 Oct 2003 14:16:21 -0800 (PST) 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.10/8.12.8) with ESMTP id h9VMGKkT010491 for ; Fri, 31 Oct 2003 14:16:20 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h9VMGFc0030674 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 31 Oct 2003 14:16:17 -0800 Message-ID: <3FA2DF29.2040803@Royer.com> Date: Fri, 31 Oct 2003 15:16:09 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Alarms and SEQUENCE References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070408060701090905040000" X-Royer.com-MailScanner-Information: Please contact the ISP 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. --------------ms070408060701090905040000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 10/21/2003 03:02:57 PM: > > Yes you do seem to understand why removing SEQUENCE breaks MODIFY > > of VALARMS. So I too do not want to break MODIFY of VALARMS. > > Actually thats not what I said but Ive already pointed that out. In > the interest of resovling this quicker I took time to go reread > CAP-12-e, Section 10.9 MODIFY Command again to see if I had just > missed something originally. After doing this I find that I still > disagree with Dougs assertion that removing SEQUENCE from VALARMs > breaks MODIFY. > > Lets take a look at the text and example to see why it does not break > MODIFY. First off, the command says (in part): Better yet, an example of when MODIFY breaks. Take TWO VLARMS that are identical in one component. Withou a unique identifier - you can not uniquly identify the 2nd instance. Now show me an example where you can without a unique identifier replace the ACTION in the secoond valarm and make it antother value. -- 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 --------------ms070408060701090905040000 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 9w0BCQUxDxcNMDMxMDMxMjIxNjA5WjAjBgkqhkiG9w0BCQQxFgQUHgi2zYNuIlnsD3ur/FnK Y57XA5swUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAhNbovhImLrWXnAVUiviH0SSN3k9oif260xwShIu/HZk2kHkAtTIUH7rgGBWP7ybK S7wxTCs30s5wQjZJEILnu0yoRElbX4OQaqk4c+Z0IlooCNBN+rN2shJ5hdf82OYYsJRIRmUQ loodEfp8DibDM9KQckoLlFucGx9MyaCyVT27H32hkFRB5PcoKR54SlGuW6TtnZWyjgYil8us /f/gbXkfrb2OHb3IYFhNsePHiVR6nslihAEqEi4VLGDGRcS3iNhn1hqdIgRJ1dVWL6FPMch/ YjM8M6yEekXS2QQGSexowM18Aq4wn1w3T0NiGJJezf5yoEJgH6mR+YaS8A9rIwAAAAAAAA== --------------ms070408060701090905040000-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 20:06:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27344 for ; Fri, 31 Oct 2003 20:06:35 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA10qbkT019323 for ; Fri, 31 Oct 2003 16:52:37 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA10qbkF019322 for ietf-calendar-bks; Fri, 31 Oct 2003 16:52:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from gw.provo.novell.com (gw.provo.novell.com [137.65.47.29]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA10qakT019316 for ; Fri, 31 Oct 2003 16:52:36 -0800 (PST) (envelope-from cjohnson@gw.novell.com) Received: from PROVO7-MTA by gw.provo.novell.com with Novell_GroupWise; Fri, 31 Oct 2003 17:50:00 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Fri, 31 Oct 2003 17:54:07 -0700 From: "Craig Johnson" To: Subject: Re: When to publish -12 - VFREEBUSY Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartCF915E3F.0__=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=__PartCF915E3F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bruce Wrote on 10/31/03 13:19: > Craig wrote on 10/02/2003 07:35:54 AM: > > The example uses the SEARCH command with a VFREEBUSY to make > > the request. The advantages/benefits are: > > * It creates consistency and continuity between the WG standards for > > making a free-busy requests. > > Umm, I have to disagree with a couple of your points here. iTIP currently defines how to do > busytime lookups and > thats with METHOD:REQUEST (iTIP, Section 3.3.2 REQUEST). > As such, CAP is not consistant nor continuous from the existing standards since its using > CMD:SEARCH and no METHOD property. Respectfully, that misses the KEY point ... but gives me an opportunity to restate it: !!! The WG standard for making a request for free-busy time is with the VFREEBUSY object. !!! RFC 2445, p. 58: Component Name: VFREEBUSY Purpose: Provide a grouping of component properties that describe ... a request for free/busy time (I shall refer to such an object as a "VFREEBUSY request". It is a VFREEBUSY object containing, at least, a DTSTART and DTEND property defining the period of interest.) iTIP simply defines how iTIP 'wrappers' a "VFREEBUSY request" (which uses METHOD:REQUEST). In CAP, the presence of the METHOD property is what distinguishes an iTIP message (and iTIP handling) from regular CAP. It should not be expected that a strictly CAP implementation of a "VFREEBUSY request" would have a METHOD property. Which brings up the next point: CAP does not (and with CAP-12e still does not) support this working group's own standard for obtaining free-busy information: a "VFREEBUSY request". This was discussed and acknowledged in a previous thread. That discussion concluded that using a "VFREEBUSY request" would be more appropriate and consistent with existing standards. It facilitates a CUA needing free-busy information for several attendees, some accessible via CAP and others via iMIP (or any future mechanism), to form a single "VFREEBUSY request" and to issue that same request to all attendees. Once again, my proposal is that CAP conform to and support the WG standard by defining the use of a "VFREEBUSY request" to obtain free-busy information. It makes little difference whether we give it's own command, or overload the SEARCH command. A CAP "VFREEBUSY request" would simply be: C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//Prodid C: CMD:SEARCH (or GET-FREEBUSY) C: TARGET:usera C: TARGET:userb C: BEGIN:VFREEBUSY (start of "VFREEBUSY request") C: DTSTART:startrange C: DTEND:endrange C: ORGANIZER:... C: ATTENDEE:... C: ATTENDEE:... C: DTSTAMP:... C: UID:... C: END:VFREEBUSY (end of "VFREEBUSY request") C: END:VCALENDAR C. Johnson --=__PartCF915E3F.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
Bruce Wrote on 10/31/03 13:19:
> Craig wrote on 10/02/2003 07:35:54 AM:
> = > The example uses the SEARCH command with a VFREEBUSY to make
> = > the request. The advantages/benefits are:
> > * It creates = consistency and continuity between the WG standards for
> > = making a free-busy requests.
>
> Umm, I have to = disagree with a couple of your points here.  iTIP currently defines = how to do
> busytime lookups and > thats with METHOD:REQUEST = (iTIP, Section 3.3.2 REQUEST). 
> As such, CAP is not = consistant nor continuous from the existing standards since its using =
> CMD:SEARCH and no METHOD property.
 
Respectfully, that misses the KEY point ... but gives me an opportunity = to restate it: 
!!! The WG standard for making a request for = free-busy time is with the VFREEBUSY object. !!! 
RFC 2445, p. = 58:
 
   Component = Name: VFREEBUSY
 
   Purpose: = Provide a grouping of component properties that describe
   = ... a request for free/busy time
 
(I shall refer to = such an object as a "VFREEBUSY request".  It is a VFREEBUSY object = containing,
at least, a DTSTART and DTEND property defining the period = of interest.)
 
iTIP simply defines how iTIP 'wrappers' a = "VFREEBUSY request" (which uses METHOD:REQUEST). 
In CAP, the = presence of the METHOD property is what distinguishes an iTIP message (and = iTIP handling)
from regular CAP.  It should not be expected that a = strictly CAP implementation of a
"VFREEBUSY request" would have a = METHOD property. 
 
Which brings up the next point:
&nb= sp;
CAP does not (and with CAP-12e still does not) support this working = group's own standard
for obtaining free-busy information: a "VFREEBUSY = request".  This was discussed and
acknowledged in a previous = thread.  That discussion concluded that using a "VFREEBUSY
request"= would be more appropriate and consistent with existing standards.  = It facilitates
a CUA needing free-busy information for several = attendees, some accessible via CAP and
others via iMIP (or any future = mechanism), to form a single "VFREEBUSY request" and to
issue that same request to all = attendees.
 
Once again, my proposal is that CAP conform = to and support the WG standard by defining
the use of a "VFREEBUSY request" to obtain = free-busy information.  It makes little difference
whether we = give it's own command, or overload the SEARCH command.  A CAP =
"VFREEBUSY request" would simply be:
 
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//P= rodid
C: CMD:SEARCH (or GET-FREEBUSY)
C: TARGET:usera
C: = TARGET:userb
C: BEGIN:VFREEBUSY       = (start of "VFREEBUSY request")
C: DTSTART:startrange
C: DTEND:endrang= e
C: ORGANIZER:...
C: ATTENDEE:...
C: ATTENDEE:...
C: = DTSTAMP:...
C: UID:...
C: END:VFREEBUSY     =     (end of "VFREEBUSY request")
C: END:VCALENDAR<= /DIV>
 
C. Johnson
--=__PartCF915E3F.0__=-- From owner-ietf-calendar@mail.imc.org Fri Oct 31 20:48:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28180 for ; Fri, 31 Oct 2003 20:48:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA11e2kT020271 for ; Fri, 31 Oct 2003 17:40:02 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA11e2Zu020270 for ietf-calendar-bks; Fri, 31 Oct 2003 17:40:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hA11e1kT020264 for ; Fri, 31 Oct 2003 17:40:01 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA11e1c0000425 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 31 Oct 2003 17:40:02 -0800 Message-ID: <3FA30EEB.8060000@Royer.com> Date: Fri, 31 Oct 2003 18:39:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: When to publish -12 - VFREEBUSY References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010509060909080404070203" X-Royer.com-MailScanner-Information: Please contact the ISP 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. --------------ms010509060909080404070203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Craig Johnson wrote: > Bruce Wrote on 10/31/03 13:19: > > Craig wrote on 10/02/2003 07:35:54 AM: > > > The example uses the SEARCH command with a VFREEBUSY to make > > > the request. The advantages/benefits are: > > > * It creates consistency and continuity between the WG standards for > > > making a free-busy requests. > > > > Umm, I have to disagree with a couple of your points here. iTIP > currently defines how to do > > busytime lookups and > thats with METHOD:REQUEST (iTIP, Section > 3.3.2 REQUEST). > > As such, CAP is not consistant nor continuous from the existing > standards since its using > > CMD:SEARCH and no METHOD property. > > Respectfully, that misses the KEY point ... but gives me an > opportunity to restate it: > !!! The WG standard for making a request for free-busy time is with > the VFREEBUSY object. !!! > RFC 2445, p. 58: It does and in -exactlyt- the same way - by the CUA and we added by the CS. > -- 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 --------------ms010509060909080404070203 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 9w0BCQUxDxcNMDMxMTAxMDEzOTU1WjAjBgkqhkiG9w0BCQQxFgQU4CvvejA6cRw46ztlQdzM TXdjvzYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAXDzEeULa1KkMb2246piY/BI8ttczkWE+bt03467z1EY10BWc8//HMHZBcjQS2NjW G+OwzXivu7eLmZma5yIGjNPFgtvanW4Q1Mlhb9Zp2v97lZhhn6jwa0SH9zY0NZguRtbrnMPS YLg3BgFtcs2LtWQD/NUKkigefsrj2tPXMpdEofGSl8OgV6XEBfmIpb07gxZeRVnf82azvnZl sniduxadARzC6ZgoOCWbsk3En3eb1/fpxSPWjF8qwJ6nDNbn9yCpsblOqOmjAx/6uKVnSvvD c/i6gsAatZbW+BTUVyxSYv2BEyK31tF9JcWcF7ohvw227qa4bU2gHzF+SVL66AAAAAAAAA== --------------ms010509060909080404070203--