From owner-ietf-calendar@mail.imc.org Mon Dec 1 13:39: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 NAA21886 for ; Mon, 1 Dec 2003 13:39:49 -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 hB1ILQib099803 for ; Mon, 1 Dec 2003 10:21: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 hB1ILQB8099802 for ietf-calendar-bks; Mon, 1 Dec 2003 10:21:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1ILOib099795 for ; Mon, 1 Dec 2003 10:21:26 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FC7AE2A.6010206@Royer.com> To: ietf-calendar@imc.org Subject: Re: an idea as an alternative to stored queries MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 1 Dec 2003 11:37:40 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/01/2003 01:18:28 PM, Serialize complete at 12/01/2003 01:18:28 PM Content-Type: multipart/alternative; boundary="=_alternative 005B199685256DEF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B199685256DEF_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/28/2003 03:20:58 PM: > Ether the CUA knew what XXX > did or not. Ether you were allowed (by VCAR like any other > component) to modify it, remove it, add one, or not. You neglect to take into account that a CU may use different CUAs and each may have their own expectation of what XXX does depending on who coded them (or if XXX was changed by a different CUA or other means). As such, just because CUA-1 'knows' that XXX performs a particular action does not mean it will always be so and unless CUA-1 can retrieve and confirm this by existing means then a change by CUA-2 may different behaviour for the same CU depending on what CUA they are using. For example, your PDA may have one expecation while your desktop CUA may have another. This is not goodness. So if CUAs are coded to rely on things they cannot retrieve and look at using CAP such as unencodable in CAP actions or queries then this expecation that the CUA 'knows' what XXX does is fundamentally flawed and bad. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005B199685256DEF_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/28/2003 03:20:58 PM:
>                               Ether the CUA knew what XXX
> did or not. Ether you were allowed (by VCAR like any other
> component) to modify it, remove it, add one, or not.
You neglect to take into account that a CU may use different CUAs and each may have their own expectation of what XXX does depending on who coded them (or if XXX was changed by a different CUA or other means).

As such, just because CUA-1 'knows' that XXX performs a particular action does not mean it will always be so and unless CUA-1 can retrieve and confirm this by existing means then a change by CUA-2 may different behaviour for the same CU depending on what CUA they are using.  For example, your PDA may have one expecation while your desktop CUA may have another.  This is not goodness.

So if CUAs are coded to rely on things they cannot retrieve and look at using CAP such as unencodable in CAP actions or queries then this expecation that the CUA 'knows' what XXX does is fundamentally flawed and bad.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005B199685256DEF_=-- From owner-ietf-calendar@mail.imc.org Mon Dec 1 14:21: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 OAA23406 for ; Mon, 1 Dec 2003 14:21:20 -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 hB1J4Pib002374 for ; Mon, 1 Dec 2003 11:04:25 -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 hB1J4Pwu002371 for ietf-calendar-bks; Mon, 1 Dec 2003 11:04:25 -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 hB1J4Oib002365 for ; Mon, 1 Dec 2003 11:04:24 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:K8+3uhQiNqR1Jh8B1yIxiLQtSfioxQYn@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB1J4CvI017452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 1 Dec 2003 11:04:14 -0800 Message-ID: <3FCB90AB.3090408@Royer.com> Date: Mon, 01 Dec 2003 12:04:11 -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: an idea as an alternative to stored queries References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040409080400020908040904" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040409080400020908040904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 11/28/2003 03:20:58 PM: > > Ether the CUA knew what XXX > > did or not. Ether you were allowed (by VCAR like any other > > component) to modify it, remove it, add one, or not. > > You neglect to take into account that a CU may use different CUAs and > each may have their own expectation of what XXX does depending on who > coded them (or if XXX was changed by a different CUA or other means). Your declaration of what I take into account is false. > As such, just because CUA-1 'knows' that XXX performs a particular > action does not mean it will always be so and unless CUA-1 can > retrieve and confirm this by existing means then a change by CUA-2 may > different behaviour for the same CU depending on what CUA they are > using. For example, your PDA may have one expecation while your > desktop CUA may have another. This is not goodness. > > So if CUAs are coded to rely on things they cannot retrieve and look > at using CAP such as unencodable in CAP actions or queries then this > expecation that the CUA 'knows' what XXX does is fundamentally flawed > and bad. If you put XXX into your calendar: don't tweak it if it will break you or your CUAs. If you do not want other to be able tweak XXX, put in a VCAR to stop them. If you did not put XXX into your calendar don't tweak it if you do not know what it does. If it has a decreed VCAR, you can't tweak it anyway. If you do not like it, and you have permission, delete it. This is NO different than any other component. If you tweak a VEVENT and add a RRULE, and your other CUA can not handle RRULE's, it is not the protocols fault and has no moral (bad) implications. -- 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 --------------ms040409080400020908040904 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 9w0BCQUxDxcNMDMxMjAxMTkwNDExWjAjBgkqhkiG9w0BCQQxFgQUPQ6nnEsHjvuu7ICgs358 UBLQUgowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAMwv/MtJg2PltjTRu1pVu5JY2wWk+k+pN6cwX6T69+0+QCkv9t0jo5PN/NXphcELg m/uoZ9rANoGD1Q8KkoTgFt0w/AclrnB/isnqeeArE/Jrizdry/Lka9ukY12Ip+yjTlihLKe/ H5iqUNdlMfppJSwggxhd28B1IBTtSRynJ6XxoycG/Y/242CVFkPFwckyAKXxew5YHbF2HVzg MfSiDZUXbDZxhRtcCXeDwOfXeotzH9N2cPdsI77tKwJQGyjidoh3ea616uRjqeRSweR/eSA7 IqAmlOnk20KaBnrrUE/f66TfrE59oiJRt5BsXiXGrpZwb3JlwSuZUebd8CsvzAAAAAAAAA== --------------ms040409080400020908040904-- From owner-ietf-calendar@mail.imc.org Mon Dec 1 14:34: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 OAA24021 for ; Mon, 1 Dec 2003 14:34: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 hB1JLRib003131 for ; Mon, 1 Dec 2003 11:21: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 hB1JLRx4003130 for ietf-calendar-bks; Mon, 1 Dec 2003 11:21:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB1JLNib003125 for ; Mon, 1 Dec 2003 11:21:25 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003120114364625919 for ; Mon, 01 Dec 2003 14:36:51 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Dec 2003 14:18:19 -0500 Message-ID: <3FCB93FA.1020608@centive.com> Date: Mon, 01 Dec 2003 14:18:18 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: an idea as an alternative to stored queries References: <3FCB90AB.3090408@Royer.com> In-Reply-To: <3FCB90AB.3090408@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2003 19:18:19.0140 (UTC) FILETIME=[E0DAEC40:01C3B83F] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > This is NO different than any other component. If you tweak a VEVENT > and add a RRULE, and your other CUA can not handle RRULE's, it is not > the protocols fault This is entirely different. With a stored query, there is no hope of knowing what the query does. -- /=====================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=====================================================| |"The Reality Check's in the mail." --L. Peter Deutsch| \=====================================================/ From owner-ietf-calendar@mail.imc.org Mon Dec 1 16:55: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 QAA03312 for ; Mon, 1 Dec 2003 16:55:29 -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 hB1LYiib008136 for ; Mon, 1 Dec 2003 13:34:44 -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 hB1LYicW008135 for ietf-calendar-bks; Mon, 1 Dec 2003 13:34:44 -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 hB1LYgib008130 for ; Mon, 1 Dec 2003 13:34:43 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:cVC4g54i6kdiwdebsMgRI7k7BaOTq2GX@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB1LYgvI020063 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 1 Dec 2003 13:34:43 -0800 Message-ID: <3FCBB3F1.9060404@Royer.com> Date: Mon, 01 Dec 2003 14:34:41 -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: an idea as an alternative to stored queries References: <3FCB90AB.3090408@Royer.com> <3FCB93FA.1020608@centive.com> In-Reply-To: <3FCB93FA.1020608@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050107090203030701050503" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050107090203030701050503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > >> This is NO different than any other component. If you tweak a VEVENT >> and add a RRULE, and your other CUA can not handle RRULE's, it is not >> the protocols fault > > > This is entirely different. With a stored query, there is no hope of > knowing what the query does. Fetch it and look just like any other component. -- 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 --------------ms050107090203030701050503 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 9w0BCQUxDxcNMDMxMjAxMjEzNDQxWjAjBgkqhkiG9w0BCQQxFgQU7anfLBahripdeUJOmszO 1c4yTeowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAC2BCG3KeHkww8e1kLvC8vZYjzQtvujpoBf2Im2vswHPF2HyGm4FbpvF3GmQfaKWG R3KRytTBhleSkRkTb+5uHyNG2dPjHjHtVsxVq1oCGryPG1XLJEDJ46WbkotnVIGINnsv1aBP FeettYBiAit5emUAzf4XawnE9mI2SNYhTnxKhNjdZQgSM1rx1/rH9Piducd8aIUiBMwPaivF SoYMgszu+jqRdPpR1wwM4QTf1GzPIymcKyzdVwleq6S3+P5Lw/Ata5kWYvdQ5pkxLeXv61Kx mMGCkFpaB2K6htCpd4iZzhpZnZRUOnYwGm4Ah4ASGj1EvdU+tIc8tzTWAlAPegAAAAAAAA== --------------ms050107090203030701050503-- From owner-ietf-calendar@mail.imc.org Mon Dec 1 17:14: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 RAA05185 for ; Mon, 1 Dec 2003 17:14:00 -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 hB1Lwdib009015 for ; Mon, 1 Dec 2003 13:58:39 -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 hB1Lwdxf009014 for ietf-calendar-bks; Mon, 1 Dec 2003 13:58:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB1Lwaib009009 for ; Mon, 1 Dec 2003 13:58:37 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003120117140403483 for ; Mon, 01 Dec 2003 17:14:04 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Dec 2003 16:55:37 -0500 Message-ID: <3FCBB8D9.20104@centive.com> Date: Mon, 01 Dec 2003 16:55:37 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: an idea as an alternative to stored queries References: <3FCB90AB.3090408@Royer.com> <3FCB93FA.1020608@centive.com> <3FCBB3F1.9060404@Royer.com> In-Reply-To: <3FCBB3F1.9060404@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2003 21:55:37.0442 (UTC) FILETIME=[DA858420:01C3B855] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > John Stracke wrote: > >> With a stored query, there is no hope of knowing what the query does. > > Fetch it and look just like any other component. But part of the point of stored queries is that you're supposed to be able to do things that can't be done in the query language. (Right?) Given that, there's nothing to fetch. Besides, the only reliable strategy would be to fetch it every time you connect; that's not going to save you anything over sending it every time. -- /=====================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=====================================================| |"The Reality Check's in the mail." --L. Peter Deutsch| \=====================================================/ From owner-ietf-calendar@mail.imc.org Mon Dec 1 18:54:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12959 for ; Mon, 1 Dec 2003 18:54:16 -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 hB1Nciib012934 for ; Mon, 1 Dec 2003 15:38:44 -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 hB1Ncihk012933 for ietf-calendar-bks; Mon, 1 Dec 2003 15:38:44 -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 hB1Ncgib012927 for ; Mon, 1 Dec 2003 15:38:42 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:Y5Ek1lSt6/vjT8V8YCNFJDMnoUl2y+Yn@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB1NcgvI022422 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 1 Dec 2003 15:38:43 -0800 Message-ID: <3FCBD101.1090205@Royer.com> Date: Mon, 01 Dec 2003 16:38:41 -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: an idea as an alternative to stored queries References: <3FCB90AB.3090408@Royer.com> <3FCB93FA.1020608@centive.com> <3FCBB3F1.9060404@Royer.com> <3FCBB8D9.20104@centive.com> In-Reply-To: <3FCBB8D9.20104@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050307070702010901050802" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050307070702010901050802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> >> >>> With a stored query, there is no hope of knowing what the query does. >> >> >> Fetch it and look just like any other component. > > > But part of the point of stored queries is that you're supposed to be > able to do things that can't be done in the query language. (Right?) > Given that, there's nothing to fetch. No. A dynamically created query is not the same thing as an undefineable query. Today a fetch of a hypthotecial 'CELL-VENDOR-NAME-TODAY' could return a VQUERY containing: ....where RECURRENCE-ID < 20031202T000000Z AND RECURRENCE-ID > 20031201T000000Z Tomorrow a fetch of that same VQUERY could return one containing: ....where RECURRENCE-ID < 20031203T000000Z AND RECURRENCE-ID > 20031202T000000Z How that dynamically stored VQUERY is inserted into your calendar and dynamically altered depending on the time/TZ is not a CAP issue, it is an implementaiton issue. > Besides, the only reliable strategy would be to fetch it every time > you connect; that's not going to save you anything over sending it > every time. No. If your cell phone needs 'get-vevents-only-for-today' and you tweak that VQUERY and change the VEVENT to VJOURNAL's, then you busted the query yourself, it is not a protocol issue, don't do that. Cell phones do get me XXX queries now (not using CAP however) and the cell phone can not change what is returned or tweak the contents of the query and do not need to download the query each time. Stored queries allow for cell phones to use CAP. -- 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 --------------ms050307070702010901050802 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 9w0BCQUxDxcNMDMxMjAxMjMzODQxWjAjBgkqhkiG9w0BCQQxFgQUWFV96WLAEGrEDKRkuDJz Ad0c9KcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAjdXK5srpolI7YDmwtIXSlcl0i/gEIuhMinS0jwAQQr9mDQandGKmOyXgcvcljfHT G9PTBNLFhdW+sp9QHokahqjaufjfLSuqb+orB7WSQurJk6oy7L7+BbLWF/VM2gMh+jRfZyVN FzwrumoO1omxb8Ln+RvVuQpMoJe/hLTYvvC2UN75r32INFkvKneS3BQ2fSTVIRGf82zPq/6A F9AeooMM+zlCF63AYPI/Y7K8DtR/F5sFVm7afo7+0Gjiq2Mpi3l/+swL12QK0rxkKYjMr61n vKhZMtVUTxt4NCQMXQqouW7sXejE8qAMD3Li4owVr94q4W7j0vIQbZgof+cevwAAAAAAAA== --------------ms050307070702010901050802-- From owner-ietf-calendar@mail.imc.org Mon Dec 1 20:18: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 UAA15081 for ; Mon, 1 Dec 2003 20:18:05 -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 hB213bib019986 for ; Mon, 1 Dec 2003 17:03: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 hB213b4F019985 for ietf-calendar-bks; Mon, 1 Dec 2003 17:03:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB213Zib019979 for ; Mon, 1 Dec 2003 17:03:35 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (sccrmhc12) with SMTP id <20031202010332012008deqre> (Authid: TimHare); Tue, 2 Dec 2003 01:03:32 +0000 Message-Id: <5.2.1.1.0.20031201190728.00a43050@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 01 Dec 2003 19:55:08 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: an idea as an alternative to stored queries In-Reply-To: <3FCBD101.1090205@Royer.com> References: <3FCBB8D9.20104@centive.com> <3FCB90AB.3090408@Royer.com> <3FCB93FA.1020608@centive.com> <3FCBB3F1.9060404@Royer.com> <3FCBB8D9.20104@centive.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Your stored query named "CELL-VENDOR-NAME-TODAY" would need to contain strings such as $CURRDATE and $CURRDATE+1 so that the implementation can substitute correctly each time. These strings would need to be implementation-defined; or else some standard for replaceable variables would need to be defined so that other implementations would know what to substitute for them. There would need to be a decreed VCAR to keep one implementation from using a stored VCAR which another implementation has defined - but from what I see, it isn't particularly easy to authenticate an implementation to assign it a UPN. That's an issue that might be difficult to resolve - I can't think of a good way to restrict stored queries by implementation without implementations having a UPN - but then each instance (cell phone, PDA, whatever) of a particular instance would have the same UPN, which is a problem. Another way around it is for each instance to store its own queries and lock them to the UPN of the CU using that device (CUA) - i.e. "John's stored queries can only be used by John" - but what if that CU uses more than one CUA with different implementations? Will the implementation name/identifier have to be stored as a propery of the VQUERY component? We could just let implementations use iana- or x-cmds to provide specialized function, but then the CUA would have to connect to a particular CS, one which supports the x-cmd, and we'd be almost be back to the proprietary methods we have now. The few proposals that I have now are (choose one, I'd guess): 1. Allow CUAs to store and retrieve VQUERY objects, much as CAP contains now, but explicitly state in CAP that interpretation and execution of the stored query is implementation-specific and therefore may not be (and probably is not) interoperable. 2. Define a small set of useful commands (as I have proposed before) which must be in all implementations (the GET-TODAY, GET-NEXT commands). This option requires all parties to agree to the set of commands and their implementation (i.e. what does "today" mean, etc.) 3. Remove stored queries from CAP and let each CUA store its own query objects in whatever form it wants, modify them, and send them - if there's a small set of them, such as the 'CELL-VENDOR-NAME-TODAY' query, it won't cost that much storage on a "small"-footprint device; there are also coding techniques to "compress" the storage of them (for example encoding frequently used strings into an index which points to the string, etcetera). I, having proposed it before, continue to favor option #2. What we need, however, is to reach consensus on _what_ we are going to do. If we are going to leave stored queries in CAP then I strongly favor something along the lines of option #1. Side notes: A) option 2 would _also_ allow cell phones to participate in CAP B) option 3 needs storage for the query commands- possibly as literals and such in the program objects. I think, however, that the amount of storage to build a query and send it might be _less_ than the storage to retrieve a stored query, parse it enough to substitute variables into it, and send it. If we're trying to save space for "small-footprint" devices, that's a consideration. C) let's not forget that the amount of storage on the "average" device which is a CUA (cell phone, organizer, etc.) is constantly growing - and that implementers of CAP on devices like that will probably implement on new models of devices, not retrofit it to their older ones Tim Hare Interested Bystander, Inc. From owner-ietf-calendar@mail.imc.org Mon Dec 1 20:18: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 UAA15083 for ; Mon, 1 Dec 2003 20:18:05 -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 hB216Rib020090 for ; Mon, 1 Dec 2003 17:06: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 hB216RWh020089 for ietf-calendar-bks; Mon, 1 Dec 2003 17:06:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from xgate.provo.novell.com (xgate.provo.novell.com [137.65.47.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB216Qib020081 for ; Mon, 1 Dec 2003 17:06:26 -0800 (PST) (envelope-from cjohnson@gw.novell.com) Received: from PROVO7-MTA by xgate.provo.novell.com with Novell_GroupWise; Mon, 01 Dec 2003 18:01:33 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Mon, 01 Dec 2003 18:07:59 -0700 From: "Craig Johnson" To: Subject: DTSTART for recurrence instances Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part86D87FFF.0__=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=__Part86D87FFF.0__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In the thread "Re: list of items (recur-id is not CAP)", Doug wrote (on 11/25/03): > When expanding an existing recurring object, you do not > modify the DTSTART value... (i.e. the DTSTART value of a recurrance instance is the DTSTART value of the recurrence 'master'.) Unless I have misunderstood, this seems contrary to common practice. Some clarification regarding DTSTART value for recurrence instances would be helpful. Suppose we have a recurring event for every Monday in January: BEGIN:VEVENT SUMMARY:Every Monday in January DTSTART:20040105T100000Z DTEND:20040105T110000Z UID:A-Unique-ID RRULE:FREQ=WEEKLY;UNTIL=20040131T170000Z; INTERVAL=1;BYDAY=MO;WKST=SU ... END:VEVENT Now suppose we SEARCH for that event with Expand:TRUE: BEGIN:VQUERY EXPAND:TRUE QUERY: SELECT * from VEVENT WHERE UID = 'A-Unique-ID' END:VQUERY What will be returned in the query? Will the DTSTART (and DTEND) of each recurrence instance be the same as the 'master' (as in column 1 below)? Or will DTSTART and DTEND have the 'effective' value for the recurrence instance (as in column 2 below)? Note: The first instance in each column is the same; subsequent instances begin to differ. For each instance - For each instance - DTSTART is same as the master DTSTART has 'effective' value (DTSTART not modified). for the recurrence instance. *----------------------------- *----------------------------- BEGIN:VEVENT BEGIN:VEVENT DTSTART: 20040105T100000Z DTSTART: 20040105T100000Z DTEND: 20040105T110000Z DTEND: 20040105T110000Z RECURRENCE-ID:20040105T100000Z RECURRENCE-ID:20040105T100000Z ... ... BEGIN:VEVENT BEGIN:VEVENT DTSTART: 20040105T100000Z DTSTART: 20040112T100000Z DTEND: 20040105T110000Z DTEND: 20040112T110000Z RECURRENCE-ID:20040112T100000Z RECURRENCE-ID:20040112T100000Z ... ... BEGIN:VEVENT BEGIN:VEVENT DTSTART: 20040105T100000Z DTSTART: 20040119T100000Z DTEND: 20040105T110000Z DTEND: 20040119T110000Z RECURRENCE-ID:20040119T100000Z RECURRENCE-ID:20040119T100000Z ... ... BEGIN:VEVENT BEGIN:VEVENT DTSTART: 20040105T100000Z DTSTART: 20040126T100000Z DTEND: 20040105T110000Z DTEND: 20040126T110000Z RECURRENCE-ID:20040126T100000Z RECURRENCE-ID:20040126T100000Z ... ... The expected result, intuitively and instinctively, is Column 2. The prior discussion thread implied that Column 1 is correct (along with some discussion explaining that this is why DTSTART is not always suitable for use in QUERYs, whereas RECURRENCE-ID is more suitable). This is a fundamental issue that impacts interoperability. I'd like to hear others view on this issue: What is the value of DTSTART for recurrence instances? - DTSTART is the same as the 'master'. - DTSTART is the 'effective' value for the instance. Thanks. Craig J. --=__Part86D87FFF.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
In the thread "Re: list of items (recur-id is not = CAP)",
Doug wrote (on 11/25/03):
 
> When expanding an existing recurring object, = you do not
> modify the DTSTART value...
(i.e. the DTSTART value of a recurrance instance = is the
DTSTART value of the recurrence 'master'.)
 
Unless I have misunderstood, this seems contrary = to common
practice.  Some clarification regarding DTSTART = value for
recurrence instances would be helpful.
=
 
Suppose we have a recurring event for every = Monday in January:
 
BEGIN:VEVENT
SUMMARY:Every Monday in = January
DTSTART:20040105T100000Z
DTEND:20040105T110000Z
UID:A-Uniq= ue-ID
RRULE:FREQ=3DWEEKLY;UNTIL=3D20040131T170000Z;
 INTERVAL=3D= 1;BYDAY=3DMO;WKST=3DSU
...
END:VEVENT
 
Now suppose we SEARCH for that event with = Expand:TRUE:
 
BEGIN:VQUERY
EXPAND:TRUE
QUERY: SELECT * = from VEVENT
  WHERE UID =3D 'A-Unique-ID'
END:VQUERY
 
What will be returned in the query?  Will the = DTSTART
(and DTEND) of each recurrence instance be the = same as
the 'master' (as in column 1 below)?  Or will = DTSTART and
DTEND have the 'effective' value for the recurrence= instance
(as in column 2 below)?  Note: The first = instance in each
column is the same; subsequent instances begin to = differ.
 
For each instance -    &= nbsp;         For each = instance -
DTSTART is same as the master   &n= bsp;DTSTART has 'effective' value
(DTSTART not modified).  &nb= sp;       for the recurrence instance.=
=97-----------------------------   = =97-----------------------------
BEGIN:VEVENT      &= nbsp;           &nbs= p;  BEGIN:VEVENT
DTSTART:      20040105T10= 0000Z   DTSTART:      20040105T100000ZDTEND:        20040105T110000Z &n= bsp; DTEND:        20040105T110000Z
R= ECURRENCE-ID:20040105T100000Z   RECURRENCE-ID:20040105T100000Z...            = ;            &n= bsp;     ...
BEGIN:VEVENT      &= nbsp;           &nbs= p;  BEGIN:VEVENT
DTSTART:      20040105T10= 0000Z   DTSTART:      20040112T100000ZDTEND:        20040105T110000Z &n= bsp; DTEND:        20040112T110000Z
R= ECURRENCE-ID:20040112T100000Z   RECURRENCE-ID:20040112T100000Z...            = ;            &n= bsp;     ...
BEGIN:VEVENT      &= nbsp;           &nbs= p;  BEGIN:VEVENT
DTSTART:      20040105T10= 0000Z   DTSTART:      20040119T100000ZDTEND:        20040105T110000Z &n= bsp; DTEND:        20040119T110000Z
R= ECURRENCE-ID:20040119T100000Z   RECURRENCE-ID:20040119T100000Z...            = ;            &n= bsp;     ...
BEGIN:VEVENT      &= nbsp;           &nbs= p;  BEGIN:VEVENT
DTSTART:      20040105T10= 0000Z   DTSTART:      20040126T100000ZDTEND:        20040105T110000Z &n= bsp; DTEND:        20040126T110000Z
R= ECURRENCE-ID:20040126T100000Z   RECURRENCE-ID:20040126T100000Z...            = ;            &n= bsp;     ...
 
=
The expected result, intuitively and = instinctively, is Column 2.
The prior discussion thread implied that Column 1 is correct=
(along with some discussion explaining that this is why DTSTART =
is not always suitable for use in QUERYs, whereas RECURRENCE-ID
is more suitable).
 
This is a fundamental issue that impacts = interoperability. 
I'd like to hear oth= ers view on this issue:
What is the value of DTSTART for recurrence instances?
  - DTSTART is the same as the 'master'.
  - DTSTART is the 'effective' value for the = instance.
 
Thanks.
Craig J.
--=__Part86D87FFF.0__=-- From owner-ietf-calendar@mail.imc.org Mon Dec 1 21:11:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16578 for ; Mon, 1 Dec 2003 21:11:33 -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 hB21wMib021459 for ; Mon, 1 Dec 2003 17:58:22 -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 hB21wM1l021458 for ietf-calendar-bks; Mon, 1 Dec 2003 17:58:22 -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 hB21wKib021453 for ; Mon, 1 Dec 2003 17:58:20 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:dNeK9OFHNg0eIeDW2i2/uZsGF1nB9iD/@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB21wJvI024304 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 1 Dec 2003 17:58:20 -0800 Message-ID: <3FCBF1BA.5010908@Royer.com> Date: Mon, 01 Dec 2003 18:58: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: an idea as an alternative to stored queries References: <3FCBB8D9.20104@centive.com> <3FCB90AB.3090408@Royer.com> <3FCB93FA.1020608@centive.com> <3FCBB3F1.9060404@Royer.com> <3FCBB8D9.20104@centive.com> <5.2.1.1.0.20031201190728.00a43050@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031201190728.00a43050@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050108040604050601030206" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050108040604050601030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > > Your stored query named "CELL-VENDOR-NAME-TODAY" would need to > contain strings such as $CURRDATE and $CURRDATE+1 No. -- 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 --------------ms050108040604050601030206 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 9w0BCQUxDxcNMDMxMjAyMDE1ODE4WjAjBgkqhkiG9w0BCQQxFgQUGMiJbAMmvOOxnEiVXAoB +ILiwikwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAmb6Oa/VnHIpy1187t9vZoNWpnRcb2GQQl7NlL2S36kB8mDepEnfulFdrVIxLZyHm Gv1WcZD6lZpAyxp0COrjPT2HjGpDO4iQeBSFLyEsfWs7Kg1iTfphRUvX3L8xhfNbbUhu+jRg B94DZMzG2RHRhaHFuawFfxXPhxRGBdrAubljZFqULv+dRcHOJoCmRXB45M+50p/owkOPJS9l hnmgdfkFRbOTm4BSVgvShP/G1VnOd9BgFFRS6IdVD/T8y+tjqtPaKvN1adR29ZCZUzBC1+H/ tZWlAdHbyI+BJ5n/Aq94XFr/wFxnBTcVY4HNdwwKkhWLwADYmvrvhrwZPxExgwAAAAAAAA== --------------ms050108040604050601030206-- From owner-ietf-calendar@mail.imc.org Mon Dec 1 21:27:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16897 for ; Mon, 1 Dec 2003 21:27:10 -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 hB22Euib021986 for ; Mon, 1 Dec 2003 18:14:56 -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 hB22EuB7021985 for ietf-calendar-bks; Mon, 1 Dec 2003 18:14:56 -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 hB22Esib021976 for ; Mon, 1 Dec 2003 18:14:54 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:hXJMX//YgcaMkEdPc2Ry5+yeTkfWsRqa@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB22EsvI024622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 1 Dec 2003 18:14:55 -0800 Message-ID: <3FCBF59D.80704@Royer.com> Date: Mon, 01 Dec 2003 19:14:53 -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: DTSTART for recurrence instances References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080805090201020805020908" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080805090201020805020908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Craig Johnson wrote: > Unless I have misunderstood, this seems contrary to common > practice. Some clarification regarding DTSTART value for > recurrence instances would be helpful. > > Suppose we have a recurring event for every Monday in January: > > BEGIN:VEVENT > SUMMARY:Every Monday in January > DTSTART:20040105T100000Z > DTEND:20040105T110000Z > UID:A-Unique-ID > RRULE:FREQ=WEEKLY;UNTIL=20040131T170000Z; > INTERVAL=1;BYDAY=MO;WKST=SU > ... > END:VEVENT > > Now suppose we SEARCH for that event with Expand:TRUE: > > BEGIN:VQUERY > EXPAND:TRUE > QUERY: SELECT * from VEVENT > WHERE UID = 'A-Unique-ID' > END:VQUERY > > What will be returned in the query? Will the DTSTART > (and DTEND) of each recurrence instance be the same as > the 'master' (as in column 1 below)? Yes. And each object returned will have a RECURRENCE-ID property added with its value set to the effective start time of that instance of the component. All objects returned will have the same DTSTART / [ DTEND | DURATION ] IN 2445 (EXDATE) (a similar section for EXRULE also exists): The "EXDATE" property can be used to exclude the value specified in "DTSTART". However, in such cases the original "DTSTART" date MUST still be maintained by the calendaring and scheduling system because the original "DTSTART" value has inherent usage dependencies by other properties such as the "RECURRENCE-ID". The only time the DTSTART is not the same as the master is when specifying a change to a single instance as described in iTIP 3.7.1 and 4.4.2 . Then the master is not altered, just the specifc object declaring the change details. > Or will DTSTART and > DTEND have the 'effective' value for the recurrence instance > (as in column 2 below)? No. Why would there need to be a new property (RECURRENCE-ID)? It could be done with a boolean (this is a single instance) to DTSTART if that were true. > The expected result, intuitively and instinctively, is Column 2. > The prior discussion thread implied that Column 1 is correct > (along with some discussion explaining that this is why DTSTART > is not always suitable for use in QUERYs, whereas RECURRENCE-ID > is more suitable). DTSTART is a fixed value for any specific revision of a UID. RECURRENCE-ID is calculated only when the object is expanded. > > This is a fundamental issue that impacts interoperability. > I'd like to hear others view on this issue: > What is the value of DTSTART for recurrence instances? > - DTSTART is the same as the 'master'. > - DTSTART is the 'effective' value for the instance. -- 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 --------------ms080805090201020805020908 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 9w0BCQUxDxcNMDMxMjAyMDIxNDUzWjAjBgkqhkiG9w0BCQQxFgQUu3fr/JwZA80t4KF7q9d/ rhte9Y0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA2G/UCdyYtzuG6q/5qCb5TF/2UD+HJG0kH8h7rlsDWOaFBskb1hD9sT8NITbFWFKv QRxq8ewd27YvEH1ShSO1HRtt+Kd9bbr1y13VElQ3mmPyafXRK6lR60hnacJZ8cl/v0SWjU7O A8MYuxyWPQfxatvdanpLA98ZWZHJdIeBhBSawfYDpukbJfFUDzjpc2EaCTKkBPh/hTW4b/I4 BmeGs6R6lcVbnopGqcI4M65gh9GSWsZXRnD0ar3seVCrDmgJXg2ZtQt4qHXoGnmMYxvGN6Ay 6z4oxlDkhB9Otck0s8zL3KUlFSAW2vsiCea/lDb5GFd6EatPOCaksVhDrvDl5QAAAAAAAA== --------------ms080805090201020805020908-- From owner-ietf-calendar@mail.imc.org Mon Dec 1 21:33: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 VAA17015 for ; Mon, 1 Dec 2003 21:33:48 -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 hB22J6ib022138 for ; Mon, 1 Dec 2003 18:19:06 -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 hB22J6Dk022137 for ietf-calendar-bks; Mon, 1 Dec 2003 18:19:06 -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 hB22J4ib022132 for ; Mon, 1 Dec 2003 18:19:05 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:H15ce0ZlMxb7Y+LjQNF1dupOoM9rJQsg@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB22J5vI024661 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 1 Dec 2003 18:19:05 -0800 Message-ID: <3FCBF698.8090607@Royer.com> Date: Mon, 01 Dec 2003 19:19:04 -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: an idea as an alternative to stored queries References: <3FCBB8D9.20104@centive.com> <3FCB90AB.3090408@Royer.com> <3FCB93FA.1020608@centive.com> <3FCBB3F1.9060404@Royer.com> <3FCBB8D9.20104@centive.com> <5.2.1.1.0.20031201190728.00a43050@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031201190728.00a43050@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000502050105000503070009" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000502050105000503070009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > ... > > The few proposals that I have now are (choose one, I'd guess): > > 1. Allow CUAs to store and retrieve VQUERY objects, much as CAP > contains now, but explicitly state in CAP that interpretation and > execution of the stored query is implementation-specific and therefore > may not be (and probably is not) interoperable. Yes, but not needed. The CS could just return this instance in times version of the query. > 2. Define a small set of useful commands (as I have proposed before) > which must be in all implementations (the GET-TODAY, GET-NEXT > commands). This option requires all parties to agree to the set of > commands and their implementation (i.e. what does "today" mean, etc.) > Side notes: > > A) option 2 would _also_ allow cell phones to participate in CAP If everyone could agree what is needed and what they did. Examples: I do not support VJOURNAL, I do not want to pay transfer those. Do not transfer attachments. Do not transfer DESCRIPTION ... -- 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 --------------ms000502050105000503070009 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 9w0BCQUxDxcNMDMxMjAyMDIxOTA0WjAjBgkqhkiG9w0BCQQxFgQUTClgXdTewCaud1po3r/k W13PyGgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAgdVz55ukpkXi3wpZGhBPtsZwzbjj791P8X3KNzcsEee+TFuiBj9Ay3VyIJZ10DRg tQ9/G38SUHGb43NhgbkExpUPpw9mcd0vElzEDnm1OfISxdmsHbcgBOsxTzOeWOIXmG56bSdU xFK+3ZceLpSHUwa2fIkDQBAfo7VeRX8rOuebzVEANZjwGqoYGlG8Mm1xzVnW0jqX+dcm0ZWF DENenxf57kp/U6SZN5529GW2nGkX2NHFuN60+Anx7r1nFE3oo/PGFss/b/PgZgSJ2opC3gsl mwsnjsbpYHkiSS+ommcFaxybdJPiFrxT4N5KJZqr9q40KLHVx4A1GLQuFWlZrgAAAAAAAA== --------------ms000502050105000503070009-- From owner-ietf-calendar@mail.imc.org Tue Dec 2 09:25: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 JAA18501 for ; Tue, 2 Dec 2003 09:25:20 -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 hB2E6Mib019982 for ; Tue, 2 Dec 2003 06:06:22 -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 hB2E6M0Y019981 for ietf-calendar-bks; Tue, 2 Dec 2003 06:06:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2E6Lib019974 for ; Tue, 2 Dec 2003 06:06:21 -0800 (PST) (envelope-from olivierg@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id hB2E6HLh028845 for ; Tue, 2 Dec 2003 06:06:17 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 2 Dec 2003 06:06:15 -0800 Received: from [17.1.53.242] ([17.1.53.242]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id hB2E5e0m010460 for ; Tue, 2 Dec 2003 06:05:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3FCBF59D.80704@Royer.com> References: <3FCBF59D.80704@Royer.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2--275025939 Message-Id: From: Olivier Gutknecht Subject: Re: DTSTART for recurrence instances Date: Tue, 2 Dec 2003 15:06:10 +0100 To: ietf-calendar@imc.org X-Mailer: Apple Mail (2.606) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-2--275025939 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 2 d=E9c. 03, at 03:14, Doug Royer wrote: > Craig Johnson wrote: > >> Unless I have misunderstood, this seems contrary to common >> practice. Some clarification regarding DTSTART value for >> recurrence instances would be helpful. >> Suppose we have a recurring event for every Monday in January: >> BEGIN:VEVENT >> SUMMARY:Every Monday in January >> DTSTART:20040105T100000Z >> DTEND:20040105T110000Z >> UID:A-Unique-ID >> RRULE:FREQ=3DWEEKLY;UNTIL=3D20040131T170000Z; >> INTERVAL=3D1;BYDAY=3DMO;WKST=3DSU >> ... >> END:VEVENT >> Now suppose we SEARCH for that event with Expand:TRUE: >> BEGIN:VQUERY >> EXPAND:TRUE >> QUERY: SELECT * from VEVENT >> WHERE UID =3D 'A-Unique-ID' >> END:VQUERY >> What will be returned in the query? Will the DTSTART >> (and DTEND) of each recurrence instance be the same as >> the 'master' (as in column 1 below)? > > Yes. And each object returned will have a RECURRENCE-ID property > added with its value set to the effective start time of that instance=20= > of the component. > All objects returned will have the same DTSTART / [ DTEND | DURATION = ] 2445 and 2446 mention RECURRENCE-ID as a way to actually identify=20 component instance more than for actual date for the event. For=20 example, in RFC 2445, sect 4.2.7: 'Component instances are identified by the combination of = "UID",=20 "RECURRENCE-ID", and "SEQUENCE" Or: RFC 2445, sect 4.8.4.4 The full range of calendar components specified by a recurrence set is referenced by referring to just the "UID" property value corresponding to the calendar component. The "RECURRENCE-ID" property allows the reference to an individual instance within the recurrence set. RFC 2446, sect 2.1.5 To reference an instance of a recurring component, the primary = key is=20 composed of the "UID" and the "RECURRENCE-ID" properties. There is also a note in 2445 4.8.4.4 about DATE value type that=20 actually tells something about DTSTART semantics in a RECURRENCE-ID=20 based component: If the value of the "DTSTART" property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. The definition here is for the -recurrence instance- and is a MUST. > IN 2445 (EXDATE) (a similar section for EXRULE also exists): > > The "EXDATE" property can be used to exclude the value specified in > "DTSTART". However, in such cases the original "DTSTART" date MUST > still be maintained by the calendaring and scheduling system because > the original "DTSTART" value has inherent usage dependencies by = other > properties such as the "RECURRENCE-ID". This is coherent in that case: making an exception on original DTSTART=20= with an EXDATE must not change the other, unrelated component instances=20= in the recurrence, as the RECURRENCE-ID is using the date where an=20 occurrence should happen in the recurrence. The recurrence definition=20 must not change for this to be possible, this include the RRULE of=20 course, and the original DTSTART. This has been corroborated by Frank=20= Dawson and Derik Stenerson recently: " a) the value for RECURRENCE-ID was agreed to be the date/time = =A0value=20 of the original recurrence instance. This value remains unchanged for=20 as =A0long as the base recurrence set (or pattern) exists. A = rescheduling=20 of an =A0individual recurrence instance did not cause creation of new=20 base recurrence =A0set, but only moved the start/end of the specified=20 recurrence instance. =A0 " RFC 2445 in 4.8.5.1 also mentions: The "DTSTART" property defines the first instance in the = recurrence=20 set. But note that this is in the context of a component definining the=20 recurrence (RRULE, EXDATE, RDATE, EXDATE, ...), not in the context of a=20= RECURRENCE-ID identified component instance. Actually, DTSTART=20 definition (4.8.4.2) only refer to the VEVENT component: Description: Within the "VEVENT" calendar component, this = property defines the start date and time for the event. So it seems somewhat unrelated to the DTSTART issue within a=20 RECURRENCE-ID identified component from Craig's example. > The only time the DTSTART is not the same as the master is when > specifying a change to a single instance as described in iTIP 3.7.1 > and 4.4.2 . Then the master is not altered, just the specifc object > declaring the change details. I think the issue comes from ambiguities like: RFC 2445 - 4.8.2.3 Date/Time Due Description: The value MUST be a date/time equal to or after = the=20 DTSTART value, if specified. RFC 2446 - 4.5.7.2 Calculating due dates in recurring VTODOs The due date in a recurring "VTODO" calendar component is either a fixed interval specified in the "REQUEST" method or specified using the "RECURRENCE-ID" property. The former is calculated by applying the difference between "DTSTART" and "DUE" properties and applying = it to each of the start of each recurring instance. Hence, if the initial "VTODO" calendar component specifies a "DTSTART" property value of "19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the interval of one day which is applied to each recurring instance of the "VTODO" calendar component to determine = the "DUE" date of the instance. Even if the text mention the original DTSTART as the reference point,=20 it does not mention the actual value of the DTSTART/DUE values in an=20 identified recurrence instance. The section is actually quite clear=20 when it differentiates the 'recurring instance' and the initial VTODO=20 component. And also: RFC 2245 - 4.6.6 Alarm Component In an alarm set to trigger on the "START" of an event or to-do, = the "DTSTART" property MUST be present in the associated event or to-do. RFC 2445 - 4.8.6.3 Trigger If the trigger is set relative to START, then the "DTSTART" = property MUST be present in the associated "VEVENT" or "VTODO" calendar component. In all these cases, the property is defined relative to the DTSTART (or=20= DTEND) of the associated component. If we assume that the DTSTART is=20 the DTSTART of the original event, how can we express an iTIP ADD=20 ("especially useful if there are instance-specific properties to be=20 preserved in a recurring "VEVENT"" - idem for VTODO) or COUNTER and=20 referring to actual DTSTART instance in that case and to global DTSTART=20= in another case ? >> Or will DTSTART and DTEND have the 'effective' value for the=20 >> recurrence instance >> (as in column 2 below)? > No. Why would there need to be a new property (RECURRENCE-ID)? > It could be done with a boolean (this is a single instance) to DTSTART > if that were true. Why introducing a new parameter if the existing model is sufficient ? >> The expected result, intuitively and instinctively, is Column 2. >> The prior discussion thread implied that Column 1 is correct >> (along with some discussion explaining that this is why DTSTART >> is not always suitable for use in QUERYs, whereas RECURRENCE-ID >> is more suitable). > > DTSTART is a fixed value for any specific revision of a UID. I can't see anything in 2445/2446 that explicitly states that. > RECURRENCE-ID is calculated only when the object is expanded. I agree with that. However (DUE case above), if the returned DTSTART is the original=20 DTSTART, I assume that means that a DUE property will also be the=20 original component DUE value ? If find that worrying for two reasons - EXPAND=3DTRUE is convenient for CUA that don't want or can't handle = the=20 complete recurrence model (PDA or cell phones were cited in earlier=20 discussions). That means that the query results will not be immediately=20= usable. I'm also worried with the case of a original event having an=20 alarm and a specific instance having a different alarm (a case likely=20= to be related to the ALARMID/SEQUENCE discussion). - Semantics of the returned VEVENT/VTODO recurrence instances seem to=20 be conflicting with many parts of the RFC 2445 texts that mentions=20 recurrence instances as 'self sufficient' components (see above,=20 4.8.4.1, 4.8.4.4). >> This is a fundamental issue that impacts interoperability. I'd like=20= >> to hear others view on this issue: >> What is the value of DTSTART for recurrence instances? >> - DTSTART is the same as the 'master'. >> - DTSTART is the 'effective' value for the instance. I also understand it as the effective value for the instance, instance=20= which is identified through UID/RECURRENCE-ID/SEQUENCE properties. Ol.= --Apple-Mail-2--275025939 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2 d=E9c. 03, at 03:14, Doug Royer wrote: Craig Johnson wrote: Unless I have misunderstood, this seems contrary to common practice. Some clarification regarding DTSTART value for recurrence instances would be helpful. Suppose we have a recurring event for every Monday in January: BEGIN:VEVENT SUMMARY:Every Monday in January DTSTART:20040105T100000Z DTEND:20040105T110000Z UID:A-Unique-ID RRULE:FREQ=3DWEEKLY;UNTIL=3D20040131T170000Z; INTERVAL=3D1;BYDAY=3DMO;WKST=3DSU ... END:VEVENT Now suppose we SEARCH for that event with Expand:TRUE: BEGIN:VQUERY EXPAND:TRUE QUERY: SELECT * from VEVENT WHERE UID =3D 'A-Unique-ID' END:VQUERY What will be returned in the query? Will the DTSTART (and DTEND) of each recurrence instance be the same as the 'master' (as in column 1 below)? Yes. And each object returned will have a RECURRENCE-ID property added with its value set to the effective start time of that instance of the component. All objects returned will have the same DTSTART / [ DTEND | DURATION ] 2445 and 2446 mention RECURRENCE-ID as a way to actually identify component instance more than for actual date for the event. For example, in RFC 2445, sect 4.2.7: 'CourierComponent = instances are identified by the combination of "UID", "RECURRENCE-ID", and "SEQUENCE"=20 Or: RFC 2445, sect 4.8.4.4 Courier The full range = of calendar components specified by a recurrence set is referenced by referring to just the "UID" property value corresponding to the calendar component. The "RECURRENCE-ID" property allows the reference to an individual instance within the recurrence set. RFC 2446, sect 2.1.5 To reference an instance of a recurring component, the primary = key is composed of the "UID" and the "RECURRENCE-ID" properties. There is also a note in 2445 4.8.4.4 about DATE value type that actually tells something about DTSTART semantics in a RECURRENCE-ID based component: Courier If the value of the "DTSTART" property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. The definition here is for the -recurrence instance- and is a MUST.=20 IN 2445 (EXDATE) (a similar section for EXRULE also exists): The "EXDATE" property can be used to exclude the value specified in "DTSTART". However, in such cases the original "DTSTART" date MUST still be maintained by the calendaring and scheduling system because the original "DTSTART" value has inherent usage dependencies by other properties such as the "RECURRENCE-ID". This is coherent in that case: making an exception on original DTSTART with an EXDATE must not change the other, unrelated component instances in the recurrence, as the RECURRENCE-ID is using the date where an occurrence should happen in the recurrence. The recurrence definition must not change for this to be possible, this include the RRULE of course, and the original DTSTART. This has been corroborated by Frank Dawson and Derik Stenerson recently: " a) the value for RECURRENCE-ID was agreed to be the date/time =A0value of the original recurrence instance. This value remains unchanged for as =A0long as the base recurrence set (or pattern) exists. A rescheduling of an =A0individual recurrence instance did not cause creation of new base recurrence =A0set, but only moved the start/end of the specified recurrence instance. =A0 " CourierRFC 2445 in 4.8.5.1 also mentions: The "DTSTART" property defines the first instance in the = recurrence set. But note that this is in the context of a component definining the recurrence (RRULE, EXDATE, RDATE, EXDATE, ...), not in the context of a RECURRENCE-ID identified component instance. Actually, DTSTART definition (4.8.4.2) only refer to the VEVENT component: CourierDescription: = Within the "VEVENT" calendar component, this property defines the start date and time for the event. = So it seems somewhat unrelated to the DTSTART issue within a RECURRENCE-ID identified component from Craig's example. The only time the DTSTART is not the same as the master is when specifying a change to a single instance as described in iTIP 3.7.1 and 4.4.2 . Then the master is not altered, just the specifc object declaring the change details. I think the issue comes from ambiguities like: Courier RFC 2445 - 4.8.2.3 Date/Time Due Courier Description: = The value MUST be a date/time equal to or after the DTSTART value, if specified. CourierRFC 2446 - 4.5.7.2 Calculating due dates in recurring VTODOs The due date in a recurring "VTODO" calendar component is either a fixed interval specified in the "REQUEST" method or specified using the "RECURRENCE-ID" property. The former is calculated by applying the difference between "DTSTART" and "DUE" properties and applying it to each of the start of each recurring instance. Hence, if the initial "VTODO" calendar component specifies a "DTSTART" property value of "19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the interval of one day which is applied to each recurring instance of the "VTODO" calendar component to determine the "DUE" date of the instance. Even if the text mention the original DTSTART as the reference point, it does not mention the actual value of the DTSTART/DUE values in an identified recurrence instance. The section is actually quite clear when it differentiates the 'recurring instance' and the initial VTODO component. And also: Courier RFC 2245 - 4.6.6 Alarm Component Courier In an alarm set = to trigger on the "START" of an event or to-do, the "DTSTART" property MUST be present in the associated event or to-do. RFC 2445 - 4.8.6.3 Trigger If the trigger is set relative to START, then the "DTSTART" = property MUST be present in the associated "VEVENT" or "VTODO" calendar component. In all these cases, the property is defined relative to the DTSTART (or DTEND) of the associated component. If we assume that the DTSTART is the DTSTART of the original event, how can we express an iTIP ADD ("Courierespecially useful if there are instance-specific properties to be preserved in a recurring "VEVENT"" - idem for VTODO) or COUNTER and referring to actual DTSTART instance in that case and to global DTSTART in another case ? Or will DTSTART and DTEND have the 'effective' value for the recurrence instance (as in column 2 below)?=20 No. Why would there need to be a new property (RECURRENCE-ID)? It could be done with a boolean (this is a single instance) to DTSTART if that were true. Why introducing a new parameter if the existing model is sufficient ? The expected result, intuitively and instinctively, is Column 2. The prior discussion thread implied that Column 1 is correct (along with some discussion explaining that this is why DTSTART is not always suitable for use in QUERYs, whereas RECURRENCE-ID is more suitable). DTSTART is a fixed value for any specific revision of a UID. I can't see anything in 2445/2446 that explicitly states that. RECURRENCE-ID is calculated only when the object is expanded. I agree with that. However (DUE case above), if the returned DTSTART is the original DTSTART, I assume that means that a DUE property will also be the original component DUE value ? If find that worrying for two reasons - EXPAND=3DTRUE is convenient for CUA that don't want or can't handle the complete recurrence model (PDA or cell phones were cited in earlier discussions). That means that the query results will not be immediately usable. I'm also worried with the case of a original event having an alarm and a specific instance having a different alarm (a case likely to be related to the ALARMID/SEQUENCE discussion). - Semantics of the returned VEVENT/VTODO recurrence instances seem to be conflicting with many parts of the RFC 2445 texts that mentions recurrence instances as 'self sufficient' components (see above, 4.8.4.1, 4.8.4.4). This is a fundamental issue that impacts interoperability. I'd like to hear others view on this issue: What is the value of DTSTART for recurrence instances? - DTSTART is the same as the 'master'. - DTSTART is the 'effective' value for the instance. I also understand it as the effective value for the instance, instance which is identified through UID/RECURRENCE-ID/SEQUENCE properties. Ol.= --Apple-Mail-2--275025939-- From owner-ietf-calendar@mail.imc.org Tue Dec 2 14:20: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 OAA03128 for ; Tue, 2 Dec 2003 14:20: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 hB2J1cib034362 for ; Tue, 2 Dec 2003 11:01:38 -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 hB2J1cKe034361 for ietf-calendar-bks; Tue, 2 Dec 2003 11:01:38 -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 hB2J1bib034356 for ; Tue, 2 Dec 2003 11:01:37 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:3aoK3GWaIdXvr/WVPB6yJsT6aAZ0lV2J@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB2J1XvI005461 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 2 Dec 2003 11:01:34 -0800 Message-ID: <3FCCE18D.8070007@Royer.com> Date: Tue, 02 Dec 2003 12:01:33 -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: DTSTART for recurrence instances References: <3FCBF59D.80704@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010608020000000005050609" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010608020000000005050609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Olivier Gutknecht wrote: > .... Because you mixed without quoting the author of the comments, I can not figure out which comment your are asking about or commenting on in your reply. Perhaps your GUI processes leading spaces/tabs differently than mine. -- 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 --------------ms010608020000000005050609 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 9w0BCQUxDxcNMDMxMjAyMTkwMTMzWjAjBgkqhkiG9w0BCQQxFgQUH3UuDzdqKCMudtEDlTWq jQdtfjYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAM1Se6BanBcHbTFfJteZa+wq2BTKwKNRP1Dkj9XywiKRDW2dz6+GwAeEnAOfuRCgZ Ghcp/552hWASHMKwjxoXWdrQttcnXf/2gWUa8+V7MwKbVdMLTW7y0uaU4QWRruQOU56y07S1 8CuoEmhw6jVN2I4FfyDSKGjUYGFbymdNmq9JPfm+TPO5mruFESgAWG/eodDrbH4u2QntRqX9 gzA8S/7igbVfyGPdQhiesN0DcXPVYhkPGPT/RYQBX/hGEwWIsxC76wtKxLpbosVenGfHBRmH O4bFGM0KXsQZVoJMDhW6rMDbz5VKdgowR2Xho8lUtcwiKE+9be4xcXsdDaI8YgAAAAAAAA== --------------ms010608020000000005050609-- From owner-ietf-calendar@mail.imc.org Wed Dec 3 05:00:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08043 for ; Wed, 3 Dec 2003 05:00: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 hB39fhib046071 for ; Wed, 3 Dec 2003 01:41:43 -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 hB39fhDi046069 for ietf-calendar-bks; Wed, 3 Dec 2003 01:41:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB39fgib046032 for ; Wed, 3 Dec 2003 01:41:42 -0800 (PST) (envelope-from olivierg@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hB39fbnc000981 for ; Wed, 3 Dec 2003 01:41:37 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 3 Dec 2003 01:41:36 -0800 Received: from [17.1.53.242] ([17.1.53.242]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id hB39f0ww001122 for ; Wed, 3 Dec 2003 01:41:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3FCCE18D.8070007@Royer.com> References: <3FCBF59D.80704@Royer.com> <3FCCE18D.8070007@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: From: Olivier Gutknecht Subject: Re: DTSTART for recurrence instances Date: Wed, 3 Dec 2003 10:41:34 +0100 To: ietf-calendar@imc.org X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB39fgib046060 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On 2 déc. 03, at 20:01, Doug Royer wrote: > Because you mixed without quoting the author of the comments, I can not > figure out which comment your are asking about or commenting on in > your reply. > Perhaps your GUI processes leading spaces/tabs differently than mine. Sorry, I copied some rich text and forgot to reforce everything in plain text. Here is a repost. On 2 déc. 03, at 03:14, Doug Royer wrote: > Craig Johnson wrote: > >> Unless I have misunderstood, this seems contrary to common >> practice. Some clarification regarding DTSTART value for >> recurrence instances would be helpful. >> Suppose we have a recurring event for every Monday in January: >> BEGIN:VEVENT >> SUMMARY:Every Monday in January >> DTSTART:20040105T100000Z >> DTEND:20040105T110000Z >> UID:A-Unique-ID >> RRULE:FREQ=WEEKLY;UNTIL=20040131T170000Z; >> INTERVAL=1;BYDAY=MO;WKST=SU >> ... >> END:VEVENT >> Now suppose we SEARCH for that event with Expand:TRUE: >> BEGIN:VQUERY >> EXPAND:TRUE >> QUERY: SELECT * from VEVENT >> WHERE UID = 'A-Unique-ID' >> END:VQUERY >> What will be returned in the query? Will the DTSTART >> (and DTEND) of each recurrence instance be the same as >> the 'master' (as in column 1 below)? > > Yes. And each object returned will have a RECURRENCE-ID property > added with its value set to the effective start time of that instance > of the component. > All objects returned will have the same DTSTART / [ DTEND | DURATION ] 2445 and 2446 mention RECURRENCE-ID as a way to actually identify component instance more than for actual date for the event. For example, in RFC 2445, sect 4.2.7: 'Component instances are identified by the combination of "UID", "RECURRENCE-ID", and "SEQUENCE" Or: RFC 2445, sect 4.8.4.4 The full range of calendar components specified by a recurrence set is referenced by referring to just the "UID" property value corresponding to the calendar component. The "RECURRENCE-ID" property allows the reference to an individual instance within the recurrence set. RFC 2446, sect 2.1.5 To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. There is also a note in 2445 4.8.4.4 about DATE value type that actually tells something about DTSTART semantics in a RECURRENCE-ID based component: If the value of the "DTSTART" property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. The definition here is for the -recurrence instance- and is a MUST. > IN 2445 (EXDATE) (a similar section for EXRULE also exists): > > The "EXDATE" property can be used to exclude the value specified in > "DTSTART". However, in such cases the original "DTSTART" date MUST > still be maintained by the calendaring and scheduling system because > the original "DTSTART" value has inherent usage dependencies by other > properties such as the "RECURRENCE-ID". This is coherent in that case: making an exception on original DTSTART with an EXDATE must not change the other, unrelated component instances in the recurrence, as the RECURRENCE-ID is using the date where an occurrence should happen in the recurrence. The recurrence definition must not change for this to be possible, this include the RRULE of course, and the original DTSTART. This has been corroborated by Frank Dawson and Derik Stenerson recently: " a) the value for RECURRENCE-ID was agreed to be the date/time  value of the original recurrence instance. This value remains unchanged for as  long as the base recurrence set (or pattern) exists. A rescheduling of an  individual recurrence instance did not cause creation of new base recurrence  set, but only moved the start/end of the specified recurrence instance.   " RFC 2445 in 4.8.5.1 also mentions: The "DTSTART" property defines the first instance in the recurrence set. But note that this is in the context of a component definining the recurrence (RRULE, EXDATE, RDATE, EXDATE, ...), not in the context of a RECURRENCE-ID identified component instance. Actually, DTSTART definition (4.8.4.2) only refer to the VEVENT component: Description: Within the "VEVENT" calendar component, this property defines the start date and time for the event. So it seems somewhat unrelated to the DTSTART issue within a RECURRENCE-ID identified component from Craig's example. > The only time the DTSTART is not the same as the master is when > specifying a change to a single instance as described in iTIP 3.7.1 > and 4.4.2 . Then the master is not altered, just the specifc object > declaring the change details. I think the issue comes from ambiguities like: RFC 2445 - 4.8.2.3 Date/Time Due Description: The value MUST be a date/time equal to or after the DTSTART value, if specified. RFC 2446 - 4.5.7.2 Calculating due dates in recurring VTODOs The due date in a recurring "VTODO" calendar component is either a fixed interval specified in the "REQUEST" method or specified using the "RECURRENCE-ID" property. The former is calculated by applying the difference between "DTSTART" and "DUE" properties and applying it to each of the start of each recurring instance. Hence, if the initial "VTODO" calendar component specifies a "DTSTART" property value of "19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the interval of one day which is applied to each recurring instance of the "VTODO" calendar component to determine the "DUE" date of the instance. Even if the text mention the original DTSTART as the reference point, it does not mention the actual value of the DTSTART/DUE values in an identified recurrence instance. The section is actually quite clear when it differentiates the 'recurring instance' and the initial VTODO component. And also: RFC 2245 - 4.6.6 Alarm Component In an alarm set to trigger on the "START" of an event or to-do, the "DTSTART" property MUST be present in the associated event or to-do. RFC 2445 - 4.8.6.3 Trigger If the trigger is set relative to START, then the "DTSTART" property MUST be present in the associated "VEVENT" or "VTODO" calendar component. In all these cases, the property is defined relative to the DTSTART (or DTEND) of the associated component. If we assume that the DTSTART is the DTSTART of the original event, how can we express an iTIP ADD ("especially useful if there are instance-specific properties to be preserved in a recurring "VEVENT"" - idem for VTODO) or COUNTER and referring to actual DTSTART instance in that case and to global DTSTART in another case ? >> Or will DTSTART and DTEND have the 'effective' value for the >> recurrence instance >> (as in column 2 below)? > No. Why would there need to be a new property (RECURRENCE-ID)? > It could be done with a boolean (this is a single instance) to DTSTART > if that were true. Why introducing a new parameter if the existing model is sufficient ? >> The expected result, intuitively and instinctively, is Column 2. >> The prior discussion thread implied that Column 1 is correct >> (along with some discussion explaining that this is why DTSTART >> is not always suitable for use in QUERYs, whereas RECURRENCE-ID >> is more suitable). > > DTSTART is a fixed value for any specific revision of a UID. I can't see anything in 2445/2446 that explicitly states that (see comments above about recurrence instances). > RECURRENCE-ID is calculated only when the object is expanded. I agree with that. However (DUE case above), if in the query result the returned DTSTART is the original DTSTART, I assume that means that a DUE property will also be the original component DUE value ? If find that worrying for two reasons: - EXPAND=TRUE is convenient for CUA that don't want or can't handle the complete recurrence model (PDA or cell phones were cited in earlier discussions). That means that the query results will not be immediately usable. I'm also worried with the case of a original event having an alarm and a specific instance having a different alarm (a case likely to be related to the ALARMID/SEQUENCE discussion). - Semantics of the returned VEVENT/VTODO recurrence instances seem to be debatable, because of the parts of RFC 2445 that mentions recurrence instances as 'self sufficient' components (see above, 4.8.4.1, 4.8.4.4). >> This is a fundamental issue that impacts interoperability. I'd like >> to hear others view on this issue: >> What is the value of DTSTART for recurrence instances? >> - DTSTART is the same as the 'master'. >> - DTSTART is the 'effective' value for the instance. I admit I also understand it as the effective value for the instance component, instance which is identified through UID/RECURRENCE-ID/SEQUENCE properties. Ol. From owner-ietf-calendar@mail.imc.org Wed Dec 3 16:22: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 QAA08262 for ; Wed, 3 Dec 2003 16:22:53 -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 hB3Ktmib081087 for ; Wed, 3 Dec 2003 12:55:48 -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 hB3KtmS4081086 for ietf-calendar-bks; Wed, 3 Dec 2003 12:55:48 -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 hB3Ktgib081080 for ; Wed, 3 Dec 2003 12:55:44 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:Q7xmwOFf/xGuDxLg9AhcKhkS1Y5Nlb3T@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB3KtavI026508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 3 Dec 2003 12:55:37 -0800 Message-ID: <3FCE4DC7.6020600@Royer.com> Date: Wed, 03 Dec 2003 13:55:35 -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: DTSTART for recurrence instances References: <3FCBF59D.80704@Royer.com> <3FCCE18D.8070007@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080701030401030408000406" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080701030401030408000406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Olivier Gutknecht wrote: > On 2 d=E9c. 03, at 03:14, Doug Royer wrote: > >> Craig Johnson wrote: >> >>> Unless I have misunderstood, this seems contrary to common >>> practice. Some clarification regarding DTSTART value for >>> recurrence instances would be helpful. >>> Suppose we have a recurring event for every Monday in January: >>> BEGIN:VEVENT >>> SUMMARY:Every Monday in January >>> DTSTART:20040105T100000Z >>> DTEND:20040105T110000Z >>> UID:A-Unique-ID >>> RRULE:FREQ=3DWEEKLY;UNTIL=3D20040131T170000Z; >>> INTERVAL=3D1;BYDAY=3DMO;WKST=3DSU >>> ... >>> END:VEVENT >>> Now suppose we SEARCH for that event with Expand:TRUE: >>> BEGIN:VQUERY >>> EXPAND:TRUE >>> QUERY: SELECT * from VEVENT >>> WHERE UID =3D 'A-Unique-ID' >>> END:VQUERY >>> What will be returned in the query? Will the DTSTART >>> (and DTEND) of each recurrence instance be the same as >>> the 'master' (as in column 1 below)? >> >> >> Yes. And each object returned will have a RECURRENCE-ID property >> added with its value set to the effective start time of that instance = >> of the component. >> All objects returned will have the same DTSTART / [ DTEND | DURATION = ] > > > 2445 and 2446 mention RECURRENCE-ID as a way to actually identify=20 > component instance more than for actual date for the event. For=20 > example, in RFC 2445, sect 4.2.7: > 'Component instances are identified by the combination of "UID",=20 > "RECURRENCE-ID", and "SEQUENCE" > > Or: RFC 2445, sect 4.8.4.4 > The full range of calendar components specified by a > recurrence set is referenced by referring to just the "UID" property= > value corresponding to the calendar component. The "RECURRENCE-ID" > property allows the reference to an individual instance within the > recurrence set. > > RFC 2446, sect 2.1.5 > To reference an instance of a recurring component, the primary key = > is composed of the "UID" and > the "RECURRENCE-ID" properties. > > There is also a note in 2445 4.8.4.4 about DATE value type that=20 > actually tells something about DTSTART semantics in a RECURRENCE-ID=20 > based component: > > If the value of the "DTSTART" property is a DATE type value, then the > value MUST be the calendar date for the recurrence instance. > > The definition here is for the -recurrence instance- and is a MUST.=20 Yes and as the section and subject of that text is 'Recurrence ID', as i= n : If the value of the "DTSTART" property is a DATE type value, then the= value [of RECURRENCE-ID] MUST be the calendar date for the=20 recurrence instance =20 >> IN 2445 (EXDATE) (a similar section for EXRULE also exists): >> >> The "EXDATE" property can be used to exclude the value specified in >> "DTSTART". However, in such cases the original "DTSTART" date MUST >> still be maintained by the calendaring and scheduling system because= >> the original "DTSTART" value has inherent usage dependencies by othe= r >> properties such as the "RECURRENCE-ID". > > > This is coherent in that case: making an exception on original DTSTART = > with an EXDATE must not change the other, unrelated component=20 > instances in the recurrence, as the RECURRENCE-ID is using the date=20 > where an occurrence should happen in the recurrence. The recurrence=20 > definition must not change for this to be possible, this include the=20 > RRULE of course, and the original DTSTART. This has been corroborated = > by Frank Dawson and Derik Stenerson recently: > > " a) the value for RECURRENCE-ID was agreed to be the date/time=20 > value of the original recurrence instance. This value remains=20 > unchanged for as long as the base recurrence set (or pattern) exists. = > A rescheduling of an individual recurrence instance did not cause=20 > creation of new base recurrence set, but only moved the start/end of=20 > the specified recurrence instance. =20 > > RFC 2445 in 4.8.5.1 also mentions: > The "DTSTART" property defines the first instance in the=20 > recurrence set. > But note that this is in the context of a component defining the=20 > recurrence (RRULE, EXDATE, RDATE, EXDATE, ...), not in the context of=20 > a RECURRENCE-ID identified component instance. Actually, DTSTART=20 > definition (4.8.4.2) only refer to the VEVENT component: > Description: Within the "VEVENT" calendar component, this property > defines the start date and time for the event. > > So it seems somewhat unrelated to the DTSTART issue within a=20 > RECURRENCE-ID identified component from Craig's example.=20 My point was that it can not be both ways. It has to change or it never=20 changes. >> The only time the DTSTART is not the same as the master is when >> specifying a change to a single instance as described in iTIP 3.7.1 >> and 4.4.2 . Then the master is not altered, just the specific object >> declaring the change details. > > > I think the issue comes from ambiguities like: > > RFC 2445 - 4.8.2.3 Date/Time Due > Description: The value MUST be a date/time equal to or after the=20 > DTSTART value, if specified.=20 I do no know why that would be ambiguous, for the 1st or Nth entry that=20 would be true no matter if DTSTART was changed or not. > RFC 2446 - 4.5.7.2 Calculating due dates in recurring VTODOs > The due date in a recurring "VTODO" calendar component is either a > fixed interval specified in the "REQUEST" method or specified using > the "RECURRENCE-ID" property. The former is calculated by applying > the difference between "DTSTART" and "DUE" properties and applying i= t > to each of the start of each recurring instance. Hence, if the > initial "VTODO" calendar component specifies a "DTSTART" property > value of "19970701T190000Z" and a "DUE" property value of > "19970801T190000Z" the interval of one day which is applied to each > recurring instance of the "VTODO" calendar component to determine th= e > "DUE" date of the instance. > > Even if the text mention the original DTSTART as the reference point,=20 > it does not mention the actual value of the DTSTART/DUE values in an=20 > identified recurrence instance. The section is actually quite clear=20 > when it differentiates the 'recurring instance' and the initial VTODO=20 > component.=20 So you are saying that the DUE date must change in each expanded instance= of a recurring VTODO? If so I disagree as it says to calculate the due date from the DTSTART=20 and DUE dates to get the offset and apply it to RECURRENCE-ID (which would have t= o be different or it would be pointless). this-instance-due =3D ( DUE - DTSTART) + RECURRENCE-ID Where DUE must be >=3D DTSTART as defined in 2445 in your quote above. > And also: > > RFC 2245 - 4.6.6 Alarm Component > In an alarm set to trigger on the "START" of an event or to-do, the > "DTSTART" property MUST be present in the associated event or to-do.= =20 If DTSTART were the same as RECURRENCE-ID or not, that would be true as START is defined to be relative to the 'start' of the component, and=20 not DTSTART. If DTSTART were not present then recurring or not, you can not use any time relative to the 'start' (or 'DTSTART'). For a recurring instance the effective start of an instance is defined in 2445 to be the RECURRENCE-ID. So for an expanded component (With RECURRENCE-ID): component-start-time =3D RECURRENCE-ID =20 alarm-start-time =3D component-start-time + 'START' component-end-time =3D RECURRENCE-ID + DURATION -or- =20 component-end-time =3D RECURRENCE-ID + ( DTEND - DTSTART) alarm-end-time =3D component-end-time + 'END' > RFC 2445 - 4.8.6.3 Trigger > If the trigger is set relative to START, then the "DTSTART" propert= y > MUST be present in the associated "VEVENT" or "VTODO" calendar > component. > > In all these cases, the property is defined relative to the DTSTART=20 > (or DTEND) of the associated component. If we assume that the DTSTART=20 > is the DTSTART of the original event, how can we express an iTIP ADD=20 > ("especially useful if there are instance-specific properties to be=20 > preserved in a recurring "VEVENT"" - idem for VTODO) or COUNTER and=20 > referring to actual DTSTART instance in that case and to global=20 > DTSTART in another case ?=20 No. The text says that "START" is relative to the "start" of a component, it does NOT say START is relative to 'DTSTART'. And "END" is defined to be relative to the "end" of a component, it does NOT say END is relative to 'DTEND' or 'DURATION' See "4.2.14 Alarm Trigger Relationship" >>> Or will DTSTART and DTEND have the 'effective' value for the=20 >>> recurrence instance >>> (as in column 2 below)? >> >> No. Why would there need to be a new property (RECURRENCE-ID)? >> It could be done with a boolean (this is a single instance) to DTSTART= >> if that were true. > > > Why introducing a new parameter if the existing model is sufficient ?=20 I agree. I am not proposing new parameter. I am saying that defining DTSTART to be the same as RECURRENCE-ID in an expanded instance is pointless and the fact that RECURRENCE-ID exists is an argument for that fact it needs to be different (when instance > 1st). Else why was it invented whe= n a boolean parameter would have worked? >>> The expected result, intuitively and instinctively, is Column 2. >>> The prior discussion thread implied that Column 1 is correct >>> (along with some discussion explaining that this is why DTSTART >>> is not always suitable for use in QUERYs, whereas RECURRENCE-ID >>> is more suitable). >> >> >> DTSTART is a fixed value for any specific revision of a UID. > > > I can't see anything in 2445/2446 that explicitly states that (see=20 > comments above about recurrence instances).=20 See "4.8.7.4 Sequence Number", if DTSTART changes, the SEQUENCE MUST chan= ge. Thus the specific revisions of the UID is not the same. I used the words 'specific revision' to mean 'pattern' as you quoted=20 from Derik/Frank above. So restated: DTSTART is a fixed value for any specific pattern of a UID. Expanding the instances does not alter the DTSTART. >> RECURRENCE-ID is calculated only when the object is expanded. > > > I agree with that. > However (DUE case above), if in the query result the returned DTSTART=20 > is the original DTSTART, I assume that means that a DUE property will=20 > also be the original component DUE value ? If find that worrying for=20 > two reasons:=20 Yes that is what I mean. > - EXPAND=3DTRUE is convenient for CUA that don't want or can't handl= e=20 > the complete recurrence model (PDA or cell phones were cited in=20 > earlier discussions). That means that the query results will not be=20 > immediately usable. I'm also worried with the case of a original event = > having an alarm and a specific instance having a different alarm (a=20 > case likely to be related to the ALARMID/SEQUENCE discussion). > - Semantics of the returned VEVENT/VTODO recurrence instances seem=20 > to be debatable, because of the parts of RFC 2445 that mentions=20 > recurrence instances as 'self sufficient' components (see above,=20 > 4.8.4.1, 4.8.4.4).=20 Doing date math is really simple even in a cell phone. >>> This is a fundamental issue that impacts interoperability. I'd like = >>> to hear others view on this issue: >>> What is the value of DTSTART for recurrence instances? >>> - DTSTART is the same as the 'master'. >>> - DTSTART is the 'effective' value for the instance. >> > > I admit I also understand it as the effective value for the instance=20 > component, instance which is identified through=20 > UID/RECURRENCE-ID/SEQUENCE properties. > > Ol. --=20 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 --------------ms080701030401030408000406 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 9w0BCQUxDxcNMDMxMjAzMjA1NTM1WjAjBgkqhkiG9w0BCQQxFgQUpI3a1Na4r+y4Xo4y8IIn 1nJRd1cwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAgM9XTYJm14z0kAsMG8qzbP7oRKL5z5u1AEGTZgFX/5zb3kIIFceaw/ZATQmfAz4d AN6BvGDDIqX6BqPTQECIy2I6bd5v8jZXO7DewMQcJ434mLIsZhkGfGrNeSbW+rHyxjx2W/cH pBNmoa7V7mehOSFG/I39PtrG/CB48P0Vn/qlV2PVn0ZHiAX3HXWYbpdyMmz3GUZ/piB4zpfZ /ylgSycmKe78Evbs6VgcFG2qyQphLoDrxCfZ/kYLq0Dpbq1RVcSN6kR4f/UplUWCxwJD5XT6 8zWTKRWZXlJcJA39v3j1WGehbcnH4l5QVMMeNew4lhl+0MZdrX18DPN6fckWOAAAAAAAAA== --------------ms080701030401030408000406-- From owner-ietf-calendar@mail.imc.org Thu Dec 4 13:23:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07091 for ; Thu, 4 Dec 2003 13:23:57 -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 hB4I9Aib014708 for ; Thu, 4 Dec 2003 10:09:10 -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 hB4I994c014707 for ietf-calendar-bks; Thu, 4 Dec 2003 10:09:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from xgate.provo.novell.com (xgate.provo.novell.com [137.65.47.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4I97ib014701 for ; Thu, 4 Dec 2003 10:09:09 -0800 (PST) (envelope-from cjohnson@gw.novell.com) Received: from PROVO7-MTA by xgate.provo.novell.com with Novell_GroupWise; Thu, 04 Dec 2003 11:04:01 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Wed, 03 Dec 2003 17:10:02 -0700 From: "Craig Johnson" To: Subject: Re: DTSTART for recurrence instances Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartA8F6544A.0__=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=__PartA8F6544A.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Olivier presented an excellent case showing that a RECCURRENCE-ID's primary role is that of an 'identifier'; and not a 'date/time' value that can be relied on as the 'effective start' for a recurrence instance. This is made even more clear in the following from 2445: Section 4.8.4.4 Recurrence ID . . . The date/time value (RECURRENCE-ID) is set to the time when the original recurrence instance would occur; meaning that if the intent is to change a Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still set to the original Friday meeting. With RECURRENCE-ID consigned to the role of an identifier it clearly falls to DTSTART to represent a recurrence instance's effective start time. Doug wrote: > For a recurring instance the effective start of an instance > is defined in 2445 to be the RECURRENCE-ID. That is not quite correct. The effective start of an instance is its DTSTART. RECURRENCE-ID gets DTSTART as its initial value: 4.8.4.4 Recurrence ID . . . The property value is the effective value of the "DTSTART" property of the recurrence instance. This statement makes it clear that a recurrence instance has a DTSTART property containing the "effective" value ... and this is where RECURRENCE-ID gets its initial value. Initially, DTSTART and RECURRENCE-ID have the same value. If the instance is changed to a different time, DTSTART changes and RECURRENCE-ID does not. Craig J --=__PartA8F6544A.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
Olivier presented an excellent case showing that a = RECCURRENCE-ID's
primary role is that of an 'identifier'; and not a = 'date/time' value that can
be relied on as the 'effective start' for a = recurrence instance.  This is made
even more clear in the = following from 2445:
 
Section 4.8.4.4 Recurrence ID
. . .
 &= nbsp; The date/time value (RECURRENCE-ID) is set to the time when the original recurrence
   instance = would occur; meaning that if the intent is to change a
   = Friday meeting to Thursday, the date/time (RECURRENC= E-ID) is still set to the
   original Friday = meeting.
 
With RECURRENCE-ID consigned to the role of an = identifier
it clearly falls to DTSTART to represent a recurrence = instance's
effective start time.
 
Doug wrote:
> For a recurring instance the = effective start of an instance
> is defined in 2445 to be the = RECURRENCE-ID.
 
That is not quite correct.  The effective = start of an instance
is its DTSTART.  RECURRENCE-ID gets DTSTART = as its
initial value:
 
4.8.4.4 Recurrence ID
. . .   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      The property
   value = is the effective value of the "DTSTART" property of the
   = recurrence instance.
 
This statement makes it clear that a recurrence = instance has a
DTSTART property containing the "effective" value  = ... and this is
where RECURRENCE-ID gets its initial value.  = Initially, DTSTART
and RECURRENCE-ID have the same value.  If the = instance is
changed to a different time, DTSTART changes and
RECURR= ENCE-ID does not.
 
Craig J
--=__PartA8F6544A.0__=-- From owner-ietf-calendar@mail.imc.org Thu Dec 4 16:28: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 QAA16034 for ; Thu, 4 Dec 2003 16:28:10 -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 hB4LAGib024874 for ; Thu, 4 Dec 2003 13:10:16 -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 hB4LAGgU024873 for ietf-calendar-bks; Thu, 4 Dec 2003 13:10:16 -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 hB4LAEib024867 for ; Thu, 4 Dec 2003 13:10:14 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:bv8v2Hw5aaAWZSFgr8HSEEnmyTLxYcmz@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB4LACvI014442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 4 Dec 2003 13:10:14 -0800 Message-ID: <3FCFA2B3.7030304@Royer.com> Date: Thu, 04 Dec 2003 14:10:11 -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: DTSTART for recurrence instances References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000307070401050704000302" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000307070401050704000302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Craig Johnson wrote: > Olivier presented an excellent case showing that a RECCURRENCE-ID's > primary role is that of an 'identifier'; and not a 'date/time' value > that can > be relied on as the 'effective start' for a recurrence instance. This > is made > even more clear in the following from 2445: > > Section 4.8.4.4 Recurrence ID > . . . > The date/time value (RECURRENCE-ID) is set to the time when the > original recurrence > instance would occur; meaning that if the intent is to change a > Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still > set to the > original Friday meeting. Meaning in the object being sent in the reschedule. In order to say X moves to Y, you need to properties to hold X and Y. So the above paragraph means send a new object with the new Y in RECURRENCE-ID and the old X in DTSTART. > With RECURRENCE-ID consigned to the role of an identifier > it clearly falls to DTSTART to represent a recurrence instance's > effective start time. 2445 is talking about a reschedule object not what 2446 calls the master object. > Doug wrote: > > For a recurring instance the effective start of an instance > > is defined in 2445 to be the RECURRENCE-ID. > > That is not quite correct. The effective start of an instance > is its DTSTART. RECURRENCE-ID gets DTSTART as its > initial value: > > 4.8.4.4 Recurrence ID > . . . The property > value is the effective value of the "DTSTART" property of the > recurrence instance. > > This statement makes it clear that a recurrence instance has a > DTSTART property containing the "effective" value ... and this is > where RECURRENCE-ID gets its initial value. Initially, DTSTART > and RECURRENCE-ID have the same value. If the instance is > changed to a different time, DTSTART changes and > RECURRENCE-ID does not. Yet the topic of the section is RECURRENCE-ID and not DTSTART, so the subject usage 'THE" in that sentence is RECURENCE-ID and not DTSTART. Yes RECURRENCE-ID is the effective DTSTART of the 'instance'. If you have 3 daily instances the effective DTSTART of the 1st is 4-DEC, 2nd 5-DEC, and the 3rd 6-DEC. So the value of recurrence ids are: 1st RECURRENCE-ID: 4-DEC 2nd RECURRENCE-ID:5-DEC 3rd RECURRENCE-ID:6-DEC Is does not say the "the value of DTSTART is", it says the value [of recurrence-id] is the effective value of DTSTART. Not the same meaning. It also does not say the value of DTSTART and RECURRENCE-ID are both set to the same value (as I understoon one person to have said). -- 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 --------------ms000307070401050704000302 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 9w0BCQUxDxcNMDMxMjA0MjExMDExWjAjBgkqhkiG9w0BCQQxFgQUQP2OJ8BZdGvEmM0MOXx5 6CJluWQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAS7Yv9Igp/w6CdZ7eH1TmYNYhpFg1IvJ3Pt/8cvYgj7RP+w1tL0MeYPowjM/f0FS8 jMHytzs4yqrU9KE2kLbyfBmtIqUkvJmMlEK9EaeDKdcB7Fhiap9QLBZ5x6lb/EtzOEGonPVb MmUvGk/qRT4gXBlMbpbcHunQcwzyXM3OSWTLb38XTiFM0X8sy1eI3qDDKS8/mUwhKUPWo75l ldB8jA5pLKmocepVbhNBKyJs1F1ni3NdVveNLK0NkUWcOzvoBG7KD+FZf96+jJkc0LdAI1xz tQ1H27JJmhyPI0f8NZmRFY9fgUYvxvU18ZlZXcwjTBsiOjXhiMeHkP4PzhQVLwAAAAAAAA== --------------ms000307070401050704000302-- From owner-ietf-calendar@mail.imc.org Fri Dec 5 12:24:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14592 for ; Fri, 5 Dec 2003 12:24:11 -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 hB5H8Iib053026 for ; Fri, 5 Dec 2003 09:08: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 hB5H8I6T053025 for ietf-calendar-bks; Fri, 5 Dec 2003 09:08:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5H8Hib053014 for ; Fri, 5 Dec 2003 09:08:17 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FCFA2B3.7030304@Royer.com> To: ietf-calendar@imc.org Subject: Re: DTSTART for recurrence 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, 5 Dec 2003 12:08:06 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/05/2003 12:05:20 PM, Serialize complete at 12/05/2003 12:05:20 PM Content-Type: multipart/alternative; boundary="=_alternative 005DDDFC85256DF3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DDDFC85256DF3_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 12/04/2003 04:10:11 PM: > > Section 4.8.4.4 Recurrence ID > > . . . > > The date/time value (RECURRENCE-ID) is set to the time when the > > original recurrence > > instance would occur; meaning that if the intent is to change a > > Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still > > set to the > > original Friday meeting. > > Meaning in the object being sent in the reschedule. In order to say X > moves to Y, > you need to properties to hold X and Y. So the above paragraph means send a > new object with the new Y in RECURRENCE-ID and the old X in DTSTART. Lets not start this again shall we? The original authors have even responded to this and they have clearly said that RECURRENCE-ID does not change on an instance reschedule. The DTSTART for the instance can change on each instance reschedule but the the RECURRENCE-ID does not. I dont know what you mean by "hold X and Y". What you need is an identifier to correctly identify the instance in question as its properties change. Thats why was specified RECURRENCE-ID not to change on reschedules but DTSTART can. The others have got it right from the bits Ive read. If the identifier changed each time, you'll have one heck of a time trying to deal with missequenced or lost messages. Thats why RECURRENCE-ID does not change on each instance reschedule; so you can safely detect missed messages or missequenced ones and properly deal with them. Doug and Franks response to this seemed to be pretty clear on this point. And you seem to have it backwards in your last line there. The reschedule would send the unchanged RECURRENCE-ID (the old X?) and the new DTSTART (the new Y?) in a reschedule REQUEST (with 'newer' or 'higher' SEQUENCE, DTSTAMP etc values). Thus a second reschedule would use the same unchanged RECURRENCE-ID (the old X?) and another newer DTSTART (a new Z) value with a still higher SEQUENCE and newer DTSTAMP. If RECURRENCE-ID was supposed to be the previous incarnations DTSTART then you have 3 problems to contend with: Cases where reschedules do NOT entail changes to DTSTART (ie: a duration change only), how to deal with resequencing of messages that can arrive in any order and how to deal with missed messages. If you tried to build a 'chain' of RECURRENCE-ID(0) -> DTSTART(1) / RECURRENCE-ID(1) -> DTSTART(2)... then you cannot recover easily if a message is lost. It has been shown that in 5 simple steps you can easily mangle the workflow process when missequencing occurs too. Derik & Frank noted as much in their recent posting on this. > > With RECURRENCE-ID consigned to the role of an identifier > > it clearly falls to DTSTART to represent a recurrence instance's > > effective start time. > > 2445 is talking about a reschedule object not what 2446 calls the master > object. 2445 deals with the C&S properties and their meanings / behavoiur. 2446 deals with putting those properties into a coherent message for doing C&S workflow. The term "master" as first used in iTIP Section 2.1 Application Protocol refers to the Organizers copy of the entry since that is the "definitive" copy. All other copies are just that, copies that may or may not be in sync w/the Organizers version. Much like there is only 1 'master' copy of the U.S. Constitution or the Deed for your property. There can be copies made all you like but there is only 'master' copy or version of it. The line: "Attendees" do not make direct changes to the master calendar entry. could be slightly wrong in the CAP context since it is possible that an Invitee may have sufficient access rights to go and modify the Organizers copy directly. However this was not how we originally modeled the workflow process since that was not something anyone actually did in the C&S systems. Invitees always sent some kind of response back and the Organziers CUA (or perhaps server) would apply that change (or keep the information separate from the actual entry itself). Whether or not its good CAP design/practice to allow invitees to do this is something else though... > > This statement makes it clear that a recurrence instance has a > > DTSTART property containing the "effective" value ... and this is > > where RECURRENCE-ID gets its initial value. Initially, DTSTART > > and RECURRENCE-ID have the same value. If the instance is > > changed to a different time, DTSTART changes and > > RECURRENCE-ID does not. > > Yet the topic of the section is RECURRENCE-ID and not DTSTART, so the > subject usage 'THE" in that sentence is RECURENCE-ID and not DTSTART. > > Yes RECURRENCE-ID is the effective DTSTART of the 'instance'. If you have 3 > daily instances the effective DTSTART of the 1st is 4-DEC, 2nd 5-DEC, and > the 3rd 6-DEC. [Snip] > Is does not say the "the value of DTSTART is", it says the value [of > recurrence-id] > is the effective value of DTSTART. Not the same meaning. You are correct in that the text under 4.8.4.4 does NOT discuss the DTSTART value for the instance. It is talking about how RECURRENCE-ID is defined and dealt with. The text actually says: The date/time value is set to the time when the original recurrence instance would occur... meaning that when the instance is created the DTSTART and RECURRENCE-ID values are the same. As the instance gets rescheduled, the DTSTART may/may not change but the RECURRENCE-ID defintely does not. It is kept at the "original" value for the instance (which matched the original DTSTART value the instance had). The only reason the term "effective" is used is because not all recurrence is sent using RDATEs where the values are just given. With RRULEs the recipent must roll the rule out and calculate when the date/time of each repeat instance is (factoring in TZ shifts, etc). > It also does not say the value of DTSTART and RECURRENCE-ID are both > set to the same value (as I understoon one person to have said). I guess its all in how you read the cited line above then. BTW: more than 1 person has said this. I said it when we had the entire RECURRENCE-ID discussion during the summer and Frank and Derik (the original authors of 2445) said this in their posting on 18-Aug-03 (http://www.imc.org/ietf-calendar/mail-archive/msg08662.html ): a) the value for RECURRENCE-ID was agreed to be the date/time value of the original recurrence instance. This value remains unchanged for as long as the base recurrence set (or pattern) exists. A rescheduling of an individual recurrence instance did not cause creation of new base recurrence set, but only moved the start/end of the specified recurrence instance. and they even tried to explain why we did this: This semantic and behavior was settled on because it is imperative in order for an implementation to maintain order and sensibility between the original definition for the recurrence set and exceptions created by subsequent rescheduling actions on the recurrence set. To illustrate, consider the consequences if RECURRENCE-ID changed on each reschedule of an instance. Specifically, if the RECURRENCE-ID is changed on each reschedule of an instance, the sender and the recipient have no way to accurately know which instance is being referred to if just a single iTIP message was lost or mis-sequenced, or if the message is an invitation to a new instance entirely. This inability to distinguish invitation, from reschedule, from update is not problematic with the fixed RECURRENCE-ID because it is unambiguous which instance is being referred to. Ok, I guess it depends on your understanding of the word "original" but thats not something we need to codify in RFCs I hope. After all, you should be assigning RECURRENCE-ID properties to each instance when you first create them so you should see that the DTSTART and RECURRENCE-ID values you start with are the same. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005DDDFC85256DF3_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 12/04/2003 04:10:11 PM:
> > Section 4.8.4.4 Recurrence ID
> > . . .
> >    The date/time value (RECURRENCE-ID) is set to the time when the
> > original recurrence
> >    instance would occur; meaning that if the intent is to change a
> >    Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still
> > set to the
> >    original Friday meeting.
>
> Meaning in the object being sent in the reschedule. In order to say X
> moves to Y,
> you need to properties to hold X and Y. So the above paragraph means send a
> new object with the new Y in RECURRENCE-ID and the old X in DTSTART.
Lets not start this again shall we?  The original authors have even responded to this and they have clearly said that RECURRENCE-ID does not change on an instance reschedule.  The DTSTART for the instance can change on each instance reschedule but the the RECURRENCE-ID does not.  

I dont know what you mean by "hold X and Y".  What you need is an identifier to correctly identify the instance in question as its properties change.  Thats why was specified RECURRENCE-ID not to change on reschedules but DTSTART can.  The others have got it right from the bits Ive read.  

If the identifier changed each time, you'll have one heck of a time trying to deal with missequenced or lost messages.  Thats why RECURRENCE-ID does not change on each instance reschedule; so you can safely detect missed messages or missequenced ones and properly deal with them.  Doug and Franks response to this seemed to be pretty clear on this point.

And you seem to have it backwards in your last line there.  The reschedule would send the unchanged RECURRENCE-ID (the old X?) and the new DTSTART (the new Y?) in a reschedule REQUEST (with 'newer' or 'higher' SEQUENCE, DTSTAMP etc values).  Thus a second reschedule would use the same unchanged RECURRENCE-ID (the old X?) and another newer DTSTART (a new Z) value with a still higher SEQUENCE and newer DTSTAMP.  

If RECURRENCE-ID was supposed to be the previous incarnations DTSTART then you have 3 problems to contend with: Cases where reschedules do NOT entail changes to DTSTART (ie: a duration change only), how to deal with resequencing of messages that can arrive in any order and how to deal with missed messages.  If you tried to build a 'chain' of RECURRENCE-ID(0) -> DTSTART(1) / RECURRENCE-ID(1) -> DTSTART(2)... then you cannot recover easily if a message is lost.  It has been shown that in 5 simple steps you can easily mangle the workflow process when missequencing occurs too.  Derik & Frank noted as much in their recent posting on this.

> > With RECURRENCE-ID consigned to the role of an identifier
> > it clearly falls to DTSTART to represent a recurrence instance's
> > effective start time.
>
> 2445 is talking about a reschedule object not what 2446 calls the master
> object.
2445 deals with the C&S properties and their meanings / behavoiur.  2446 deals with putting those properties into a coherent message for doing C&S workflow.

The term "master" as first used in iTIP Section 2.1 Application Protocol refers to the Organizers copy of the entry since that is the "definitive" copy.  All other copies are just that, copies that may or may not be in sync w/the Organizers version.  Much like there is only 1 'master' copy of the U.S. Constitution or the Deed for your property.  There can be copies made all you like but there is only 'master' copy or version of it.

The line:

                                    "Attendees" do not make
  direct changes to the master calendar entry.

could be slightly wrong in the CAP context since it is possible that an Invitee may have sufficient access rights to go and modify the Organizers copy directly.  However this was not how we originally modeled the workflow process since that was not something anyone actually did in the C&S systems.  Invitees always sent some kind of response back and the Organziers CUA (or perhaps server) would apply that change (or keep the information separate from the actual entry itself).  Whether or not its good CAP design/practice to allow invitees to do this is something else though...

> > This statement makes it clear that a recurrence instance has a
> > DTSTART property containing the "effective" value  ... and this is
> > where RECURRENCE-ID gets its initial value.  Initially, DTSTART
> > and RECURRENCE-ID have the same value.  If the instance is
> > changed to a different time, DTSTART changes and
> > RECURRENCE-ID does not.
>
> Yet the topic of the section is RECURRENCE-ID and not DTSTART, so the
> subject usage 'THE" in that sentence is RECURENCE-ID and not DTSTART.
>
> Yes RECURRENCE-ID is the effective DTSTART of the 'instance'. If you have 3
> daily instances the effective DTSTART of the 1st is 4-DEC, 2nd 5-DEC, and
> the 3rd 6-DEC.
[Snip]
> Is does not say the "the value of DTSTART is", it says the value [of
> recurrence-id]
> is the effective value of DTSTART. Not the same meaning.
You are correct in that the text under 4.8.4.4 does NOT discuss the DTSTART value for the instance.  It is talking about how RECURRENCE-ID is defined and dealt with.  The text actually says:

   The date/time value is set to the time when the original recurrence
  instance would occur...

meaning that when the instance is created the DTSTART and RECURRENCE-ID values are the same.  As the instance gets rescheduled, the DTSTART may/may not change but the RECURRENCE-ID defintely does not.  It is kept at the "original" value for the instance (which matched the original DTSTART value the instance had).  

The only reason the term "effective" is used is because not all recurrence is sent using RDATEs where the values are just given.  With RRULEs the recipent must roll the rule out and calculate when the date/time of each repeat instance is (factoring in TZ shifts, etc).  

> It also does not say the value of DTSTART and RECURRENCE-ID are both
> set to the same value (as I understoon one person to have said).
I guess its all in how you read the cited line above then.

BTW: more than 1 person has said this.  I said it when we had the entire RECURRENCE-ID discussion during the summer and Frank and Derik (the original authors of 2445) said this in their posting on 18-Aug-03 (http://www.imc.org/ietf-calendar/mail-archive/msg08662.html ):

a) the value for RECURRENCE-ID was agreed to be the date/time value of the original recurrence instance. This value remains unchanged for as long as the base recurrence set (or pattern) exists. A rescheduling of an individual recurrence instance did not cause creation of new base recurrence set, but only moved the start/end of the specified recurrence instance.

and they even tried to explain why we did this:

This semantic and behavior was settled on because it is imperative in order for an implementation to maintain order and sensibility between the original definition for the recurrence set and exceptions created by subsequent rescheduling actions on the recurrence set. To illustrate, consider the consequences if RECURRENCE-ID changed on each reschedule of an instance. Specifically, if the RECURRENCE-ID is changed on each reschedule of an instance, the sender and the recipient have no way to accurately know which instance is being referred to if just a single iTIP message was lost or mis-sequenced, or if the message is an invitation to a new instance entirely.  This inability to distinguish invitation, from reschedule, from update is not problematic with the fixed RECURRENCE-ID because it is unambiguous which instance is being referred to.

Ok, I guess it depends on your understanding of the word "original" but thats not something we need to codify in RFCs I hope.  After all, you should be assigning RECURRENCE-ID properties to each instance when you first create them so you should see that the DTSTART and RECURRENCE-ID values you start with are the same.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005DDDFC85256DF3_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 5 13:06: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 NAA16682 for ; Fri, 5 Dec 2003 13:06:08 -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 hB5Hokib055614 for ; Fri, 5 Dec 2003 09:50: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 hB5Hok0s055613 for ietf-calendar-bks; Fri, 5 Dec 2003 09:50:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Hoiib055602 for ; Fri, 5 Dec 2003 09:50:44 -0800 (PST) (envelope-from olivierg@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hB5Hofnc005831 for ; Fri, 5 Dec 2003 09:50:41 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 5 Dec 2003 09:50:39 -0800 Received: from [17.1.53.242] ([17.1.53.242]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id hB5HoIEV027600 for ; Fri, 5 Dec 2003 09:50:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3FCFA2B3.7030304@Royer.com> References: <3FCFA2B3.7030304@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> From: Olivier Gutknecht Subject: Re: DTSTART for recurrence instances Date: Fri, 5 Dec 2003 18:50:38 +0100 To: ietf-calendar@imc.org X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB5Hojib055607 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On 3 déc. 03, at 21:55, Doug Royer wrote: >> >> There is also a note in 2445 4.8.4.4 about DATE value type that >> actually tells something about DTSTART semantics in a RECURRENCE-ID >> based component: >> >> If the value of the "DTSTART" property is a DATE type value, then the >> value MUST be the calendar date for the recurrence instance. >> >> The definition here is for the -recurrence instance- and is a MUST. > > Yes and as the section and subject of that text is 'Recurrence ID', > as in : > If the value of the "DTSTART" property is a DATE type value, then > the > value [of RECURRENCE-ID] MUST be the calendar date for the > recurrence instance Right, so we agree this is only about the 'value type' coherence problem between (original) DTSTART & RECURRENCE-ID. On 4 déc. 03, at 22:10, Doug Royer wrote: > Craig Johnson wrote: >> Olivier presented an excellent case showing that a RECCURRENCE-ID's >> primary role is that of an 'identifier'; and not a 'date/time' value >> that can >> be relied on as the 'effective start' for a recurrence instance. >> This is made >> even more clear in the following from 2445: >> Section 4.8.4.4 Recurrence ID >> . . . >> The date/time value (RECURRENCE-ID) is set to the time when the >> original recurrence >> instance would occur; meaning that if the intent is to change a >> Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still >> set to the >> original Friday meeting. > > Meaning in the object being sent in the reschedule. In order to say X > moves to Y, > you need to properties to hold X and Y. So the above paragraph means > send a > new object with the new Y in RECURRENCE-ID and the old X in DTSTART. [..] >> With RECURRENCE-ID consigned to the role of an identifier >> it clearly falls to DTSTART to represent a recurrence instance's >> effective start time. > 2445 is talking about a reschedule object not what 2446 calls the > master object. I don't think so as the text only refer to recurrence instance identification, and disagree with the above interpretation of having the object sent to reschedule. RFC 2445 is not talking about a reschedule object. The only concept in the RECURRENCE-ID definition in 2445 is the 'specific instance of a recurring event'. Which is coherent with the aim of 2445 to be a core, standalone, data model in my opinion (and close to Craig's views if I understand him correctly), leaving the (re)scheduling aspects to additional specifications (2446 being one specific possible model) Having the RECURRENCE-ID value reflecting the effective value of the start date for the given instance is not coherent with the aim of using recurrence-id along with UID and sequence to properly identify the recurrence instance, as clarified by Frank and Derik: "The value for RECURRENCE-ID was agreed to be the date/time  value of the original recurrence instance. This value remains unchanged for as  long as the base recurrence set (or pattern) exists. A rescheduling of an  individual recurrence instance did not cause creation of new base recurrence  set, but only moved the start/end of the specified recurrence instance." [...] "Rescheduling individual recurrence instances did not cause recreation of the recurrence set or change the value of the RECURRENCE-ID property for the associated recurrence instance, but only involved changes to the start/end of the recurrence instance." If the RECURRENCE-ID value is not changed, "changes to the start/end of the recurrence instance" are done, how can it be expressed if not in DTSTART / DTEND values ? How can a rescheduled specific instance could be expressed in a complete snapshot of the event state if not by having the recurrence-ID identifying the initial value for the instance and dtstart giving the actual, rescheduled value ? >> Doug wrote: >> > For a recurring instance the effective start of an instance >> > is defined in 2445 to be the RECURRENCE-ID. >> That is not quite correct. The effective start of an instance >> is its DTSTART. RECURRENCE-ID gets DTSTART as its >> initial value: >> 4.8.4.4 Recurrence ID >> . . . The property >> value is the effective value of the "DTSTART" property of the >> recurrence instance. >> This statement makes it clear that a recurrence instance has a >> DTSTART property containing the "effective" value ... and this is >> where RECURRENCE-ID gets its initial value. Initially, DTSTART >> and RECURRENCE-ID have the same value. If the instance is >> changed to a different time, DTSTART changes and >> RECURRENCE-ID does not. > > Yet the topic of the section is RECURRENCE-ID and not DTSTART, so the > subject usage 'THE" in that sentence is RECURENCE-ID and not DTSTART. Immediatly below, this is precised to be "The date/time value is set to the time when the original recurrence instance would occur; meaning that if the intent is to change a Friday meeting to Thursday, the date/time is still set to the original Friday meeting." Why insisting on "the time when the *original* recurrence instance would occur" if not to have a possible -distinct- dtstart ? the 'The' in that case is the RECURRENCE-ID (topic of the section). > Yes RECURRENCE-ID is the effective DTSTART of the 'instance'. If you > have 3 > daily instances the effective DTSTART of the 1st is 4-DEC, 2nd 5-DEC, > and > the 3rd 6-DEC. > > So the value of recurrence ids are: > 1st > RECURRENCE-ID: 4-DEC > 2nd > RECURRENCE-ID:5-DEC > 3rd > RECURRENCE-ID:6-DEC Agreed. > Is does not say the "the value of DTSTART is", it says the value [of > recurrence-id] > is the effective value of DTSTART. Not the same meaning. ... as the initial recurrence instance value, and I think we all agree about that. This does not imply that the DTSTART for the specified recurrence instance must never change or be the start date of the original event instance. It is more than likely that we're actually discussing the very same problem of recurrence-ID 'stability' again. Ol. From owner-ietf-calendar@mail.imc.org Fri Dec 5 14:30: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 OAA19799 for ; Fri, 5 Dec 2003 14:30: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 hB5J8Zib059391 for ; Fri, 5 Dec 2003 11:08:35 -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 hB5J8Z1a059390 for ietf-calendar-bks; Fri, 5 Dec 2003 11:08: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 hB5J8Yib059382 for ; Fri, 5 Dec 2003 11:08:34 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:MzdkqPM+Nnrpf9Z5rzkoordDc5dtv7L9@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB5J8TvI031736 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 5 Dec 2003 11:08:31 -0800 Message-ID: <3FD0D7AC.2070602@Royer.com> Date: Fri, 05 Dec 2003 12:08:28 -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: DTSTART for recurrence instances References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060208090103030507070408" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060208090103030507070408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 12/04/2003 04:10:11 PM: > > > Section 4.8.4.4 Recurrence ID > > > . . . > > > The date/time value (RECURRENCE-ID) is set to the time when the > > > original recurrence > > > instance would occur; meaning that if the intent is to change a > > > Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still > > > set to the > > > original Friday meeting. > > > > Meaning in the object being sent in the reschedule. In order to say X > > moves to Y, > > you need to properties to hold X and Y. So the above paragraph means > send a > > new object with the new Y in RECURRENCE-ID and the old X in DTSTART. > > Lets not start this again shall we? The original authors have even > responded to this and they have clearly said that RECURRENCE-ID does > not change on an instance reschedule. The DTSTART for the instance > can change on each instance reschedule but the the RECURRENCE-ID does > not. NO ONE SAID THAT IS THE TOPIC. -- 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 --------------ms060208090103030507070408 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 9w0BCQUxDxcNMDMxMjA1MTkwODI5WjAjBgkqhkiG9w0BCQQxFgQU7IQ7vDO3mLNQXyC14fzn q1saFyAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEArZC8VitW8EsNZCFOqN1bqBBw2BvYCnx2b6KXUXr79o6aErh7tx0O6oKoETwhD/mX ysncRlDXBIh4NUmGLS5s0CX4fgcac/MyaJbZTLlTl1WD3AzEVxO/rxLGKRWYwg68eiW6Vt0V lPMyrEW1bbQN6grPslwXiEf5d4e+/bUc55+id84VaS7ZEdA0y2SxKx+xa5MjUG/W9PpGTsFF X7V6jPTxurmM4+Tk7W8xoqpyBFc/Pruy9Lm80DBCB1a4lR2e2FKVd6pFGqkhpBozHB3jfJxx afmFdJWCiV41ZdbSxvHhGAyD1EeVrSML5+AOj15vs/yqUd/C7nwcCrhmQpKC9wAAAAAAAA== --------------ms060208090103030507070408-- From owner-ietf-calendar@mail.imc.org Fri Dec 5 14:32: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 OAA19927 for ; Fri, 5 Dec 2003 14:32:01 -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 hB5JG1ib059737 for ; Fri, 5 Dec 2003 11:16:01 -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 hB5JG1Ul059736 for ietf-calendar-bks; Fri, 5 Dec 2003 11:16:01 -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 hB5JFxib059728 for ; Fri, 5 Dec 2003 11:16:00 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:R0BI5QLyDwzTO3K4qLFGakNawFXDOqPl@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB5JFuvI031839 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 5 Dec 2003 11:15:57 -0800 Message-ID: <3FD0D96C.9030704@Royer.com> Date: Fri, 05 Dec 2003 12:15:56 -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: DTSTART for recurrence instances References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> In-Reply-To: <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070406040704040808010106" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070406040704040808010106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Olivier Gutknecht wrote: > > On 3 d=E9c. 03, at 21:55, Doug Royer wrote: > >>> >>> There is also a note in 2445 4.8.4.4 about DATE value type that=20 >>> actually tells something about DTSTART semantics in a RECURRENCE-ID=20 >>> based component: >>> >>> If the value of the "DTSTART" property is a DATE type value, then th= e >>> value MUST be the calendar date for the recurrence instance. >>> >>> The definition here is for the -recurrence instance- and is a MUST. >> >> >> Yes and as the section and subject of that text is 'Recurrence ID',=20 >> as in : >> If the value of the "DTSTART" property is a DATE type value, then t= he >> value [of RECURRENCE-ID] MUST be the calendar date for the=20 >> recurrence instance > > > Right, so we agree this is only about the 'value type' coherence=20 > problem between (original) DTSTART & RECURRENCE-ID.=20 Yes. > > On 4 d=E9c. 03, at 22:10, Doug Royer wrote: > >> Craig Johnson wrote: >> >>> Olivier presented an excellent case showing that a RECCURRENCE-ID's >>> primary role is that of an 'identifier'; and not a 'date/time' value = >>> that can >>> be relied on as the 'effective start' for a recurrence instance. =20 >>> This is made >>> even more clear in the following from 2445: >>> Section 4.8.4.4 Recurrence ID >>> . . . >>> The date/time value (RECURRENCE-ID) is set to the time when the=20 >>> original recurrence >>> instance would occur; meaning that if the intent is to change a >>> Friday meeting to Thursday, the date/time (RECURRENCE-ID) is=20 >>> still set to the >>> original Friday meeting. >> >> >> Meaning in the object being sent in the reschedule. In order to say X = >> moves to Y, >> you need to properties to hold X and Y. So the above paragraph means=20 >> send a >> new object with the new Y in RECURRENCE-ID and the old X in DTSTART. > > [..] > >>> With RECURRENCE-ID consigned to the role of an identifier >>> it clearly falls to DTSTART to represent a recurrence instance's >>> effective start time. >> >> 2445 is talking about a reschedule object not what 2446 calls the=20 >> master object. > > > I don't think so as the text only refer to recurrence instance=20 > identification, and disagree with the above interpretation of having=20 > the object sent to reschedule. > If the RECURRENCE-ID value is not changed, "changes to the start/end=20 > of the recurrence instance" are done, how can it be expressed if not=20 > in DTSTART / DTEND values ? How can a rescheduled specific instance=20 > could be expressed in a complete snapshot of the event state if not=20 > by having the recurrence-ID identifying the initial value for the=20 > instance and dtstart giving the actual, rescheduled value ?=20 As I posted the date math in a previous email (yesterday?) >>> Doug wrote: >>> > For a recurring instance the effective start of an instance >>> > is defined in 2445 to be the RECURRENCE-ID. >>> That is not quite correct. The effective start of an instance >>> is its DTSTART. RECURRENCE-ID gets DTSTART as its >>> initial value: >>> 4.8.4.4 Recurrence ID >>> . . . The property >>> value is the effective value of the "DTSTART" property of the >>> recurrence instance. >>> This statement makes it clear that a recurrence instance has a >>> DTSTART property containing the "effective" value ... and this is >>> where RECURRENCE-ID gets its initial value. Initially, DTSTART >>> and RECURRENCE-ID have the same value. If the instance is >>> changed to a different time, DTSTART changes and >>> RECURRENCE-ID does not. >> >> >> Yet the topic of the section is RECURRENCE-ID and not DTSTART, so the >> subject usage 'THE" in that sentence is RECURENCE-ID and not DTSTART. > > > Immediatly below, this is precised to be "The date/time value is set=20 > to the time when the original recurrence > instance would occur; meaning that if the intent is to change a > Friday meeting to Thursday, the date/time is still set to the > original Friday meeting." > > Why insisting on "the time when the *original* recurrence instance=20 > would occur" if not to have a possible -distinct- dtstart ? the 'The'=20 > in that case is the RECURRENCE-ID (topic of the section). Again it is talking about a change object, not the original. --=20 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 --------------ms070406040704040808010106 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 9w0BCQUxDxcNMDMxMjA1MTkxNTU2WjAjBgkqhkiG9w0BCQQxFgQU2KbbvaZCQW4JiF93XZkj KqlC1rMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAfjIJvJI5NEO7dAOmdQhC5hap7AVi20R/BpC3ii2Pp0k7AD2Wfx+KZu5V0g62Lonr pJbskXhnvq0kI5haDwx1qUpXfFqRGqJA2BZwA9SDeuqwcDKTrpBEGvkQlK6Id8LLM2bg/Q3F F+opkGEtwRavr54qZQ4QafzRhyWgwTQ0RJlChv4UBVwtG9s8qnr/57aLJpdO+p5VDkB+ni8c Ao14HfDX9xA7i5ftuTq03ilM+pjIr8ArHeaFHJMAaNMX+bxYb5qfezyKcgLd795f65hRaSgg jwNPSxggRivL7RFxqvlOpowHgHrzmK8W7UaFbBdTSHpxSTLFKm9CSMEoLo7DAwAAAAAAAA== --------------ms070406040704040808010106-- From owner-ietf-calendar@mail.imc.org Fri Dec 5 14:33:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19972 for ; Fri, 5 Dec 2003 14:33:16 -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 hB5JKoib060045 for ; Fri, 5 Dec 2003 11:20:50 -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 hB5JKoH1060044 for ietf-calendar-bks; Fri, 5 Dec 2003 11:20:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JKnib060038 for ; Fri, 5 Dec 2003 11:20:49 -0800 (PST) (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 hB5JKgYu015651; Fri, 5 Dec 2003 12:20:45 -0700 (MST) Message-ID: <3FD0DA8A.32E8BD0F@INET-Calendar.net> Date: Fri, 05 Dec 2003 12:20:42 -0700 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: DTSTART for recurrence instances 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 wrote on 12/04/2003 04:10:11 PM: > > > Section 4.8.4.4 Recurrence ID > > > . . . > > > The date/time value (RECURRENCE-ID) is set to the time when the > > > > original recurrence > > > instance would occur; meaning that if the intent is to change a > > > Friday meeting to Thursday, the date/time (RECURRENCE-ID) is > still > > > set to the > > > original Friday meeting. > > > > Meaning in the object being sent in the reschedule. In order to say > X > > moves to Y, > > you need to properties to hold X and Y. So the above paragraph means > send a > > new object with the new Y in RECURRENCE-ID and the old X in DTSTART. > > Lets not start this again shall we? Is your worst fear in life (1) that you do not have a clue what others are talking about, (2) that when you speak no one takes your word as the authoritative answer, or (3) when you can not be the one to start a controversy you will just keep trying. From owner-ietf-calendar@mail.imc.org Fri Dec 5 14:52: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 OAA20780 for ; Fri, 5 Dec 2003 14:52:51 -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 hB5Jdfib062081 for ; Fri, 5 Dec 2003 11:39:41 -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 hB5Jdero062078 for ietf-calendar-bks; Fri, 5 Dec 2003 11:39:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Jdeib062059 for ; Fri, 5 Dec 2003 11:39:40 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FCE4DC7.6020600@Royer.com> To: ietf-calendar@imc.org Subject: Re: DTSTART for recurrence 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, 5 Dec 2003 14:17:04 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/05/2003 02:36:43 PM, Serialize complete at 12/05/2003 02:36:43 PM Content-Type: multipart/alternative; boundary="=_alternative 0069ACA985256DF3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069ACA985256DF3_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 12/03/2003 03:55:35 PM: > > RFC 2446 - 4.5.7.2 Calculating due dates in recurring VTODOs > > The due date in a recurring "VTODO" calendar component is either a > > fixed interval specified in the "REQUEST" method or specified using > > the "RECURRENCE-ID" property. The former is calculated by applying > > the difference between "DTSTART" and "DUE" properties and applying it > > to each of the start of each recurring instance. Hence, if the > > initial "VTODO" calendar component specifies a "DTSTART" property > > value of "19970701T190000Z" and a "DUE" property value of > > "19970801T190000Z" the interval of one day which is applied to each > > recurring instance of the "VTODO" calendar component to determine the > > "DUE" date of the instance. > > > > Even if the text mention the original DTSTART as the reference point, > > it does not mention the actual value of the DTSTART/DUE values in an > > identified recurrence instance. The section is actually quite clear > > when it differentiates the 'recurring instance' and the initial VTODO > > component. It should be noted that there is no text regarding the latter case described ("specified using the "RECURRENCE-ID" property"). I suspect that the reason for this is the change of design of RECURRENCE-ID from delta to fixed midway thru iCalendar development. The editors simply missed that line but they removed any text that would describe "the latter" case, probably its own paragraph that simply got removed. Had we stayed with the delta RECURRENCE-ID model then the latter case above would be relevant since it would be the instances previous DTSTART value thus you could derive the new DUE value. With the fixed RECURRENCE-ID model, you wind up sending the DUE value (or DURATION) so that both the recipient and the Organizer have the same view of the VTODO (coupled with the fact that the iTIP reschedule would be a full snapshot, it would also logically have a specific DUE (or DURATION) value in it for the recipient to use).. > If so I disagree as it says to calculate the due date from the DTSTART > and DUE > dates to get the offset and apply it to RECURRENCE-ID (which would have to > be different or it would be pointless). The text says NOTHING how to _apply_ RECURRENCE-ID to get the DUE value. It only says: The due date in a recurring "VTODO" calendar component is either a fixed interval specified in the "REQUEST" method or specified using the "RECURRENCE-ID" property. If the RECURRENCE-ID were changing each reschedule then you could use it to calculate a new DUE value. However as its been noted ad naseum here (and supported by the original authors), the RECURRENCE-ID value does not change. As such, a reschedule needs to provide the DUE (or DURATION) value since the reschedule is a full snapshot of the Organziers copy (and not vulnerable to sequencing problems). > > RFC 2245 - 4.6.6 Alarm Component > > In an alarm set to trigger on the "START" of an event or to-do, the > > "DTSTART" property MUST be present in the associated event or to-do. > > If DTSTART were the same as RECURRENCE-ID or not, that would be true > as START is defined to be relative to the 'start' of the component, and > not DTSTART. Huh?? Each instance has its own DTSTART value thats different from its peers. Each instance has its own VALARMs who TRIGGER relative to that instances DTSTART value. There is no concept of VALARMs being ALL relative to the set defintion (aka the 1st instance of the set). > If DTSTART were not present then recurring or not, you can not use > any time relative to the 'start' (or 'DTSTART'). I agree. The same goes for for entries that have no DTEND / DUE / DURATION too. In fact thats spelled on in 2445: In an alarm set to trigger on the "START" of an event or to-do, the "DTSTART" property MUST be present in the associated event or to-do. In an alarm in a "VEVENT" calendar component set to trigger on the "END" of the event, either the "DTEND" property MUST be present, or the "DTSTART" and "DURATION" properties MUST both be present. > For a recurring instance the effective start of an instance > is defined in 2445 to be the RECURRENCE-ID. No, the effective start of the instance is the DTSTART value. RECURRENCE-ID is strictly used to identify the instance and is ONLY the same value (for sure) when the instance is first created. (Thats the "original value" bit in Section 4.8.4.4) The reason "effective" is used is because you have to consider timezone shifts, etc when you roll out repeating grammars to determine each instances startting date/time. If we just used RDATEs then no shifting factors would be involved and the phrase "effective" would not be necssary. > The text says that "START" is relative to the "start" of a component, > it does NOT say START is relative to 'DTSTART'. > > And "END" is defined to be relative to the "end" of a component, > it does NOT say END is relative to 'DTEND' or 'DURATION' I hope you are referring to the DTSTART / DTEND of a particular instance of a component and not the 1st instance (the one that is used to make copys at all the specified repeating dates that come after it). If not, you would have ALL alarms for all instances trigger at the exact same time and NOT per instance and thats hardly the intent anyone would have. Right? (Talking about particular property [ie DTSTART] on a component [ie VEVENT] is somewhat problematic when the component is defined as a repeating one since its unclear which instance you are referring to.) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0069ACA985256DF3_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 12/03/2003 03:55:35 PM:
> > RFC 2446 - 4.5.7.2 Calculating due dates in recurring VTODOs
> >    The due date in a recurring "VTODO" calendar component is either a
> >    fixed interval specified in the "REQUEST" method or specified using
> >    the "RECURRENCE-ID" property. The former is calculated by applying
> >    the difference between "DTSTART" and "DUE" properties and applying it
> >    to each of the start of each recurring instance. Hence, if the
> >    initial "VTODO" calendar component specifies a "DTSTART" property
> >    value of "19970701T190000Z" and a "DUE" property value of
> >    "19970801T190000Z" the interval of one day which is applied to each
> >    recurring instance of the "VTODO" calendar component to determine the
> >    "DUE" date of the instance.
> >
> > Even if the text mention the original DTSTART as the reference point,
> > it does not mention the actual value of the DTSTART/DUE values in an
> > identified recurrence instance. The section is actually quite clear
> > when it differentiates the 'recurring instance' and the initial VTODO
> > component.

It should be noted that there is no text regarding the latter case described ("specified using the "RECURRENCE-ID" property").  I suspect that the reason for this is the change of design of RECURRENCE-ID from delta to fixed midway thru iCalendar development.  The editors simply missed that line but they removed any text that would describe "the latter" case, probably its own paragraph that simply got removed.

Had we stayed with the delta RECURRENCE-ID model then the latter case above would be relevant since it would be the instances previous DTSTART value thus you could derive the new DUE value.  With the fixed RECURRENCE-ID model, you wind up sending the DUE value (or DURATION) so that both the recipient and the Organizer have the same view of the VTODO (coupled with the fact that the iTIP reschedule would be a full snapshot, it would also logically have a specific DUE (or DURATION) value in it for the recipient to use)..

> If so I disagree as it says to calculate the due date from the DTSTART
> and DUE
> dates to get the offset and apply it to RECURRENCE-ID (which would have to
> be different or it would be pointless).
The text says NOTHING how to _apply_ RECURRENCE-ID to get the DUE value.  It only says:

   The due date in a recurring "VTODO" calendar component is either a
  fixed interval specified in the "REQUEST" method or specified using
  the "RECURRENCE-ID" property.

If the RECURRENCE-ID were changing each reschedule then you could use it to calculate a new DUE value.  However as its been noted ad naseum here (and supported by the original authors), the RECURRENCE-ID value does not change.  As such, a reschedule needs to provide the DUE (or DURATION) value since the reschedule is a full snapshot of the Organziers copy (and not vulnerable to sequencing problems).

> > RFC 2245 - 4.6.6 Alarm Component
> >    In an alarm set to trigger on the "START" of an event or to-do, the
> >    "DTSTART" property MUST be present in the associated event or to-do.
>
> If DTSTART were the same as RECURRENCE-ID or not, that would be true
> as START is defined to be relative to the 'start' of the component, and
> not DTSTART.
Huh??  Each instance has its own DTSTART value thats different from its peers.  Each instance has its own VALARMs who TRIGGER relative to that instances DTSTART value.  There is no concept of VALARMs being ALL relative to the set defintion (aka the 1st instance of the set).

> If DTSTART were not present then recurring or not, you can not use
> any time relative to the 'start' (or 'DTSTART').
I agree.  The same goes for for entries that have no DTEND / DUE / DURATION too.  In fact thats spelled on in 2445:

   In an alarm set to trigger on the "START" of an event or to-do, the
  "DTSTART" property MUST be present in the associated event or to-do.
  In an alarm in a "VEVENT" calendar component set to trigger on the
  "END" of the event, either the "DTEND" property MUST be present, or
  the "DTSTART" and "DURATION" properties MUST both be present.

> For a recurring instance the effective start of an instance
> is defined in 2445 to be the RECURRENCE-ID.
No, the effective start of the instance is the DTSTART value.  RECURRENCE-ID is strictly used to identify the instance and is ONLY the same value (for sure) when the instance is first created.  (Thats the "original value" bit in Section 4.8.4.4)  

The reason "effective" is used is because you have to consider timezone shifts, etc when you roll out repeating grammars to determine each instances startting date/time.  If we just used RDATEs then no shifting factors would be involved and the phrase "effective" would not be necssary.

> The text says that "START" is relative to the "start" of a component,
> it does NOT say START is relative to 'DTSTART'.
>
> And "END"  is defined to be relative to the "end" of a component,
> it does NOT say END is relative to 'DTEND' or 'DURATION'
I hope you are referring to the DTSTART / DTEND of a particular instance of a component and not the 1st instance (the one that is used to make copys at all the specified repeating dates that come after it).

If not, you would have ALL alarms for all instances trigger at the exact same time and NOT per instance and thats hardly the intent anyone would have.  Right?  (Talking about particular property [ie DTSTART] on a component [ie VEVENT] is somewhat problematic when the component is defined as a repeating one since its unclear which instance you are referring to.)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0069ACA985256DF3_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 5 14:53: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 OAA20808 for ; Fri, 5 Dec 2003 14:53:19 -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 hB5Jdfib062086 for ; Fri, 5 Dec 2003 11:39:41 -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 hB5JdfbB062084 for ietf-calendar-bks; Fri, 5 Dec 2003 11:39:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Jdeic062059 for ; Fri, 5 Dec 2003 11:39:40 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: "Craig Johnson" Cc: ietf-calendar@imc.org Subject: Re: DTSTART for recurrence 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, 5 Dec 2003 14:39:31 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/05/2003 02:36:43 PM, Serialize complete at 12/05/2003 02:36:43 PM Content-Type: multipart/alternative; boundary="=_alternative 006BBAF285256DF3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006BBAF285256DF3_= Content-Type: text/plain; charset="US-ASCII" Craig wrote on 12/01/2003 08:07:59 PM: > Suppose we have a recurring event for every Monday in January: > > BEGIN:VEVENT > SUMMARY:Every Monday in January > DTSTART:20040105T100000Z > DTEND:20040105T110000Z > UID:A-Unique-ID > RRULE:FREQ=WEEKLY;UNTIL=20040131T170000Z; > INTERVAL=1;BYDAY=MO;WKST=SU > ... > END:VEVENT > > Now suppose we SEARCH for that event with Expand:TRUE: > > BEGIN:VQUERY > EXPAND:TRUE > QUERY: SELECT * from VEVENT > WHERE UID = 'A-Unique-ID' > END:VQUERY > > What will be returned in the query? Per the CAP 12-e text, ALL instances will be returned and as individual VEVENTs. So the returned data should look something like: BEGIN:VEVENT SUMMARY:Every Monday in January DTSTART:20040105T100000Z DTEND:20040105T110000Z UID:A-Unique-ID RECURRENCE-ID:20040105T100000Z ... END:VEVENT BEGIN:VEVENT SUMMARY:Every Monday in January DTSTART:20040112T100000Z DTEND:20040112T110000Z UID:A-Unique-ID RECURRENCE-ID:20040112T100000Z ... END:VEVENT BEGIN:VEVENT SUMMARY:Every Monday in January DTSTART:20040119T100000Z DTEND:20040119T110000Z UID:A-Unique-ID RECURRENCE-ID:20040119T100000Z ... END:VEVENT BEGIN:VEVENT SUMMARY:Every Monday in January DTSTART:20040126T100000Z DTEND:20040126T110000Z UID:A-Unique-ID RECURRENCE-ID:20040126T100000Z ... END:VEVENT > Will the DTSTART > (and DTEND) of each recurrence instance be the same as > the 'master' (as in column 1 below)? No. (Please be careful using 'master' as it introduces a new term w/o defining it. I take it to mean the initial instance defined by your original VEVENT (sans repeating and exclusion grammar or RDATE / EXDATEs) but I could be slightly wrong.) > Or will DTSTART and > DTEND have the 'effective' value for the recurrence instance > (as in column 2 below)? Yes > The expected result, intuitively and instinctively, is Column 2. > The prior discussion thread implied that Column 1 is correct > (along with some discussion explaining that this is why DTSTART > is not always suitable for use in QUERYs, whereas RECURRENCE-ID > is more suitable). I havent been able to keep on WG threads lately so I didnt see that. The interpretation depends on how you read the property defintions in 2445. From my catchup attempts on this thread (bottom up) it appears as if some grok the difference between instance identifier (UID and RECURRENCE-ID) and instance starting time (DTSTART) and some may not. By correctly using each property as its defined, I dont see how one would say Column 1 (omitted) is the correct answer but Ill go back and see if I missed something. Essentially, the CUA needs to be smart about when it uses EXPAND:TRUE in a VQUERY. It depends on what the CUA is attempting to do. If you want to find a particular instance of a component (ie: UID:A-Unique-ID) then you would include RECURRENCE-ID to find it no matter where in time it exists and not use EXPAND (or use EXPAND:FALSE). If you want to find all instances of a component (ie: UID:A-Unique-ID) then you would omit any RECURRENCE-ID and use EXPAND:TRUE. If you want to find any entires during a particular time range, say the work week starting 5-Jan-2004, (even those NOT with UDI:A-Unique-ID) you would omit any UID or RECURRENCE-ID and not use EXPAND (or use EXPAND:FALSE). Its somewhat problematic if you do the latter AND include EXPAND:TRUE as the results returned would violate the WHERE constraints of the query. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006BBAF285256DF3_= Content-Type: text/html; charset="US-ASCII"
Craig wrote on 12/01/2003 08:07:59 PM:
> Suppose we have a recurring event for every Monday in January:
>  
> BEGIN:VEVENT
> SUMMARY:Every Monday in January
> DTSTART:20040105T100000Z
> DTEND:20040105T110000Z
> UID:A-Unique-ID
> RRULE:FREQ=WEEKLY;UNTIL=20040131T170000Z;
>  INTERVAL=1;BYDAY=MO;WKST=SU
> ...
> END:VEVENT
>  
> Now suppose we SEARCH for that event with Expand:TRUE:
>  
> BEGIN:VQUERY
> EXPAND:TRUE
> QUERY: SELECT * from VEVENT
>   WHERE UID = 'A-Unique-ID'
> END:VQUERY
>  
> What will be returned in the query?  

Per the CAP 12-e text, ALL instances will be returned and as individual VEVENTs.  So the returned data should look something like:

BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040105T100000Z
DTEND:20040105T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040105T100000Z
...
END:VEVENT
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040112T100000Z
DTEND:20040112T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040112T100000Z
...
END:VEVENT
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040119T100000Z
DTEND:20040119T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040119T100000Z
...
END:VEVENT
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040126T100000Z
DTEND:20040126T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040126T100000Z
...
END:VEVENT

>                                             Will the DTSTART
> (and DTEND) of each recurrence instance be the same as
> the 'master' (as in column 1 below)?  

No.  (Please be careful using 'master' as it introduces a new term w/o defining it.  I take it to mean the initial instance defined by your original VEVENT (sans repeating and exclusion grammar or RDATE / EXDATEs) but I could be slightly wrong.)

>                                       Or will DTSTART and
> DTEND have the 'effective' value for the recurrence instance
> (as in column 2 below)?  

Yes

> The expected result, intuitively and instinctively, is Column 2.
> The prior discussion thread implied that Column 1 is correct
> (along with some discussion explaining that this is why DTSTART
> is not always suitable for use in QUERYs, whereas RECURRENCE-ID
> is more suitable).

I havent been able to keep on WG threads lately so I didnt see that.  

The interpretation depends on how you read the property defintions in 2445.  From my catchup attempts on this thread (bottom up) it appears as if some grok the difference between instance identifier (UID and RECURRENCE-ID) and instance starting time (DTSTART) and some may not.   By correctly using each property as its defined,  I dont see how one would say Column 1 (omitted) is the correct answer but Ill go back and see if I missed something.

Essentially, the CUA needs to be smart about when it uses EXPAND:TRUE in a VQUERY.  It depends on what the CUA is attempting to do.

If you want to find a particular instance of a component (ie: UID:A-Unique-ID) then you would include RECURRENCE-ID to find it no matter where in time it exists and not use EXPAND (or use EXPAND:FALSE).  

If you want to find all instances of a component (ie: UID:A-Unique-ID) then you would omit any RECURRENCE-ID and use EXPAND:TRUE.

If you want to find any entires during a particular time range, say the work week starting 5-Jan-2004, (even those NOT with UDI:A-Unique-ID) you would omit any UID or RECURRENCE-ID and not use EXPAND (or use EXPAND:FALSE).

Its somewhat problematic if you do the latter AND include EXPAND:TRUE as the results returned would violate the WHERE constraints of the query.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006BBAF285256DF3_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 5 15:03: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 PAA21411 for ; Fri, 5 Dec 2003 15:03: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 hB5JqZib062846 for ; Fri, 5 Dec 2003 11:52:35 -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 hB5JqZQx062845 for ietf-calendar-bks; Fri, 5 Dec 2003 11:52:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JqYib062836 for ; Fri, 5 Dec 2003 11:52:34 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FD0D7AC.2070602@Royer.com> To: ietf-calendar@imc.org Subject: Re: DTSTART for recurrence 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, 5 Dec 2003 14:52:27 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/05/2003 02:49:37 PM, Serialize complete at 12/05/2003 02:49:37 PM Content-Type: multipart/alternative; boundary="=_alternative 006CE9CB85256DF3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CE9CB85256DF3_= Content-Type: text/plain; charset="US-ASCII" Doug shot back on 12/05/2003 02:08:28 PM: > > > > Section 4.8.4.4 Recurrence ID > > > > . . . > > > > The date/time value (RECURRENCE-ID) is set to the time when the > > > > original recurrence > > > > instance would occur; meaning that if the intent is to change a > > > > Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still > > > > set to the > > > > original Friday meeting. > > > > > > Meaning in the object being sent in the reschedule. In order to say X > > > moves to Y, > > > you need to properties to hold X and Y. So the above paragraph means > > send a > > > new object with the new Y in RECURRENCE-ID and the old X in DTSTART. > > > > Lets not start this again shall we? The original authors have even > > responded to this and they have clearly said that RECURRENCE-ID does > > not change on an instance reschedule. The DTSTART for the instance > > can change on each instance reschedule but the the RECURRENCE-ID does > > not. > > > NO ONE SAID THAT IS THE TOPIC. You appeared to be reintroducing that idea in this discussion. At least thats how I take your comments given the citation you were responding to. Please do not use concepts that were already covered and the original authors have noted as being incorrect. On instance reschedules RECURRENCE-ID is unchanging so using it as part of some X - Y or Y - X or other calculation is not viable. As I noted in another reply, there is no iTIP text regaring the use of RECURRENCE-ID to calculate DUE values and thats likely due to the edits we made when we changed the design for RECURRENCE-ID. Thinking logically, if you tried to do some calculation based on a changing DTSTART and a fixed RECURRENCE-ID value then you can get a wildly changing and inaccurate DUE value. For example, if you move the VTODO out a day the DUE date would move out 1 day. If you then moved it out 3 more days your DUE date would be calculated as 4 days after the DTSTART rather than 1 day after it. If you moved the instance backwards a few days in time, the DUE value would be miscalcuated as being before the DTSTART value. Clearly this is not desirable. Since the iTIP messages are full snapshots of the Organizers copy it would provide a DUE (or DURATION) value for the recipient to use if the Organizer had one. If they did not, none will be present. No need for mess or fuss and certainly no problem with not being in sync w/the Organzier. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006CE9CB85256DF3_= Content-Type: text/html; charset="US-ASCII"
Doug shot back on 12/05/2003 02:08:28 PM:
> > > > Section 4.8.4.4 Recurrence ID
> > > > . . .
> > > >    The date/time value (RECURRENCE-ID) is set to the time when the
> > > > original recurrence
> > > >    instance would occur; meaning that if the intent is to change a
> > > >    Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still
> > > > set to the
> > > >    original Friday meeting.
> > >
> > > Meaning in the object being sent in the reschedule. In order to say X
> > > moves to Y,
> > > you need to properties to hold X and Y. So the above paragraph means
> > send a
> > > new object with the new Y in RECURRENCE-ID and the old X in DTSTART.
> >
> > Lets not start this again shall we?  The original authors have even
> > responded to this and they have clearly said that RECURRENCE-ID does
> > not change on an instance reschedule.  The DTSTART for the instance
> > can change on each instance reschedule but the the RECURRENCE-ID does
> > not.  
>
>
> NO ONE SAID THAT IS THE TOPIC.
You appeared to be reintroducing that idea in this discussion.   At least thats how I take your comments given the citation you were responding to.  Please do not use concepts that were already covered and the original authors have noted as being incorrect.   On instance reschedules RECURRENCE-ID is unchanging so using it as part of some X - Y or Y - X or other calculation is not viable.

As I noted in another reply, there is no iTIP text regaring the use of RECURRENCE-ID to calculate DUE values and thats likely due to the edits we made when we changed the design for RECURRENCE-ID.  
Thinking logically, if you tried to do some calculation based on a changing DTSTART and a fixed RECURRENCE-ID value then you can get a wildly changing and inaccurate DUE value.  For example, if you move the VTODO out a day the DUE date would move out 1 day.  If you then moved it out 3 more days your DUE date would be calculated as 4 days after the DTSTART rather than 1 day after it.  If you moved the instance backwards a few days in time, the DUE value would be miscalcuated as being before the DTSTART value.  Clearly this is not desirable.

Since the iTIP messages are full snapshots of the Organizers copy it would provide a DUE (or DURATION) value for the recipient to use if the Organizer had one.  If they did not, none will be present.  No need for mess or fuss and certainly no problem with not being in sync w/the Organzier.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006CE9CB85256DF3_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 5 15:29:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23779 for ; Fri, 5 Dec 2003 15:29:53 -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 hB5KD5ib064011 for ; Fri, 5 Dec 2003 12:13:05 -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 hB5KD5bj064010 for ietf-calendar-bks; Fri, 5 Dec 2003 12:13:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5KD4ib064003 for ; Fri, 5 Dec 2003 12:13:04 -0800 (PST) (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 hB5KD0Yu015782; Fri, 5 Dec 2003 13:13:00 -0700 (MST) Message-ID: <3FD0E6CC.839C9017@INET-Calendar.net> Date: Fri, 05 Dec 2003 13:13:00 -0700 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: DTSTART for recurrence instances 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: > > You appeared to be reintroducing that idea in this discussion. Are you completely incapable of haveing a technical discussion without controversy? Why do you always insist on makeing a pointt of a on a non technecal point? From owner-ietf-calendar@mail.imc.org Fri Dec 5 15:41:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25015 for ; Fri, 5 Dec 2003 15:41:32 -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 hB5KS2ib064883 for ; Fri, 5 Dec 2003 12:28: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 hB5KS2XQ064881 for ietf-calendar-bks; Fri, 5 Dec 2003 12:28: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 hB5KS0ib064869 for ; Fri, 5 Dec 2003 12:28:01 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:SFBclZ174h2GdjC8XvsCVj9R3cucte6/@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB5KRuvI000450 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 5 Dec 2003 12:27:57 -0800 Message-ID: <3FD0EA4C.3050307@Royer.com> Date: Fri, 05 Dec 2003 13:27:56 -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: DTSTART for recurrence instances References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> In-Reply-To: <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010103030904050702030407" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010103030904050702030407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Olivier, I want to take a recurrence change step by step until we disagree and see if I can understand what exactly is the issue. (Sorry Bruce - I am going to ignore ALL of your email on this subject as you seem to be focused on differences and your version of history rather than solutions and understanding). So, if the ORGANIZER sends the following iTIP object to ATTENDEE: BEGIN:VEVENT UID:XXX SEQUENCE:0 ... METHOD:REQUEST ATTENDEE:attendee ... DTSTART: 1-dec-2003 at noon DTEND: 1-dec-2003 at 1pm ... RRULE:FREQ=DAILY;COUNT=3 ... END:VEVENT (And 'attendee' sends a reply saying yes). Now later ORGANIZER sends an iTIP update to move the 2nd instance from noon->1pm and have it at 2pm->3:30pm: BEGIN:VEVENT UID:XXX SEQUENCE:1 ... METHOD:REQUEST DTSTART:2-dec-2003 at 2pm DTEND:2-dec-2003 at 3:30pm RECURRENCE-ID:2-dec-2003 at noon .. END:VEVENT Do you agree that is a valid object to tell the ATTENDEE of the single instance change? -- 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 --------------ms010103030904050702030407 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 9w0BCQUxDxcNMDMxMjA1MjAyNzU2WjAjBgkqhkiG9w0BCQQxFgQURpAzQXP7CRuKNjEAR7Tx vBOfBW4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEABB1vdFNgCftqrSmKIqP+V1S21A7Z+wKPIN1w1KFAZNSAeWdDTH/qyeEXpRsTXNsp IbqmwVn6gDRMxrd4wZ7Gw1lVJc7yPEE9HO4AyKQXZb3CktttsvDXEUGO5wTRUkiu3uDWU1rR PnhkTNDUhYuUmQc7dyOSaTbGwyiGKDgGfy0TnswxAjFM4bqWxmoTKYrfDmcQcrPnK3ll7fwo Oj/iXcJtiTDcvrc64yGVrAnEaVZRPB4AwH/F1JxCW7MXJtraejvzu/vMyJSH09zD3EhXWMUK W0dl6bFz1xFxhN5r+gL+QECGCMFkaNczg3ckyxFai8nWSgtBapPuLWafNDTffQAAAAAAAA== --------------ms010103030904050702030407-- From owner-ietf-calendar@mail.imc.org Fri Dec 5 15:42: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 PAA25130 for ; Fri, 5 Dec 2003 15:42: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 hB5KObib064735 for ; Fri, 5 Dec 2003 12:24: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 hB5KOb2F064734 for ietf-calendar-bks; Fri, 5 Dec 2003 12:24:37 -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 hB5KOZib064728 for ; Fri, 5 Dec 2003 12:24:35 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:kggCrdv0EsKFXGUpU9hynAxwwXQO92k/@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB5KOVvI000413 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 5 Dec 2003 12:24:31 -0800 Message-ID: <3FD0E97E.9070504@Royer.com> Date: Fri, 05 Dec 2003 13:24:30 -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: DTSTART for recurrence instances References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> In-Reply-To: <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040400070705090109050201" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040400070705090109050201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Oliver, I want to take a recurrence change step by step until we disagree and see if I can understand where the issues is (Sorry Bruce - I am going to ignore ALL of your email on this subject as you seem to be focused on differences rather than solutions and understanding). If the ORGANIZER sends the following iTIP object to ATTENDEE: BEGIN:VEVENT UID:XXX SEQUENCE:0 ... METHOD:REQUEST ATTENDEE:attendee ... DTSTART: 1-dec-2003 at noon DTEND: 1-dec-2003 at 1pm ... RRULE:FREQ=DAILY;COUNT=3 ... END:VEVENT (And 'attendee' sends a reply saying yes). Now later ORGANIZER sends an iTIP update to move the 2nd instance from noon->1pm and have it at 2pm->3:30pm: BEGIN:VEVENT UID:XXX SEQUENCE:1 ... METHOD:REQUEST DTSTART:2-dec-2003 at 2pm DTEND:2-dec-2003 at 3:30pm RECURRENCE-ID:2-dec-2003 at noon .. END:VEVENT Do you agree that is how to move a single instance? -- 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 --------------ms040400070705090109050201 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 9w0BCQUxDxcNMDMxMjA1MjAyNDMwWjAjBgkqhkiG9w0BCQQxFgQU/sYdg50MijcG/NvrP7kK 0PEcf0IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAvVZkk87Mny1cy5ASt3dfGn3nRLnQ5boxQCEt5G9szrjQ3/xYykxKrz+2pJPDxzyo gUF7XDKruWHGj+2vys2/duiM0opsL8tsA+0KGcRqvIlFC3hc2YMQuaIBlElwyJOpkVxZUGDk bKURsTzPySp6nmWKyIegqLOphuY/oEfbLrPjVMZrPb/CjD/HCjDOmc4lWL0mW7qYTNfzM0iO gPNi6i6B6vh6+Ti1k6FRFJFrDKjUMBmTm/bR0dgmSIgAuG934Oh2cSsEAFiZDlbKoDtZDFyD 3pKiFmU1QldVfwXlKCwWaTgI2BIr90wnF7aZySQza+7PptieqB1drXOXd/NNsQAAAAAAAA== --------------ms040400070705090109050201-- From owner-ietf-calendar@mail.imc.org Mon Dec 8 14:37:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26260 for ; Mon, 8 Dec 2003 14:37:28 -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 hB8JJjib056974 for ; Mon, 8 Dec 2003 11:19:45 -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 hB8JJjMn056973 for ietf-calendar-bks; Mon, 8 Dec 2003 11:19:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8JJhib056933 for ; Mon, 8 Dec 2003 11:19:43 -0800 (PST) (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 hB8JJdYu022485 for ; Mon, 8 Dec 2003 12:19:39 -0700 (MST) Message-ID: <3FD4CECB.9187A40D@INET-Calendar.net> Date: Mon, 08 Dec 2003 12:19:39 -0700 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: DTSTART for recurrence instances 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: > No. (Please be careful using 'master' as it introduces a new term w/o > defining it. Yet again you failed to know iCalendar - 'master' is in 2446 no one made it up. > > I havent been able to keep on WG threads lately so I didnt see that. It seem amasing to me that you could keep posting to this list that you do not follow the the topics, yet in your very NEXT email you yet again promote your self as being on topic. From owner-ietf-calendar@mail.imc.org Mon Dec 8 14:37:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26282 for ; Mon, 8 Dec 2003 14:37:30 -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 hB8JLsib057265 for ; Mon, 8 Dec 2003 11:21:54 -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 hB8JLrDl057264 for ietf-calendar-bks; Mon, 8 Dec 2003 11:21:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8JLqib057251 for ; Mon, 8 Dec 2003 11:21:52 -0800 (PST) (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 hB8JLnYu022492; Mon, 8 Dec 2003 12:21:49 -0700 (MST) Message-ID: <3FD4CF4D.4A3436DA@INET-Calendar.net> Date: Mon, 08 Dec 2003 12:21:49 -0700 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: DTSTART for recurrence instances 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: Bruce Kahn flew off the handle and shot from the hip: > > You appeared to be reintroducing that idea in this discussion. In your previous email you just declared you had not followed the topic. Please explain how you get to argue both sides of 'yes I do' and 'no I do not' follow the same topic. From owner-ietf-calendar@mail.imc.org Mon Dec 8 14:42: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 OAA26439 for ; Mon, 8 Dec 2003 14:42:37 -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 hB8JPiib057934 for ; Mon, 8 Dec 2003 11:25:44 -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 hB8JPinb057933 for ietf-calendar-bks; Mon, 8 Dec 2003 11:25:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8JPgib057924 for ; Mon, 8 Dec 2003 11:25:42 -0800 (PST) (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 hB8JPdYu022499; Mon, 8 Dec 2003 12:25:39 -0700 (MST) Message-ID: <3FD4D033.7D15044C@INET-Calendar.net> Date: Mon, 08 Dec 2003 12:25:39 -0700 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: DTSTART for recurrence instances 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 shot back on 12/05/2003 02:08:28 PM: > > > > > Section 4.8.4.4 Recurrence ID > > > > > . . . > > > > > The date/time value (RECURRENCE-ID) is set to the time when > the > > > > > original recurrence > > > > > instance would occur; meaning that if the intent is to > change a > > > > > Friday meeting to Thursday, the date/time (RECURRENCE-ID) > is still > > > > > set to the > > > > > original Friday meeting. > > > > > > > > Meaning in the object being sent in the reschedule. In order to > say X > > > > moves to Y, > > > > you need to properties to hold X and Y. So the above paragraph > means > > > send a > > > > new object with the new Y in RECURRENCE-ID and the old X in > DTSTART. > > > > > > Lets not start this again shall we? The original authors have > even > > > responded to this and they have clearly said that RECURRENCE-ID > does > > > not change on an instance reschedule. The DTSTART for the > instance > > > can change on each instance reschedule but the the RECURRENCE-ID > does > > > not. > > > > > > NO ONE SAID THAT IS THE TOPIC. > > You appeared to be reintroducing that idea in this discussion. At > least thats how I take your comments given the citation you were > responding to. Please do not use concepts that were already covered > and the original authors have noted as being incorrect. On instance > reschedules RECURRENCE-ID is unchanging so using it as part of some X > - Y or Y - X or other calculation is not viable. > > As I noted in another reply, there is no iTIP text regaring the use of > RECURRENCE-ID to calculate DUE values and thats likely due to the > edits we made when we changed the design for RECURRENCE-ID. Yes 2446 does, look for 'Calculating due dates in recurring VTODOs'. > Thinking logically, if you tried to do some calculation based on a > changing DTSTART and a fixed RECURRENCE-ID value then you can get a > wildly changing and inaccurate DUE value. > For example, if you move > the VTODO out a day the DUE date would move out 1 day. If you then > moved it out 3 more days your DUE date would be calculated as 4 days > after the DTSTART rather than 1 day after it. If you moved the > instance backwards a few days in time, the DUE value would be > miscalcuated as being before the DTSTART value. Clearly this is not > desirable. instance due date as described in 4.5.7.2 is: instance-due-date = RECURRENCE-ID + (DUE - DTSTART). It is always correct. Clearly you are using incorrect procedures as outlined in 2446. From owner-ietf-calendar@mail.imc.org Mon Dec 8 17:33:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07780 for ; Mon, 8 Dec 2003 17:33:11 -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 hB8MGuib089336 for ; Mon, 8 Dec 2003 14:16:56 -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 hB8MGuMm089335 for ietf-calendar-bks; Mon, 8 Dec 2003 14:16:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8MGtib089325 for ; Mon, 8 Dec 2003 14:16:56 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FD4D033.7D15044C@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: DTSTART for recurrence instances MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 8 Dec 2003 17:16:43 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/08/2003 05:13:59 PM, Serialize complete at 12/08/2003 05:13:59 PM Content-Type: multipart/alternative; boundary="=_alternative 007A100585256DF6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007A100585256DF6_= Content-Type: text/plain; charset="US-ASCII" Mark wrote on 12/08/2003 02:25:39 PM: > > As I noted in another reply, there is no iTIP text regaring the use of > > RECURRENCE-ID to calculate DUE values and thats likely due to the > > edits we made when we changed the design for RECURRENCE-ID. > > Yes 2446 does, look for 'Calculating due dates in recurring VTODOs'. Dont bother trying to bait me into non-technical discussions or exchanging personal barbs. I wont waste my time or the WG bandwidth on it. If you actually read iTIP, it only says: 4.5.7.2 Calculating due dates in recurring VTODOs The due date in a recurring "VTODO" calendar component is either a fixed interval specified in the "REQUEST" method or specified using the "RECURRENCE-ID" property. The former is calculated by applying the difference between "DTSTART" and "DUE" properties and applying it to each of the start of each recurring instance. Hence, if the initial "VTODO" calendar component specifies a "DTSTART" property value of "19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the interval of one day which is applied to each recurring instance of the "VTODO" calendar component to determine the "DUE" date of the instance. There is no actual text for the "latter case" describing _how_ RECURRENCE-ID would be used on a VTODO; just that "or specified..." bit that has nothing supporting it elsewhere in the text. It was likely in a second paragraph that got removed before we went to Last Call. One could take it to be "Well, I can just use the RECURRENCE-ID as the DUE value" however thats not valid because A) it could be BEFORE the instances DTSTART and B) the reschedule is a full snapshot so if it had no DUE or DURATION value then you should not be calculating one now. If we had kept the delta RECURRENCE-ID model then a CUA could have done something like "diff between RECURRENCE-ID and new DTSTART" is how much the VTODO shifted and so the new DUE date can be calculated based on the old DUE date. However this logic is useless now if you properly consider: 1: Any initial VTODO wont have be able to calculate a difference between 2 versions of the VTODO since both RECURRENCE-ID and DTSTART at identical. As such each VTODO instance will have the same length interval between its DTSTART and its DUE. 2: On any reschedule of the VTODO instance, the Organzier would be sending a full snapshot of the VTODO and as such the recipient would be using that so they are in sync w/the Organzier. If the Organzier did not include a DUE then who is the invitee to add one for them? (They can if they want but its not a valid DUE value.) 3: When dealing with multiple instances at a time, the DUE for each subsequent instance should be calculated based on the difference between the DTSTART and DUE (or DURATION) of the 1st instance of the affected subset, if provided (see #2). 4: We did not opt for a delta RECURRENCE-ID model so its not useful in trying to do any shift calculations. This coupled the above means you are inventing mechanisms or behaivour that is just not there or that is incorrect. > instance due date as described in 4.5.7.2 is: > > instance-due-date = RECURRENCE-ID + (DUE - DTSTART). > > It is always correct. > > Clearly you are using incorrect procedures as outlined in 2446. Actually I think you are still under the mistaken impression that RECURRENCE-ID changes when the a component is rescheduled. As the authors have already confirmed, this is not the case. ( http://www.imc.org/ietf-calendar/mail-archive/msg08662.html ) Plus you may be misreading the iTIP text that says "either a fixed interval specified in the "REQUEST" method or specified using the "RECURRENCE-ID" property"" Essentially its "either A or B" and you are reading it more like "A + B". With a fixed RECURRENCE-ID you cannot use that algorithm as then you can get wildly incorrect instance due dates/times. An algorithm that will work is: instance-DUE = instance-DTSTART + ( ( DURATION ) ? DURATION : ( DUE - DTSTART ) where you calculate the DUE value based on either the given DURATION or the difference of DUE and DTSTART. However you apply it to the instances current DTSTART and not to its RECURRENCE-ID. This algorithm though does NOT show that you do NOT calculate a DUE value if there was no DUE / DURATION value in the reschedule. After all, if the sender did NOT set a DUE / DURATION then the recipient should not when they get 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 007A100585256DF6_= Content-Type: text/html; charset="US-ASCII"
Mark wrote on 12/08/2003 02:25:39 PM:
> > As I noted in another reply, there is no iTIP text regaring the use of
> > RECURRENCE-ID to calculate DUE values and thats likely due to the
> > edits we made when we changed the design for RECURRENCE-ID.
>
> Yes 2446 does, look for 'Calculating due dates in recurring VTODOs'.
Dont bother trying to bait me into non-technical discussions or exchanging personal barbs.  I wont waste my time or the WG bandwidth on it.

If you actually read iTIP, it only says:

4.5.7.2 Calculating due dates in recurring VTODOs

  The due date in a recurring "VTODO" calendar component is either a
  fixed interval specified in the "REQUEST" method or specified using
  the "RECURRENCE-ID" property. The former is calculated by applying
  the difference between "DTSTART" and "DUE" properties and applying it
  to each of the start of each recurring instance. Hence, if the
  initial "VTODO" calendar component specifies a "DTSTART" property
  value of "19970701T190000Z" and a "DUE" property value of
  "19970801T190000Z" the interval of one day which is applied to each
  recurring instance of the "VTODO" calendar component to determine the
  "DUE" date of the instance.

There is no actual text for the "latter case" describing _how_ RECURRENCE-ID would be used on a VTODO; just that "or specified..." bit that has nothing supporting it elsewhere in the text.  It was likely in a second paragraph that got removed before we went to Last Call.  One could take it to be "Well, I can just use the RECURRENCE-ID as the DUE value" however thats not valid because A) it could be BEFORE the instances DTSTART and B) the reschedule is a full snapshot so if it had no DUE or DURATION value then you should not be calculating one now.

If we had kept the delta RECURRENCE-ID model then a CUA could have done something like "diff between RECURRENCE-ID and new DTSTART" is how much the VTODO shifted and so the new DUE date can be calculated based on the old DUE date.

However this logic is useless now if you properly consider:

1: Any initial VTODO wont have be able to calculate a difference between 2 versions of the VTODO since both RECURRENCE-ID and DTSTART at identical.  As such each VTODO instance will have the same length interval between its DTSTART and its DUE.

2: On any reschedule of the VTODO instance, the Organzier would be sending a full snapshot of the VTODO and as such the recipient would be using that so they are in sync w/the Organzier.  If the Organzier did not include a DUE then who is the invitee to add one for them?  (They can if they want but its not a valid DUE value.)

3: When dealing with multiple instances at a time, the DUE for each subsequent instance should be calculated based on the difference between the DTSTART and DUE (or DURATION) of the 1st instance of the affected subset, if provided (see #2).

4: We did not opt for a delta RECURRENCE-ID model so its not useful in trying to do any shift calculations.  This coupled the above means you are inventing mechanisms or behaivour that is just not there or that is incorrect.

> instance due date as described in 4.5.7.2 is:
>
>   instance-due-date = RECURRENCE-ID + (DUE - DTSTART).
>
> It is always correct.
>
> Clearly you are using incorrect procedures as outlined in 2446.
Actually I think you are still under the mistaken impression that RECURRENCE-ID changes when the a component is rescheduled.  As the authors have already confirmed, this is not the case.  ( http://www.imc.org/ietf-calendar/mail-archive/msg08662.html )  Plus you may be misreading the iTIP text that says "either a fixed interval specified in the "REQUEST" method or specified using the "RECURRENCE-ID" property""  Essentially its "either A or B" and you are reading it more like "A + B".

With a fixed RECURRENCE-ID you cannot use that algorithm as then you can get wildly incorrect instance due dates/times.  

An algorithm that will work is:

        instance-DUE = instance-DTSTART + ( ( DURATION ) ? DURATION : ( DUE - DTSTART )

where you calculate the DUE value based on either the given DURATION or the difference of DUE and DTSTART.  However you apply it to the instances current DTSTART and not to its RECURRENCE-ID.

This algorithm though does NOT show that you do NOT calculate a DUE value if there was no DUE / DURATION value in the reschedule.  After all, if the sender did NOT set a DUE / DURATION then the recipient should not when they get 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 007A100585256DF6_=-- From owner-ietf-calendar@mail.imc.org Mon Dec 8 18:19:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11670 for ; Mon, 8 Dec 2003 18:19:48 -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 hB8N4xib091259 for ; Mon, 8 Dec 2003 15:04:59 -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 hB8N4xWQ091258 for ietf-calendar-bks; Mon, 8 Dec 2003 15:04:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8N4wib091252 for ; Mon, 8 Dec 2003 15:04:58 -0800 (PST) (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 hB8N4tYu022761; Mon, 8 Dec 2003 16:04:55 -0700 (MST) Message-ID: <3FD50397.6BECC140@INET-Calendar.net> Date: Mon, 08 Dec 2003 16:04:55 -0700 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: DTSTART for recurrence instances References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark wrote on 12/08/2003 02:25:39 PM: > > > As I noted in another reply, there is no iTIP text regaring the > use of > > > RECURRENCE-ID to calculate DUE values and thats likely due to the > > > edits we made when we changed the design for RECURRENCE-ID. > > > > Yes 2446 does, look for 'Calculating due dates in recurring VTODOs'. > > Dont bother trying to bait me into non-technical discussions or > exchanging personal barbs. I wont waste my time or the WG bandwidth > on it. > > If you actually read iTIP, it only says: > > 4.5.7.2 Calculating due dates in recurring VTODOs > > The due date in a recurring "VTODO" calendar component is either a > fixed interval specified in the "REQUEST" method or specified using > the "RECURRENCE-ID" property. The former is calculated by applying > the difference between "DTSTART" and "DUE" properties and applying > it > to each of the start of each recurring instance. Hence, if the > initial "VTODO" calendar component specifies a "DTSTART" property > value of "19970701T190000Z" and a "DUE" property value of > "19970801T190000Z" the interval of one day which is applied to each > recurring instance of the "VTODO" calendar component to determine > the > "DUE" date of the instance. > > There is no actual text for the "latter case" describing _how_ > RECURRENCE-ID would be used on a VTODO; just that "or specified..." > bit that has nothing supporting it elsewhere in the text. It was > likely in a second paragraph that got removed before we went to Last > Call. One could take it to be "Well, I can just use the RECURRENCE-ID > as the DUE value" however thats not valid because A) it could be > BEFORE the instances DTSTART and B) the reschedule is a full snapshot > so if it had no DUE or DURATION value then you should not be > calculating one now. > > If we had kept the delta RECURRENCE-ID model then a CUA could have > done something like "diff between RECURRENCE-ID and new DTSTART" is > how much the VTODO shifted and so the new DUE date can be calculated > based on the old DUE date. > > However this logic is useless now if you properly consider: > > 1: Any initial VTODO wont have be able to calculate a difference > between 2 versions of the VTODO since both RECURRENCE-ID and DTSTART > at identical. As such each VTODO instance will have the same length > interval between its DTSTART and its DUE. > > 2: On any reschedule of the VTODO instance, the Organzier would be > sending a full snapshot of the VTODO and as such the recipient would > be using that so they are in sync w/the Organzier. If the Organzier > did not include a DUE then who is the invitee to add one for them? > (They can if they want but its not a valid DUE value.) > > 3: When dealing with multiple instances at a time, the DUE for each > subsequent instance should be calculated based on the difference > between the DTSTART and DUE (or DURATION) of the 1st instance of the > affected subset, if provided (see #2). > > 4: We did not opt for a delta RECURRENCE-ID model so its not useful in > trying to do any shift calculations. This coupled the above means you > are inventing mechanisms or behaivour that is just not there or that > is incorrect. > > > instance due date as described in 4.5.7.2 is: > > > > instance-due-date = RECURRENCE-ID + (DUE - DTSTART). > > > > It is always correct. > > > > Clearly you are using incorrect procedures as outlined in 2446. > > Actually I think you are still under the mistaken impression that > RECURRENCE-ID changes when the a component is rescheduled. FYI - EVERY discussion about RECURRENCE-ID is not that topic. From owner-ietf-calendar@mail.imc.org Mon Dec 8 18:28:39 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 SAA12108 for ; Mon, 8 Dec 2003 18:28:38 -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 hB8NCwib091495 for ; Mon, 8 Dec 2003 15:12:58 -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 hB8NCwR0091494 for ietf-calendar-bks; Mon, 8 Dec 2003 15:12:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8NCvib091485 for ; Mon, 8 Dec 2003 15:12:57 -0800 (PST) (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 hB8NCsYu022772; Mon, 8 Dec 2003 16:12:54 -0700 (MST) Message-ID: <3FD50576.B3DB78CE@INET-Calendar.net> Date: Mon, 08 Dec 2003 16:12:54 -0700 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: DTSTART for recurrence instances References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark wrote on 12/08/2003 02:25:39 PM: > > > As I noted in another reply, there is no iTIP text regaring the > use of > > > RECURRENCE-ID to calculate DUE values and thats likely due to the > > > edits we made when we changed the design for RECURRENCE-ID. > > > > Yes 2446 does, look for 'Calculating due dates in recurring VTODOs'. > > Dont bother trying to bait me into non-technical discussions or > exchanging personal barbs. I wont waste my time or the WG bandwidth > on it. You said there was NO SUCH text, and there IS text that describes that in iTIP. You expect people to believe your point of view when you make such inaccurate statements about text in the RFCs? No, you accuracy rating is in the low 10% when you make statements. From owner-ietf-calendar@mail.imc.org Mon Dec 8 19:22: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 TAA15422 for ; Mon, 8 Dec 2003 19:22:19 -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 hB9070ib093659 for ; Mon, 8 Dec 2003 16:07: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 hB9070o6093658 for ietf-calendar-bks; Mon, 8 Dec 2003 16:07:00 -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 hB906xib093653 for ; Mon, 8 Dec 2003 16:06:59 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:Ug3tWlRMIVfXZGbetL26O5J/VBnnBas5@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hB906tZf011195 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 8 Dec 2003 16:06:56 -0800 Message-ID: <3FD5121E.5000500@Royer.com> Date: Mon, 08 Dec 2003 17:06:54 -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: DTSTART for recurrence instances References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030507050206010307020009" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030507050206010307020009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > 4: We did not opt for a delta RECURRENCE-ID model so its not useful in > trying to do any shift calculations. This coupled the above means you > are inventing mechanisms or behavior that is just not there or that is > incorrect. The discussion was how to expand RECURRENCE-ID's in the result set. So, what you are talking about has (again) nothing to do with the topic of if (or not) the RECURRENCE-ID changes on old 'set's. As has been pointed out by several on this mailing list, including Robert-(what-ever-his-name-is) from Lotus AND YOU that the RECRRENCE-ID is not fixed to the value it was in SEQUENCE:0. Everyone seems to agree to that including your peers and Frank and Derik. If it was you can never invite a new attendee or delegate to someone that never got the sequence:0 object. -You- also seem to have declared that it is per 'set' (uid/sequence/...). So, given an object you were first invited to is (or your 'booked' object is): SEQUENCE:100 UID: uid-1 DTSTART: monday 10am DTEND: monday 11am RRULE ... daily for 5 days... Are you trying to tell me that only a CS that have the sequence:0 object can ever return an expanded object? No. there has never been any one that proposed that RECURRENCE-IDs only relate to only old objects. If your BOOKED object is SEQUENCE:X, then the -ONLY- RECURRENCE-ID's that you will ever be able to calculate is the set that contains SEQUENCE:X . No amount of claming 'this' means 'that' or quoting for the nTh time that someone said whatever, will ever make such objets be able to create the SEQUENCE: X. If you expand an object, that is exactly what it means, the named object is expanded. It can not mean that some previous incarnation of the object is to be expanded. It means the object you have is expanded. So, no, the RECURRENCE-ID's are NOT the same as in the previous topic, they must be from the BOOKED (or unscheduled) objects you have. Think of it this way, you have X new unscheduled objects in your CS. The CU wishes to determine IF they will respond YES I WILL ATTEND. The CU will need to know the dates IN THAT OBJECT in order to decide if THOSE dates are acceptable. The CS MUST expand those object "as is", else no matter how many times the CUA asks, it will only get the dates for the OLDER object? No, that would be busted. -- 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 --------------ms030507050206010307020009 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 9w0BCQUxDxcNMDMxMjA5MDAwNjU0WjAjBgkqhkiG9w0BCQQxFgQUCiWV0bHmesT+mFtMDcYS +L03n3MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAALgBY6K/tvbc7LE4d/kbLS1XPjJRsD/BXthPma/klxvoN+wGtm9mxhsdjbZOoNfB IrhmbH+ofyC0jXQUvjbr2EhudD28Byg0c777Qk2grXoy+ScepUjgmYoLaZSV8FCBZcu1+hxJ ReEquM7DuaFttRtPwblkZQbbehBe0dRmfP8qRjeCN9wTrg1W/Avb0694evLPl1qygeLckjxw liRsBcZJv09JYBKvu6oVSOiGmDLABp6Zj6f9gOfZP7EOqOMMWlMy5dDDlV1Yj45UsrBS+YtH oH0//JyNqdwRhDiNtsyea0JRU/rhCyr1sZH6sWvZCexdEyvjIxh7cDjFA4QhbwAAAAAAAA== --------------ms030507050206010307020009-- From owner-ietf-calendar@mail.imc.org Mon Dec 8 20:01:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17014 for ; Mon, 8 Dec 2003 20:01: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 hB90leib095019 for ; Mon, 8 Dec 2003 16:47:40 -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 hB90leUu095018 for ietf-calendar-bks; Mon, 8 Dec 2003 16:47:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB90lcib095011 for ; Mon, 8 Dec 2003 16:47:38 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (sccrmhc12) with SMTP id <2003120900473501200focfce> (Authid: TimHare); Tue, 9 Dec 2003 00:47:35 +0000 Message-Id: <5.2.1.1.0.20031208194103.00a45280@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 08 Dec 2003 19:47:02 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: "and so this is Christmas, and what have you done?" In-Reply-To: <3FC15CA8.9060701@Royer.com> References: <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> 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: Apologies to whomever owns the rights to that song, but back on 11/20 I proposed that we come up with a list of items yet to be resolved in CAP. To the best of my knowledge, there were a couple of replies about items on _my_ proposed list, including a correction that the recurrence-ID issue is not really a CAP issue but an iTIP issue; however I've seen no other replies. In my (some would say not-so-humble) opinion, we need to reach a consensus on what there is left to do, so we can get it done. Does anyone else have a list? Can we come up with an agreed-upon list of outstanding issues and then work on them one-by-one? Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Tue Dec 9 10:55:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01069 for ; Tue, 9 Dec 2003 10:55:30 -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 hB9FUeib005824 for ; Tue, 9 Dec 2003 07:30:40 -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 hB9FUeV1005823 for ietf-calendar-bks; Tue, 9 Dec 2003 07:30:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9FUdib005817 for ; Tue, 9 Dec 2003 07:30:39 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FD50397.6BECC140@INET-Calendar.net> To: ietf-calendar@imc.org Subject: Re: DTSTART for recurrence instances MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 9 Dec 2003 10:18:30 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/09/2003 10:27:42 AM, Serialize complete at 12/09/2003 10:27:42 AM Content-Type: multipart/alternative; boundary="=_alternative 0053C0A485256DF7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053C0A485256DF7_= Content-Type: text/plain; charset="US-ASCII" Mark replied on 12/08/2003 06:04:55 PM: > > > instance due date as described in 4.5.7.2 is: > > > > > > instance-due-date = RECURRENCE-ID + (DUE - DTSTART). > > > > > > It is always correct. > > > > > > Clearly you are using incorrect procedures as outlined in 2446. > > > > Actually I think you are still under the mistaken impression that > > RECURRENCE-ID changes when the a component is rescheduled. > > FYI - EVERY discussion about RECURRENCE-ID is not that topic. I suggest you learn to distingush the role of instance _identifier_ (RECURRENCE-ID) from instance _start_date/time_ (DTSTART) when you propose algorithms then. You (and others) continue to misuse RECURRENCE-ID and I will continue to try and disavow you of that mistaken idea. RECURRENCE-ID is strictly used to find and identify the correct repeat instance of a repeat set. Its intended to help both sides of the workflow process correctly identify the instance in question. It is NOT designed to be anything like "the instances last DTSTART time" as this makes dealing with missequenced or lost workflow messages impossible (or at least waaay to cumbersome). DTSTART is used to specify when the instance starts. When an instance first gets created this value is assigned to the instances RECURRENCE-ID. As the instance gets rescheduled though, only DTSTART changes. As such, your proposed algorithm would generate wildly varying and inaccurate DUE values depending on how far the instance gets rescheduled from its original DTSTART value. As noted before, you could even get DUE values before the DSTART value of an instance and thats hardly acceptable. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0053C0A485256DF7_= Content-Type: text/html; charset="US-ASCII"
Mark replied on 12/08/2003 06:04:55 PM:
> > > instance due date as described in 4.5.7.2 is:
> > >
> > >   instance-due-date = RECURRENCE-ID + (DUE - DTSTART).
> > >
> > > It is always correct.
> > >
> > > Clearly you are using incorrect procedures as outlined in 2446.
> >
> > Actually I think you are still under the mistaken impression that
> > RECURRENCE-ID changes when the a component is rescheduled.
>
> FYI - EVERY discussion about RECURRENCE-ID is not that topic.
I suggest you learn to distingush the role of instance _identifier_ (RECURRENCE-ID) from instance _start_date/time_ (DTSTART) when you propose algorithms then.  You (and others) continue to misuse RECURRENCE-ID and I will continue to try and disavow you of that mistaken idea.

RECURRENCE-ID is strictly used to find and identify the correct repeat instance of a repeat set.  Its intended to help both sides of the workflow process correctly identify the instance in question.  It is NOT designed to be anything like "the instances last DTSTART time" as this makes dealing with missequenced or lost workflow messages impossible (or at least waaay to cumbersome).  

DTSTART is used to specify when the instance starts.  When an instance first gets created this value is assigned to the instances RECURRENCE-ID.  As the instance gets rescheduled though, only DTSTART changes.

As such, your proposed algorithm would generate wildly varying and inaccurate DUE values depending on how far the instance gets rescheduled from its original DTSTART value.   As noted before, you could even get DUE values before the DSTART value of an instance and thats hardly acceptable.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0053C0A485256DF7_=-- From owner-ietf-calendar@mail.imc.org Tue Dec 9 11:13:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01887 for ; Tue, 9 Dec 2003 11:13:34 -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 hB9Frvib006700 for ; Tue, 9 Dec 2003 07:53:57 -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 hB9Frudj006699 for ietf-calendar-bks; Tue, 9 Dec 2003 07:53:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Fruib006692 for ; Tue, 9 Dec 2003 07:53:56 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FD4CECB.9187A40D@INET-Calendar.net> To: ietf-calendar@imc.org Subject: Re: DTSTART for recurrence instances MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 9 Dec 2003 10:52:05 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/09/2003 10:50:58 AM, Serialize complete at 12/09/2003 10:50:59 AM, Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/09/2003 10:50:59 AM Content-Type: multipart/alternative; boundary="=_alternative 0056D3E985256DF7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056D3E985256DF7_= Content-Type: text/plain; charset="US-ASCII" Mark contributed on 12/08/2003 02:19:39 PM: > > No. (Please be careful using 'master' as it introduces a new term w/o > > defining it. > > Yet again you failed to know iCalendar - 'master' is in 2446 > no one made it up. Lets be clear about this shall we. The phrase "master" is used in iTIP Section 2.1 Application Protocol to describe the copy of the entry that exists in the Organziers calendar. That is, invitees see their own copy and work on it, NOT the 'master' copy that exists solely in the Organziers calendar. That is not the same context that it appeared to be used in Craigs posting. Craigs usage may have been referring to that but the way he used it implied it was referring to the VEVENT in the REQUEST that had the RRULE on it. Its was not clear and after the entire "full REFRESH" thing with Doug I prefer to make sure terms are properly defined so we are all on the same page so we can be more productive. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0056D3E985256DF7_= Content-Type: text/html; charset="US-ASCII"
Mark contributed on 12/08/2003 02:19:39 PM:
> > No.  (Please be careful using 'master' as it introduces a new term w/o
> > defining it.
>
> Yet again you failed to know iCalendar - 'master' is in 2446
> no one made it up.
Lets be clear about this shall we.  The phrase "master" is used in iTIP Section 2.1 Application Protocol to describe the copy of the entry that exists in the Organziers calendar.  That is, invitees see their own copy and work on it, NOT the 'master' copy that exists solely in the Organziers calendar.  That is not the same context that it appeared to be used in Craigs posting.  Craigs usage may have been referring to that but the way he used it implied it was referring to the VEVENT in the REQUEST that had the RRULE on it.

Its was not clear and after the entire "full REFRESH" thing with Doug I prefer to make sure terms are properly defined so we are all on the same page so we can be more productive.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0056D3E985256DF7_=-- From owner-ietf-calendar@mail.imc.org Tue Dec 9 13:52: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 NAA07585 for ; Tue, 9 Dec 2003 13:52: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 hB9IbJib014723 for ; Tue, 9 Dec 2003 10:37:19 -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 hB9IbJrx014722 for ietf-calendar-bks; Tue, 9 Dec 2003 10:37:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9IbIib014713 for ; Tue, 9 Dec 2003 10:37:18 -0800 (PST) (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 hB9IbEYu024725; Tue, 9 Dec 2003 11:37:14 -0700 (MST) Message-ID: <3FD6165A.1208393D@INET-Calendar.net> Date: Tue, 09 Dec 2003 11:37:14 -0700 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: DTSTART for recurrence instances References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark replied on 12/08/2003 06:04:55 PM: > > > > instance due date as described in 4.5.7.2 is: > > > > > > > > instance-due-date = RECURRENCE-ID + (DUE - DTSTART). > > > > > > > > It is always correct. > > > > > > > > Clearly you are using incorrect procedures as outlined in 2446. > > > > > > Actually I think you are still under the mistaken impression that > > > RECURRENCE-ID changes when the a component is rescheduled. > > > > FYI - EVERY discussion about RECURRENCE-ID is not that topic. > > I suggest you learn to distingush the role of instance _identifier_ > (RECURRENCE-ID) from instance _start_date/time_ (DTSTART) when you > propose algorithms then. You (and others) continue to misuse > RECURRENCE-ID and I will continue to try and disavow you of that > mistaken idea. And it STILL is not that topic. From owner-ietf-calendar@mail.imc.org Tue Dec 9 13:53: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 NAA07601 for ; Tue, 9 Dec 2003 13:53:16 -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 hB9IcYib014801 for ; Tue, 9 Dec 2003 10:38:34 -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 hB9IcYNq014800 for ietf-calendar-bks; Tue, 9 Dec 2003 10:38:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9IcXib014792 for ; Tue, 9 Dec 2003 10:38:33 -0800 (PST) (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 hB9IcUYu024728; Tue, 9 Dec 2003 11:38:30 -0700 (MST) Message-ID: <3FD616A6.5FA5D432@INET-Calendar.net> Date: Tue, 09 Dec 2003 11:38:30 -0700 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: DTSTART for recurrence instances References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark contributed on 12/08/2003 02:19:39 PM: > > > No. (Please be careful using 'master' as it introduces a new term > w/o > > > defining it. > > > > Yet again you failed to know iCalendar - 'master' is in 2446 > > no one made it up. > > Lets be clear about this shall we. The phrase "master" is used in > iTIP Section 2.1 Application Protocol to describe the copy of the > entry that exists in the Organziers calendar. No apology for AGAIN sending false information to this list? > Its was not clear and after the entire "full REFRESH" thing with Doug > I prefer to make sure terms are properly defined so we are all on the > same page so we can be more productive. Yet again - NOT the topic. From owner-ietf-calendar@mail.imc.org Tue Dec 9 17:47: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 RAA21461 for ; Tue, 9 Dec 2003 17:47:16 -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 hB9MRaib026220 for ; Tue, 9 Dec 2003 14:27: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 hB9MRaxM026219 for ietf-calendar-bks; Tue, 9 Dec 2003 14:27:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9MRXib026212 for ; Tue, 9 Dec 2003 14:27:34 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATqKI-0008Jl-00 for ; Tue, 09 Dec 2003 23:27:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATqKG-0008Jd-00 for ; Tue, 09 Dec 2003 23:27:28 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATqKG-00064f-00 for ; Tue, 09 Dec 2003 23:27:28 +0100 From: "Michael Fair" Subject: Re: DTSTART for recurrence instances Date: Tue, 9 Dec 2003 14:27:27 -0800 Lines: 42 Message-ID: References: <3FD616A6.5FA5D432@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark, if you are going to waste our time beating up on Bruce, correct him if you think he is lying. He asserted a definition and context for the term "master" for the sake of creating clarity. If you disagree, then you have an obligation (in the context of being productive) to explain your understanding of said terms. Bruce may be lying (I happen to agree with his side of this), but he is making an earnest effort to create clarity. Please (hopefully starting with this last email), if you think Bruce is lying to us, correct him so that either you or he can adjust their views, or at worst at least understand what each other is saying. -- Michael -- "Mark Smith" wrote in message news:3FD616A6.5FA5D432@INET-Calendar.net... > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > Mark contributed on 12/08/2003 02:19:39 PM: > > > > No. (Please be careful using 'master' as it introduces a new term > > w/o > > > > defining it. > > > > > > Yet again you failed to know iCalendar - 'master' is in 2446 > > > no one made it up. > > > > Lets be clear about this shall we. The phrase "master" is used in > > iTIP Section 2.1 Application Protocol to describe the copy of the > > entry that exists in the Organziers calendar. > > No apology for AGAIN sending false information to this list? > > > Its was not clear and after the entire "full REFRESH" thing with Doug > > I prefer to make sure terms are properly defined so we are all on the > > same page so we can be more productive. > > Yet again - NOT the topic. > From owner-ietf-calendar@mail.imc.org Tue Dec 9 18:11: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 SAA22709 for ; Tue, 9 Dec 2003 18:11:05 -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 hB9N0Iib027499 for ; Tue, 9 Dec 2003 15:00: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 hB9N0Ht7027497 for ietf-calendar-bks; Tue, 9 Dec 2003 15:00:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9N0Gib027489 for ; Tue, 9 Dec 2003 15:00:16 -0800 (PST) (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 hB9N0DYu025110; Tue, 9 Dec 2003 16:00:13 -0700 (MST) Message-ID: <3FD653FD.5CD07609@INET-Calendar.net> Date: Tue, 09 Dec 2003 16:00:13 -0700 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: DTSTART for recurrence instances References: <3FD616A6.5FA5D432@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: He said 'master' introduces a new term. No it did not. It has nothing to do with clarity, it has to do with shooting from the hip yet again and backpedaling and not checking to see if he sent was accurate. > Mark, if you are going to waste our time beating up on Bruce, > correct him if you think he is lying. > > He asserted a definition and context for the term "master" for > the sake of creating clarity. If you disagree, then you have an > obligation (in the context of being productive) to explain your > understanding of said terms. Bruce may be lying (I happen to > agree with his side of this), but he is making an earnest effort > to create clarity. Please (hopefully starting with this last > email), if you think Bruce is lying to us, correct him so that > either you or he can adjust their views, or at worst at least > understand what each other is saying. > > -- Michael -- > From owner-ietf-calendar@mail.imc.org Tue Dec 9 19:10: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 TAA25477 for ; Tue, 9 Dec 2003 19:10:30 -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 hB9Nvoib029078 for ; Tue, 9 Dec 2003 15:57:50 -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 hB9Nvos6029077 for ietf-calendar-bks; Tue, 9 Dec 2003 15:57:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Nvkib029065 for ; Tue, 9 Dec 2003 15:57:48 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATrjf-0000tc-00 for ; Wed, 10 Dec 2003 00:57:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATrje-0000tU-00 for ; Wed, 10 Dec 2003 00:57:46 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATrje-0000L3-00 for ; Wed, 10 Dec 2003 00:57:46 +0100 From: "Michael Fair" Subject: Re: DTSTART for recurrence instances Date: Tue, 9 Dec 2003 15:57:45 -0800 Lines: 52 Message-ID: References: <3FD616A6.5FA5D432@INET-Calendar.net> <3FD653FD.5CD07609@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Mark Smith" wrote in message news:3FD653FD.5CD07609@INET-Calendar.net... > > Michael Fair wrote: > > He said 'master' introduces a new term. No it did not. Do you have a differing or counter definition for the term 'master' or do you simply have a personal gripe with posts initiating from Bruce? In the context of Craig's post, Bruce found the use of the term master sloppy and called it a new term. He might have been mistaken about that (people make mistakes), but he offered us the definition of 'master' that he was going to use for the context of that email. The appropriate response to that would have been to cite the definition of the term 'master' from iTip _AND_ cite whether or not you agreed that Craig's use of the term 'master' followed with Bruce's definition. Instead you simply called Bruce a liar and made a passing reference to iTip thereby making us all duplicate the lookup work and reread the posts to see if the usage was consistent with the real definition or with Craig's. Please don't do that, it doesn't help me interpret what you believe, nor give any meaningful correction to Bruce's purported misdirection. Do you have a different definition for the term 'master' for use in Bruce's response to Craig? If so, I request you assert it. I believe Bruce made an accurate assessment of Craig's usage despite the differing definition in iTIP. I believe that Craig's usage meant the copy in the CU's storage. For the context of Bruce's response to Craig, and for that thread only or at least only that message, do you have a differing interpretation that would prevent us from moving forward on that discussion? This is an extemely sensitive topic capable of creating thousands of unproductive lines of text and we aren't off to a great start. I request that we all give each other a little more way leeway than is usual until we start getting some traction on the topic (which still hasn't even been clearly identified). And that really means _all_ of us (except of course the chairs, they can and should be able to crack down whenever they feel things are getting out of hand). Trying to reach understanding so that we may then try and move toward consensus, -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Dec 9 19:22:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26072 for ; Tue, 9 Dec 2003 19:22:26 -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 hBA09iib029391 for ; Tue, 9 Dec 2003 16:09:44 -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 hBA09ibs029390 for ietf-calendar-bks; Tue, 9 Dec 2003 16:09:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA09gib029383 for ; Tue, 9 Dec 2003 16:09:43 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATrvE-0000zp-00 for ; Wed, 10 Dec 2003 01:09:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATrvD-0000zh-00 for ; Wed, 10 Dec 2003 01:09:43 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATrvD-0000ew-00 for ; Wed, 10 Dec 2003 01:09:43 +0100 From: "Michael Fair" Subject: Re: DTSTART for recurrence instances Date: Tue, 9 Dec 2003 16:09:43 -0800 Lines: 44 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think someone should pick up this thread with Doug. This is the most productive line of conversation yet to create clarity around this. Some time ago Doug Royer started ignoring me. Will someone please reply to my post or Doug's directly to persue this? > BEGIN:VEVENT > UID:XXX > SEQUENCE:1 > ... > METHOD:REQUEST > DTSTART:2-dec-2003 at 2pm > DTEND:2-dec-2003 at 3:30pm > RECURRENCE-ID:2-dec-2003 at noon > .. > END:VEVENT > > Do you agree that is how to move a single instance? Yes I agree that would be the iTIP to send to move the 2nd instance from noon to 2pm. Now I believe the next step is to move it from 2pm to 4pm. (I moved the RECURRENCE-ID property to place it with the identifiers.) BEGIN:VEVENT METHOD:REQUEST UID:XXX RECURRENCE-ID:2-dec-2003 at noon SEQUENCE:2 ... DTSTART:2-dec-2003 at 4pm DTEND:2-dec-2003 at 5:30pm .. END:VEVENT The key being that Recurrence-id is "at noon" and not "at 2pm". Do you agree that is how to move a single instance a second time? -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Dec 9 19:30: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 TAA26382 for ; Tue, 9 Dec 2003 19:30:12 -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 hBA0J2ib029775 for ; Tue, 9 Dec 2003 16:19: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 hBA0J2tP029774 for ietf-calendar-bks; Tue, 9 Dec 2003 16:19:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA0J0ib029747 for ; Tue, 9 Dec 2003 16:19:00 -0800 (PST) (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 hBA0IwYu025513 for ; Tue, 9 Dec 2003 17:18:58 -0700 (MST) Message-ID: <3FD66672.DFCE7767@INET-Calendar.net> Date: Tue, 09 Dec 2003 17:18:58 -0700 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: DTSTART for recurrence instances References: <3FD616A6.5FA5D432@INET-Calendar.net> <3FD653FD.5CD07609@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > "Mark Smith" wrote in message > news:3FD653FD.5CD07609@INET-Calendar.net... > > > > Michael Fair wrote: > > > > He said 'master' introduces a new term. No it did not. > > Do you have a differing or counter definition for the term 'master' or > do you simply have a personal gripe with posts initiating from Bruce? As already posted. And I did post the location of the definition. From owner-ietf-calendar@mail.imc.org Tue Dec 9 20:46: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 UAA28136 for ; Tue, 9 Dec 2003 20:46:13 -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 hBA1Xjib031994 for ; Tue, 9 Dec 2003 17:33:45 -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 hBA1XjGd031993 for ietf-calendar-bks; Tue, 9 Dec 2003 17:33:45 -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 hBA1Xhib031987 for ; Tue, 9 Dec 2003 17:33:43 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:2eKQspEF42z2S6VoP3b3rot5Gv/dgG6C@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBA1XdZf032222 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 9 Dec 2003 17:33:40 -0800 Message-ID: <3FD677F3.8090203@Royer.com> Date: Tue, 09 Dec 2003 18:33:39 -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: DTSTART for recurrence instances References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090300080701070601040307" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090300080701070601040307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (Again the topic is DTSTART for recurrence instances, not any thing else) Is there any disagreement that these are -also- a valid ways to change the 2nd instance: Again starting from the same original object. BEGIN:VEVENT UID:XXX SEQUENCE:0 ... METHOD:REQUEST ATTENDEE:attendee ... DTSTART: 1-dec-2003 at noon DTEND: 1-dec-2003 at 1pm ... RRULE:FREQ=DAILY;COUNT=3 ... END:VEVENT (And 'attendee' sends a reply saying yes). Method A: Now later ORGANIZER sends iTIP updates to move the second instance from noon->1pm and have it at 2pm->3:30pm: BEGIN:VCALENDAR ... METHOD:REQUEST BEGIN:VEVENT UID:XXX SEQUENCE:1 ... DTSTART: 1-dec-2003 at noon DTEND: 1-dec-2003 at 1pm ... RDATE:3-dec-2003 at noon ... END:VEVENT END:VCALENDAR BEGIN:VCALENDAR METHOD:ADD BEGIN:VEVENT UID:XXX SEQUENCE:2 ... DTSTART:2-dec-2003 at 2pm DTEND:2-dec-2003 at 3:30pm ... END:VEVENT END:VCALENDAR Method B: Now later ORGANIZER sends iTIP updates to move the second instance from noon->1pm and have it at 2pm->3:30pm: BEGIN:VEVENT UID:XXX SEQUENCE:1 ... METHOD:REQUEST ATTENDEE:attendee ... DTSTART: 1-dec-2003 at noon DTEND: 1-dec-2003 at 1pm ... RRULE:FREQ=DAILY;COUNT=3 EXDATE:2-dec-2003 at noon ... END:VEVENT BEGIN:VCALENDAR METHOD:ADD BEGIN:VEVENT UID:XXX SEQUENCE:2 ... DTSTART:2-dec-2003 at 2pm DTEND:2-dec-2003 at 3:30pm ... END:VEVENT END:VCALENDAR Method C: -OR- this: BEGIN:VCALENDAR ... METHOD:CANCEL BEGIN:VEVENT UID:XXX SEQUENCE:1 ... RECURRENCE-ID:2-dec-2003 at noon ... END:VEVENT END:VCALENDAR BEGIN:VCALENDAR METHOD:ADD BEGIN:VEVENT UID:XXX SEQUENCE:2 ... DTSTART:2-dec-2003 at 2pm DTEND:2-dec-2003 at 3:30pm ... END:VEVENT END:VCALENDAR Do you agree that these are also valid objects to tell the ATTENDEE of the single instance change? -- 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 --------------ms090300080701070601040307 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 9w0BCQUxDxcNMDMxMjEwMDEzMzM5WjAjBgkqhkiG9w0BCQQxFgQUol3H02PGAzAW9fIViljF mjiAliswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA2tAVnF6DL+kJEYvhf4+Kcd7nQscT2CbOxhAjzSaksi4xHRKX/o/V+su72WozfwMm Xl36Y6v+OU+vUZDUBMtIyoPeBQmFFDFwaLUQdfb5RtsGmMgB8b0Uc56WuvTsglfzsoCIkaDV Wn5NUNDvgJ1h8j8cSJO861gQw1cYIrJ2FSaH+cM4Althv/DEe37L6gCHQpYGWPUTgL58zC+2 2+zvSUV7jryETDeB9/Fo6cujXICMjiYcx2R6adGCoZj32Zf5pflTZs1qRZxZ+uqNbGP8yPof AllIuD5z02iKBtriZpFZIf7HMEmqI1Vkh3lBwW6VLLWeoMkL8AbzaBBtA4utJgAAAAAAAA== --------------ms090300080701070601040307-- From owner-ietf-calendar@mail.imc.org Tue Dec 9 22:06: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 WAA29756 for ; Tue, 9 Dec 2003 22:06: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 hBA2paib034800 for ; Tue, 9 Dec 2003 18:51: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 hBA2pa4s034799 for ietf-calendar-bks; Tue, 9 Dec 2003 18:51:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA2pXib034793 for ; Tue, 9 Dec 2003 18:51:34 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATuRr-0002R1-00 for ; Wed, 10 Dec 2003 03:51:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATuRq-0002Qt-00 for ; Wed, 10 Dec 2003 03:51:34 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATuRq-0004J8-00 for ; Wed, 10 Dec 2003 03:51:34 +0100 From: "Michael Fair" Subject: Re: DTSTART for recurrence instances Date: Tue, 9 Dec 2003 18:51:33 -0800 Lines: 167 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Doug Royer" wrote in message news:3FD677F3.8090203@Royer.com... > > (Again the topic is DTSTART for recurrence instances, not any thing else) > > Is there any disagreement that these are -also- a valid ways to change > the 2nd instance: > > Again starting from the same original object. > > BEGIN:VEVENT > UID:XXX > SEQUENCE:0 > ... > METHOD:REQUEST > ATTENDEE:attendee > ... > DTSTART: 1-dec-2003 at noon > DTEND: 1-dec-2003 at 1pm > ... > RRULE:FREQ=DAILY;COUNT=3 > ... > END:VEVENT > > (And 'attendee' sends a reply saying yes). Just to ensure that I am following I am going to describe the state of the CU's store at the end of each message. > Method A: Now later ORGANIZER sends iTIP updates to move the second > instance > from noon->1pm and have it at 2pm->3:30pm: > > BEGIN:VCALENDAR > ... > METHOD:REQUEST > BEGIN:VEVENT > UID:XXX > SEQUENCE:1 > ... > DTSTART: 1-dec-2003 at noon > DTEND: 1-dec-2003 at 1pm > ... > RDATE:3-dec-2003 at noon > ... > END:VEVENT > END:VCALENDAR > > BEGIN:VCALENDAR > METHOD:ADD > BEGIN:VEVENT > UID:XXX > SEQUENCE:2 > ... > DTSTART:2-dec-2003 at 2pm > DTEND:2-dec-2003 at 3:30pm > ... > END:VEVENT > END:VCALENDAR I agree. This first message would redefine the event XXX to have exactly two instances (Dec 1, Dec 3), and drop the orginal Dec 2 instance. The second message then adds to the series of UID XXX one singleton on Dec 2 and updates the SEQUENCE of all instances to 2. > Method B: Now later ORGANIZER sends iTIP updates to move the second > instance > from noon->1pm and have it at 2pm->3:30pm: > > BEGIN:VEVENT > UID:XXX > SEQUENCE:1 > ... > METHOD:REQUEST > ATTENDEE:attendee > ... > DTSTART: 1-dec-2003 at noon > DTEND: 1-dec-2003 at 1pm > ... > RRULE:FREQ=DAILY;COUNT=3 > EXDATE:2-dec-2003 at noon > ... > END:VEVENT > > BEGIN:VCALENDAR > METHOD:ADD > BEGIN:VEVENT > UID:XXX > SEQUENCE:2 > ... > DTSTART:2-dec-2003 at 2pm > DTEND:2-dec-2003 at 3:30pm > ... > END:VEVENT > END:VCALENDAR I agree. The first message redefines the series to contain two instances on Dec 1 and Dec 3. The second message redefines the entire series to add a singleton event happening on Dec 2. It then updates the SEQUENCE for all instances of XXX to 2. > Method C: -OR- this: > > BEGIN:VCALENDAR > ... > METHOD:CANCEL > BEGIN:VEVENT > UID:XXX > SEQUENCE:1 > ... > RECURRENCE-ID:2-dec-2003 at noon > ... > END:VEVENT > END:VCALENDAR > > BEGIN:VCALENDAR > METHOD:ADD > BEGIN:VEVENT > UID:XXX > SEQUENCE:2 > ... > DTSTART:2-dec-2003 at 2pm > DTEND:2-dec-2003 at 3:30pm > ... > END:VEVENT > END:VCALENDAR > > Do you agree that these are also valid objects to tell the ATTENDEE of > the single instance change? I agree. I'm not entirely certain of all the gritty details of how the first message gets handled because of other questions I raised back in August. Don't bother looking for them though, they aren't relevant at this point. For now I'm fine to just accept that this has the effect of cancelling the second instance in the series leaving just Dec 1 and Dec 3. The second message then adds a new instance to the series XXX on Dec-2 and updates the SEQUENCE of all instances of XXX to 2. Having said that there is one thing I do have a problem with and that is calling any of the above methods an instance reschedule. They result in the intended calendar and that's about all I can say about them. Everyone of the aboves methods uses extremely invasive reschedules of the entire series and I cannot consider them as proper methods for instance updates or reschedules. Where do we go from here? -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Dec 9 23:58:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02179 for ; Tue, 9 Dec 2003 23:58:33 -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 hBA4eaib038873 for ; Tue, 9 Dec 2003 20:40: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 hBA4eaR5038872 for ietf-calendar-bks; Tue, 9 Dec 2003 20:40:36 -0800 (PST) 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 hBA4eYib038867 for ; Tue, 9 Dec 2003 20:40:35 -0800 (PST) (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 <2003121004403201500bsnt0e> (Authid: TimHare); Wed, 10 Dec 2003 04:40:32 +0000 Message-Id: <5.2.1.1.0.20031209233809.00a308e0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 09 Dec 2003 23:39:51 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: "and so this is Christmas, and what have you done?" In-Reply-To: References: <3FD54AD1.6030205@Royer.com> <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> <5.2.1.1.0.20031208194103.00a45280@mail.comcast.net> <3FD54AD1.6030205@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As I have no experience to speak of with bugzilla, I am probably not the best person for that task. I could learn it, I'm sure, but we can ill afford the time at this point. Tim Hare Interested Bystander, Non-Inc. At 01:16 AM 12/9/03 -0800, "RL 'Bob' Morgan" wrote: >First, let me apologize and say that there was really unfortunate timing >in that my appointment as WG co-chair coincided with a family illness that >has taken much of my time for the last month, so I have been unable to hit >the ground running as chair as I would have hoped. > >Yes, I am entirely in favor of making an issues list and working through >it systematically. This may take time, but it will absolutely take less >time than not having one. I personally favor an approach where each new >issue gets an identifier of some kind, status is kept, list discussion >refers to issues by id, and issues are closed either by dropping/deferring >them or by incorporating doc text to reflect them. I also prefer an >approach where the issue list keeper is not a doc author, but it can work >either way. > >If you are volunteering to do the issues list (and I'm quite open to using >eg bugzilla but won't have time to set it up myself) Tim, I'm happy to >work with you on that. > > - RL "Bob" From owner-ietf-calendar@mail.imc.org Wed Dec 10 03:09:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03758 for ; Wed, 10 Dec 2003 03:09: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 hBA7vCib085774 for ; Tue, 9 Dec 2003 23:57:12 -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 hBA7vCWF085773 for ietf-calendar-bks; Tue, 9 Dec 2003 23:57:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA7vBib085760 for ; Tue, 9 Dec 2003 23:57:11 -0800 (PST) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBA7uw9n027348; Tue, 9 Dec 2003 23:57:03 -0800 Received: from [192.168.1.103] (12-207-222-248.client.attbi.com [12.207.222.248]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBA7uvvo016925 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 9 Dec 2003 23:56:57 -0800 Date: Tue, 9 Dec 2003 23:56:57 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG cc: Pat Egen Subject: rules of engagement for ietf-calendar 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: (Let me say first that I apologize for the delay in getting this message out, but personal matters got in the way of my taking up the baton as WG co-chair as quickly as I had hoped to. - RL "Bob") There has been considerable discussion of the state of the IETF calsch WG, at the recent WG meeting at IETF 58 and elsewhere. It is clear that, while many people and organizations have a strong interest in seeing this WG complete its chartered goals, many potentially productive participants have been driven away from the WG based on their perception that the group is just broken. Let's say this as plainly as possible: this WG must very soon start working effectively, or it will be shut down. It's possible that a new WG could be chartered, following a BoF; even if this happened the completion of standards-track calendar documents would be delayed by many months or years. There are several aspects to working effectively, but the first step is proper behavior on this mailing list. First, all WG participants should take a few minutes and read BCP 54 (aka RFC 3184), "IETF Guidelines for Conduct", and act accordingly. (Extra credit reading: Radia Perlman's presentation at IETF 53, "Miss Manners Meets the IETF", http://www.ietf.org/proceedings/02mar/slides/plenary-3/index.html ) The rules below add some specifics to the BCP 54 guidelines. Those violating these rules will be handled according to the procedures in the last paragraph of section 3.2 of RFC 2418: warnings, followed by revocation of posting privileges. As of this moment we are starting with a clean sheet for all participants, but we will be vigorous in keeping things in line after this, in hopes of creating a WG environment that will be productive for all who wish to contribute. 1. No negative personal comments in messages to the WG list. As this has been the biggest problem on the list up to now, this will be most strictly enforced. Here's a suggestion: avoid the words "you" and "your" in messages to the list. Aim criticism at proposals, not people. Also banned is discussion on the list of any participant's behavior, past, present, or future. Those who wish to make comments about other participants can make them to the WG chairs (or to each other). We are also available by phone if need be, just ask. 2. No more than 5 messages to the WG list per person per day. Interested parties have said that often the sheer amount of traffic on the list can be an obstacle. While in rare cases lots of messages in a short time can indicate lots of progress, usually they just represent a shouting match. Instead of firing off that one-line response, take a break, wait until tomorrow; or conduct the heated discussion in private email, and bring the results back to the list later. 3. Issue-based list discussion. The chairs are working to set up a standard issue-tracking method for the WG, so that issues can be clearly identified with status visible to all. Discussion on the list will be conducted about specific issues. As new potential issues come up, they will either be clearly identified and tracked for further discussion and resolution, or they will be deferred or dropped. Extended discussion of topics other than those on the open issues list will be strongly discouraged (with exceptions at the discretion of the chairs). Thanks in advance for your cooperation and hard work, - RL "Bob" and Pat From owner-ietf-calendar@mail.imc.org Wed Dec 10 09:30: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 JAA12958 for ; Wed, 10 Dec 2003 09:30:13 -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 hBAED8ib038022 for ; Wed, 10 Dec 2003 06:13: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 hBAED8Rh038021 for ietf-calendar-bks; Wed, 10 Dec 2003 06:13:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAED7ib038016 for ; Wed, 10 Dec 2003 06:13:07 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: "Michael Fair" Cc: ietf-calendar@imc.org Subject: Re: DTSTART for recurrence instances MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 10 Dec 2003 09:12:11 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/10/2003 09:10:10 AM, Serialize complete at 12/10/2003 09:10:10 AM Content-Type: multipart/alternative; boundary="=_alternative 004DA87E85256DF8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004DA87E85256DF8_= Content-Type: text/plain; charset="US-ASCII" Michael replied on 12/09/2003 07:09:43 PM: > > BEGIN:VEVENT > > UID:XXX > > SEQUENCE:1 > > ... > > METHOD:REQUEST > > DTSTART:2-dec-2003 at 2pm > > DTEND:2-dec-2003 at 3:30pm > > RECURRENCE-ID:2-dec-2003 at noon > > .. > > END:VEVENT > > > > Do you agree that is how to move a single instance? > > Yes I agree that would be the iTIP to send to move the > 2nd instance from noon to 2pm. I agree too. (I dont know if Oliver didnt see Dougs posting was directed at him or not so maybe thats why he didnt respond yet.) > Now I believe the next step is to move it from 2pm to 4pm. > (I moved the RECURRENCE-ID property to place it with the identifiers.) > > BEGIN:VEVENT > METHOD:REQUEST > UID:XXX > RECURRENCE-ID:2-dec-2003 at noon > SEQUENCE:2 > ... > DTSTART:2-dec-2003 at 4pm > DTEND:2-dec-2003 at 5:30pm > .. > END:VEVENT > > The key being that Recurrence-id is "at noon" and not "at 2pm". > Do you agree that is how to move a single instance a second time? Yes. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 004DA87E85256DF8_= Content-Type: text/html; charset="US-ASCII"
Michael replied on 12/09/2003 07:09:43 PM:
> >     BEGIN:VEVENT
> >     UID:XXX
> >     SEQUENCE:1
> >     ...
> >     METHOD:REQUEST
> >     DTSTART:2-dec-2003 at 2pm
> >     DTEND:2-dec-2003 at 3:30pm
> >     RECURRENCE-ID:2-dec-2003 at noon
> >     ..
> >     END:VEVENT
> >
> > Do you agree that is how to move a single instance?
>
> Yes I agree that would be the iTIP to send to move the
> 2nd instance from noon to 2pm.
I agree too.  (I dont know if Oliver didnt see Dougs posting was directed at him or not so maybe thats why he didnt respond yet.)

> Now I believe the next step is to move it from 2pm to 4pm.
> (I moved the RECURRENCE-ID property to place it with the identifiers.)
>
>      BEGIN:VEVENT
>      METHOD:REQUEST
>      UID:XXX
>      RECURRENCE-ID:2-dec-2003 at noon
>      SEQUENCE:2
>      ...
>      DTSTART:2-dec-2003 at 4pm
>      DTEND:2-dec-2003 at 5:30pm
>      ..
>      END:VEVENT
>
> The key being that Recurrence-id is "at noon" and not "at 2pm".
> Do you agree that is how to move a single instance a second time?
Yes.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 004DA87E85256DF8_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 10 11:08: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 LAA19692 for ; Wed, 10 Dec 2003 11:08:11 -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 hBAFkCib042530 for ; Wed, 10 Dec 2003 07:46:12 -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 hBAFkCQe042529 for ietf-calendar-bks; Wed, 10 Dec 2003 07:46:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAFkBib042522 for ; Wed, 10 Dec 2003 07:46:12 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <5.2.1.1.0.20031209233809.00a308e0@mail.comcast.net> To: Tim Hare Cc: ietf-calendar@imc.org Subject: Re: "and so this is Christmas, and what have you done?" MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 10 Dec 2003 10:46:03 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/10/2003 10:43:14 AM, Serialize complete at 12/10/2003 10:43:14 AM Content-Type: multipart/alternative; boundary="=_alternative 0056406985256DF8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056406985256DF8_= Content-Type: text/plain; charset="US-ASCII" Tim replied on 12/09/2003 11:39:51 PM: > As I have no experience to speak of with bugzilla, I am probably not the > best person for that task. I could learn it, I'm sure, but we can ill > afford the time at this point. In the past we used to keep a running textual list that got posted on a ~weekly basis to the WG. It was formatted like (minor edits applied): This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org. There are two parts to this list: (W) Working group action items. (C) CAP editor action items. Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of issues/proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y Instead of taking the time to learn bugzilla, why not just adopt a textual posting format similar to this one for now? That way not everyone has to learn bugzilla just to see what the issues are and it saves us cycles we may not have for working on the technical issues. (Im not sure we need to have the CAP Editor action items in the general WG list but maybe we do since we no longer have multiple draft editors and the WG never really discussed those AIs anyway...) 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 0056406985256DF8_= Content-Type: text/html; charset="US-ASCII"
Tim replied on 12/09/2003 11:39:51 PM:
> As I have no experience to speak of with bugzilla, I am probably not the
> best person for that task. I could learn it, I'm sure, but we can ill
> afford the time at this point.
In the past we used to keep a running textual list that got posted on a ~weekly basis to the WG.  It was formatted like (minor edits applied):

This is a list of action items for the CALSCH Working Group.
This list will be sent out once a week and updated as often
as practical (That means if I am not available it may take
an extra week or two before you see your changes).

Updates should be sent to mailto:ietf-calendar@imc.org.

There are two parts to this list:

                (W) Working group action items.
                (C) CAP editor action items.

Each action item will be assigned a unique ID that will aid in
tracking the items.

------------------------------------------------------------------------------

                                                  Working Group Action Items  

Where Resolution is one of:

                U - undecided.
                Y - Chair determined consensus is in favor of the proposal.
                N - Chair determined consensus is NOT in favor of the proposal.
                D - Dropped. Chair has decided that it may never reach consensus.

The following are a list of issues/proposals and their status in the WG:

WG Action Item                                             Resolution
--------------                                             ----------

W-1 CAP Use HTTP as transport                                   N

W-2 CAP If all booked and scheduled                             Y
    appointments are in same table

W-3 CAP Use SASL as authentication method                       Y
Instead of taking the time to learn bugzilla, why not just adopt a textual posting format similar to this one for now?  That way not everyone has to learn bugzilla just to see what the issues are and it saves us cycles we may not have for working on the technical issues.

(Im not sure we need to have the CAP Editor action items in the general WG list but maybe we do since we no longer have multiple draft editors and the WG never really discussed those AIs anyway...)

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 0056406985256DF8_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 10 11:29: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 LAA20227 for ; Wed, 10 Dec 2003 11:29:17 -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 hBAGIqib045320 for ; Wed, 10 Dec 2003 08:18:52 -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 hBAGIqmm045319 for ietf-calendar-bks; Wed, 10 Dec 2003 08:18:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAGIpib045308 for ; Wed, 10 Dec 2003 08:18:51 -0800 (PST) (envelope-from olivierg@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hBAGIlnc001841 for ; Wed, 10 Dec 2003 08:18:47 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 10 Dec 2003 08:18:44 -0800 Received: from [17.1.53.242] ([17.1.53.242]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id hBAGHx0n021883; Wed, 10 Dec 2003 08:18:11 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <87706A2A-2B2C-11D8-ACD3-000A9599D63E@apple.com> Cc: Michael Fair , ietf-calendar@imc.org From: Olivier Gutknecht Subject: Re: DTSTART for recurrence instances Date: Wed, 10 Dec 2003 17:18:45 +0100 To: Bruce_Kahn@notesdev.ibm.com X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBAGIpib045314 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On 10 déc. 03, at 15:12, Bruce_Kahn@notesdev.ibm.com wrote: > Michael replied on 12/09/2003 07:09:43 PM: > > >     BEGIN:VEVENT > > >     UID:XXX > > >     SEQUENCE:1 > > >     ... > > >     METHOD:REQUEST > > >     DTSTART:2-dec-2003 at 2pm > > >     DTEND:2-dec-2003 at 3:30pm > > >     RECURRENCE-ID:2-dec-2003 at noon > > >     .. > > >     END:VEVENT > > > > > > Do you agree that is how to move a single instance? > > > > Yes I agree that would be the iTIP to send to move the > > 2nd instance from noon to 2pm. > > I agree too.  (I dont know if Oliver didnt see Dougs posting was > directed at him or not so maybe thats why he didnt respond yet.) I agree too. I was just somewhat offline in the last two days, sorry for the delay. > > Now I believe the next step is to move it from 2pm to 4pm. > > (I moved the RECURRENCE-ID property to place it with the > identifiers.) > > > >      BEGIN:VEVENT > >      METHOD:REQUEST > >      UID:XXX > >      RECURRENCE-ID:2-dec-2003 at noon > >      SEQUENCE:2 > >      ... > >      DTSTART:2-dec-2003 at 4pm > >      DTEND:2-dec-2003 at 5:30pm > >      .. > >      END:VEVENT > > > > The key being that Recurrence-id is "at noon" and not "at 2pm". > > Do you agree that is how to move a single instance a second time? > Yes. If the instance was previously identified as above with the first REQUEST, yes I agree. Ol. From owner-ietf-calendar@mail.imc.org Wed Dec 10 11:29: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 LAA20243 for ; Wed, 10 Dec 2003 11:29:20 -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 hBAGJEib045343 for ; Wed, 10 Dec 2003 08:19:14 -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 hBAGJEc6045342 for ietf-calendar-bks; Wed, 10 Dec 2003 08:19:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAGJDib045333 for ; Wed, 10 Dec 2003 08:19:13 -0800 (PST) (envelope-from olivierg@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hBAGJ9nc002016 for ; Wed, 10 Dec 2003 08:19:09 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 10 Dec 2003 08:19:07 -0800 Received: from [17.1.53.242] ([17.1.53.242]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id hBAGHx0o021883 for ; Wed, 10 Dec 2003 08:18:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3FD0EA4C.3050307@Royer.com> References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0EA4C.3050307@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <95113428-2B2C-11D8-ACD3-000A9599D63E@apple.com> From: Olivier Gutknecht Subject: Re: DTSTART for recurrence instances Date: Wed, 10 Dec 2003 17:19:08 +0100 To: "ietf-calendar@imc.org" X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBAGJDib045338 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On 5 déc. 03, at 21:27, Doug Royer wrote: > So, if the ORGANIZER sends the following iTIP object to ATTENDEE: > > BEGIN:VEVENT > UID:XXX > SEQUENCE:0 > ... > METHOD:REQUEST > ATTENDEE:attendee > ... > DTSTART: 1-dec-2003 at noon > DTEND: 1-dec-2003 at 1pm > ... > RRULE:FREQ=DAILY;COUNT=3 > ... > END:VEVENT > > (And 'attendee' sends a reply saying yes). > > Now later ORGANIZER sends an iTIP update to move the 2nd instance from > noon->1pm > and have it at 2pm->3:30pm: > > BEGIN:VEVENT > UID:XXX > SEQUENCE:1 > ... > METHOD:REQUEST > DTSTART:2-dec-2003 at 2pm > DTEND:2-dec-2003 at 3:30pm > RECURRENCE-ID:2-dec-2003 at noon > .. > END:VEVENT > > Do you agree that is a valid object to tell the ATTENDEE of the single > instance change? I agree. iTIP to request that the instance identified by UID xxx and RECURRENCE-ID 2-dec-2003 noon (occurrence time) has now a DTSTART of 2-dec-2003 2pm (and DTEND of 3:30pm). Although this was the first solution, let's call that 'method D' to differentiate it from the A, B, C proposals of your next mail. Ol. From owner-ietf-calendar@mail.imc.org Wed Dec 10 11:31:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20295 for ; Wed, 10 Dec 2003 11:31:24 -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 hBAGIeib045301 for ; Wed, 10 Dec 2003 08:18:40 -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 hBAGIe0m045300 for ietf-calendar-bks; Wed, 10 Dec 2003 08:18:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAGIdib045295 for ; Wed, 10 Dec 2003 08:18:39 -0800 (PST) (envelope-from olivierg@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hBAGIZnc001796 for ; Wed, 10 Dec 2003 08:18:35 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 10 Dec 2003 08:18:33 -0800 Received: from [17.1.53.242] ([17.1.53.242]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id hBAGHx0m021883 for ; Wed, 10 Dec 2003 08:17:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3FD677F3.8090203@Royer.com> References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> From: Olivier Gutknecht Subject: Re: DTSTART for recurrence instances Date: Wed, 10 Dec 2003 17:18:33 +0100 To: ietf-calendar@imc.org X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBAGIdib045296 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On 10 déc. 03, at 02:33, Doug Royer wrote: > (Again the topic is DTSTART for recurrence instances, not any thing > else) > Is there any disagreement that these are -also- a valid ways to change > the 2nd instance: > [...] > Method A: Now later ORGANIZER sends iTIP updates to move the second > instance > from noon->1pm and have it at 2pm->3:30pm: > > BEGIN:VCALENDAR > ... > METHOD:REQUEST > BEGIN:VEVENT > UID:XXX > SEQUENCE:1 > ... > DTSTART: 1-dec-2003 at noon > DTEND: 1-dec-2003 at 1pm > ... > RDATE:3-dec-2003 at noon > ... > END:VEVENT > END:VCALENDAR > > BEGIN:VCALENDAR > METHOD:ADD > BEGIN:VEVENT > UID:XXX > SEQUENCE:2 > ... > DTSTART:2-dec-2003 at 2pm > DTEND:2-dec-2003 at 3:30pm > ... > END:VEVENT > END:VCALENDAR Method A: I agree. I rephrase to be sure we all understand it the same way: - a REQUEST to modify the event by having an instance on at 3-dec noon, the other one being the DTSTART at 1-dec-2003 noon - an ADD to then add another instance at 2-dec-2003 2pm > Method B: Now later ORGANIZER sends iTIP updates to move the second > instance > from noon->1pm and have it at 2pm->3:30pm: > > BEGIN:VEVENT > UID:XXX > SEQUENCE:1 > ... > METHOD:REQUEST > ATTENDEE:attendee > ... > DTSTART: 1-dec-2003 at noon > DTEND: 1-dec-2003 at 1pm > ... > RRULE:FREQ=DAILY;COUNT=3 > EXDATE:2-dec-2003 at noon > ... > END:VEVENT > > BEGIN:VCALENDAR > METHOD:ADD > BEGIN:VEVENT > UID:XXX > SEQUENCE:2 > ... > DTSTART:2-dec-2003 at 2pm > DTEND:2-dec-2003 at 3:30pm > ... > END:VEVENT > END:VCALENDAR Method B: I agree - a REQUEST to modify the event. We keep the RRULE and remove the 2-dec noon instance - a subsequent ADD to add the 2-dec-2003 2pm instance > Method C: -OR- this: > > BEGIN:VCALENDAR > ... > METHOD:CANCEL > BEGIN:VEVENT > UID:XXX > SEQUENCE:1 > ... > RECURRENCE-ID:2-dec-2003 at noon > ... > END:VEVENT > END:VCALENDAR > > BEGIN:VCALENDAR > METHOD:ADD > BEGIN:VEVENT > UID:XXX > SEQUENCE:2 > ... > DTSTART:2-dec-2003 at 2pm > DTEND:2-dec-2003 at 3:30pm > ... > END:VEVENT > END:VCALENDAR > > Do you agree that these are also valid objects to tell the ATTENDEE of > the single instance change? Method C: ok too - CANCEL to remove the instance identified by UID + recurrence-ID 2-dec-noon - then a ADD to put another instance at 2-dec-2003 2pm And in all cases (A,B,C,D), SEQUENCE for all instances is 2. I also agree with Michael's comments that we end with a calendar where we have 1-dec noon->1pm, 2-dec 2pm->3:30pm, 3-dec noon->1pm and I'm not sure I can consider every method as a 'reschedule'. Ol. From owner-ietf-calendar@mail.imc.org Wed Dec 10 11:32:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20345 for ; Wed, 10 Dec 2003 11:32:34 -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 hBAGJ8ib045335 for ; Wed, 10 Dec 2003 08:19: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 hBAGJ8Hw045334 for ietf-calendar-bks; Wed, 10 Dec 2003 08:19:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBAGJ6ib045324 for ; Wed, 10 Dec 2003 08:19:07 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003121011353814434 for ; Wed, 10 Dec 2003 11:35:38 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Dec 2003 11:16:07 -0500 Message-ID: <3FD746C7.1020106@centive.com> Date: Wed, 10 Dec 2003 11:16:07 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: "and so this is Christmas, and what have you done?" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2003 16:16:07.0370 (UTC) FILETIME=[EABAF2A0:01C3BF38] 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: > Instead of taking the time to learn bugzilla, why not just adopt a > textual posting format similar to this one for now? The periodic posting approach seems to have a tendency to bitrot, because it requires diligence from the person who updates it. > That way not everyone has to learn bugzilla just to see what the > issues are and it saves us cycles we may not have for working on the > technical issues. Personally, I don't think bugzilla is that hard to use, but then I've been using it since 1996. :-) (It was an internal tool at Netscape, called bugsplat, before it was released with Mozilla.) I'd be willing to take a crack at getting it set up, if the WG wants it. Or...Damon, are you still here? Ximian already has a bugzilla system set up for Evolution, etc.; would you guys be willing to extend it for calsch? That might be more reliable than me hosting it on my home boxen. -- /================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================| |World domination should never be left to chance.| \================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 10 13:31:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08328 for ; Wed, 10 Dec 2003 13:31: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 hBAIF3ib052128 for ; Wed, 10 Dec 2003 10:15: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 hBAIF3fB052127 for ietf-calendar-bks; Wed, 10 Dec 2003 10:15:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAIExib052104 for ; Wed, 10 Dec 2003 10:15:00 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3775F594-2B30-11D8-ADC8-000393BBAFF6@skyrix.com> To: Helge Hess Cc: ietf-calendar@imc.org, John Stracke , owner-ietf-calendar@mail.imc.org Subject: Re: "and so this is Christmas, and what have you done?" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Wed, 10 Dec 2003 13:14:56 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 12/10/2003 01:15:02 PM, Serialize complete at 12/10/2003 01:15:02 PM Content-Type: multipart/alternative; boundary="=_alternative 00643EC285256DF8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00643EC285256DF8_= Content-Type: text/plain; charset="US-ASCII" Helge, this is a great idea. It would be great if you can do that for us. Helge Hess Sent by: owner-ietf-calendar@mail.imc.org 12/10/2003 11:45 To John Stracke cc ietf-calendar@imc.org Subject Re: "and so this is Christmas, and what have you done?" On Dec 10, 2003, at 5:16 PM, John Stracke wrote: > Personally, I don't think bugzilla is that hard to use, but then I've > been using it since 1996. :-) (It was an internal tool at Netscape, > called bugsplat, before it was released with Mozilla.) Bugzilla is an excellent tool to track/classify/search issues, manage votes and do a "structured discussion". > I'd be willing to take a crack at getting it set up, if the WG wants > it. Or...Damon, are you still here? Ximian already has a bugzilla > system set up for Evolution, etc.; would you guys be willing to extend > it for calsch? That might be more reliable than me hosting it on my > home boxen. If this is of interest, we could jump in and create a Bugzilla category for calsch at the OpenGroupware.org Bugzilla: http://bugzilla.opengroupware.org/bugzilla/index.cgi Let me know if you are interested in that. best regards, Helge -- OpenGroupware.org => http://www.opengroupware.org/ --=_alternative 00643EC285256DF8_= Content-Type: text/html; charset="US-ASCII"
Helge, this is a great idea.  It would be great if you can do that for us.


Helge Hess <helge.hess@skyrix.com>
Sent by: owner-ietf-calendar@mail.imc.org

12/10/2003 11:45

To
John Stracke <jstracke@centive.com>
cc
ietf-calendar@imc.org
Subject
Re: "and so this is Christmas, and what have you done?"






On Dec 10, 2003, at 5:16 PM, John Stracke wrote:
> Personally, I don't think bugzilla is that hard to use, but then I've
> been using it since 1996.  :-) (It was an internal tool at Netscape,
> called bugsplat, before it was released with Mozilla.)

Bugzilla is an excellent tool to track/classify/search issues, manage
votes and do a "structured discussion".

> I'd be willing to take a crack at getting it set up, if the WG wants
> it.  Or...Damon, are you still here? Ximian already has a bugzilla
> system set up for Evolution, etc.; would you guys be willing to extend
> it for calsch? That might be more reliable than me hosting it on my
> home boxen.

If this is of interest, we could jump in and create a Bugzilla category
for calsch at the OpenGroupware.org Bugzilla:
  http://bugzilla.opengroupware.org/bugzilla/index.cgi

Let me know if you are interested in that.

best regards,
  Helge
--
OpenGroupware.org => http://www.opengroupware.org/
--=_alternative 00643EC285256DF8_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 10 13:35: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 NAA08464 for ; Wed, 10 Dec 2003 13:35:31 -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 hBAIMIib052807 for ; Wed, 10 Dec 2003 10:22: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 hBAIMIsS052806 for ietf-calendar-bks; Wed, 10 Dec 2003 10:22:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAIMGib052795 for ; Wed, 10 Dec 2003 10:22:16 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3FD653FD.5CD07609@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: DTSTART for recurrence instances MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Wed, 10 Dec 2003 13:22:15 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 12/10/2003 01:22:18 PM, Serialize complete at 12/10/2003 01:22:18 PM Content-Type: multipart/alternative; boundary="=_alternative 0064EA6E85256DF8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064EA6E85256DF8_= Content-Type: text/plain; charset="US-ASCII" In the interest of moving this along, can we get back to the matters at hand. If anyone is going to reply to the list, it should be with constructive opinions/ideas/thoughts and not personality attacks. That goes for everyone that participates on this list. Mark Smith Sent by: owner-ietf-calendar@mail.imc.org 12/09/2003 18:00 To ietf-calendar@imc.org cc Subject Re: DTSTART for recurrence instances Michael Fair wrote: He said 'master' introduces a new term. No it did not. It has nothing to do with clarity, it has to do with shooting from the hip yet again and backpedaling and not checking to see if he sent was accurate. > Mark, if you are going to waste our time beating up on Bruce, > correct him if you think he is lying. > > He asserted a definition and context for the term "master" for > the sake of creating clarity. If you disagree, then you have an > obligation (in the context of being productive) to explain your > understanding of said terms. Bruce may be lying (I happen to > agree with his side of this), but he is making an earnest effort > to create clarity. Please (hopefully starting with this last > email), if you think Bruce is lying to us, correct him so that > either you or he can adjust their views, or at worst at least > understand what each other is saying. > > -- Michael -- > --=_alternative 0064EA6E85256DF8_= Content-Type: text/html; charset="US-ASCII"
In the interest of moving this along, can we get back to the matters at hand.  If anyone is going to reply to the list, it should be with constructive opinions/ideas/thoughts and not personality attacks.  That goes for everyone that participates on this list.


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

12/09/2003 18:00

To
ietf-calendar@imc.org
cc
Subject
Re: DTSTART for recurrence instances






Michael Fair wrote:

He said 'master' introduces a new term. No it did not.

It has nothing to do with clarity, it has to do with shooting
from the hip yet again and backpedaling and not checking to
see if he sent was accurate.

> Mark, if you are going to waste our time beating up on Bruce,
> correct him if you think he is lying.
>
> He asserted a definition and context for the term "master" for
> the sake of creating clarity.  If you disagree, then you have an
> obligation (in the context of being productive) to explain your
> understanding of said terms.  Bruce may be lying (I happen to
> agree with his side of this), but he is making an earnest effort
> to create clarity.  Please (hopefully starting with this last
> email), if you think Bruce is lying to us, correct him so that
> either you or he can adjust their views, or at worst at least
> understand what each other is saying.
>
> -- Michael --
>
--=_alternative 0064EA6E85256DF8_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 10 13:41: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 NAA08759 for ; Wed, 10 Dec 2003 13:41: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 hBAIOmib052933 for ; Wed, 10 Dec 2003 10:24:48 -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 hBAIOmeZ052932 for ietf-calendar-bks; Wed, 10 Dec 2003 10:24:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAIOkib052921 for ; Wed, 10 Dec 2003 10:24:46 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: To: "Michael Fair" Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Restart DTSTART for recurrence instances thread MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Wed, 10 Dec 2003 13:24:46 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 12/10/2003 01:24:48 PM, Serialize complete at 12/10/2003 01:24:48 PM Content-Type: multipart/alternative; boundary="=_alternative 0065257B85256DF8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065257B85256DF8_= Content-Type: text/plain; charset="US-ASCII" If we have a good line of conversation going, I agree, let's keep it rolling. Anyone else want to reply? If we keep the number of notes to a minimum it may give people bandwidth to be able to reply. Also, try to change the subject line if you are stating something different. In trying to go back and build and issues list, i am missing things because they are in notes that have different subject lines. Thanks for helping on that. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "Michael Fair" Sent by: owner-ietf-calendar@mail.imc.org 12/09/2003 19:09 To ietf-calendar@imc.org cc Subject Re: DTSTART for recurrence instances I think someone should pick up this thread with Doug. This is the most productive line of conversation yet to create clarity around this. Some time ago Doug Royer started ignoring me. Will someone please reply to my post or Doug's directly to persue this? > BEGIN:VEVENT > UID:XXX > SEQUENCE:1 > ... > METHOD:REQUEST > DTSTART:2-dec-2003 at 2pm > DTEND:2-dec-2003 at 3:30pm > RECURRENCE-ID:2-dec-2003 at noon > .. > END:VEVENT > > Do you agree that is how to move a single instance? Yes I agree that would be the iTIP to send to move the 2nd instance from noon to 2pm. Now I believe the next step is to move it from 2pm to 4pm. (I moved the RECURRENCE-ID property to place it with the identifiers.) BEGIN:VEVENT METHOD:REQUEST UID:XXX RECURRENCE-ID:2-dec-2003 at noon SEQUENCE:2 ... DTSTART:2-dec-2003 at 4pm DTEND:2-dec-2003 at 5:30pm .. END:VEVENT The key being that Recurrence-id is "at noon" and not "at 2pm". Do you agree that is how to move a single instance a second time? -- Michael -- --=_alternative 0065257B85256DF8_= Content-Type: text/html; charset="US-ASCII"
If we have a good line of conversation going, I agree, let's keep it rolling.  Anyone else want to reply?  If we keep the number of notes to a minimum it may give people bandwidth to be able to reply.  Also, try to change the subject line if you are stating something different.  In trying to go back and build and issues list, i am missing things because they are in notes that have different subject lines.  Thanks for helping on that.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

12/09/2003 19:09

To
ietf-calendar@imc.org
cc
Subject
Re: DTSTART for recurrence instances






I think someone should pick up this thread with Doug.
This is the most productive line of conversation yet to
create clarity around this.  Some time ago Doug Royer
started ignoring me.  Will someone please reply to my post
or Doug's directly to persue this?


>     BEGIN:VEVENT
>     UID:XXX
>     SEQUENCE:1
>     ...
>     METHOD:REQUEST
>     DTSTART:2-dec-2003 at 2pm
>     DTEND:2-dec-2003 at 3:30pm
>     RECURRENCE-ID:2-dec-2003 at noon
>     ..
>     END:VEVENT
>
> Do you agree that is how to move a single instance?

Yes I agree that would be the iTIP to send to move the
2nd instance from noon to 2pm.

Now I believe the next step is to move it from 2pm to 4pm.
(I moved the RECURRENCE-ID property to place it with the identifiers.)

    BEGIN:VEVENT
    METHOD:REQUEST
    UID:XXX
    RECURRENCE-ID:2-dec-2003 at noon
    SEQUENCE:2
    ...
    DTSTART:2-dec-2003 at 4pm
    DTEND:2-dec-2003 at 5:30pm
    ..
    END:VEVENT

The key being that Recurrence-id is "at noon" and not "at 2pm".
Do you agree that is how to move a single instance a second time?

-- Michael --
--=_alternative 0065257B85256DF8_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 10 13:47:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09079 for ; Wed, 10 Dec 2003 13:47:17 -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 hBAIVJib053136 for ; Wed, 10 Dec 2003 10:31:19 -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 hBAIVJ0R053135 for ietf-calendar-bks; Wed, 10 Dec 2003 10:31:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAIVGib053130 for ; Wed, 10 Dec 2003 10:31:17 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AU97E-0007nK-00 for ; Wed, 10 Dec 2003 19:31:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AU97C-0007nC-00 for ; Wed, 10 Dec 2003 19:31:14 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AU97C-0006H2-00 for ; Wed, 10 Dec 2003 19:31:14 +0100 From: "Michael Fair" Subject: Re: RFC2445/RFC2446: SEQUENCE property Date: Wed, 10 Dec 2003 10:31:22 -0800 Lines: 79 Message-ID: References: <002f01c3b418$d0401020$2a01a8c0@persistent.co.in> <3FC4DDB3.7010809@Royer.com> X-Complaints-To: usenet@sea.gmane.org X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >Can recurrence instances of a vevent component have a > >larger(or different) SEQUENCE when the main vevent > >component (that describes the recurrence set) has a > >smaller SEQUENCE? Yes, they absolutely can. > If you have: > > VEVENT: UID:1, SEQUENCE:6 (NO RECURRENCE-ID) > > Then you get a: > > VEVENT: UID:1, SEQUENCE:7 (With a RECURENCE-ID) > > then you are being told that the new SEQUENCE number is 7 > and that exactly one instance has been updated with the details > in the new object. Now the main vevent is also at 7. No, this is not true. The main vevent is still at 6. UID:1/SEQ:6 is the set identifier and descriptor. Any Recurrence-ID generated from the set described by UID:1/SEQ:6 is an instance of UID:1. Any Recurrence-ID not described in that vevent is not an instance of UID:1. Rescheduling any of the instances described by UID:1/SEQ:6 has no impact on the set described by UID:1/SEQ:6. Put another way: The UID:1/SEQ:6 set of Recurrence-IDs are the RECURRENCE-IDs that _must_ be used when addressing individual instances. Any instance update/reschedule (aka with Recurrence-ID), _never_ impacts the SEQUENCE of the base vevent, it is not considered a rescheduling of the entire series. It is just an update to one of the instances described by the set from UID:1/SEQ:6. > >or > >Is SEQUENCE property for a vevent component > >different than the SEQUENCE property of an individual > >vevent recurrence instance? If they are different, how are > >they related? > > > >For example an instance update might change only the > >SEQUENCE of the instance, whereas the main vevent > >does not change. At no point in time will an instance sequence ever be less than the main vevent. If you receive a REQUEST message with UID:1 and no RECURRENCE-ID it has the effect of throwing away ALL prior instances and recreating every instance based on the new description. The SEQUENCE for all instances is the same as the message when the process is complete. If you receive an ADD message with UID:1 this will add all instances described by the message. AT the end of the process it will update the SEQUENCE for all prior instances because this is considered a rescheduling of the entire series. The main vevent will be updated and all instances will be updated to the SEQUENCE from the message. (In this case, the SEQUENCE chosen will be one higher than the largest instance SEQUENCE of the entire series (so 8 in the above snippet). If you received a SEQUENCE that was more than one higher than the largest instance SEQUENCE then you should request a refresh. The same is not true for a REQUEST message.) There, from my understanding, are questions about what impact cancelling an instance has on the entire series. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Dec 10 13:58:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09521 for ; Wed, 10 Dec 2003 13:58:32 -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 hBAIkMib053788 for ; Wed, 10 Dec 2003 10:46:22 -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 hBAIkMrC053787 for ietf-calendar-bks; Wed, 10 Dec 2003 10:46:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAIkLib053778 for ; Wed, 10 Dec 2003 10:46:21 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FD677F3.8090203@Royer.com> To: ietf-calendar@imc.org Subject: Re: DTSTART for recurrence instances MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 10 Dec 2003 13:39:02 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/10/2003 01:43:24 PM, Serialize complete at 12/10/2003 01:43:24 PM Content-Type: multipart/alternative; boundary="=_alternative 0066169085256DF8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066169085256DF8_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 12/09/2003 08:33:39 PM: > Is there any disagreement that these are -also- a valid ways to change > the 2nd instance: I disagree that the semantics of the examples included are NOT instance reschedules. Rather they all are a recreation of the set of instances in a recipients calendar. There is a semantic difference between a reschedule of a particluar instance and recreating the entire set of instances. The end result of your examples MAY result in the same but it may not be for various reasons including: 1: The state of the 1st and 3rd instances are negotiatble separately. So if there was ANYTHING done to them such as changing PARTSTAT (ie: the CU DECLINED it) then that information will be lost when the CU recreates the instance set using any of the included methods. 2: Given that workflow for instances can occur independently, using any of the alternate methods will result in all participation info being reset on ALL OTHER instances. For example, if instance 1 was uncontested by everyone and they all ACCEPTed before the Organzier sent any of the alternatives reschedules then the iTIP message would result in a higher SEQUENCE value for ALL instances, NOT just the second instance. This has 2 big drawbacks: A) Workflow already done for that instance MUST be redone all over again. That is, although instance 1 was not being rescheduled the invitee MUST reACCEPT the new version at a higher SEQUENCE value. B) This need to renegotiate applys to ALL other instances in the set potentially! Imagine trying to deal with this resetting of PARSTAT while rescheduling 2 separate instances, not just 1. Users would wind up reACCEPTing or reDECLINEing the same instance multiple times for apparent reason as _other_ instances are rescheduled instead of the one you ACCEPTed or DECLINEd. 3: The RECURRENCE-ID value for the new second instance is NOT the same as its original incarination. It is a new instance as seen by its different value. For example, Method A would create a second instance whose RECURRENCE-ID is 2-dec-2003 at 2pm (for those implementations that support ADD) and would destroy the original second instance whose RECURRENCE-ID was 2-dec-2003 at noon. This means that there is an effective disjoin because: A) For those implementations that do not support ADD, there is no longer a RECURRENCE-ID:2-dec-2003 at noon; only a 2 instance set for UID:XXX. This means their picture of the repeating set is different from the Organziers. This disjoin may not be readily visible in workflow messages so recovery is non-trivial at best. B) If one compares the per instance info the RECURRENCE-ID property for the second instance of the set will be different (assuming ADD was supported). In the original case, the RECURRENCE-ID stayed at 2-dec-2003 at noon but in the alternative cases all the RECURRENCE-IDs were changed to 2-dec-2003 at 2pm. Clearly this means the end results are NOT equivalent. > Method A: Now later ORGANIZER sends iTIP updates to move the second > instance > from noon->1pm and have it at 2pm->3:30pm: Again, technically speaking this example and the others that follow are NOT moving the second instance. It was recreating the set as 2 instances and then adding an instance in between to get back to 3 instances. That is not the same as moving an existing entry. > Do you agree that these are also valid objects to tell the ATTENDEE of > the single instance change? Again, they do not change the second instance but rather they remove it and create a new one. As show above, this does not always result in the equivalent data or view of the set by all parties. The end result may be a 3 instance repeat set on both sides but its not equivalent in that other instances are also impacted needlessly. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0066169085256DF8_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 12/09/2003 08:33:39 PM:
> Is there any disagreement that these are -also- a valid ways to change
> the 2nd instance:
I disagree that the semantics of the examples included are NOT instance reschedules.  Rather they all are a recreation of the set of instances in a recipients calendar.

There is a semantic difference between a reschedule of a particluar instance and recreating the entire set of instances.  

The end result of your examples MAY result in the same but it may not be for various reasons including:

1: The state of the 1st and 3rd instances are negotiatble separately.  So if there was ANYTHING done to them such as changing PARTSTAT (ie: the CU DECLINED it) then that information will be lost when the CU recreates the instance set using any of the included methods.

2: Given that workflow for instances can occur independently, using any of the alternate methods will result in all participation info being reset on ALL OTHER instances.  For example, if instance 1 was uncontested by everyone and they all ACCEPTed before the Organzier sent any of the alternatives reschedules then the iTIP message would result in a higher SEQUENCE value for ALL instances, NOT just the second instance.  This has 2 big drawbacks:

        A) Workflow already done for that instance MUST be redone all over again.  That is, although instance 1 was not being rescheduled the invitee MUST reACCEPT the new version at a higher SEQUENCE value.
        B) This need to renegotiate applys to ALL other instances in the set potentially!  Imagine trying to deal with this resetting of PARSTAT while rescheduling 2 separate instances, not just 1.  Users would wind up reACCEPTing or reDECLINEing the same instance multiple times for apparent reason as _other_ instances are rescheduled instead of the one you ACCEPTed or DECLINEd.

3: The RECURRENCE-ID value for the new second instance is NOT the same as its original incarination.  It is a new instance as seen by its different value.  For example, Method A would create a second instance whose RECURRENCE-ID is 2-dec-2003 at 2pm (for those implementations that support ADD) and would destroy the original second instance whose RECURRENCE-ID was 2-dec-2003 at noon.  This means that there is an effective disjoin because:

        A) For those implementations that do not support ADD, there is no longer a RECURRENCE-ID:2-dec-2003 at noon; only a 2 instance set for UID:XXX.  This means their picture of the repeating set is different from the Organziers.  This disjoin may not be readily visible in workflow messages so recovery is non-trivial at best.

        B) If one compares the per instance info the RECURRENCE-ID property for the second instance of the set will be different (assuming ADD was supported).  In the original case, the RECURRENCE-ID stayed at 2-dec-2003 at noon but in the alternative cases all the RECURRENCE-IDs were changed to 2-dec-2003 at 2pm.  Clearly this means the end results are NOT equivalent.

> Method A:  Now later ORGANIZER sends iTIP updates to move the second
> instance
>  from  noon->1pm  and have it at 2pm->3:30pm:
Again, technically speaking this example and the others that follow are NOT moving the second instance.  It was recreating the set as 2 instances and then adding an instance in between to get back to 3 instances.  That is not the same as moving an existing entry.

> Do you agree that these are also valid objects to tell the ATTENDEE of
> the single instance change?
Again, they do not change the second instance but rather they remove it and create a new one.  As show above, this does not always result in the equivalent data or view of the set by all parties.  The end result may be a 3 instance repeat set on both sides but its not equivalent in that other instances are also impacted needlessly.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0066169085256DF8_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 10 14:12: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 OAA10667 for ; Wed, 10 Dec 2003 14:12: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 hBAIwvib054292 for ; Wed, 10 Dec 2003 10:58:57 -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 hBAIwvLl054291 for ietf-calendar-bks; Wed, 10 Dec 2003 10:58:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAIwtib054284 for ; Wed, 10 Dec 2003 10:58:55 -0800 (PST) (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 hBAIwqYu027120 for ; Wed, 10 Dec 2003 11:58:52 -0700 (MST) Message-ID: <3FD76CEC.453498D6@INET-Calendar.net> Date: Wed, 10 Dec 2003 11:58:52 -0700 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: DTSTART for recurrence instances 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 pregen@egenconsulting.com wrote: > > In the interest of moving this along, can we get back to the matters > at hand. If anyone is going to reply to the list, it should be with > constructive opinions/ideas/thoughts and not personality attacks. > That goes for everyone that participates on this list. I have said this on this list before and I will say it again, this time to Bob. Could you add a rule something like: Please read the drafts before posting and make sure that what you are about to say is true before posting. Some people make what seems to many to be an authoritative statement and after reading the RFC's or submitted drafts, they seem to have ignored specific parts of the text or declare it as (not valid). So such topics need to be tagged as 'iCal-next', 'itip-next' or whatever so they do not get confused with a discussion about what has actually been submitted. And can there be some sort of suspension from the list when someone repeatedly posts incorrect information to this list? I for one am getting REAL tired of having to re-read the specs only to find out that almost verbatim text exists in submitted text when others say no such topic or item exists. From owner-ietf-calendar@mail.imc.org Wed Dec 10 14:18: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 OAA10887 for ; Wed, 10 Dec 2003 14:18:15 -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 hBAIdEib053437 for ; Wed, 10 Dec 2003 10:39:14 -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 hBAIdDPV053436 for ietf-calendar-bks; Wed, 10 Dec 2003 10:39:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAIdCib053421 for ; Wed, 10 Dec 2003 10:39:13 -0800 (PST) (envelope-from helge.hess@skyrix.com) Received: from [213.187.86.104] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 700F32156B8; Wed, 10 Dec 2003 19:35:55 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <22F5CB4B-2B40-11D8-8033-000393C29C2A@skyrix.com> Cc: John Stracke , owner-ietf-calendar@mail.imc.org, ietf-calendar@imc.org From: Helge Hess Subject: Re: "and so this is Christmas, and what have you done?" Date: Wed, 10 Dec 2003 19:39:07 +0100 To: pregen@egenconsulting.com X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBAIdDib053427 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On 10.12.2003, at 19:14, pregen@egenconsulting.com wrote: > Helge, this is a great idea.  It would be great if you can do that for > us. No problem, I've just created: - a CALSCH product, which is the entry point for the group - a component (read: topic/category) "general" for general issues - a user "ietf-calendar@imc.org" which is set as the initial owner for "general" issues (receives mail on each issue) So feel free to create an own account in Bugzilla for posting new issues. There are two forms, an easy one: http://bugzilla.opengroupware.org/bugzilla/easy_enter_bug.cgi and a "poweruser" one: http://bugzilla.opengroupware.org/bugzilla/enter_bug.cgi?product=CALSCH Now we need to decide what additional "components" (discussion topics) we need - eg iMIP, CAP, Interoperability, ... - so that issues can be properly classified. Let me know if you need anything else. best regards, Helge > > Helge Hess > Sent by: owner-ietf-calendar@mail.imc.org > Bugzilla is an excellent tool to track/classify/search issues, manage > votes and do a "structured discussion". > > If this is of interest, we could jump in and create a Bugzilla category > for calsch at the OpenGroupware.org Bugzilla: >   http://bugzilla.opengroupware.org/bugzilla/index.cgi -- OpenGroupware.org http://www.opengroupware.org/ From owner-ietf-calendar@mail.imc.org Wed Dec 10 15:32:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14869 for ; Wed, 10 Dec 2003 15:32:06 -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 hBAKFSib057491 for ; Wed, 10 Dec 2003 12:15:28 -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 hBAKFSa2057490 for ietf-calendar-bks; Wed, 10 Dec 2003 12:15:28 -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 hBAKFOib057481 for ; Wed, 10 Dec 2003 12:15:24 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:wwqJ7MRwFC2k+6cUD686j6UfSPvNG0xj@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBAKFIZf014853 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 10 Dec 2003 12:15:20 -0800 Message-ID: <3FD77ED5.3040105@Royer.com> Date: Wed, 10 Dec 2003 13:15:17 -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: DTSTART for recurrence instances References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> In-Reply-To: <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010501050307040704020104" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010501050307040704020104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit PLEASE - if you want to talk about the other RECURRENCE-ID issue - change the subject line. How you derive RECURRENCE-ID from a given object with EXPAND:TRUE and how it effects DTSTART is NOT the same as if (or not) RECURRENCE-ID changes after a reschedule. Please read all of this as there are some interdependencies with text after statements. Olivier Gutknecht wrote: > > Method C: ok too > - CANCEL to remove the instance identified by UID + recurrence-ID > 2-dec-noon > - then a ADD to put another instance at 2-dec-2003 2pm > And in all cases (A,B,C,D), SEQUENCE for all instances is 2. > I also agree with Michael's comments that we end with a calendar where > we have 1-dec noon->1pm, 2-dec 2pm->3:30pm, 3-dec noon->1pm and I'm > not sure I can consider every method as a 'reschedule'. In the first email the sequence is '1', and in (A, B, C) the sequence is '2'. (D?). And although they are -all- -not- really a 'reschedule' they all four represent ways the CU could change the 2nd instance. Now assume that 'A' or 'B' as sent previously to this list was sent to ATTENDEE:attendee-2 as attendee-2's initial REQUEST to attendee this meeting. Except 'ATTENDEE:attendee-2' in place of (or in addition to) ATTENDEE:attendee. And attendee-2 said yes. The CS of the attendee-2 (I am NOT talking about the organizer or attendee-1) has in the attendee-2's CS (I am NOT talking about the CUAs) BEGIN:VEVENT ... (no METHOD as it is booked) ... UID:XXX ... SEQUENCE:2 ... ATTENDEE:attendee-2 ... DTSTART: 1-dec-2003 at noon DTEND: 1-dec-2003 at 1pm ... RRULE:FREQ=DAILY;COUNT=3 EXDATE:2-dec-2003 at noon ... (plus the following start/stop time however it may be represented in the 'attendee-2' CS) ... DTSTART:2-dec-2003 at 2pm DTEND:2-dec-2003 at 3:30pm ... END:VEVENT END:VCALENDAR Assume this is the ONLY UID for all of the organizer, original attendee, and attendee-2 in their CS's (not CUAs). On -4-dec-2003, I said, and you replied on 5-dec for to the ORIGINAL object (Not A, B, or C as they has not been sent yet) to attendee (not attendee-2)' and you agreed. >> Yes RECURRENCE-ID is the effective DTSTART of the 'instance'. If you have 3 >> daily instances the effective DTSTART of the 1st is 4-DEC, 2nd 5-DEC, and >> the 3rd 6-DEC. So the value of recurrence ids are: >> >> 1st >> RECURRENCE-ID: 4-DEC >> >> 2nd >> RECURRENCE-ID:5-DEC >> >>3rd >> RECURRENCE-ID:6-DEC > > Agreed. At this point both 'attendee' and 'attendee-2' have the same pattern of instances. The ORGANIZER (master copy) of UID:XXX is at SEQUENCE:2. So my questions to any and all using your understanding of how they are generated. What are the RECURRENCE-ID's and DTSTARTs for 'attendee-2'? That is attendee-2 does an EXPAND:TRUE fetch. (Got one object == SEQUENCE:2) What are the RECURRENCE-ID's and DTSTARTs for 'attendee' (not-2) after getting the 1st (not A, B, or C) objects? (Got original[SEQUENCE:0] + instance update[SEQUENCE:1], 'attendee' at SEQUENCE:1) What are the RECURRENCE-ID's and DTSTARTs for 'attendee' after getting A, B, or C (not the first reschedule)? (Got original [SEQUENCE:0], + 2 sequence updates, 'attendee' now at SEQUENCE:2). What are the RECURRENCE-ID's and DTSTARTs for the ORGANIZER? (master copy now at SEQUENCE:2). As I understand the process that some on this list believe to be true, the answers will not be the same for some of; ORGANIZER, both ATTENDEE's, or for all 4 update methods. And that is busted as no ORGANIZER CUA could figure them out if they -later- send single instance reschedule (As sent in the 1st email) to the same UID. As the ORGANZER's CUA would have to contact each ATTENDEEs CS to figure out what that ATTENDEE's CS thought the RECURRECE-ID's were or do some vendor specific CAP I/O to look at a log of what was sent to each attendee which may not work with the next CUA looking at the same UID. Attendee-2 will not have any history of the object at this point only has SEQUENCE:2 invite. Which is why I say for any UID/SEQUENCE the RECURRENCE-ID's must be derived from the object it self without any knowledge of history - or of the previous methods. And as the ORGANIZER is the owner of a UID, then the owners object is the 'master' copy. The answers have to be all 2-dec-2003 at noon, 3-dec-2003-at 2pm, and 4-dec-2003 at noon for RECURENCE-ID's and the DTSTARTs are the one in the master object. If you disagree: - And if all of your answers to the above questions are the same: Say so and start a NEW thread (new subject line) on how and why. - And if all of your answers to the above questions are not the same: Start a new thread (new subject line) and please step this WG through the process you use to later send a single instance update to all attendees. And we can start a thread (new subject line) on how you got your answers. Only when everything is documented step by stem in writing can we solve this. -- 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 --------------ms010501050307040704020104 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 9w0BCQUxDxcNMDMxMjEwMjAxNTE3WjAjBgkqhkiG9w0BCQQxFgQU2vOiPu/AEu+1Sb6pGzbt JOwSFjowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAnBECJhPf9n+axcXlNrvj/+L5xGzJXwxxjj7QRBEo6ypgeShlFzeC5XqES5leXJq5 rgfzM0Kxs1VLNAXLsHtTvpk9VZRntth8uq5QXxjETO+sbL6ZOOrEBwK90NbpXv6845kX6Esy BUaHl9WflEEghmq4NAAjZx01TKteuwMi7dd8upX3vCiRnjSEkT3WlzbU98h3qivnxrwTjAJ+ 1YaSnmiCr5o4FFRU1jD9fM6eSXAxSMb6caIP4XmijJJ3QN3PMxachR7i0HlY9l4aQh+jJt+F 35csq8YCESTVn/zIf5tlrYQltUt2lhZ+hzvv9sxYPt8pyTHaclWGTgFVmbQPugAAAAAAAA== --------------ms010501050307040704020104-- From owner-ietf-calendar@mail.imc.org Wed Dec 10 15:56: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 PAA16816 for ; Wed, 10 Dec 2003 15:56:01 -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 hBAKkVib059030 for ; Wed, 10 Dec 2003 12:46:33 -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 hBAKkVYs059029 for ietf-calendar-bks; Wed, 10 Dec 2003 12:46:31 -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 hBAKkUib059024 for ; Wed, 10 Dec 2003 12:46:30 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:jq7yMi6yrbCkRzp2mtCUoYD9YaRaz1gV@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBAKkSZf015345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 10 Dec 2003 12:46:29 -0800 Message-ID: <3FD78623.7080402@Royer.com> Date: Wed, 10 Dec 2003 13:46:27 -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: "and so this is Christmas, and what have you done?" References: <22F5CB4B-2B40-11D8-8033-000393C29C2A@skyrix.com> In-Reply-To: <22F5CB4B-2B40-11D8-8033-000393C29C2A@skyrix.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070408040902000104040706" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070408040902000104040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have closed the one at http://INET-Consulting.com/bugzilla . Old records still viewable. Helge Hess wrote: > > On 10.12.2003, at 19:14, pregen@egenconsulting.com wrote: > >> Helge, this is a great idea. It would be great if you can do that >> for us. > > > No problem, I've just created: > - a CALSCH product, which is the entry point for the group > - a component (read: topic/category) "general" for general issues > - a user "ietf-calendar@imc.org" which is set as the initial owner > for "general" issues (receives mail on each issue) > > So feel free to create an own account in Bugzilla for posting new > issues. There are two forms, an easy one: > http://bugzilla.opengroupware.org/bugzilla/easy_enter_bug.cgi > and a "poweruser" one: > http://bugzilla.opengroupware.org/bugzilla/enter_bug.cgi?product=CALSCH > > Now we need to decide what additional "components" (discussion topics) > we need - eg iMIP, CAP, Interoperability, ... - so that issues can be > properly classified. > > Let me know if you need anything else. > > best regards, > Helge > >> >> Helge Hess >> Sent by: owner-ietf-calendar@mail.imc.org > > >> Bugzilla is an excellent tool to track/classify/search issues, manage >> votes and do a "structured discussion". >> >> If this is of interest, we could jump in and create a Bugzilla category >> for calsch at the OpenGroupware.org Bugzilla: >> http://bugzilla.opengroupware.org/bugzilla/index.cgi > -- 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 --------------ms070408040902000104040706 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 9w0BCQUxDxcNMDMxMjEwMjA0NjI3WjAjBgkqhkiG9w0BCQQxFgQUFNNVMIADI58Gjt6OwJMy 1RZbovQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAN504xqN+yz4ZTPuO7N6mMiNsCHqZiQE8TtbHJUr7o4R90mHS57zjUd2jeYzJsvL9 aFxLHgvVZYzWgIoSpyjIBsLyP2rxlaZIrSSluXvmSXFFKTPPKQGavNgrcEbWRllLsp0w2Awe 6OeA5iDt7fZG+1hQ4eIIkB3j+DKnwnp9StsTmzTReSUKneXWQDJLHDKExWK7ba30wFHC+8oB /IuLxl8Sc64YGneZRAelxGNhc/qrkuM+4XnPLW8hwvEU0Lj7dy/LvoDf1LRIDcpImBNGFS29 C+uwqa39KSVXSiHPsoJuLwBWYKLTcwhHU0zZ7rFPt2bOFyPTV6mit9YQrTmT0wAAAAAAAA== --------------ms070408040902000104040706-- From owner-ietf-calendar@mail.imc.org Wed Dec 10 15:56: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 PAA16832 for ; Wed, 10 Dec 2003 15:56:06 -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 hBAKj5ib058995 for ; Wed, 10 Dec 2003 12:45:05 -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 hBAKj5n1058994 for ietf-calendar-bks; Wed, 10 Dec 2003 12:45:05 -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 hBAKj3ib058989 for ; Wed, 10 Dec 2003 12:45:03 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:vc4TkGYQ5/lS7l0sy/c93Hv9zZrtfX7E@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBAKihZf015307 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 10 Dec 2003 12:44:44 -0800 Message-ID: <3FD785BA.8090300@Royer.com> Date: Wed, 10 Dec 2003 13:44:42 -0700 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: John Stracke CC: ietf-calendar@imc.org Subject: Re: "and so this is Christmas, and what have you done?" References: <3FD746C7.1020106@centive.com> In-Reply-To: <3FD746C7.1020106@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020402000900090909060701" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020402000900090909060701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Bruce_Kahn@notesdev.ibm.com wrote: > >> Instead of taking the time to learn bugzilla, why not just adopt a >> textual posting format similar to this one for now? > > > The periodic posting approach seems to have a tendency to bitrot, > because it requires diligence from the person who updates it. Not only that, I stopped it because people kept wanting it to be more and more of a history and not an issues list. Some wanted the old history so they new not to re-open issues. Others got tired of look at the old issues and only wanted open issues. Bugzilla is great for issues and issue history. And for those that do not want to look at it, they do not have to see anyting. Should there be a monthly post to this list saying ...go...here ... for issue list? Else it may be a FAQ. -- 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 --------------ms020402000900090909060701 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 9w0BCQUxDxcNMDMxMjEwMjA0NDQyWjAjBgkqhkiG9w0BCQQxFgQU1NHV7oKNriQ43ha6bDX3 0+WFHVUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAXGvR8T8ZB1VPzMbiWBqLFhJSUeJK1frk9MeubxTCyxcZK+CkQxBtZhrc+By3IEWg kjzthJWAxULAfNf4QE4V27rlLTalAc1iP+1qLbrrsRQABgS2+xYvsVJx/4mxTSsuZ8Orw2Ui MoqQn3MvNi1SMV5hXHRq/RUKwEbCrdxa2+5hhcIhdQ13yy9EVSSN4Vj2fxKMGPkQ5aBjePab 0s02s0reiTenuomLAoLFJifYlkaUMYvc5FMARAl7yzwXxvL0DJhetnVzFluKp5clWAc7h0Nh RN+ugpFSEvMPllTOJWsOEq3O36EEUv2/W0WasGCLNPl/NQSQqzgmybtBWPZzVQAAAAAAAA== --------------ms020402000900090909060701-- From owner-ietf-calendar@mail.imc.org Wed Dec 10 16:16:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18896 for ; Wed, 10 Dec 2003 16:16:57 -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 hBAL5cib060190 for ; Wed, 10 Dec 2003 13:05:40 -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 hBAL5cm4060189 for ietf-calendar-bks; Wed, 10 Dec 2003 13:05:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAL5aib060182 for ; Wed, 10 Dec 2003 13:05:36 -0800 (PST) (envelope-from lennox@cs.columbia.edu) Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hBAL5biF002800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 10 Dec 2003 16:05:37 -0500 (EST) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.12.9p1/8.12.9) with ESMTP id hBAL5aMT002275 for ; Wed, 10 Dec 2003 16:05:37 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.12.9p1/8.12.9/Submit) id hBAL5Q2t002253; Wed, 10 Dec 2003 16:05:26 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16343.35478.416120.817876@cnr.cs.columbia.edu> Date: Wed, 10 Dec 2003 16:05:26 -0500 To: "ietf-calendar@imc.org" Subject: Re: "and so this is Christmas, and what have you done?" In-Reply-To: <3FD78623.7080402@Royer.com> References: <22F5CB4B-2B40-11D8-8033-000393C29C2A@skyrix.com> <3FD78623.7080402@Royer.com> X-Mailer: VM 7.17 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, December 10 2003, "Doug Royer" wrote to "ietf-calendar@imc.org" saying: > > I have closed the one at http://INET-Consulting.com/bugzilla . > Old records still viewable. Should old calsch-related bugs be migrated over to the new Bugzilla? > Helge Hess wrote: > > > > > On 10.12.2003, at 19:14, pregen@egenconsulting.com wrote: > > > >> Helge, this is a great idea. It would be great if you can do that > >> for us. > > > > > > No problem, I've just created: > > - a CALSCH product, which is the entry point for the group > > - a component (read: topic/category) "general" for general issues > > - a user "ietf-calendar@imc.org" which is set as the initial owner > > for "general" issues (receives mail on each issue) > > > > So feel free to create an own account in Bugzilla for posting new > > issues. There are two forms, an easy one: > > http://bugzilla.opengroupware.org/bugzilla/easy_enter_bug.cgi > > and a "poweruser" one: > > http://bugzilla.opengroupware.org/bugzilla/enter_bug.cgi?product=CALSCH > > > > Now we need to decide what additional "components" (discussion topics) > > we need - eg iMIP, CAP, Interoperability, ... - so that issues can be > > properly classified. > > > > Let me know if you need anything else. > > > > best regards, > > Helge > > > >> > >> Helge Hess > >> Sent by: owner-ietf-calendar@mail.imc.org > > > > > >> Bugzilla is an excellent tool to track/classify/search issues, manage > >> votes and do a "structured discussion". > >> > >> If this is of interest, we could jump in and create a Bugzilla category > >> for calsch at the OpenGroupware.org Bugzilla: > >> http://bugzilla.opengroupware.org/bugzilla/index.cgi > > > > -- > > 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 Thu Dec 11 12:37:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11518 for ; Thu, 11 Dec 2003 12:37:08 -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 hBBHFuib085515 for ; Thu, 11 Dec 2003 09:15:56 -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 hBBHFu7J085514 for ietf-calendar-bks; Thu, 11 Dec 2003 09:15:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBHFuib085508 for ; Thu, 11 Dec 2003 09:15:56 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <22F5CB4B-2B40-11D8-8033-000393C29C2A@skyrix.com> To: ietf-calendar@imc.org Subject: Re: "and so this is Christmas, and what have you done?" MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 11 Dec 2003 12:14:41 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/11/2003 12:12:59 PM, Serialize complete at 12/11/2003 12:12:59 PM Content-Type: multipart/alternative; boundary="=_alternative 005E579E85256DF9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E579E85256DF9_= Content-Type: text/plain; charset="US-ASCII" Helge wrote on 12/10/2003 01:39:07 PM: > Let me know if you need anything else. I for one have not really used bugzilla before (I tried using the older one found it less than intuitive so I gave up). Is there a QuickRef or Cheat Sheet to get use non-bugzilla users up to speed on using 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 005E579E85256DF9_= Content-Type: text/html; charset="US-ASCII"
Helge wrote on 12/10/2003 01:39:07 PM:
> Let me know if you need anything else.
I for one have not really used bugzilla before (I tried using the older one found it less than intuitive so I gave up).  Is there a QuickRef or Cheat Sheet to get use non-bugzilla users up to speed on using 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 005E579E85256DF9_=-- From owner-ietf-calendar@mail.imc.org Thu Dec 11 13:16:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12603 for ; Thu, 11 Dec 2003 13:16:56 -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 hBBI5oib087546 for ; Thu, 11 Dec 2003 10:05:50 -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 hBBI5ouE087544 for ietf-calendar-bks; Thu, 11 Dec 2003 10:05:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBBI5mib087529 for ; Thu, 11 Dec 2003 10:05:48 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003121113221825618 for ; Thu, 11 Dec 2003 13:22:20 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Dec 2003 13:02:47 -0500 Message-ID: <3FD8B147.5060802@centive.com> Date: Thu, 11 Dec 2003 13:02:47 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: "and so this is Christmas, and what have you done?" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2003 18:02:47.0449 (UTC) FILETIME=[FBE34090:01C3C010] 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: > Is there a QuickRef or Cheat Sheet to get use non-bugzilla users up to > speed on using it? http://www.bugzilla.org/docs216/html/using.html -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"I lost an 7-foot boa constrictor once in our house." --Gary| |Larson on his youth | \============================================================/ From owner-ietf-calendar@mail.imc.org Thu Dec 11 13:17:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12627 for ; Thu, 11 Dec 2003 13:17:17 -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 hBBI5Wib087526 for ; Thu, 11 Dec 2003 10:05: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 hBBI5WZ0087525 for ietf-calendar-bks; Thu, 11 Dec 2003 10:05:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBI5Wib087518 for ; Thu, 11 Dec 2003 10:05:32 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FD77ED5.3040105@Royer.com> To: ietf-calendar@imc.org Subject: RECURRENCE-ID / instance reschedule (Was Re: DTSTART for recurrence instances) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 11 Dec 2003 13:05:24 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/11/2003 01:02:35 PM, Serialize complete at 12/11/2003 01:02:35 PM Content-Type: multipart/alternative; boundary="=_alternative 0062FC6385256DF9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0062FC6385256DF9_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 12/10/2003 03:15:17 PM: > PLEASE - if you want to talk about the other RECURRENCE-ID issue - change > the subject line. How you derive RECURRENCE-ID from a given object with > EXPAND:TRUE and how it effects DTSTART is NOT the same as > if (or not) RECURRENCE-ID changes after a reschedule. It was already hammered at ad naseum and confirmed by the RFC authors that RECURRENCE-ID does not change on an instance reschedule. Please see http://www.imc.org/ietf-calendar/mail-archive/msg08662.html for confirmation of this. As such, can we please NOT even go down any discussion path that tries to reintroduce the concept of RECURRENCE-ID changing on a reschedule?!? The RECURRENCE-ID value should be the the DTSTART that the instance was originally created at as described in iCalendar Section 4.8.4.4: The date/time value is set to the time when the original recurrence instance would occur; meaning that if the intent is to change a Friday meeting to Thursday, the date/time is still set to the original Friday meeting. The use of EXPAND should be orthogonal to the discussion of calculating any instances RECURRENCE-ID. EXPAND is currently defined in CAP-12-e 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 it is defined as a way for the CUA to tell the CS how to handle bundling results to return. It should have no bearing on the actual instance properties themselves. The EXPAND property does not impact how the CS calculates the RECURRENCE-ID of any particular instance; that is already defined by 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 0062FC6385256DF9_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 12/10/2003 03:15:17 PM:
> PLEASE - if you want to talk about the other RECURRENCE-ID issue - change
> the subject line. How you derive RECURRENCE-ID from a given object with
> EXPAND:TRUE and how it effects DTSTART is NOT the same as
> if (or not) RECURRENCE-ID changes after a reschedule.
It was already hammered at ad naseum and confirmed by the RFC authors that RECURRENCE-ID does not change on an instance reschedule.  Please see http://www.imc.org/ietf-calendar/mail-archive/msg08662.html for confirmation of this.  

As such, can we please NOT even go down any discussion path that tries to reintroduce the concept of RECURRENCE-ID changing on a reschedule?!?

The RECURRENCE-ID value should be the the DTSTART that the instance was originally created at as described in iCalendar Section 4.8.4.4:

   The date/time value is set to the time when the original recurrence
  instance would occur; meaning that if the intent is to change a
  Friday meeting to Thursday, the date/time is still set to the
  original Friday meeting.

The use of EXPAND should be orthogonal to the discussion of calculating any instances RECURRENCE-ID.  EXPAND is currently defined in CAP-12-e 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 it is defined as a way for the CUA to tell the CS how to handle bundling results to return.  It should have no bearing on the actual instance properties themselves.  The EXPAND property  does not impact how the CS calculates the RECURRENCE-ID of any particular instance; that is already defined by 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 0062FC6385256DF9_=-- From owner-ietf-calendar@mail.imc.org Thu Dec 11 14:37:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16633 for ; Thu, 11 Dec 2003 14:37:10 -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 hBBJCsib090135 for ; Thu, 11 Dec 2003 11:12:54 -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 hBBJCsWL090134 for ietf-calendar-bks; Thu, 11 Dec 2003 11:12:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBJCrib090107 for ; Thu, 11 Dec 2003 11:12:54 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12-e: 6.1.1.15 Query by Date-Time range MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 11 Dec 2003 13:57:58 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/11/2003 02:09:57 PM, Serialize complete at 12/11/2003 02:09:57 PM Content-Type: multipart/alternative; boundary="=_alternative 0069265985256DF9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069265985256DF9_= Content-Type: text/plain; charset="US-ASCII" In revistiing some sections of CAP 12-e for snippets for other postings I ran across what appears to be an incorrect example for the section. Section 6.1.1.15 Query by Date-Time range should have an example for getting "every booked "VEVENT" component that has an instance greater than or equal to July 1st, 2000 00:00:00 UTC and less than or equal to July 30st, 2000 23:59:59 UTC." However the query is using RECURRENCE-ID which is an instance identifier and NOT the acutal entry occuring in that time range. I believe the correct example should be: BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE DTSTART >= '20000701T000000Z' AND DTEND <= '20000730T235959Z' AND STATE() = 'BOOKED' END:VQUERY Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0069265985256DF9_= Content-Type: text/html; charset="US-ASCII"
In revistiing some sections of CAP 12-e for snippets for other postings I ran across what appears to be an incorrect example for the section.  Section 6.1.1.15 Query by Date-Time range should have an example for getting "every booked "VEVENT" component that has an instance greater than or equal to July 1st, 2000 00:00:00 UTC and less than or equal to July 30st, 2000 23:59:59 UTC."

However the query is using RECURRENCE-ID which is an instance identifier and NOT the acutal entry occuring in that time range.  I believe the correct example should be:

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

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0069265985256DF9_=-- From owner-ietf-calendar@mail.imc.org Thu Dec 11 14:40:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16715 for ; Thu, 11 Dec 2003 14:40:06 -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 hBBJOEib090675 for ; Thu, 11 Dec 2003 11:24:14 -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 hBBJOEms090674 for ietf-calendar-bks; Thu, 11 Dec 2003 11:24:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBJODib090662 for ; Thu, 11 Dec 2003 11:24:13 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FD77ED5.3040105@Royer.com> To: ietf-calendar@imc.org Subject: Why discuss non-alternatives? (Was Re: DTSTART for recurrence instances) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 11 Dec 2003 13:33:27 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/11/2003 02:21:17 PM, Serialize complete at 12/11/2003 02:21:17 PM Content-Type: multipart/alternative; boundary="=_alternative 00658D9F85256DF9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00658D9F85256DF9_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 12/10/2003 03:15:17 PM: > Please read all of this as there are some interdependencies with > text after statements. I will soon be out of touch for a few weeks on vacation so I may not be able to continue this discussion until I get back. Fore warning in case it appears as if I just disappeared (my silence is not acceptance, merely my inability to participate while traveling) > And although they are -all- -not- really a 'reschedule' they all four > represent ways the CU could change the 2nd instance. Actually they all represent ways for an Organizer to recreate a 3 instance repeat set. Since there is a fundamental difference between a simple instance reschedule (iTIP Section 3.2.2.1 Rescheduling an Event) and recreating all instances in the repeat set (see the analysis from yesterday), why are we even considering these "alternatives"? If the intent of this discussion is how to determine how RECURRENCE-IDs are assigned in the CS then thats simple to answer (see iCalendar). If the intent of this discussion is to understand how invitation/rescheduling of a repeating instance happens then thats also simple to answer (see iTIP). However it seems that the intent is to discuss alternative means of trying to represent an instance reschedule (which are not truely equivalent) for reasons that I just dont grok. Why do we spend cycles discussing different means of recreating the entire repeating set (as opposed to actually rescheduling the just that instance) which have no direct bearing on how the EXPAND property is handled on a query? > Only when everything is documented step by stem in writing can we solve > this. What steps of the C&S workflow process are not already documented in iTIP? Also, I am having a hard time understanding how any of this digression relates to handling EXPAND on a query. Am I the only one? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... --=_alternative 00658D9F85256DF9_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 12/10/2003 03:15:17 PM:
> Please read all of this as there are some interdependencies with
> text after statements.
I will soon be out of touch for a few weeks on vacation so I may not be able to continue this discussion until I get back.  Fore warning in case it appears as if I just disappeared (my silence is not acceptance, merely my inability to participate while traveling)

> And although they are -all-  -not- really a 'reschedule' they all four
> represent ways the CU could change the 2nd instance.
Actually they all represent ways for an Organizer to recreate a 3 instance repeat set.  Since there is a fundamental difference between a simple instance reschedule (iTIP Section 3.2.2.1 Rescheduling an Event) and recreating all instances in the repeat set (see the analysis from yesterday), why are we even considering these "alternatives"?  

If the intent of this discussion is how to determine how RECURRENCE-IDs are assigned in the CS then thats simple to answer (see iCalendar).  

If the intent of this discussion is to understand how invitation/rescheduling of a repeating instance happens then thats also simple to answer (see iTIP).  

However it seems that the intent is to discuss alternative means of trying to represent an instance reschedule (which are not truely equivalent) for reasons that I just dont grok.

Why do we spend cycles discussing different means of recreating the entire repeating set (as opposed to actually rescheduling the just that instance) which have no direct bearing on how the EXPAND property is handled on a query?

> Only when everything is documented step by stem in writing can we solve
> this.
What steps of the C&S workflow process are not already documented in iTIP?  

Also, I am having a hard time understanding how any of this digression relates to handling EXPAND on a query.  Am I the only one?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX... --=_alternative 00658D9F85256DF9_=-- From owner-ietf-calendar@mail.imc.org Thu Dec 11 15:12:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19053 for ; Thu, 11 Dec 2003 15:12:16 -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 hBBJuGib091726 for ; Thu, 11 Dec 2003 11:56:16 -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 hBBJuFuc091725 for ietf-calendar-bks; Thu, 11 Dec 2003 11:56:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBJuFib091713 for ; Thu, 11 Dec 2003 11:56:15 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: The intent/meaning of EXPAND and its usefullness MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 11 Dec 2003 14:51:29 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/11/2003 02:53:18 PM, Serialize complete at 12/11/2003 02:53:18 PM Content-Type: multipart/alternative; boundary="=_alternative 006CB2A285256DF9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CB2A285256DF9_= Content-Type: text/plain; charset="US-ASCII" Ok, I know Im going to be out of touch soon but I wanted to ask in the interest of getting some WG discussion to resolve my confusion. A while back I asked a question about the usefulness of EXPAND at all (Subject "EXPAND property: All instances?" back on 31-Oct-2003). There was no technical discussion of it so Ill try again given the recent other thread on DTSTART/RECURRENCE-ID/EXPAND. In CAP-12-e is defined: 8.16 EXPAND property Property Name: EXPAND 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. [Snip, snip] 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. and in Section 6.1.1.15 Query by Date-Time range is also written: This works only for CSs that have the "RECUR-EXPAND" property value set to "TRUE" in the "GET-CAPABILITY" exchange. So, my take on this is: 1: If a CS does not support expanding recurrence rules then it would send RECUR-EXPAND:FALSE when asked. 2: If RECUR-EXPAND is FALSE then: A) EXPAND on a QUERY is ignored and B) a CUA will be unable to query for entries using a date-time range (even if its not repeating ) This raises some questions which Id like to get some WG concensus on (and perhaps clarification in CAP too). These include: 1: If a CS does not support recurrence rules then why would that preclude the use of RDATEs? The CS does not have to evaluate any rules to correctly roll out the repeating set. 2: Why does the lack of recurrence rule support in the CS preclude dong date-time range searches for non-repeating entries ("Give me all the VEVENTs for tomorrow") or for those specified in RDATEs? Date-time range searching is something nearly all CS need to have in order to function well at all. Otherwise its usability would be somewhat questionable. 3: What real use is the EXPAND property in actual practice? This question has 2 parts behind it: 3A: The 1st line of the Description says to set EXPAND:TRUE if the CUA wants all instances of a recurring component. Why not just use a simple QUERY like: BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' AND STATE() = 'BOOKED' END:VQUERY which should cause the CS to return all instances of UID:uid123 in that calendar? 3B: If there were multiple instances of a recurring component that match a date-time range query , wont the CS return both matching instances without EXPAND? For example, I have a semi-weekly W & F Project Leaders meeting that repeats all year. As such if my CUA were to use a date-time range query like: BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE DTSTART >= '20031208T050000Z' AND DTEND <= '20031213T045959Z' AND STATE() = 'BOOKED' END:VQUERY to get all my booked entries for this week (Im in EST which is -5 from GMT hence the odd looking times) then I would expect the CS to return to me something like: BEGIN:VCALENDAR PRODID:-//someProdID VERSION:2.0 BEGIN:VEVENT ORGANIZER:BigMgr@example.com ATTENDEE;MEMBER="Dev Project Leads";PARTSTAT=ACCEPTED:Bruce@example.com DTSTART:20031210T140000Z DTEND:20031210T143000Z SUMMARY:Semiweekly PL Meeting RECURRENCE-ID:20031210T163000Z SEQUENCE:4 UID:12345 END:VEVENT PRODID:-//someProdID VERSION:2.0 BEGIN:VEVENT ORGANIZER:BigMgr@example.com ATTENDEE;MEMBER="Dev Project Leads";PARTSTAT=ACCEPTED:Bruce@example.com DTSTART:20031212T150000Z DTEND:20031212T153000Z SUMMARY:Semiweekly PL Meeting RECURRENCE-ID:20031212T163000Z SEQUENCE:6 UID:12345 END:VEVENT END:VCALENDAR where the CS returns the data for the 2 repeat instances that occur this week. There should be no need for an EXPAND:TRUE since the CS should return all entries (repeating instances or not) that match the search criteria without the CUA saying "Give me ALL instances of any repeating instances.". So I have to question either the usefullness of EXPAND or the way it is described in relation to the acutal intent of it. As I mull over making sure the questions are accurate and clear I think I figured out what the intent may have been but just not well phrased. Could it be that the intent was to tell the CS "If Im getting all repeating instances of a particular component, I prefer to get back explicit, unwound individual VEVENTs instead of the base defintion followed by any changed instances."? That is, for my question 3A, there are 2 possible ways to return the data: 1: The base set defintion and then all changed instances like: BEGIN:VCALENDAR PRODID:-//someProdID VERSION:2.0 BEGIN:VEVENT ORGANIZER:BigMgr@example.com ATTENDEE;MEMBER="Dev Project Leads ";PARTSTAT=NEEDS-ACTION:Bruce@example.com DTSTART:20030106T160000Z DTEND:20030106T163000Z SUMMARY:Semiweekly PL Meeting RRULE:FREQ=WEEKLY;UNTIL=20031231T235959Z;BYDAY=WE,FR SEQUENCE:0 UID:12345 END:VEVENT ... [Assorted instances that differ from their 'base' content including:] BEGIN:VEVENT ORGANIZER:BigMgr@example.com ATTENDEE;MEMBER="Dev Project Leads";PARTSTAT=ACCEPTED:Bruce@example.com DTSTART:20031210T140000Z DTEND:20031210T143000Z SUMMARY:Semiweekly PL Meeting RECURRENCE-ID:20031210T163000Z SEQUENCE:4 UID:12345 END:VEVENT ... END:VCALENDAR so that the CUA can unwind the RRULE and replaces those changed instances w/the ones it finds afterwards OR 2: All the instances rolled out as individual VEVENTs. As I try to compare the usefullness of both ideas one thought comes to mind as being a problem with #2 above. If the repeating entry repeats infinitely, EXPAND:TRUE will cause the CS to unwind the instances indefinitely. This is not goodness and something we should address in CAP (an implementation issue, security issue, or the like). In any case, is anyone able to answer the questions I have regarding EXPAND:TRUE (or confirm my epiphany)? Bruce PS: Note to CAP editor(s): The Description text should read "EXPAND:TRUE" (in dquotes) not "EXPAND=TRUE" (no dquotes) and the multiple "false" should be "FALSE". =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006CB2A285256DF9_= Content-Type: text/html; charset="US-ASCII"
Ok, I know Im going to be out of touch soon but I wanted to ask in the interest of getting some WG discussion to resolve my confusion.

A while back I asked a question about the usefulness of EXPAND at all (Subject "EXPAND property: All instances?" back on 31-Oct-2003).  There was no technical discussion of it so Ill try again given the recent other thread on DTSTART/RECURRENCE-ID/EXPAND.

In CAP-12-e is defined:

8.16 EXPAND property

  Property Name: EXPAND

  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.

[Snip, snip]

   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.

and in Section 6.1.1.15 Query by Date-Time range is also written:

          This works only for CSs that have the "RECUR-EXPAND"
  property value set to "TRUE" in the "GET-CAPABILITY" exchange.

So, my take on this is:

1: If a CS does not support expanding recurrence rules then it would send RECUR-EXPAND:FALSE when asked.
2: If RECUR-EXPAND is FALSE then:
        A) EXPAND on a QUERY is ignored and
        B) a CUA will be unable to query for entries using a date-time range (even if its not repeating )

This raises some questions which Id like to get some WG concensus on (and perhaps clarification in CAP too).  These include:

1: If a CS does not support recurrence rules then why would that preclude the use of RDATEs?  The CS does not have to evaluate any rules to correctly roll out the repeating set.

2: Why does the lack of recurrence rule support in the CS preclude dong date-time range searches for non-repeating entries ("Give me all the VEVENTs for tomorrow") or for those specified in RDATEs?  Date-time range searching is something nearly all CS need to have in order to function well at all.  Otherwise its usability would be somewhat questionable.

3: What real use is the EXPAND property in actual practice?  This question has 2 parts behind it:

        3A: The 1st line of the Description says to set EXPAND:TRUE if the CUA wants all instances of a recurring component.  Why not just use a simple QUERY like:

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

        which should cause the CS to return all instances of UID:uid123 in that calendar?

        3B: If there were multiple instances of a recurring component that match a date-time range query , wont the CS return both matching instances without EXPAND?  For example, I have a semi-weekly W & F Project Leaders meeting that repeats all year.  As such if my CUA were to use a date-time range query like:

           BEGIN:VQUERY
          EXPAND:TRUE
          QUERY:SELECT * FROM VEVENT
          WHERE DTSTART >= '20031208T050000Z'
          AND DTEND <= '20031213T045959Z'
          AND STATE() = 'BOOKED'
          END:VQUERY

to get all my booked entries for this week (Im in EST which is -5 from GMT hence the odd looking times) then I would expect the CS to return to me something like:

   BEGIN:VCALENDAR
  PRODID:-//someProdID
  VERSION:2.0
  BEGIN:VEVENT
  ORGANIZER:BigMgr@example.com
   ATTENDEE;MEMBER="Dev Project Leads";PARTSTAT=ACCEPTED:Bruce@example.com
  DTSTART:20031210T140000Z
   DTEND:20031210T143000Z
   SUMMARY:Semiweekly PL Meeting
   RECURRENCE-ID:20031210T163000Z
   SEQUENCE:4
  UID:12345
  END:VEVENT
  PRODID:-//someProdID
  VERSION:2.0
  BEGIN:VEVENT
  ORGANIZER:BigMgr@example.com
   ATTENDEE;MEMBER="Dev Project Leads";PARTSTAT=ACCEPTED:Bruce@example.com
  DTSTART:20031212T150000Z
   DTEND:20031212T153000Z
   SUMMARY:Semiweekly PL Meeting
   RECURRENCE-ID:20031212T163000Z
   SEQUENCE:6
  UID:12345
  END:VEVENT
  END:VCALENDAR

where the CS returns the data for the 2 repeat instances that occur this week.  There should be no need for an EXPAND:TRUE since the CS should return all entries (repeating instances or not) that match the search criteria without the CUA saying "Give me ALL instances of any repeating instances.".

So I have to question either the usefullness of EXPAND or the way it is described in relation to the acutal intent of it.   As I mull over making sure the questions are accurate and clear I think I figured out what the intent may have been but just not well phrased.  
Could it be that the intent was to tell the CS "If Im getting all repeating instances of a particular component, I prefer to get back explicit, unwound individual VEVENTs instead of the base defintion followed by any changed instances."?  That is, for my question 3A, there are 2 possible ways to return the data:

1: The base set defintion and then all changed instances like:

   BEGIN:VCALENDAR
  PRODID:-//someProdID
  VERSION:2.0
  BEGIN:VEVENT
  ORGANIZER:BigMgr@example.com
   ATTENDEE;MEMBER="Dev Project Leads";PARTSTAT=NEEDS-ACTION:Bruce@example.com
  DTSTART:20030106T160000Z
   DTEND:20030106T163000Z
   SUMMARY:Semiweekly PL Meeting
   RRULE:FREQ=WEEKLY;UNTIL=20031231T235959Z;BYDAY=WE,FR
  SEQUENCE:0
  UID:12345
  END:VEVENT
... [Assorted instances that differ from their 'base' content including:]
   BEGIN:VEVENT
  ORGANIZER:BigMgr@example.com
   ATTENDEE;MEMBER="Dev Project Leads";PARTSTAT=ACCEPTED:Bruce@example.com
  DTSTART:20031210T140000Z
   DTEND:20031210T143000Z
   SUMMARY:Semiweekly PL Meeting
   RECURRENCE-ID:20031210T163000Z
   SEQUENCE:4
  UID:12345
  END:VEVENT
...
   END:VCALENDAR
so that the CUA can unwind the RRULE and replaces those changed instances w/the ones it finds afterwards OR

2: All the instances rolled out as individual VEVENTs.

As I try to compare the usefullness of both ideas one thought comes to mind as being a problem with #2 above.  If the repeating entry repeats infinitely, EXPAND:TRUE will cause the CS to unwind the instances indefinitely.  This is not goodness and something we should address in CAP (an implementation issue, security issue, or the like).  In any case, is anyone able to answer the questions I have regarding EXPAND:TRUE (or confirm my epiphany)?

Bruce
PS: Note to CAP editor(s): The Description text should read "EXPAND:TRUE" (in dquotes) not "EXPAND=TRUE" (no dquotes) and the multiple "false" should be "FALSE".
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006CB2A285256DF9_=-- From owner-ietf-calendar@mail.imc.org Thu Dec 11 15:31: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 PAA20946 for ; Thu, 11 Dec 2003 15:31: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 hBBK8lib092268 for ; Thu, 11 Dec 2003 12:08:47 -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 hBBK8l32092267 for ietf-calendar-bks; Thu, 11 Dec 2003 12:08:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBK8kib092262 for ; Thu, 11 Dec 2003 12:08:46 -0800 (PST) (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 hBBK8hYu029111 for ; Thu, 11 Dec 2003 13:08:43 -0700 (MST) Message-ID: <3FD8CECB.172D649F@INET-Calendar.net> Date: Thu, 11 Dec 2003 13:08:43 -0700 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: 6.1.1.15 Query by Date-Time range 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 Is this not the current discussion? Bruce_Kahn@notesdev.ibm.com wrote: > > In revistiing some sections of CAP 12-e for snippets for other > postings I ran across what appears to be an incorrect example for the > section. Section 6.1.1.15 Query by Date-Time range should have an > example for getting "every booked "VEVENT" component that has an > instance greater than or equal to July 1st, 2000 00:00:00 UTC and less > than or equal to July 30st, 2000 23:59:59 UTC." > > However the query is using RECURRENCE-ID which is an instance > identifier and NOT the acutal entry occuring in that time range. I > believe the correct example should be: > > BEGIN:VQUERY > QUERY:SELECT * FROM VEVENT > WHERE DTSTART >= '20000701T000000Z' > AND DTEND <= '20000730T235959Z' > AND STATE() = 'BOOKED' > END:VQUERY > > Bruce > =========================================================================== > Bruce Kahn INet: > Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the > FAX... > Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Thu Dec 11 15:44:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22209 for ; Thu, 11 Dec 2003 15:44:11 -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 hBBKSfib093541 for ; Thu, 11 Dec 2003 12:28:41 -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 hBBKSfHB093540 for ietf-calendar-bks; Thu, 11 Dec 2003 12:28:41 -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 hBBKSdib093535 for ; Thu, 11 Dec 2003 12:28:39 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:foOWKQnZM6APctA12YWIhLgQKbF62WRp@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBBKSYZf002304 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 11 Dec 2003 12:28:35 -0800 Message-ID: <3FD8D371.8060308@Royer.com> Date: Thu, 11 Dec 2003 13:28:33 -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: (unlimited) The intent/meaning of EXPAND and its usefullness References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020402090902060402090503" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020402090902060402090503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit See RECUR-LIMIT. > As I try to compare the usefullness of both ideas one thought comes to > mind as being a problem with #2 above. If the repeating entry repeats > infinitely, EXPAND:TRUE will cause the CS to unwind the instances > indefinitely. This is not goodness and something we should address in > CAP (an implementation issue, security issue, or the like). In any > case, is anyone able to answer the questions I have regarding > EXPAND:TRUE (or confirm my epiphany)? -- 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 --------------ms020402090902060402090503 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 9w0BCQUxDxcNMDMxMjExMjAyODMzWjAjBgkqhkiG9w0BCQQxFgQUkgjxP+CkSaCK+DyGi9pp S/nCS0cwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAaKCORCUuLl4h9V/UOVJE0x/5KeUv0syvhc1Rk1rjnXoX9wU8aRjUlMrv/5oFcJSf CCRxRBH3vv7hDuhRWtMhqm0X1e5y2kLLfJ4w1baeO06Hg/k5L7SF9OdTlEcxWpI8to6Lifx+ 2M7n2uxEhjGti38w5mFfcGWv+4xxyOze+w5s48h7DpJQalZj1+9JyRrF2ws84UhAYoY3QmO7 l+ssLEdNMCMW5N3QHnell9XqpTlj6TO8s4KVI+erDFRUJd5MQR3ZL4LYncJ5hlGoV3DFdp74 ewZZpUEFf2oUexVSzatlfajddDsuqbhC06QWE9YhAEyee273B5U8iKjd2L6qjAAAAAAAAA== --------------ms020402090902060402090503-- From owner-ietf-calendar@mail.imc.org Thu Dec 11 15:59: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 PAA22992 for ; Thu, 11 Dec 2003 15:59:15 -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 hBBKjtib094068 for ; Thu, 11 Dec 2003 12:45:55 -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 hBBKjtWO094067 for ietf-calendar-bks; Thu, 11 Dec 2003 12:45:55 -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 hBBKjrib094062 for ; Thu, 11 Dec 2003 12:45:53 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:5X6Q5Eyn3+/rWCnLIY6qmX+6ISYpjsea@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBBKjnZf002547 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 11 Dec 2003 12:45:51 -0800 Message-ID: <3FD8D77D.2060808@Royer.com> Date: Thu, 11 Dec 2003 13:45:49 -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: The intent/meaning of EXPAND and its usefullness References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080704060408050901040802" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080704060408050901040802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit There is (was?) a big vendor that always converted any recurring instances upon receipt to an unspecified number of RDATEs. They removed the RRULE and EXRULE properties then stored the object. There is (was?) another big vendor that always expanded repeating instances to single instances on the way out to an unspecified maximum number of instances. There were some vendors that did NOT support RRULE or EXRULE, they would only except RDATE. We had discussions and no big vendor would budge at all, so we just set flags. The RECUR-ACCEPTED, RECUR-LIMIT, and RECUR-EXPAND capability replies were added so the CUA could be able to ask the CS (and CS ask the CUA). As iTIP has fallback and errors to those same problems that pre-date CAP, we did not feel that CAP should address those iTIP issues, just allow the endpoints to determine that the problem existed prior to transferring data. The only way to solve this problem is in iTIP-next, mandate some kind of minimum or overlapping sets of rules. I do not think CAP created this problem, I think it is an iTIP issue that CAP allows you to find. -- 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 --------------ms080704060408050901040802 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 9w0BCQUxDxcNMDMxMjExMjA0NTQ5WjAjBgkqhkiG9w0BCQQxFgQU9lu+H++iItLzArEJiDM2 lXhgy54wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAhK+5APzPQs9ZxrF1rlxbbHMS7Hasv5z8x8+enyNS1M+8Ngn/EGlphVyQ/q+PgMn4 qkfdEWrAtRn8OYuHtmGzCXiNk8EibDVn49IFtPZmof628bqV/nvvZj4oSoYJdPg+JrSsw6MW Rd1fN8vDeMKNIeZA2BXYrTF8XWoqdDu7Yy33Jm4e1OL3gnMDxKXAZTYrGvUfa5/5/pMoXF2r k/dbpdLJmvJ6lNztWpJNZvjzAzNzUNRBaq5h+kt/uLsdVZJzM2htO80MoGpXGhRuN48x+hAm dS3MXe4gVCHFRyfTbmwVl1hI4/SM9rB/WhlxyIFz+PdnmgQcfl53K2IpmaDBVgAAAAAAAA== --------------ms080704060408050901040802-- From owner-ietf-calendar@mail.imc.org Thu Dec 11 16:30: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 QAA26220 for ; Thu, 11 Dec 2003 16:29:59 -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 hBBLF7ib095214 for ; Thu, 11 Dec 2003 13:15:07 -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 hBBLF7r3095213 for ietf-calendar-bks; Thu, 11 Dec 2003 13:15:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBLF6ib095207 for ; Thu, 11 Dec 2003 13:15:06 -0800 (PST) (envelope-from arnaud.quillaud@sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hBBLF3UP005048; Thu, 11 Dec 2003 13:15:03 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hBBLF2Cm024792; Thu, 11 Dec 2003 13:15:03 -0800 (PST) Received: from iabs-2k.red.iplanet.com (iabs-2k.red.iplanet.com [192.18.144.144]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with ESMTP id <0HPR00DJU1P2AT@mpkmail.eng.sun.com>; Thu, 11 Dec 2003 13:15:02 -0800 (PST) Date: Thu, 11 Dec 2003 13:14:56 -0800 From: Arnaud Quillaud Subject: RE: CAP-12-e: 6.1.1.15 Query by Date-Time range In-reply-to: To: Bruce_Kahn@notesdev.ibm.com, ietf-calendar@imc.org Message-id: <0HPR00DJV1P2AT@mpkmail.eng.sun.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT I posted the same question a few days ago: http://www.imc.org/ietf-calendar/mail-archive/msg11342.html Doug replied to this thread but I must confess I was still confused after reading it and I didn't get a chance to reply back. Arnaud -----Original Message----- From: Bruce_Kahn@notesdev.ibm.com [mailto:Bruce_Kahn@notesdev.ibm.com] Sent: Thursday, December 11, 2003 10:58 AM To: ietf-calendar@imc.org Subject: CAP-12-e: 6.1.1.15 Query by Date-Time range In revistiing some sections of CAP 12-e for snippets for other postings I ran across what appears to be an incorrect example for the section. Section 6.1.1.15 Query by Date-Time range should have an example for getting "every booked "VEVENT" component that has an instance greater than or equal to July 1st, 2000 00:00:00 UTC and less than or equal to July 30st, 2000 23:59:59 UTC." However the query is using RECURRENCE-ID which is an instance identifier and NOT the acutal entry occuring in that time range. I believe the correct example should be: BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE DTSTART >= '20000701T000000Z' AND DTEND <= '20000730T235959Z' AND STATE() = 'BOOKED' END:VQUERY Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Thu Dec 11 19:21: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 TAA04572 for ; Thu, 11 Dec 2003 19:21:00 -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 hBC02uib000950 for ; Thu, 11 Dec 2003 16:02:56 -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 hBC02udP000949 for ietf-calendar-bks; Thu, 11 Dec 2003 16:02:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC02qib000930 for ; Thu, 11 Dec 2003 16:02:54 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUale-0001YT-00 for ; Fri, 12 Dec 2003 01:02:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUald-0001YK-00 for ; Fri, 12 Dec 2003 01:02:49 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUald-0005zy-00 for ; Fri, 12 Dec 2003 01:02:49 +0100 From: "Michael Fair" Subject: Re: DTSTART for recurrence instances Date: Thu, 11 Dec 2003 16:02:59 -0800 Lines: 141 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > As I understand the process that some on this list believe to be true, the > answers will not be the same for some of; ORGANIZER, both ATTENDEE's, > or for all 4 update methods. Ok I think the easiest way to answer the first half of this message is merely to iterate the calendar stores for UID:XXX resulting from each method. At the bottom I address how the assertment that there is a problem with things being out of sync is not a problem and why the assertment that RECURRENCE-IDs should be derived from the present state of an instance must not be followed and to do so would be a violation of the RFCs. First the CS gets the original 3 instance recurring event resulting in the following four calendar store components: UID:XXX / SEQUENCE:0 RRULE:FREQ=DAILY;COUNT=3 DTSTART: 1-dec-2003 at noon UID:XXX / RECURRENCE-ID: 1-dec-2003 at noon / SEQUENCE:0 DTSTART: 1-dec-2003 at noon UID:XXX / RECURRENCE-ID: 2-dec-2003 at noon / SEQUENCE:0 DTSTART: 2-dec-2003 at noon UID:XXX / RECURRENCE-ID: 3-dec-2003 at noon / SEQUENCE:0 DTSTART: 3-dec-2003 at noon Then we start manipulating the store: Method A: 1) Recreate UID:XXX to have 2 instances on 1-Dec and 3-Dec 2) Add the 2-Dec instance back in After step 1: - The store has deleted all instances and created a new set - 1-Dec and 3-Dec instances are reinitialized - All SEQUENCEs are at 1. - There is no 2-Dec instance After step 2: - The store retains 1-Dec and 3-Dec instances - The store now also has a 2-Dec instance the newly created instance has RECURRENCE-ID: 2-dec-2003 at 2pm - All SEQUENCEs are at 2. Method B: 1) Recreate UID:XXX to have 2 instances on 1-Dec and 3-Dec 2) Add the 2-Dec instance back in The results are exactly the same as Method A. (The only difference between A and B was the method used to describe the set in step 1). Method C: 1) Cancel the 2-dec-2003 instance 2) Add the 2-dec instance back in After step 1: - The store retains all information about 1-Dec and 3-Dec instances - The store no longer has a 2-dec-2003 instance - All SEQUENCEs are at 1 After step 2: - The store retains the 1-dec-2003 and 3-dec-2003 instances - The store now has a 2-dec-2003 instance the instance has RECURRENCE-ID: 2-dec-2003 at 2pm - All SEQUENCEs are at 2. Method D: 1) Properly reschedule the 2-dec-2003 instance After step 1: - The store retains all instances with their original RECURRENCE-ID - The 2-dec-2003 instance begins at 3:30 and has kept the RECURRENCE-ID: 2-dec-2003 at noon (the original) - All SEQUENCEs are 0 except the 2-dec instance which is 1. > And that is busted as no ORGANIZER CUA could figure them out if they -later- > send single instance reschedule (As sent in the 1st email) to the same UID. > As the ORGANZER's CUA would have to contact each ATTENDEEs CS to > figure out what that ATTENDEE's CS thought the RECURRECE-ID's were > or do some vendor specific CAP I/O to look at a log of what was sent > to each attendee which may not work with the next CUA looking at the > same UID. This is not a real problem as this can never legally happen. It is a violation of the protocol to send Attendee-1 one set description for UID:XXX and Attendee-2 a differing description for UID:XXX. There is no allowance in iTIP or iCal for differing RECURRENCE-IDs to be in the set of instances for the same UID between different CS' (assuming the updates aren't still in transit or lost or something abnormal). To do so violates the global uniqueness rule of UIDs. All attendees MUST be sent the same set description information for the same UID under all circumstances. > Which is why I say for any UID/SEQUENCE the RECURRENCE-ID's must be > derived from the object it self without any knowledge of history The RECURRENCE-IDs are derived from the set described by the object with the UID in question but no RECURRENCE-ID property. period. The RECURRENCE-ID MUST NEVER be derived from the instance itself. If the instance is being stored as a separate object in the CS it must also track the RECURRENCE-ID value originally assigned to it. The REQUEST message that has the proper UID with the highest SEQUENCE and no RECURRENCE-ID defines the set of legal RECURRENCE-IDs for that UID. If you ever receive a message for a RECURRENCE-ID that is not in the set described the most recent UID only object there is something wrong. If there ever exists more than one set of RECURRENCE-IDs described by the same UID/SEQUENCE pair there has been a violation of the protocol. A UID/RECURRENCE-ID/SEQUENCE triplet does not count as a UID/SEQUENCE pair. There will never be a REQUEST object that redefines the set of instances and has a RECURRENCE-ID property. To invoke the clause regarding a UID/SEQUENCE pair the RECURRENCE-ID property can not be present. -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Dec 11 20: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 UAA06362 for ; Thu, 11 Dec 2003 20:17:29 -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 hBC12Aib003020 for ; Thu, 11 Dec 2003 17:02:10 -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 hBC12A3F003019 for ietf-calendar-bks; Thu, 11 Dec 2003 17:02:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC129ib003012 for ; Thu, 11 Dec 2003 17:02:09 -0800 (PST) (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 hBC127Yu029466 for ; Thu, 11 Dec 2003 18:02:07 -0700 (MST) Message-ID: <3FD9138F.B5E9C8F4@INET-Calendar.net> Date: Thu, 11 Dec 2003 18:02:07 -0700 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: DTSTART for recurrence instances References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > The RECURRENCE-IDs are derived from the set described by the object > with the UID in question but no RECURRENCE-ID property. period. > The RECURRENCE-ID MUST NEVER be derived from the instance itself. > If the instance is being stored as a separate object in the CS it > must also track the RECURRENCE-ID value originally assigned to it. How would the CS used by attendee-2 ever have that history in order to find or track the originall and RECURRENCE-ID? > There will never be a REQUEST object that redefines the set of > instances and has a RECURRENCE-ID property. To invoke the clause regarding > a UID/SEQUENCE pair the RECURRENCE-ID property can not be present. When you send and instance update you must bump the sequence, so the set changes? correct? From owner-ietf-calendar@mail.imc.org Thu Dec 11 23:07: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 XAA10520 for ; Thu, 11 Dec 2003 23:07:28 -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 hBC3tPib008381 for ; Thu, 11 Dec 2003 19:55:25 -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 hBC3tPmo008380 for ietf-calendar-bks; Thu, 11 Dec 2003 19:55:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC3tNib008374 for ; Thu, 11 Dec 2003 19:55:23 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (sccrmhc11) with SMTP id <2003121203551501100mkbqhe> (Authid: TimHare); Fri, 12 Dec 2003 03:55:15 +0000 Message-Id: <5.2.1.1.0.20031211224648.00a4b580@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 11 Dec 2003 22:54:13 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: Bugzilla questions In-Reply-To: <22F5CB4B-2B40-11D8-8033-000393C29C2A@skyrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thank you, Helge Hess, for the bugzilla setup. Now, I have some semi-related questions: 1) I just remembered that Doug's site used to have a bugzilla for CAP - do we need to move things over? 2) Is there an issue-numbering or issue-naming convention built into bugzilla, or should we come up with one? 3) If we do have a convention, may I suggest that we then adopt the practice on this mailing list of leading off each subject line with an issue identifer (or Re: issue identifier in the case of a reply)? This would then make thread and archive searching a little easier Tim Hare Interested Bystander, Non-Inc. At 07:39 PM 12/10/03 +0100, you wrote: >On 10.12.2003, at 19:14, pregen@egenconsulting.com wrote: >>Helge, this is a great idea. It would be great if you can do that for us. > >No problem, I've just created: >- a CALSCH product, which is the entry point for the group >- a component (read: topic/category) "general" for general issues >- a user "ietf-calendar@imc.org" which is set as the initial owner > for "general" issues (receives mail on each issue) > >So feel free to create an own account in Bugzilla for posting new issues. >There are two forms, an easy one: > http://bugzilla.opengroupware.org/bugzilla/easy_enter_bug.cgi >and a "poweruser" one: > >http://bugzilla.opengroupware.org/bugzilla/enter_bug.cgi?product=CALSCH > >Now we need to decide what additional "components" (discussion topics) we >need - eg iMIP, CAP, Interoperability, ... - so that issues can be >properly classified. > >Let me know if you need anything else. > >best regards, > Helge > >> >>Helge Hess >>Sent by: owner-ietf-calendar@mail.imc.org > >>Bugzilla is an excellent tool to track/classify/search issues, manage >>votes and do a "structured discussion". >> >>If this is of interest, we could jump in and create a Bugzilla category >>for calsch at the OpenGroupware.org Bugzilla: >> http://bugzilla.opengroupware.org/bugzilla/index.cgi >-- >OpenGroupware.org >http://www.opengroupware.org/ > From owner-ietf-calendar@mail.imc.org Fri Dec 12 06:23:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04476 for ; Fri, 12 Dec 2003 06:23:21 -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 hBCB8rib099269 for ; Fri, 12 Dec 2003 03:08:53 -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 hBCB8rSo099268 for ietf-calendar-bks; Fri, 12 Dec 2003 03:08:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCB8qib099260 for ; Fri, 12 Dec 2003 03:08:53 -0800 (PST) (envelope-from helge.hess@skyrix.com) Received: from [192.168.0.176] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 64BB0219180; Fri, 12 Dec 2003 12:05:28 +0100 (CET) In-Reply-To: <5.2.1.1.0.20031211224648.00a4b580@mail.comcast.net> References: <5.2.1.1.0.20031211224648.00a4b580@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7FDAB6FA-2C93-11D8-AEEB-000393BBAFF6@skyrix.com> Content-Transfer-Encoding: 7bit Cc: ietf-calendar@imc.org From: Helge Hess Subject: Re: Bugzilla questions Date: Fri, 12 Dec 2003 12:08:22 +0100 To: Tim Hare X-Mailer: Apple Mail (2.606) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Dec 12, 2003, at 4:54 AM, Tim Hare wrote: > 1) I just remembered that Doug's site used to have a bugzilla for CAP > - do we need to move things over? I had a look whether there are categories, but I didn't found any. Is a lot of stuff contained there? (how many issues?) > 2) Is there an issue-numbering or issue-naming convention built into > bugzilla, or should we come up with one? You mean the "bug tracking ID", yes, this can be used. > 3) If we do have a convention, may I suggest that we then adopt the > practice on this mailing list of leading off each subject line with an > issue identifer (or Re: issue identifier in the case of a reply)? This > would then make thread and archive searching a little easier This is automatically done by Bugzilla and after all the reason to use it ;-) It doesn't provide threading though, only flat comments. On the other side you can structure and link bugs, eg say that one issues blocks another or that issues are the same, etc. best regards, Helge -- OpenGroupware.org => http://www.opengroupware.org/ From owner-ietf-calendar@mail.imc.org Fri Dec 12 11:33:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15260 for ; Fri, 12 Dec 2003 11:33:17 -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 hBCGKTib012906 for ; Fri, 12 Dec 2003 08:20:29 -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 hBCGKSjW012905 for ietf-calendar-bks; Fri, 12 Dec 2003 08:20:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCGKSib012896 for ; Fri, 12 Dec 2003 08:20:28 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FD8D371.8060308@Royer.com> To: ietf-calendar@imc.org Subject: Re: (unlimited) The intent/meaning of EXPAND and its usefullness MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 12 Dec 2003 10:53:24 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/12/2003 11:17:31 AM, Serialize complete at 12/12/2003 11:17:31 AM Content-Type: multipart/alternative; boundary="=_alternative 0056E1D185256DFA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056E1D185256DFA_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 12/11/2003 03:28:33 PM: > See RECUR-LIMIT. That and STORES-EXPANDED (which is interrelated) but I dont think all bases are covered yet. RECUR-LIMIT is defined as: Purpose: This property specifies the maximum number of instances the endpoint will expand instances into at query or storage time. [snip, snip] Description: For implementations that have the "STORES-EXPANDED" value set to TRUE, then this value specifies the maximum number of instances that will be stored and fetched. For all implementations this is the maximum number of instances that will be returned when the "EXPAND" parameter is specified as TRUE and the results contain a infinite or large number of recurring instances. and STORES-EXPANDED is defined as: Purpose: This property specifies if the sending endpoint expands recurrence rules prior to storing them into the CS. [Snip, snip] Description: If the value is TRUE then the endpoint expands recurrence rules and then stores the results into the CS. If this is TRUE then the "RECUR-LIMIT" property is significant because an infinitely recurring appointment will be stored no more than "RECUR-LIMIT" property values into the CS and all other instances will be lost. The unclear/unspecified bits I find are: 1: RECUR-LIMIT says that its a limit for query results or for storage time. However this latter bit is inaccurate if STORES-EXPANDED is FALSE. Both STORES-EXPANDED and RECUR-LIMIT need to have prose in them that clearly indicates that RECUR-LIMIT is not used as a storage constraint if STORES-EXPANDED is FALSE (there is only text now to the effect o STORES-EXPANDED:TRUE). 2: There is no indication of how to indicate "no limit", if we want to support that. There is an example of RECUR-LIMIT:0 in the text however this violates the ABNF for RECUR-LIMIT which says its a posint1 which is defined as: posint1 = posintfirst 1*DIGIT ; A number starting with 1 through 9. ; posintfirst = %x31-39 so the example on p112 violates the ABNF or is intended to be "I allow infinite expansion". If we do not want to support "No limit" in CAP, we need to add some explicit text to that effect. If we do want to support it, we need to say exactly how we indicate that. 3: There is nothing to indicate how the endpoint can tell the requestor "I have expanded to my RECUR-LIMIT and there are other instances that you did not get". This is important for the CUA to know so it can properly inform the CU that what they see is NOT all that should be there. In addition, if there is some way to 'resume' the expansion then that should be clearly defined. For example, if the CS says RECUR-LIMIT:10 and STORES-EXPANDED:FALSE then if the CUA asks for EXPAND:TRUE on a 30 instance repeat set there should be some clearly defined way for the CS to expand the 1st 10 (RECUR-LIMIT) instances and tell the requestor "Thats all ya get but thats not all I have." The requestor could then refine the query so that they get the next 10 instances (11-20) and the response "Thats all ya get but not all I have." And so on until they are able to extract all of them from the CS w/o having to do the unwinding themselves. This gets a little messy unless we clearly state that expansions are ALWAYS done in chronological order so that the requestor simply tweaks their QUERY to include a "AND DTSTART > "last returned instances"" kind of clause. It may be implicit so far but I would expect the CS to return expanded results in chronological order but its not written CAP that it has to so its possible the results come back in any arbitrary order making this resuming of expansion hard to do. If we do not provide some means for this we run into some usability issues. A CU could store a RRULE;COUNT=364 repeating component into a STORES-EXPANDED:FALSE CS whose has RECUR-LIMIT:100 just fine but they would be unable to use EXPAND:TRUE to get the results back out and possibly even without EXPAND:TRUE set (see #6 below). 4: When a requestor tries to store something that would violate the RECUR-LIMIT of the CS, there is no clear describing what the failure results/state should be. That is, is the entire request (for that component) rejected entirely? Is it processed to RECUR-LIMIT and the rest ignored/lost? 5: Does RECUR-LIMIT apply to manually stored instances or it is a limit per component no matter how the instances are stored? That is, if a CS says they have RECUR-LIMIT:5 and I try to create a RRULE;COUNT=6 the CS would reject it (subject to #4 above). However, what if the CUA manually rolls out the instances themselves (or they get created over time as the CU gets added to more and more instances bit by bit!). Can my CUA create 6 separate instances of a particular component without running astray of RECUR-LIMIT? Since the CS is not doing the actual expansion Im not certain that STORES-EXPANDED or RECUR-LIMIT would be applicable. After all, if I just ACCEPTed an invitation to a 6th instance of the "Super Secret Product Ship Party Planning Committee" then I would NOT expect to be rejected with some sort of "You tried to store too many instances of this repeating component" failure since form my POV I just accepted a single instance and not a bajillion repeats. 6: It is unclear how RECUR-LIMIT is affected by NOT using EXPAND:TRUE. That is, is RECUR-LIMIT used to control the number of returned results even if the caller did not request EXPAND:TRUE? For example, if the CS has RECUR-LIMIT:5 and a component repeats semi-weekly (W and F) then would a query for all of this months entries fail even if I did NOT use EXPAND:TRUE? Bruce PS: Note to CAP Editor(s): in RECUR-LIMITs Description, "EXPAND" is a property, not a parameter. Also, may I suggest that the Descriptoin be split into 2 paragraphs at the point where it talks about the EXPAND property (so each related property is in its own paragraph.) =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0056E1D185256DFA_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 12/11/2003 03:28:33 PM:
> See RECUR-LIMIT.
That and STORES-EXPANDED (which is interrelated) but I dont think all bases are covered yet.

RECUR-LIMIT is defined as:

   Purpose: This property specifies the maximum number of instances the
  endpoint will expand instances into at query or storage time.
[snip, snip]
   Description: For implementations that have the "STORES-EXPANDED"
  value set to TRUE, then this value specifies the maximum number of
  instances that will be stored and fetched. For all implementations
  this is the maximum number of instances that will be returned when
  the "EXPAND" parameter is specified as TRUE and the results contain a
  infinite or large number of recurring instances.

and STORES-EXPANDED is defined as:

   Purpose: This property specifies if the sending endpoint expands
  recurrence rules prior to storing them into the CS.
[Snip, snip]
   Description: If the value is TRUE then the endpoint expands
  recurrence rules and then stores the results into the CS. If this is
  TRUE then the "RECUR-LIMIT" property is significant because an
  infinitely recurring appointment will be stored no more than
  "RECUR-LIMIT" property values into the CS and all other instances
  will be lost.

The unclear/unspecified bits I find are:

1: RECUR-LIMIT says that its a limit for query results or for storage time.  However this latter bit is inaccurate if STORES-EXPANDED is FALSE.   Both STORES-EXPANDED and RECUR-LIMIT need to have prose in them that clearly indicates that RECUR-LIMIT is not used as a storage constraint if STORES-EXPANDED is FALSE (there is only text now to the effect o STORES-EXPANDED:TRUE).

2: There is no indication of how to indicate "no limit", if we want to support that.  There is an example of RECUR-LIMIT:0 in the text however this violates the ABNF for RECUR-LIMIT which says its a posint1 which is defined as:

    posint1     = posintfirst 1*DIGIT

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

so the example on p112 violates the ABNF or is intended to be "I allow infinite expansion".  If we do not want to support "No limit" in CAP, we need to add some explicit text to that effect.  If we do want to support it, we need to say exactly how we indicate that.

3: There is nothing to indicate how the endpoint can tell the requestor "I have expanded to my RECUR-LIMIT and there are other instances that  you did not get".   This is important for the CUA to know so it can properly inform the CU that what they see is NOT all that should be there.  In addition, if there is some way to 'resume' the expansion then that should be clearly defined.  For example, if the CS says RECUR-LIMIT:10 and STORES-EXPANDED:FALSE then if the CUA asks for EXPAND:TRUE on a 30 instance repeat set there should be some clearly defined way for the CS to expand the 1st 10 (RECUR-LIMIT) instances and tell the requestor "Thats all ya get but thats not all I have."  The requestor could then refine the query so that they get the next 10 instances (11-20) and the response "Thats all ya get but not all I have." And so on until they are able to extract all of them from the CS w/o having to do the unwinding themselves.

This gets a little messy unless we clearly state that expansions are ALWAYS done in chronological order so that the requestor simply tweaks their QUERY to include a "AND DTSTART > "last returned instances"" kind of clause.  It may be implicit so far but I would expect the CS to return expanded results in chronological order but its not written CAP that it has to so its possible the results come back in any arbitrary order making this resuming of expansion hard to do.

If we do not provide some means for this we run into some usability issues.  A CU could store a RRULE;COUNT=364 repeating component into a STORES-EXPANDED:FALSE CS whose has RECUR-LIMIT:100 just fine but they would be unable to use EXPAND:TRUE to get the results back out and possibly even without EXPAND:TRUE set (see #6 below).

4: When a requestor tries to store something that would violate the RECUR-LIMIT of the CS, there is no clear describing what the failure results/state should be.  That is, is the entire request (for that component) rejected entirely?  Is it processed to RECUR-LIMIT and the rest ignored/lost?  

5: Does RECUR-LIMIT apply to manually stored instances or it is a limit per component no matter how the instances are stored?  That is, if a CS says they have RECUR-LIMIT:5 and I try to create a RRULE;COUNT=6 the CS would reject it (subject to #4 above).  However, what if the CUA manually rolls out the instances themselves (or they get created over time as the CU gets added to more and more instances bit by bit!).  Can my CUA create 6 separate instances of a particular component without running astray of RECUR-LIMIT?  Since the CS is not doing the actual expansion Im not certain that STORES-EXPANDED or RECUR-LIMIT would be applicable.  After all, if I just ACCEPTed an invitation to a 6th instance of the "Super Secret Product Ship Party Planning Committee" then I would NOT expect to be rejected with some sort of "You tried to store too many instances of this repeating component" failure since form my POV I just accepted a single instance and not a bajillion repeats.

6: It is unclear how RECUR-LIMIT is affected by NOT using EXPAND:TRUE.  That is, is RECUR-LIMIT used to control the number of returned results even if the caller did not request EXPAND:TRUE?  For example, if the CS has RECUR-LIMIT:5 and a component repeats semi-weekly (W and F) then would a query for all of this months entries fail even if I did NOT use EXPAND:TRUE?

Bruce
PS: Note to CAP Editor(s): in RECUR-LIMITs Description, "EXPAND" is a property, not a parameter.  Also, may I suggest that the Descriptoin be split into 2 paragraphs at the point where it talks about the EXPAND property (so each related property is in its own paragraph.)
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0056E1D185256DFA_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 12 11:58: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 LAA16195 for ; Fri, 12 Dec 2003 11:58: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 hBCGlkib014732 for ; Fri, 12 Dec 2003 08:47: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 hBCGlklH014731 for ietf-calendar-bks; Fri, 12 Dec 2003 08:47:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCGljib014720 for ; Fri, 12 Dec 2003 08:47:45 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FD8D77D.2060808@Royer.com> To: ietf-calendar@imc.org Subject: Re: The intent/meaning of EXPAND and its usefullness MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 12 Dec 2003 11:41:05 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 12/12/2003 11:44:48 AM, Serialize complete at 12/12/2003 11:44:48 AM Content-Type: multipart/alternative; boundary="=_alternative 005B3F3585256DFA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B3F3585256DFA_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 12/11/2003 03:45:49 PM: > We had discussions and no big vendor would budge at all, so we just set > flags. Given that all vendors (large, medium or small) have to deal with existing customer bases I dont find this astonishing. In any case, the flags/settings we create need to be comprehensive and clear for all parties so that correct behaviour can be determined. > As iTIP has fallback and errors to those same problems that pre-date > CAP, we did > not feel that CAP should address those iTIP issues, just allow the > endpoints to determine > that the problem existed prior to transferring data. The iTIP fallbacks you refer to are protocol level behaviours like: Method Fallback -------------- ----------------------------------------------------- PUBLISH Required REQUEST PUBLISH REPLY Required ADD Required CANCEL Required REFRESH Required COUNTER Reply with Not Supported DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise reply with Not Supported The issues with EXPAND are not germane to iTIP messaging so its not an iTIP issue/problem as you contend. The questions related to EXPAND are related to CAP features/abilities and nothing directly related to iTIP. > I do not think CAP created this problem, I think it is an iTIP issue > that CAP > allows you to find. iTIP defines the semantics for doing workflow between 2 parties and nothing more. The issues with EXPAND are non-workflow related and thus CAP specific; iTIP does not cover accessing and manipulating calendar contents like CAP does. Now can we try to address the questions so CAP is clear and as unambiguious as we can make 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 005B3F3585256DFA_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 12/11/2003 03:45:49 PM:
> We had discussions and no big vendor would budge at all, so we just set
> flags.
Given that all vendors (large, medium or small) have to deal with existing customer bases I dont find this astonishing.  In any case, the flags/settings we create need to be comprehensive and clear for all parties so that correct behaviour can be determined.

> As iTIP has fallback and errors to those same problems that pre-date
> CAP, we did
> not feel that CAP should address those iTIP issues, just allow the
> endpoints to determine
> that the problem existed prior to transferring data.
The iTIP fallbacks you refer to are protocol level behaviours like:

Method           Fallback
--------------   -----------------------------------------------------
PUBLISH          Required
REQUEST          PUBLISH
REPLY            Required
ADD              Required
CANCEL           Required
REFRESH          Required
COUNTER          Reply with Not Supported
DECLINECOUNTER   Required if EVENT-COUNTER is implemented; otherwise
                reply with Not Supported

The issues with EXPAND are not germane to iTIP messaging so its not an iTIP issue/problem as you contend.  The questions related to EXPAND are related to CAP features/abilities and nothing directly related to iTIP.

> I do not think CAP created this problem, I think it is an iTIP issue
> that CAP
> allows you to find.
iTIP defines the semantics for doing workflow between 2 parties and nothing more.  The issues with EXPAND are non-workflow related and thus CAP specific; iTIP does not cover accessing and manipulating calendar contents like CAP does.

Now can we try to address the questions so CAP is clear and as unambiguious as we can make 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 005B3F3585256DFA_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 12 13:31:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19293 for ; Fri, 12 Dec 2003 13:31:34 -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 hBCIHEib017714 for ; Fri, 12 Dec 2003 10:17:16 -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 hBCIHEZ1017713 for ietf-calendar-bks; Fri, 12 Dec 2003 10:17:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCIHCib017706 for ; Fri, 12 Dec 2003 10:17:12 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUrqi-00061d-00 for ; Fri, 12 Dec 2003 19:17:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUrqh-00061U-00 for ; Fri, 12 Dec 2003 19:17:11 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUrqh-0002aX-00 for ; Fri, 12 Dec 2003 19:17:11 +0100 From: "Michael Fair" Subject: Re: DTSTART for recurrence instances Date: Fri, 12 Dec 2003 10:17:17 -0800 Lines: 93 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Mark Smith" wrote in message news:3FD9138F.B5E9C8F4@INET-Calendar.net... > > Michael Fair wrote: > > > The RECURRENCE-IDs are derived from the set described by the object > > with the UID in question but no RECURRENCE-ID property. period. > > The RECURRENCE-ID MUST NEVER be derived from the instance itself. > > If the instance is being stored as a separate object in the CS it > > must also track the RECURRENCE-ID value originally assigned to it. > > How would the CS used by attendee-2 ever have that history in > order to find or track the originall and RECURRENCE-ID? Attendee-2 received a sequence of messages that: a) defined a 3peat event (UID:XXX/SEQ:0) b) redefined that event to be a 2peat event (UID:XXX/SEQ:1) c) added a 3rd instance (using ADD) (UID:XXX/SEQ:2) None of these actions are an instance reschedule. All three messages are set redefining messages. Therefore, the "history" is a combination of messages b and c. If c were a REQUEST and not an ADD, then you would only need message c. When message b arrives, as a "REQUEST", it replaces all prior data associated with UID:XXX. When message c arrives, as an "ADD", it merges with all existing data associated with UID:XXX. By creating the "UNION" of the set described by messages b and c you get the set described by the object UID:XXX/SEQ:2. The valid RECURRENCE-IDs would be the set of start times generated by enumerating that set. For any given event that repeats N times, there are N+1 objects in the CS. N instance objects identified by UID/RECURRENCE-ID and 1 set description object identified by the UID alone. It is the 1 set description object that defines the set or RECURRENCE-IDs that the N instance objects will use. > > There will never be a REQUEST object that redefines the set of > > instances and has a RECURRENCE-ID property. To invoke the clause regarding > > a UID/SEQUENCE pair the RECURRENCE-ID property can not be present. > > When you send and instance update you must bump the sequence, so the > set changes? correct? Yes the SEQUENCE for that instance gets bumped, but no the set doesn't change. You are bumping the SEQUENCE for the instance object (UID/RID) not the set description object (UID only). In the "proper rescheduling" (aka method D) from the prior examples the 2-dec-2003 at noon instance still exists, it just doesn't start on 2-dec-2203 at noon anymore. UID:XXX/SEQ:0 defined 3 instances 1-dec, 2-dec, 3-dec. UID:XXX/RID:2-dec/SEQ:1 updated the DTSTART of the 2-dec instance. The 2-dec instance is still the 2-dec instance identified by the enumeration of the set description from UID:XXX/SEQ:0. It just starts at a different time. Another way to understand it is that all events are identified by two components, the UID and RECURRENCE-ID. For singleton events the value of the RECURRENCE-ID is NULL and there are no RDATE/RRULE or EXDATE/EXRULE properties. For recurring events, the UID object without a RECURRENCE-ID attatched is the "set definition" object and the instances are identified with a RECURRENCE-ID that is a member of the set described therein. When you reschedule an instance you don't redefine the set, you update the times of the instance identified by the RECURRENCE-ID. The RECURRENCE-ID is just a name assigned to the instance. But it's an algorithmically assigned name so that it can be automaticly chosen and so that physical storage for the instance can be delayed until there is a real need to actually track differences related to that particular instance. The RECURRENCE-ID is not a reflection of reality, it's an identifier. Only DTSTART can tell you when an instance actually starts. DTSTART is not an identifier, only UID/RECURRENCE-ID can identify a particular instance for you. They, by design, do oftentimes coincide, but that's an artifact not a mandate or rule. -- Michael -- From owner-ietf-calendar@mail.imc.org Fri Dec 12 15:46:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25598 for ; Fri, 12 Dec 2003 15:46:06 -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 hBCKWQib022397 for ; Fri, 12 Dec 2003 12:32: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 hBCKWQtx022396 for ietf-calendar-bks; Fri, 12 Dec 2003 12:32:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCKWPib022383 for ; Fri, 12 Dec 2003 12:32:25 -0800 (PST) (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 hBCKWJYu000874 for ; Fri, 12 Dec 2003 13:32:20 -0700 (MST) Message-ID: <3FDA25D3.4A81571B@INET-Calendar.net> Date: Fri, 12 Dec 2003 13:32:19 -0700 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: DTSTART for recurrence instances References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > "Mark Smith" wrote in message > news:3FD9138F.B5E9C8F4@INET-Calendar.net... > > > > Michael Fair wrote: > > > > > The RECURRENCE-IDs are derived from the set described by the object > > > with the UID in question but no RECURRENCE-ID property. period. > > > The RECURRENCE-ID MUST NEVER be derived from the instance itself. > > > If the instance is being stored as a separate object in the CS it > > > must also track the RECURRENCE-ID value originally assigned to it. > > > > How would the CS used by attendee-2 ever have that history in > > order to find or track the originall and RECURRENCE-ID? > > Attendee-2 received a sequence of messages that: > > a) defined a 3peat event (UID:XXX/SEQ:0) > b) redefined that event to be a 2peat event (UID:XXX/SEQ:1) > c) added a 3rd instance (using ADD) (UID:XXX/SEQ:2) You did not follow the example that was sent and that was not the question. From owner-ietf-calendar@mail.imc.org Fri Dec 12 15:49: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 PAA25738 for ; Fri, 12 Dec 2003 15:49: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 hBCKbbib022535 for ; Fri, 12 Dec 2003 12:37:39 -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 hBCKbb1F022534 for ietf-calendar-bks; Fri, 12 Dec 2003 12:37:37 -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 hBCKbZib022529 for ; Fri, 12 Dec 2003 12:37:35 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:Ue1aYXoZ17RV7TI5YpPbyLmH+9IOlkFw@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBCKbVZf022350 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 Dec 2003 12:37:34 -0800 Message-ID: <3FDA270A.50508@Royer.com> Date: Fri, 12 Dec 2003 13:37:30 -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: (unlimited) The intent/meaning of EXPAND and its usefullness References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010005050208020000090109" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010005050208020000090109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 12/11/2003 03:28:33 PM: > > See RECUR-LIMIT. > > That and STORES-EXPANDED (which is interrelated) but I dont think all > bases are covered yet. The LIMIT is covered - correct? The ability to get-next (or what ever) was rejected previously by the WG because when you get the last RECUR-LIMIT item, look at its date/time , start from there and ask again. No explicit get-next needed. -- 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 --------------ms010005050208020000090109 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 9w0BCQUxDxcNMDMxMjEyMjAzNzMwWjAjBgkqhkiG9w0BCQQxFgQUqhO6xdKmi/+QLY+vGlsy 8z1zHjUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAcZYsOe+PlSBwMkexKXdtvHQJMwy4dwcCa/E1htbHLUi97FjrG9AHwNTngkMhK87g hnbb1+cf9RdAj4NVYdu7IDDrBI/4xpqisTXRs2nz8hKyWvx6rY0cXk4A34ZrsUZdQJkTDySW D4sJL5BjcUji4QGbI34OKXDIZNX4IUeK0NHOhAjzVm+7yNMRXCeDCRiGuD10VJ+o+/9RoDWL GO1122zq+XgpnHnvLsloeckJ7Pm8lFk9zrnW2eBYEF5K1gIqTqxT72+PfImeS73iWJGZKHRA 5xCTwm+OpOv+7SCMPh6UwRLUNdTTMY8T4SlOj2rRrGkj/++UMoE9fdt0CyCzoQAAAAAAAA== --------------ms010005050208020000090109-- From owner-ietf-calendar@mail.imc.org Fri Dec 12 15:54:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25988 for ; Fri, 12 Dec 2003 15:54:30 -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 hBCKgUib022653 for ; Fri, 12 Dec 2003 12:42:30 -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 hBCKgUlE022652 for ietf-calendar-bks; Fri, 12 Dec 2003 12:42:30 -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 hBCKgSib022646 for ; Fri, 12 Dec 2003 12:42:29 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:+44d3a3nYdUDeazN4g6dYqn+V/OLfQ90@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBCKgQZf022394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 Dec 2003 12:42:27 -0800 Message-ID: <3FDA2831.6020908@Royer.com> Date: Fri, 12 Dec 2003 13:42:25 -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: (unlimited) The intent/meaning of EXPAND and its usefullness References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050903040204080208080106" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050903040204080208080106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > 2: There is no indication of how to indicate "no limit", if we want to > support that.support it, we need to say exactly how we indicate that. Why would we want to explicitly consider breaking or hanging a CUA or 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 --------------ms050903040204080208080106 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 9w0BCQUxDxcNMDMxMjEyMjA0MjI1WjAjBgkqhkiG9w0BCQQxFgQUc/NvWZiEpe3KuGLf9cIZ RSh6pRQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAmfu81MxuncU2qVuCHvIhJ34fHXebRm5Z70wIkGa34kBtsz+zgbcl34MGp/wNBr8M 1iFZtu/JbMYYjkKJCSyJ/xJbq27INB8/e9oKo192t6kMkBOg0SOVrZTdjynz8D+ndKfRPE47 wglOBrvouSDtRKEEbkne1OQKR71rEV39Q+mrtJM1VXMSEiyBQE0Tqn4oVume5drGn2xC3be4 eq8Ui5p59aZFbPeo9FIooXyrnsjhMeYYQT8pnhlHHbhYu06SjBZx1jnhEHIY6c3xlZbQ0Mws tWDas0vCYbOZGQXAl43xwkIlWCJaWb1UztshixmqbKj8aJEo68b1So7pWV1otgAAAAAAAA== --------------ms050903040204080208080106-- From owner-ietf-calendar@mail.imc.org Fri Dec 12 16:05: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 QAA26512 for ; Fri, 12 Dec 2003 16:05:20 -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 hBCKrJib023092 for ; Fri, 12 Dec 2003 12:53:19 -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 hBCKrJgS023091 for ietf-calendar-bks; Fri, 12 Dec 2003 12:53:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from xgate.provo.novell.com (xgate.provo.novell.com [137.65.47.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCKrHib023084 for ; Fri, 12 Dec 2003 12:53:17 -0800 (PST) (envelope-from PStephenson@gw.novell.com) Received: from PROVO7-MTA by xgate.provo.novell.com with Novell_GroupWise; Fri, 12 Dec 2003 13:47:30 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Fri, 12 Dec 2003 13:54:56 -0700 From: "Preston Stephenson" To: Subject: Re: (unlimited) The intent/meaning of EXPAND and its usefullness 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 my too bits worth. In our implementation, we expand out recurrence items on creation (so STORES:EXPANDED:TRUE). We set RECUR-LIMIT to specify the max we will fan out on creation. For access of the items after that the other recur properties/parameters don't make much sense. For query, EXPAND doesn't make sense and we ignore it (whether or not RECUR-EXPAND is set). For query, RECUR-LIMIT doesn't make sense, since we only want it to apply to storage. Can we abstract the limit to just be a limit (say QUERY-LIMIT) of any items returned? For query, RECUR-EXPAND doesn't make sense, since the items are already expanded. There is a little problem on RECUR-LIMIT applying to storage and query. In the case of 2) below, the absence of RECUR-LIMIT would mean no limit. The problem arises if you have to have it be two limits (storage and query). On creation we just expand out the item to the limit we can. We have no way of passing back a status saying, we would have created more. (We've just documented it in the past and our customers know to work around the limitations.) We have no way of adding to an existing recurrence set. How would you reflect that functionality in CAP, "IF-YOU-CREATE-A-RECURRENCE-ITEM-AND-IT-EXCEEDS-THE-LIMIT" what happens flag? Thanks. Preston >>> 12/12/2003 8:53:24 AM >>> Doug replied on 12/11/2003 03:28:33 PM: > See RECUR-LIMIT. That and STORES-EXPANDED (which is interrelated) but I dont think all bases are covered yet. RECUR-LIMIT is defined as: Purpose: This property specifies the maximum number of instances the endpoint will expand instances into at query or storage time. [snip, snip] Description: For implementations that have the "STORES-EXPANDED" value set to TRUE, then this value specifies the maximum number of instances that will be stored and fetched. For all implementations this is the maximum number of instances that will be returned when the "EXPAND" parameter is specified as TRUE and the results contain a infinite or large number of recurring instances. and STORES-EXPANDED is defined as: Purpose: This property specifies if the sending endpoint expands recurrence rules prior to storing them into the CS. [Snip, snip] Description: If the value is TRUE then the endpoint expands recurrence rules and then stores the results into the CS. If this is TRUE then the "RECUR-LIMIT" property is significant because an infinitely recurring appointment will be stored no more than "RECUR-LIMIT" property values into the CS and all other instances will be lost. The unclear/unspecified bits I find are: 1: RECUR-LIMIT says that its a limit for query results or for storage time. However this latter bit is inaccurate if STORES-EXPANDED is FALSE. Both STORES-EXPANDED and RECUR-LIMIT need to have prose in them that clearly indicates that RECUR-LIMIT is not used as a storage constraint if STORES-EXPANDED is FALSE (there is only text now to the effect o STORES-EXPANDED:TRUE). 2: There is no indication of how to indicate "no limit", if we want to support that. There is an example of RECUR-LIMIT:0 in the text however this violates the ABNF for RECUR-LIMIT which says its a posint1 which is defined as: posint1 = posintfirst 1*DIGIT ; A number starting with 1 through 9. ; posintfirst = %x31-39 so the example on p112 violates the ABNF or is intended to be "I allow infinite expansion". If we do not want to support "No limit" in CAP, we need to add some explicit text to that effect. If we do want to support it, we need to say exactly how we indicate that. 3: There is nothing to indicate how the endpoint can tell the requestor "I have expanded to my RECUR-LIMIT and there are other instances that you did not get". This is important for the CUA to know so it can properly inform the CU that what they see is NOT all that should be there. In addition, if there is some way to 'resume' the expansion then that should be clearly defined. For example, if the CS says RECUR-LIMIT:10 and STORES-EXPANDED:FALSE then if the CUA asks for EXPAND:TRUE on a 30 instance repeat set there should be some clearly defined way for the CS to expand the 1st 10 (RECUR-LIMIT) instances and tell the requestor "Thats all ya get but thats not all I have." The requestor could then refine the query so that they get the next 10 instances (11-20) and the response "Thats all ya get but not all I have." And so on until they are able to extract all of them from the CS w/o having to do the unwinding themselves. This gets a little messy unless we clearly state that expansions are ALWAYS done in chronological order so that the requestor simply tweaks their QUERY to include a "AND DTSTART > "last returned instances"" kind of clause. It may be implicit so far but I would expect the CS to return expanded results in chronological order but its not written CAP that it has to so its possible the results come back in any arbitrary order making this resuming of expansion hard to do. If we do not provide some means for this we run into some usability issues. A CU could store a RRULE;COUNT=364 repeating component into a STORES-EXPANDED:FALSE CS whose has RECUR-LIMIT:100 just fine but they would be unable to use EXPAND:TRUE to get the results back out and possibly even without EXPAND:TRUE set (see #6 below). 4: When a requestor tries to store something that would violate the RECUR-LIMIT of the CS, there is no clear describing what the failure results/state should be. That is, is the entire request (for that component) rejected entirely? Is it processed to RECUR-LIMIT and the rest ignored/lost? 5: Does RECUR-LIMIT apply to manually stored instances or it is a limit per component no matter how the instances are stored? That is, if a CS says they have RECUR-LIMIT:5 and I try to create a RRULE;COUNT=6 the CS would reject it (subject to #4 above). However, what if the CUA manually rolls out the instances themselves (or they get created over time as the CU gets added to more and more instances bit by bit!). Can my CUA create 6 separate instances of a particular component without running astray of RECUR-LIMIT? Since the CS is not doing the actual expansion Im not certain that STORES-EXPANDED or RECUR-LIMIT would be applicable. After all, if I just ACCEPTed an invitation to a 6th instance of the "Super Secret Product Ship Party Planning Committee" then I would NOT expect to be rejected with some sort of "You tried to store too many instances of this repeating component" failure since form my POV I just accepted a single instance and not a bajillion repeats. 6: It is unclear how RECUR-LIMIT is affected by NOT using EXPAND:TRUE. That is, is RECUR-LIMIT used to control the number of returned results even if the caller did not request EXPAND:TRUE? For example, if the CS has RECUR-LIMIT:5 and a component repeats semi-weekly (W and F) then would a query for all of this months entries fail even if I did NOT use EXPAND:TRUE? Bruce PS: Note to CAP Editor(s): in RECUR-LIMITs Description, "EXPAND" is a property, not a parameter. Also, may I suggest that the Descriptoin be split into 2 paragraphs at the point where it talks about the EXPAND property (so each related property is in its own paragraph.) =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Fri Dec 12 16:58: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 QAA28631 for ; Fri, 12 Dec 2003 16:58:19 -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 hBCLltib025853 for ; Fri, 12 Dec 2003 13:47:55 -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 hBCLltKN025852 for ietf-calendar-bks; Fri, 12 Dec 2003 13:47:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCLlpib025843 for ; Fri, 12 Dec 2003 13:47:53 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUv8a-0008SX-00 for ; Fri, 12 Dec 2003 22:47:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUv8Z-0008SO-00 for ; Fri, 12 Dec 2003 22:47:51 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUv8Z-0000rU-00 for ; Fri, 12 Dec 2003 22:47:51 +0100 From: "Michael Fair" Subject: Re: DTSTART for recurrence instances Date: Fri, 12 Dec 2003 13:47:55 -0800 Lines: 59 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Mark Smith" wrote in message news:3FDA25D3.4A81571B@INET-Calendar.net... > > Michael Fair wrote: > > > > "Mark Smith" wrote in message > > news:3FD9138F.B5E9C8F4@INET-Calendar.net... > > > > > > Michael Fair wrote: > > > > > > > The RECURRENCE-IDs are derived from the set described by the object > > > > with the UID in question but no RECURRENCE-ID property. period. > > > > The RECURRENCE-ID MUST NEVER be derived from the instance itself. > > > > If the instance is being stored as a separate object in the CS it > > > > must also track the RECURRENCE-ID value originally assigned to it. > > > > > > How would the CS used by attendee-2 ever have that history in > > > order to find or track the originall and RECURRENCE-ID? > > > > Attendee-2 received a sequence of messages that: > > > > a) defined a 3peat event (UID:XXX/SEQ:0) > > b) redefined that event to be a 2peat event (UID:XXX/SEQ:1) > > c) added a 3rd instance (using ADD) (UID:XXX/SEQ:2) > > You did not follow the example that was sent and that was not the > question. Could you please expand on this response? Would you please clarify for me the example you think was sent that I am not following? Here is what I followed: There were four total examples sent, named methods A, B, C, and D. Attendee-2 used method A or B. The example Doug displayed of the Calendar store was clearly from Method B but I understood why it could have been A or B because both methods A and B were fundamentally the same. The only difference was the method used to construct the set in step b above (A used RDATE, B used RRULE). Method A: a) send original 3peat event b) send redefinition to make it a 2peat event using DTSTART/RDATE c) send an add to create the 3rd instance Method B: a) send original 3peat event b) send redefinition to make it a 2peat event using DTSTART/RRULE/EXDATE c) send an add to create the 3rd instance What am I not following? If you still think that I have not addressed the question can you please rephrase it and/or expand a little more on the question so that I might understand it and respond to it? -- Michael -- From owner-ietf-calendar@mail.imc.org Fri Dec 12 17:28:55 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29811 for ; Fri, 12 Dec 2003 17:28:54 -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 hBCMHRib027061 for ; Fri, 12 Dec 2003 14:17: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 hBCMHRfP027060 for ietf-calendar-bks; Fri, 12 Dec 2003 14:17:27 -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 hBCMHQib027055 for ; Fri, 12 Dec 2003 14:17:26 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:dOH1531mgBNJZ4uGuaoOFgxizbXReHEe@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBCMHOZf023984 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 Dec 2003 14:17:25 -0800 Message-ID: <3FDA3E74.3060202@Royer.com> Date: Fri, 12 Dec 2003 15:17:24 -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: (RECUR-LIMIT) The intent/meaning of EXPAND and its usefullness References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000702070308050908070001" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000702070308050908070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: >Just my too bits worth. > >In our implementation, we expand out recurrence items on creation (so >STORES:EXPANDED:TRUE). >We set RECUR-LIMIT to specify the max we will fan out on creation >For access of the items after that the other recur >properties/parameters don't make much sense. > I do not follow that last sentence. Are you saying that RECUR-LIMIT does not apply to fetch because you have already expanded them? Or are you saying you strip out RRULE and EXRULE and perhaps RDATE and EXDATE? Or are you saying there are no more objects after RECUR-LIMIT? (FYI 'fan out' has another unrelated meaning.). >For query, EXPAND doesn't make sense and we ignore it (whether or not >RECUR-EXPAND is set). > Then the CUA will know this and also understand because you have set STORES-EXPANED to TRUE. >For query, RECUR-LIMIT doesn't make sense, since we only want it to >apply to storage. >Can we abstract the limit to just be a limit (say QUERY-LIMIT) of any >items returned? > If a CUA gets RECUR-LIMIT:L and STORES-EXPANDED:TRUE, then it that is exactly you situation. The CUA will know that it will get up to 'L' instances of a UID and that any over 'L' are not on that CS. No need for a separate limit property or parameter for STORES-EXPANED:TRUE CS's, the limit can only apply to storage as such a CS does not expand the instances at query time. >For query, RECUR-EXPAND doesn't make sense, since the items are already >expanded. > Yes, when it does apply is when STORES-EXPANDED:FALSE CS's set RECUR-LIMIT:L, then you will know that you can just re-query starting from the last date/time fetched and that you will get up to 'L' more. >There is a little problem on RECUR-LIMIT applying to storage and >query. >In the case of 2) below, the absence of RECUR-LIMIT would mean no >limit. >The problem arises if you have to have it be two limits (storage and >query). > For a STORES-EXPANDED:TRUE CS, they will never be able to return more than RECUR-LIMIT objects for a single UID. So they do not need a separate fetch limit because you can not put in more objects in a EXPAND:TRUE CS than what the CS itself stored when the CS expanded the instances. They will always be the same for such a CS. For a STORES-EXPANDED:FALSE CS, then they store the raw unexpended object so no need for a separate store RECUR-LIMIT as it is meaningless. For such a CS RECUR-LIMIT only applies to expanding of objects at fetch time. One RECUR-LIMIT and STORES-EXPANDED covers it. >On creation we just expand out the item to the limit we can. >We have no way of passing back a status saying, we would have created >more. > No need as the CUA which sent the object already knows it is a recurring object (it sent it) and it already had seen your RECUR-LIMIT capability. >(We've just documented it in the past and our customers know to work >around the limitations.) >We have no way of adding to an existing recurrence set. > METHOD:ADD ? Or did you mean once RECUR-LMIIT instances have been stored by your implementation that your implementation can not ADD more? Or did you men once RECUR-LMIIT instances have been stored by your implementation that your implementation can not inform the CUA that there should have been more? I might suggest that you store a private object with the original recurrence rules in it, when the end is hit silently expand SOME-PRIVATE-RECUR-LIMIT more, and then return or also include the results to that? Then you can set RECUR-LIMIT large and STORES-EXPANDED to TRUE and the CUA will never know that you are somewhat expanding at run time. >How would you reflect that functionality in CAP, >"IF-YOU-CREATE-A-RECURRENCE-ITEM-AND-IT-EXCEEDS-THE-LIMIT" what happens >flag? > The CUA knows it is a recurring object and it has seen your RECUR-LIMT. -- 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 --------------ms000702070308050908070001 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 9w0BCQUxDxcNMDMxMjEyMjIxNzI0WjAjBgkqhkiG9w0BCQQxFgQUDhAtXGL1e3S8kOS93Ce+ NFCg234wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAZwq6bhUi5mBBOXm+Sew56Q2ScS2RbCuRQ2GKD5BjSanBBNnicBcdKmFY0W+DNqdT uudQgq7GwXANWD1qtmeJV+99XdOzHb6ptwWLeSO7uU3xx8TSO0PhYbIzVxKJ3NggGXay0x20 oDqSDuDtLEy18kt2oL0E+z5dhZ0mx7pgkPrGfq/y1qFxVRJhALbckfeutJfxYJvF9saPxDLh IKGEyRGOe5cr/o8Zmj4nD4spHjdoghfuota+k7ODlMDyzQ1kaV8JBT+p33M1DUYH3um2b/NX FE0PQtx0Fyl5Ywd1BoBLpexq+kNrnNAk0dJrFzThkxZnaD16hq5j6IGW5gJS/QAAAAAAAA== --------------ms000702070308050908070001-- From owner-ietf-calendar@mail.imc.org Fri Dec 12 17:41:55 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00475 for ; Fri, 12 Dec 2003 17:41: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 hBCMV4ib027568 for ; Fri, 12 Dec 2003 14:31:04 -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 hBCMV4ig027567 for ietf-calendar-bks; Fri, 12 Dec 2003 14:31:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCMV2ib027558 for ; Fri, 12 Dec 2003 14:31:03 -0800 (PST) (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 hBCMUxYu001026 for ; Fri, 12 Dec 2003 15:30:59 -0700 (MST) Message-ID: <3FDA41A3.66119A9A@INET-Calendar.net> Date: Fri, 12 Dec 2003 15:30:59 -0700 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: DTSTART for recurrence instances References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > "Mark Smith" wrote in message > news:3FDA25D3.4A81571B@INET-Calendar.net... > > > > Michael Fair wrote: > > > > > > "Mark Smith" wrote in message > > > news:3FD9138F.B5E9C8F4@INET-Calendar.net... > > > > > > > > Michael Fair wrote: > > > > > > > > > The RECURRENCE-IDs are derived from the set described by the object > > > > > with the UID in question but no RECURRENCE-ID property. period. > > > > > The RECURRENCE-ID MUST NEVER be derived from the instance itself. > > > > > If the instance is being stored as a separate object in the CS it > > > > > must also track the RECURRENCE-ID value originally assigned to it. > > > > > > > > How would the CS used by attendee-2 ever have that history in > > > > order to find or track the originall and RECURRENCE-ID? > > > > > > Attendee-2 received a sequence of messages that: > > > > > > a) defined a 3peat event (UID:XXX/SEQ:0) > > > b) redefined that event to be a 2peat event (UID:XXX/SEQ:1) > > > c) added a 3rd instance (using ADD) (UID:XXX/SEQ:2) > > > > You did not follow the example that was sent and that was not the > > question. > > Could you please expand on this response? Would you please clarify > for me the example you think was sent that I am not following? > > Here is what I followed: > > There were four total examples sent, named methods A, B, C, and D. > Attendee-2 used method A or B. The example Doug displayed of the > Calendar store was clearly from Method B but I understood why it > could have been A or B because both methods A and B were fundamentally > the same. The only difference was the method used to construct the > set in step b above (A used RDATE, B used RRULE). Method B did NOT send a sequence starting at ZERO to attendee-2. Attendee-2 was not invited until sequence:2. So no such history exists in attende-2's CS. The ONLY way that attendee-2 can expand the instances for the object it was invited to is from the object it self. I can ftp or webdav fetch a sequence:2 .ics file, or get an imip sequence:2 method:request object all by itself. So, it can not be true that the expansion of the sequence:2 object depends on recurrence-id's that pre date the sequence:2 object because attendee-2 will not have that history. Nor will any other attendee that does not get invited in the initial request. From owner-ietf-calendar@mail.imc.org Fri Dec 12 17:58: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 RAA01005 for ; Fri, 12 Dec 2003 17:58:30 -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 hBCMmCib028783 for ; Fri, 12 Dec 2003 14:48:12 -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 hBCMmCJb028782 for ietf-calendar-bks; Fri, 12 Dec 2003 14:48:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from xgate.provo.novell.com (xgate.provo.novell.com [137.65.47.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCMmAib028770 for ; Fri, 12 Dec 2003 14:48:11 -0800 (PST) (envelope-from PStephenson@gw.novell.com) Received: from PROVO7-MTA by xgate.provo.novell.com with Novell_GroupWise; Fri, 12 Dec 2003 15:42:29 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Fri, 12 Dec 2003 15:49:48 -0700 From: "Preston Stephenson" To: Subject: Re: (RECUR-LIMIT) The intent/meaning of EXPAND and its usefullness 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 >Preston Stephenson wrote: >>Just my too bits worth. >> >>In our implementation, we expand out recurrence items on creation (so >>STORES:EXPANDED:TRUE). >>We set RECUR-LIMIT to specify the max we will fan out on creation >>For access of the items after that the other recur >>properties/parameters don't make much sense. >> >I do not follow that last sentence. Are you saying that RECUR-LIMIT does >not apply >to fetch because you have already expanded them? Or are you saying you >strip out RRULE and EXRULE and perhaps RDATE and EXDATE? >Or are you saying there are no more objects after RECUR-LIMIT? I just meant RECUR-EXPAND, RECUR-LIMIT. >(FYI 'fan out' has another unrelated meaning.). I know, sorry. >>For query, EXPAND doesn't make sense and we ignore it (whether or not >>RECUR-EXPAND is set). >> >Then the CUA will know this and also understand because you have >set STORES-EXPANED to TRUE. There is a little confusion in the text then. It would be helpful if it explicitly states that if STORES-EXPANDED is true, RECUR-EXPAND, RECUR-LIMIT, EXPAND are ignored. At least is that what you said above? >>For query, RECUR-LIMIT doesn't make sense, since we only want it to >>apply to storage. >>Can we abstract the limit to just be a limit (say QUERY-LIMIT) of any >>items returned? >> >If a CUA gets RECUR-LIMIT:L and STORES-EXPANDED:TRUE, then it that >is exactly your situation. The CUA will know that it will get up to 'L' >instances >of a UID and that any over 'L' are not on that CS. >No need for a separate limit property or parameter for STORES-EXPANED:TRUE >CS's, the limit can only apply to storage as such a CS does not expand >the instances >at query time. >>For query, RECUR-EXPAND doesn't make sense, since the items are already >>expanded. >> >Yes, when it does apply is when STORES-EXPANDED:FALSE CS's >set RECUR-LIMIT:L, then you will know that you can just re-query >starting from >the last date/time fetched and that you will get up to 'L' more. >>There is a little problem on RECUR-LIMIT applying to storage and >>query. >>In the case of 2) below, the absence of RECUR-LIMIT would mean no >>limit. >>The problem arises if you have to have it be two limits (storage and >>query). >> >For a STORES-EXPANDED:TRUE CS, they will never be able to return more >than RECUR-LIMIT objects for a single UID. So they do not need a separate >fetch limit because you can not put in more objects in a EXPAND:TRUE >CS than what the CS itself stored when the CS expanded the instances. >They will always be the same for such a CS. >For a STORES-EXPANDED:FALSE CS, then they store the raw unexpended >object so no need for a separate store RECUR-LIMIT as it is meaningless. >For such a CS RECUR-LIMIT only applies to expanding of objects at fetch >time. >One RECUR-LIMIT and STORES-EXPANDED covers it. >>On creation we just expand out the item to the limit we can. >>We have no way of passing back a status saying, we would have created >>more. >> >No need as the CUA which sent the object already knows it is a recurring >object (it >sent it) and it already had seen your RECUR-LIMIT capability. >>(We've just documented it in the past and our customers know to work >>around the limitations.) >>We have no way of adding to an existing recurrence set. >> >METHOD:ADD ? We can't support METHOD:ADD. They have to create a new recurrence set or delete the old set and create a new one. >Or did you mean once RECUR-LMIIT instances have been stored by your >implementation that your implementation can not ADD more? >Or did you men once RECUR-LMIIT instances have been stored by your >implementation that your implementation can not inform the CUA that >there should have been more? I might suggest that you store a private >object with the original recurrence rules in it, when the end is hit >silently >expand SOME-PRIVATE-RECUR-LIMIT more, and then return or also include >the results to that? Then you can set RECUR-LIMIT large and >STORES-EXPANDED to TRUE and the CUA will never know that you >are somewhat expanding at run time. It hasn't been a problem as of yet. We are looking to add support for full recurrence in the future. >>How would you reflect that functionality in CAP, >>"IF-YOU-CREATE-A-RECURRENCE-ITEM-AND-IT-EXCEEDS-THE-LIMIT" what happens >>flag? >> >The CUA knows it is a recurring object and it has seen your RECUR-LIMT. > >-- > >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 Thanks for your input. Preston From owner-ietf-calendar@mail.imc.org Fri Dec 12 18:23: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 SAA03176 for ; Fri, 12 Dec 2003 18:23: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 hBCNDpib029835 for ; Fri, 12 Dec 2003 15:13:51 -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 hBCNDpj8029834 for ietf-calendar-bks; Fri, 12 Dec 2003 15:13:51 -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 hBCNDoib029829 for ; Fri, 12 Dec 2003 15:13:50 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:Oqu07y/GuDEFJV5E+VCgq918fJ6YeEUL@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBCNDlZf024921 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 Dec 2003 15:13:49 -0800 Message-ID: <3FDA4BAA.7070608@Royer.com> Date: Fri, 12 Dec 2003 16:13:46 -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: (RECUR-LIMIT) The intent/meaning of EXPAND and its usefullness References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010005080103090902020102" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010005080103090902020102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > >There is a little confusion in the text then. >It would be helpful if it explicitly states that if STORES-EXPANDED is >true, >RECUR-EXPAND, RECUR-LIMIT, EXPAND are ignored. >At least is that what you said above? > I have made a note. Suggested text changes? You might want to use the new bugzilla recently posted and add it as an issue. >We can't support METHOD:ADD. >They have to create a new recurrence set or delete the old set and >create a new one. > > Okay, then that is an iTIP issues, not a CAP issue. The iTIP objects would react the same as in iMIP and thus no such additional instances could be added at the iTIP level. -- 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 --------------ms010005080103090902020102 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 9w0BCQUxDxcNMDMxMjEyMjMxMzQ2WjAjBgkqhkiG9w0BCQQxFgQUoReoDNkZ578n//XRcPDj FQ4WFXAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAB0CY+2zh2WL4vppDIEHmHVbe/TqMzyZEcNnFQt28B9OuJxrZ8NmLtZpkBh+eGymL S9bNaRJ5H27fTyYXsX34G3Qf9wmDWkGvm+8119/YU7GrPFnTz75wpb/Z7xMGFk+QdgDD90Jq J27ixvycqkw+CeVs1+kU+V7oAgKco0AF1XAB9X97jMrmxegY905aFJ0rtO4i5CvEVqszss/C PMVqHwU1Y3y/5q86P1akRT9+27blNB2DQaF0t4JLg3GVXjwzwbTKyxjKCyaDdBdbncIAuXaQ bozshw4TDIDlfiUhKCBJiqON+z+RciF4DUuWhGZI02U/c3dLqoImHJk8vs+HTwAAAAAAAA== --------------ms010005080103090902020102-- From owner-ietf-calendar@mail.imc.org Fri Dec 12 19:36: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 TAA05300 for ; Fri, 12 Dec 2003 19:36:43 -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 hBD0MDib033373 for ; Fri, 12 Dec 2003 16:22:13 -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 hBD0MDgl033372 for ietf-calendar-bks; Fri, 12 Dec 2003 16:22:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBD0MAib033362 for ; Fri, 12 Dec 2003 16:22:11 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUxXr-00021t-00 for ; Sat, 13 Dec 2003 01:22:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUxXq-00021k-00 for ; Sat, 13 Dec 2003 01:22:06 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUxXq-00028b-00 for ; Sat, 13 Dec 2003 01:22:06 +0100 From: "Michael Fair" Subject: What if the first meesage is an ADD? Date: Fri, 12 Dec 2003 16:22:09 -0800 Lines: 89 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've retitled the thread since we are no clearly on a different topic. > Method B did NOT send a sequence starting at ZERO to attendee-2. > Attendee-2 was not invited until sequence:2. So no such history exists > in attende-2's CS. The ONLY way that attendee-2 can expand > the instances for the object it was invited to is from the object > it self. My apologies. The example was hard for me to follow. I obviously did not understand that Attendee-2 did not receive all the messages. In the future, if you could clear up such misunderstandings in your first reponse it would be appreciated and cut down on the bandwidth. Thank you. In terms of constructing the set of RECURRENCE-IDs, enumerating the set described by an ADD or REQUEST with a UID only message is absolute in terms of defining the valid RECURRENCE-IDs. So reconstructing Attendee-2's CS if it did not receive messages a or b (SEQ:0 and 1 respectively) the CUA will look in its store for UID:XXX and not find it. The results are undefined. However, consistent with iTIP's mandate to handle lost and missequenced messages it should treat the ADD like a REQUEST and then since it obviously is missing data (as evidneced by both a SEQ:2 and that it has just received an ADD for a non-existant event (i.e. way out of context for the UID)) it sends a REFRESH request to the ORGANIZER. This results in the "2-dec-2003 at 3:30" instance being put on the calendar immediately and requesting the missing info. THe CS ends up with exactly 2 objects: 1) UID:XXX/SEQ:2 - a set describing an event 2-dec-2003 at 3:30 2) UID:XXX/RECURRENCE-ID:2-dec-2003 at 3:30/SEQ:2 - the instance in question. The RECURRENCE-ID is "at 3:30", not because it doesn't have prior info and had to take it from the instance object, but because taking it from the DTSTART is the right thing to do. An ADD is a set defining moment. Even if it had the prior info it would still do exactly the same thing. It's not forced to use DTSTART because of lack of info. It does so because that's what the standard says to do. An ADD will increase the number of instances present in a recurring event. It figures out the _newly created_ RIDs by expanding the set described by the ADD message and merging that set with the prior definition. The RID calculation is no different than using the DTSTART value to figure out what the RECURRENCE-IDs are for a new REQUEST. These messages are the first time these instance have ever come into existence and therefore use the initial DTSTART as the RECURRENCE-ID. However, once defined, they persist from that point forward until the RID is no longer part of the set described by the rules of UID only object. > I can ftp or webdav fetch a sequence:2 .ics file, or get an imip > sequence:2 method:request object all by itself. But the example didn't use a method:request object, it used a method:add. If it had used sequence:2 method:request object then it would have redefined the whole series to be a singleton. 1-dec-2003 and 3-dec-2003 would have been erased. There would have been no need to send a REFRESH because it clearly has the most recent information. > So, it can not be > true that the expansion of the sequence:2 object depends on > recurrence-id's that pre date the sequence:2 object because > attendee-2 will not have that history. The expansion of the sequence 2 object itself doesn't depend on prior data, but the very nature of the "add" message certainly does. An ADD unlike a REQUEST is not an authoritative description of the entire event. It is an addendum to the existing data. Therefore, by definition an ADD depends on prior data. If that data is absent the CUA should send for a REFRESH. So what's the question? -- Michael -- From owner-ietf-calendar@mail.imc.org Fri Dec 12 20:10:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06998 for ; Fri, 12 Dec 2003 20:10:26 -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 hBD10Wib034966 for ; Fri, 12 Dec 2003 17:00: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 hBD10WfH034965 for ietf-calendar-bks; Fri, 12 Dec 2003 17:00:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBD10Vib034957 for ; Fri, 12 Dec 2003 17:00:31 -0800 (PST) (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 hBD10TYu001382 for ; Fri, 12 Dec 2003 18:00:29 -0700 (MST) Message-ID: <3FDA64AD.5FA13AEB@INET-Calendar.net> Date: Fri, 12 Dec 2003 18:00:29 -0700 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: request + add References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > So reconstructing Attendee-2's CS if it did not receive messages a or b > (SEQ:0 and 1 respectively) the CUA will look in its store for UID:XXX and > not find it. > > The results are undefined. > > However, consistent with iTIP's mandate to handle lost and missequenced > messages it should treat the ADD like a REQUEST and then since it obviously > is missing data (as evidneced by both a SEQ:2 and that it has just received > an ADD for a non-existant event (i.e. way out of context for the UID)) it > sends a REFRESH request to the ORGANIZER. Okay, now what if it gets the sequence:1 request and the sequence:2 'add' as shown in 'B'. As all three instances can not be represented in one 'method request' object because the duration of all three instances are not the same. Now the master object is at sequence:2, as is attendee-2. The recurrence-id's can be calculated from what attendee-2 has. Correct? And it will be the same recurrence-id's as organizer. Correct? From owner-ietf-calendar@mail.imc.org Fri Dec 12 21:54:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10454 for ; Fri, 12 Dec 2003 21:54:07 -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 hBD2fwib039942 for ; Fri, 12 Dec 2003 18:42:00 -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 hBD2fw2e039941 for ietf-calendar-bks; Fri, 12 Dec 2003 18:41:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBD2fsib039936 for ; Fri, 12 Dec 2003 18:41:56 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUzjA-0003fp-00 for ; Sat, 13 Dec 2003 03:41:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUzj9-0003fg-00 for ; Sat, 13 Dec 2003 03:41:55 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUzj9-000509-00 for ; Sat, 13 Dec 2003 03:41:55 +0100 From: "Michael Fair" Subject: Re: request + add Date: Fri, 12 Dec 2003 18:41:58 -0800 Lines: 140 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I need to apologize for getting the original examples wrong again. All of Doug's examples moved the 2nd instance from noon to 2pm not noon to 3:30. To remain consistent with the previous posts I made I am going to continue using 3:30 as the start time for the added instance. It will still be 1.5 hours long, making the new time be from 3:30pm-5pm (instead of being from 2pm-3:30pm). I'm sorry for not reading it right to begin with. "Mark Smith" wrote in message news:3FDA64AD.5FA13AEB@INET-Calendar.net... > > Michael Fair wrote: > > > > > So reconstructing Attendee-2's CS if it did not receive messages a or b > > (SEQ:0 and 1 respectively) the CUA will look in its store for UID:XXX and > > not find it. > > > > The results are undefined. > > > > However, consistent with iTIP's mandate to handle lost and missequenced > > messages it should treat the ADD like a REQUEST and then since it obviously > > is missing data (as evidneced by both a SEQ:2 and that it has just received > > an ADD for a non-existant event (i.e. way out of context for the UID)) it > > sends a REFRESH request to the ORGANIZER. > > Okay, now what if it gets the sequence:1 request and the sequence:2 'add' > as shown in 'B'. As all three instances can not be represented in > one 'method request' object because the duration of all three instances > are not the same. Now the master object is at sequence:2, as is > attendee-2. This can actually be described in one method:request object as I'll demonstrate below in response to a REFRESH request. You are right if what you meant was that it can't be described in 1 VEVENT component. > The recurrence-id's can be calculated from what attendee-2 has. Correct? > And it will be the same recurrence-id's as organizer. Correct? This sounds correct, but since we haven't rescheduled any of the instances yet it's not all that meaningful... I'm also not sure if you're playing with the ordering of the messages so I'll address both orderings. I apologize if I'm overcomplicating your assertions, but the terse style and my past mistakes at misunderstanding your questions makes me doubt that I understand everything you're asking. Both scenarios will end up with matching RIDs (matching between ORG and A2). I just want to be sure we're clear about how/why. I also think a more meaningful example would be to use something that actually uses an instance reschedule in the mix since that's when DTSTART and RECURRENCE-ID are no longer in sync, but I'm following your lead at the moment (for instance, request - instance reschedule - add). Scenario 1: If A2 receives S1(request) then S2(add) then the CUA will not send a REFRESH. Upon receipt of S1 the CUA will store 1-Dec and 3-Dec instances along with the UID:XXX object in the CS all at SEQ:1. At this point the RIDs for UID:XXX on both ends will be: 1-Dec-2003 at noon 3-Dec-2003 at noon Then upon receipt of S2 it will store the data for instace 2-Dec, merge the DTSTART, RRULE/RDATE and EXRULE/EXDATE values from S2 (if there are any) with the ones from S1 and update the UID:XXX object with the new info. It also update the UID:XXX object and the instances 1-Dec and 3-Dec to be at SEQ:2. The RIDs for UID:XXX on both ends are now: 1-Dec-2003 at noon 3-Dec-2003 at noon 2-Dec-2003 at 3:30 If A2 receives S2 (add) then S1 (request) then the CUA will send a REFRESH. After the receipt of S2 the RIDS in the CS for UID:XXX are: 2-Dec-2003 at 3:30 It will ignore S1 and not be synchronized until the REFRESH response arrives. The ORGANIZER will send the following message in response to the REFRESH: BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VEVENT UID:XXX SEQUENCE:2 ... DTSTART: 1-dec-2003 at noon DTEND: 1-dec-2003 at 1pm ... RDATE:3-dec-2003 at noon RDATE:2-dec-2003 at 3:30 END:VEVENT BEGIN:VEVENT UID:XXX RECURRENCE-ID:2-dec-2003 at 3:30 SEQUENCE:2 ... DTSTART: 2-dec-2003 at 3:30 DTEND: 2-dec-2003 at 5pm ... END:VEVENT END:VCALENDAR (As an aside, had the ORGANIZER done a normal reschedule, then the RDATE and RECURRENCE-ID values would be "at noon" and the SEQUENCE would most likely be 1. Other then that, the response would be the same.) After receipt of the REFRESH response the two CS' would be in sync. -- Michael -- PS I am concerned that at some point in this thread you might try and bring A1 who received the proper instance reschedule message back into this and say the RIDs don't match. However, that can't legally happen because it would violate the uniqueness of UID:XXX and is an entirely different conversation. From owner-ietf-calendar@mail.imc.org Sat Dec 13 13:26:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09694 for ; Sat, 13 Dec 2003 13:26:57 -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 hBDIErib053393 for ; Sat, 13 Dec 2003 10:14:54 -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 hBDIEr4D053392 for ietf-calendar-bks; Sat, 13 Dec 2003 10:14:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBDIEqib053378 for ; Sat, 13 Dec 2003 10:14:52 -0800 (PST) (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 hBDIEmYu002578 for ; Sat, 13 Dec 2003 11:14:48 -0700 (MST) Message-ID: <3FDB5718.62178574@INET-Calendar.net> Date: Sat, 13 Dec 2003 11:14:48 -0700 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: request + add References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > > > Okay, now what if it gets the sequence:1 request and the sequence:2 'add' > > as shown in 'B'. As all three instances can not be represented in > > one 'method request' object because the duration of all three instances > > are not the same. Now the master object is at sequence:2, as is > > attendee-2. > > This can actually be described in one method:request object as I'll > demonstrate below in response to a REFRESH request. You are right > if what you meant was that it can't be described in 1 VEVENT component. However you did not do a request+add below which was the question. You did a request + single instance reschedule. > > The recurrence-id's can be calculated from what attendee-2 has. Correct? > > And it will be the same recurrence-id's as organizer. Correct? > > This sounds correct, but since we haven't rescheduled any of the instances > yet it's not all that meaningful... As this topic is part of EXPAND:TRUE debate - yes it is valid. Your example below is not the one asked. > > The ORGANIZER will send the following message in response to the REFRESH: > BEGIN:VCALENDAR > METHOD:REQUEST > > BEGIN:VEVENT > UID:XXX > SEQUENCE:2 > ... > DTSTART: 1-dec-2003 at noon > DTEND: 1-dec-2003 at 1pm > ... > RDATE:3-dec-2003 at noon > RDATE:2-dec-2003 at 3:30 > END:VEVENT > > BEGIN:VEVENT > UID:XXX > RECURRENCE-ID:2-dec-2003 at 3:30 > SEQUENCE:2 > ... > DTSTART: 2-dec-2003 at 3:30 > DTEND: 2-dec-2003 at 5pm > ... > END:VEVENT > > END:VCALENDAR > From owner-ietf-calendar@mail.imc.org Sun Dec 14 15:08:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23242 for ; Sun, 14 Dec 2003 15:08:07 -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 hBEJqiib081215 for ; Sun, 14 Dec 2003 11:52:44 -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 hBEJqias081214 for ietf-calendar-bks; Sun, 14 Dec 2003 11:52:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBEJqeib081203 for ; Sun, 14 Dec 2003 11:52:42 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AVcI9-0007ly-00 for ; Sun, 14 Dec 2003 20:52:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AVcI7-0007lq-00 for ; Sun, 14 Dec 2003 20:52:35 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AVcI7-0002if-00 for ; Sun, 14 Dec 2003 20:52:35 +0100 From: "Michael Fair" Subject: Re: request + add Date: Sun, 14 Dec 2003 11:52:40 -0800 Lines: 122 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Mark Smith" wrote in message news:3FDB5718.62178574@INET-Calendar.net... > > Michael Fair wrote: > > > > > > > Okay, now what if it gets the sequence:1 request and the sequence:2 'add' > > > as shown in 'B'. As all three instances can not be represented in > > > one 'method request' object because the duration of all three instances > > > are not the same. Now the master object is at sequence:2, as is > > > attendee-2. > > > > This can actually be described in one method:request object as I'll > > demonstrate below in response to a REFRESH request. You are right > > if what you meant was that it can't be described in 1 VEVENT component. > > However you did not do a request+add below which was the question. > You did a request + single instance reschedule. I'm not quite sure how to respond to this. I assure you that I responded accurately and completely to a request+add. You have neither corrected me by putting forth your expectation nor have you done anything other than just assert the belief that I didn't respond to the example when I have. If you have a different answer I ask that you present it and refrain from just stating that you believe someone's answer isn't correct. If you do not know what the correct answer should be then you should state that in your email. I believe what I believe and I can back up what I've presented (it's a very long email which I'm really inclined to create unless it really needs to be done). You saying that I didn't answer the question is not going to help me understand the question you think is being asked or how my answer is somehow invalid. > > > The recurrence-id's can be calculated from what attendee-2 has. Correct? > > > And it will be the same recurrence-id's as organizer. Correct? > > > > This sounds correct, but since we haven't rescheduled any of the instances > > yet it's not all that meaningful... > > As this topic is part of EXPAND:TRUE debate - yes it is valid. > > Your example below is not the one asked. The question asked was a REQUEST followed by an ADD. The first response in my email covered that. Because of my uncertainty about what you were asking I decided to cover my bases and also show what would happen if A2 received an ADD as the first message in the sequence. You said that A2 didn't see the event until SEQ:2. SEQ:2 was an ADD message. Therefore it would generate REFRESH request when the CUA received it. The ORGRANIZER would then respond with a single REQUEST message that encapsulated the entire current state of UID:XXX. This "current state" would include the merged sets of events from the SEQ:1 state and the "ADD message" resulting in the RDATEs described. As you pointed out, the second instance is 1.5 hours long and not 1 hour long. This cannot be represented in a single VEVENT component. The method outlined in the standard for relaying per instance specific data is to use multiple VEVENT components. You may use multiple VEVENT components in the same message if and only if all VEVENT components reference the same UID. What was sent below is not a REQUEST followed by a RESCHEDULE. That would be two separate and distinct messages. What was sent is a single REQUEST message. Describing the SEQ:2 state of UID:XXX. Generated in response to a REFRESH request from the CUA when it received the "ADD" message. > > > > The ORGANIZER will send the following message in response to the REFRESH: > > BEGIN:VCALENDAR > > METHOD:REQUEST > > > > BEGIN:VEVENT > > UID:XXX > > SEQUENCE:2 > > ... > > DTSTART: 1-dec-2003 at noon > > DTEND: 1-dec-2003 at 1pm > > ... > > RDATE:3-dec-2003 at noon > > RDATE:2-dec-2003 at 3:30 > > END:VEVENT > > > > BEGIN:VEVENT > > UID:XXX > > RECURRENCE-ID:2-dec-2003 at 3:30 > > SEQUENCE:2 > > ... > > DTSTART: 2-dec-2003 at 3:30 > > DTEND: 2-dec-2003 at 5pm > > ... > > END:VEVENT > > > > END:VCALENDAR > > How is this not the example given? How is this not the question asked? -- Michael -- From owner-ietf-calendar@mail.imc.org Sun Dec 14 16:10: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 QAA25579 for ; Sun, 14 Dec 2003 16:10:56 -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 hBEKw8ib083422 for ; Sun, 14 Dec 2003 12:58: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 hBEKw7Yl083421 for ietf-calendar-bks; Sun, 14 Dec 2003 12:58:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBEKw6ib083415 for ; Sun, 14 Dec 2003 12:58:06 -0800 (PST) (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 hBEKw3Yu005708 for ; Sun, 14 Dec 2003 13:58:03 -0700 (MST) Message-ID: <3FDCCEDB.CB58B505@INET-Calendar.net> Date: Sun, 14 Dec 2003 13:58:03 -0700 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: request + add References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > "Mark Smith" wrote in message > news:3FDB5718.62178574@INET-Calendar.net... > > > > Michael Fair wrote: > > > > > > > > > > Okay, now what if it gets the sequence:1 request and the sequence:2 > 'add' > > > > as shown in 'B'. As all three instances can not be represented in > > > > one 'method request' object because the duration of all three > instances > > > > are not the same. Now the master object is at sequence:2, as is > > > > attendee-2. > > > > > > This can actually be described in one method:request object as I'll > > > demonstrate below in response to a REFRESH request. You are right > > > if what you meant was that it can't be described in 1 VEVENT component. > > > > However you did not do a request+add below which was the question. > > You did a request + single instance reschedule. > > I'm not quite sure how to respond to this. > I assure you that I responded accurately and completely to a request+add. Re check what you send, there is NOT a ADD. > > > BEGIN:VEVENT > > > UID:XXX > > > RECURRENCE-ID:2-dec-2003 at 3:30 > > > SEQUENCE:2 > > > ... > > > DTSTART: 2-dec-2003 at 3:30 > > > DTEND: 2-dec-2003 at 5pm > > > ... > > > END:VEVENT > > > > > > END:VCALENDAR > > > > > How is this not the example given? The example given was ADD which is NOT the object above. See the original post and section "3.2.4 ADD" in iTIP. > How is this not the question asked? From owner-ietf-calendar@mail.imc.org Sun Dec 14 17:45:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28702 for ; Sun, 14 Dec 2003 17:45:43 -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 hBEMTIib087580 for ; Sun, 14 Dec 2003 14:29: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 hBEMTI8U087579 for ietf-calendar-bks; Sun, 14 Dec 2003 14:29:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBEMTEib087573 for ; Sun, 14 Dec 2003 14:29:16 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AVejj-0001cy-00 for ; Sun, 14 Dec 2003 23:29:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AVeji-0001cq-00 for ; Sun, 14 Dec 2003 23:29:14 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AVeji-0002hl-00 for ; Sun, 14 Dec 2003 23:29:14 +0100 From: "Michael Fair" Subject: Re: request + add Date: Sun, 14 Dec 2003 14:29:19 -0800 Lines: 77 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> <3FDCCEDB.CB58B505@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Mark Smith" wrote in message news:3FDCCEDB.CB58B505@INET-Calendar.net... > > Michael Fair wrote: > > > > "Mark Smith" wrote in message > > news:3FDB5718.62178574@INET-Calendar.net... > > > > > > Michael Fair wrote: > > > > > > > > > > > > > Okay, now what if it gets the sequence:1 request and the sequence:2 > > 'add' > > > > > as shown in 'B'. As all three instances can not be represented in > > > > > one 'method request' object because the duration of all three > > instances > > > > > are not the same. Now the master object is at sequence:2, as is > > > > > attendee-2. > > > > > > > > This can actually be described in one method:request object as I'll > > > > demonstrate below in response to a REFRESH request. You are right > > > > if what you meant was that it can't be described in 1 VEVENT component. > > > > > > However you did not do a request+add below which was the question. > > > You did a request + single instance reschedule. > > > > I'm not quite sure how to respond to this. > > I assure you that I responded accurately and completely to a request+add. > > Re check what you send, there is NOT a ADD. > > > > > BEGIN:VEVENT > > > > UID:XXX > > > > RECURRENCE-ID:2-dec-2003 at 3:30 > > > > SEQUENCE:2 > > > > ... > > > > DTSTART: 2-dec-2003 at 3:30 > > > > DTEND: 2-dec-2003 at 5pm > > > > ... > > > > END:VEVENT > > > > > > > > END:VCALENDAR > > > > > > > > How is this not the example given? > > The example given was ADD which is NOT the object above. > See the original post and section "3.2.4 ADD" in iTIP. I think you are misunderstanding what object it is that's being described here. Here's what happened: Organizer sends an ADD A2 having determined that it missed something requests a REFRESH Organizer sends a REQUEST in response to the REFRESH The object above that you keep saying is not an ADD, but imply should be an ADD, is the response object from the ORGANIZER to A2's REFRESH request. It is not an ADD (just as you said) and should not be an ADD (as you are implying). The above object is a recurring event that has per instance data which needs to be communicated. The above object is the proper object with which describe the complete state of UID:XXX at SEQ:2. What else could it be? -- Michael -- From owner-ietf-calendar@mail.imc.org Sun Dec 14 18:33: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 SAA01945 for ; Sun, 14 Dec 2003 18:33: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 hBENKUib089132 for ; Sun, 14 Dec 2003 15:20:30 -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 hBENKU2o089131 for ietf-calendar-bks; Sun, 14 Dec 2003 15:20:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBENKTib089126 for ; Sun, 14 Dec 2003 15:20:29 -0800 (PST) (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 hBENKQYu006375 for ; Sun, 14 Dec 2003 16:20:26 -0700 (MST) Message-ID: <3FDCF03A.6F2775CD@INET-Calendar.net> Date: Sun, 14 Dec 2003 16:20:26 -0700 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: request + add References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> <3FDCCEDB.CB58B505@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > > > The example given was ADD which is NOT the object above. > > See the original post and section "3.2.4 ADD" in iTIP. > > I think you are misunderstanding what object it is that's being > described here. So the question (restated) is: Once attendee-2 gets 'B' which is an 'add' (not some other things). As that is a valid way to invite an attendee. Do you agree that once 'B' is complete then attendee-2 can only get the recurrence-id's from what it has those objects described in 'B'. As attendee-2 attendee-2 will never have the sequence:0 object. A 'refresh' would only return 'A', 'B' or 'C' and not the sequence:0 iTIP message. So it can not be true that you have to have the history of an object to get the recurrence-id's. It also can not be true that the recurrence-id's are tied to the original (0) object. As it would be impossible to change an object that was later added with the add method. The attendee must be able to expand the 'A', 'B', or 'C' objects from themselves. From owner-ietf-calendar@mail.imc.org Sun Dec 14 23:43: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 XAA09677 for ; Sun, 14 Dec 2003 23:43:12 -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 hBF4Rkib097648 for ; Sun, 14 Dec 2003 20:27:47 -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 hBF4RkBi097647 for ietf-calendar-bks; Sun, 14 Dec 2003 20:27:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBF4Rjib097640 for ; Sun, 14 Dec 2003 20:27:45 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (rwcrmhc12) with SMTP id <20031215042742014000p4sse> (Authid: TimHare); Mon, 15 Dec 2003 04:27:43 +0000 Message-Id: <5.2.1.1.0.20031214231327.00a4cec0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 14 Dec 2003 23:26:49 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: xCalendar questions 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: On a semi-unrelated project, I'm trying to develop an XML DTD for conference information. I thought it might be good to use some of the xCalendar syntax, using the xCalendar namespace; however it appears that the file does not exist on the IETF site. Has this work been abandoned in favor of something else? If so, can anyone point me to good XML calendar information? I'm no XML expert; I'm working from prior experience with SGML-based markup languages in IBM's product DCF/Script. I have some other questions related to this work, if anyone with XML experience wants to e-mail me privately I have a couple of questions. Thanks Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Mon Dec 15 05:05:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02016 for ; Mon, 15 Dec 2003 05:05:26 -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 hBF9ftib077038 for ; Mon, 15 Dec 2003 01:41:55 -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 hBF9ftJN077037 for ietf-calendar-bks; Mon, 15 Dec 2003 01:41:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBF9fqib077012 for ; Mon, 15 Dec 2003 01:41:53 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AVpEd-0007MU-00 for ; Mon, 15 Dec 2003 10:41:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AVpEc-0007MM-00 for ; Mon, 15 Dec 2003 10:41:50 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AVpEc-0008IX-00 for ; Mon, 15 Dec 2003 10:41:50 +0100 From: "Michael Fair" Subject: Re: DTSTART for recurrence instances Date: Mon, 15 Dec 2003 01:41:51 -0800 Lines: 85 Message-ID: References: <3FD76CEC.453498D6@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Could you add a rule something like: > > Please read the drafts before posting and make sure that what you > are about to say is true before posting. Some people make what > seems to many to be an authoritative statement and after reading > the RFC's or submitted drafts, they seem to have ignored specific > parts of the text or declare it as (not valid). So such topics > need to be tagged as 'iCal-next', 'itip-next' or whatever so they > do not get confused with a discussion about what has actually been > submitted. While I agree that we should all read the drafts before posting, the drafts are HUGE and remember every detail all the time is not something I consider reasonable. Further, it takes a while for most of us to understand what the drafts are really trying to say. I believe that many people are fully capable of being involved and being constructive without having read every word of the drafts. The main problem I have with this is that many of us have the ability to read the exact same things and understand them completely differently, it shuts down the engagement of debate that leads to understanding and compromise through the threat of upsetting the incumbents, and most oftentimes one doesn't know they are talking about iCal next or untruths until after they have been told _and_ shown such (they are trying to understand and make sense of what they've already read and just saying they have it wrong isn't always enough). Further, there is also the topic of hotly debated issues, like the ones surrounding RECURRENCE-IDs and whether or not each instance tracks its own SEQUENCE. We still, as far as I can see, don't have complete agreement on those issues, and we each have read the drafts and interpretted them differently. Further, from what I gather, the most consensus is actually towards an interpretation that must call a particular section of iTIP invalid. This wasn't arrived at lightly. But the ability to invalidate a section of an RFC is a right we must reserve and use when necessary. I'm not saying that we should just invalidate a section whenever it helps our argument. I am saying that discussing and then upon serious reflections choosing to invalidate a section of the RFC must be protected on this WG list. Also, if someone posts information that you believe to be false then you have an obligation to correct them above and beyond just saying they are wrong. If you are not able to correct them, but know they are wrong, then you are obligated to say as much in the interest of moving the conversation forward. Those of us who engage in that practice more often than not are able to clean up misunderstanding in a message or two. Unless there is a clear point of confusion or disagreement, and then it becomes important to identify it and come to consensus. How are we going to know what goes into iCal-next if we don't pursue the conversations that will make it better? Besides who would decide what is false information or when someone has posted enough of it to be kicked out? On most occasions, information that you have called false I have determined to be true... I believe that each of our opinions carries equal weight and therefore we are at a stalemate... In addition, throwing people out just seems wrought with political woe as people take sides on whether or not it should have been done. The WG process depends upon the participants being reasonable and pursuing conversations that lead to forward progress. It depends on the pursuit of training people to be to be stewards for progress and to send each email with the idea of forwarding a conversation not stonewalling it or taking personal joy in trying to stick it to the other party. It requires respect that others may understand things differently than ourselves, and any one of us may have the more workable ideas. Therefore, it becomes paramount to understand each other, and clearly state when there seems to be a misunderstanding. As much as possible we must all consider ourselves on the same team, working toward the same goal. If someone truly is just here to be a troll, then most of us will just ignore that person. If people are in agreement with that person, then perhaps they have something worth saying or are touting a common misunderstanding (which will forever need to be corrected on the list). If that person truly is touting false information and people are buying it, then creating consensus _is_ the most important thing. Sending well constructed emails built on the foundations of the RFCs and demonstrations (non-)workability (if needed) must ensue. -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Dec 15 05:31: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 FAA02507 for ; Mon, 15 Dec 2003 05:31: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 hBFAKEib087102 for ; Mon, 15 Dec 2003 02:20:15 -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 hBFAKEof087101 for ietf-calendar-bks; Mon, 15 Dec 2003 02:20:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFAKCib087096 for ; Mon, 15 Dec 2003 02:20:13 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AVppk-0007lU-00 for ; Mon, 15 Dec 2003 11:20:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AVpph-0007lL-00 for ; Mon, 15 Dec 2003 11:20:09 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AVpph-0000tI-00 for ; Mon, 15 Dec 2003 11:20:09 +0100 From: "Michael Fair" Subject: Re: request + add Date: Mon, 15 Dec 2003 02:20:10 -0800 Lines: 154 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> <3FDCCEDB.CB58B505@INET-Calendar.net> <3FDCF03A.6F2775CD@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Mark Smith" wrote in message news:3FDCF03A.6F2775CD@INET-Calendar.net... > > Michael Fair wrote: > > > > > > > The example given was ADD which is NOT the object above. > > > See the original post and section "3.2.4 ADD" in iTIP. > > > > I think you are misunderstanding what object it is that's being > > described here. > > So the question (restated) is: > > Once attendee-2 gets 'B' which is an 'add' (not some other things). > As that is a valid way to invite an attendee. Where in rfc2446 did you get that? As far as valid invites go, I only see one "valid" way to do an invite: 3.2.2 REQUEST The "REQUEST" method in a "VEVENT" component provides the following scheduling functions: - Invite "Attendees" to an event; Further, section 3.2.4 ADD does not specify what a CUA _must_ do if it receives an ADD for a UID that isn't in the store. 3.2.4 ADD: ... The "UID" must be that of the existing event. If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VEVENT". If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". That very clearly states that ADD is not a valid method of inviting a user to a set of recurring events. Just because a CUA could safely get by utilizing the information that is in the message (which the RFC encourages) does make it a valid method. Further, let me stress _could_. Another legal thing for the CUA to do is to throw the message out and just send a REFRESH request only. The only section that is explcitly blessed as a valid invite is REQUEST. > Do you agree that once 'B' is complete then attendee-2 can > only get the recurrence-id's from what it has those objects > described in 'B'. As attendee-2 attendee-2 will never have > the sequence:0 object. Yes and then no. Once B is complete a generous CUA will only be able to put onto the calendar that which the ADD message describes. However, it sent the REFRESH request and therefore has a REQUEST message coming its way. This REQUEST message has all the data for every currently valid instance in it. So I disagree that A2 will never see the prior info. I want to stress that A2 will never see and has no need to see the SEQ:0 object to construct the most recent version of UID:XXX. So the sentence that A2 will never see the SEQ:0 info is true, but the statement that it will never see earlier information is false. A2 will see the SEQ:1 info. A2 needs only to receive information from SEQ:1 forward because SEQ:1 is the most recent redefinition of the entire set. In our example, once SEQ:1 has been created by the ORGANIZER, the SEQ:0 object becomes completely obsolete and totally useless and irrevocably consigned to be forgotten by all parties interested in UID:XXX. At that moment, the only necessary information comes from the SEQ:1 version of UID:XXX. The same is not true of the SEQ:2 ADD though. It is the combination of the SEQ:1 REQUEST and the SEQ:2 ADD that make up the current state of UID:XXX. That combined state can be encapsulated in a single REQUEST message, and that SEQ:2 ADD message will never be sent to any interested party ever again. It will be sent once and only once to the ATTENDEES and if they have a problem with it that's tough. The ORGANIZER will never generate it for them again as they have no way to ask for that. > A 'refresh' would only return 'A', 'B' or 'C' and not > the sequence:0 iTIP message. I'm not sure I'm following you... Above I thought you were referring to message B, here I'm not sure what A,B, and C are... Here's what I can say though. A REFRESH, once methods A,B or C have completed, will send the exact same response. The single REQUEST message from my prior email. Method D (the proper method) however would give the 2nd instance a different RECURRENCE-ID but otherwise would be the same. In methods A, B and C, the SEQ:0 version of the object is utterly and completely useless. There is no need to see it... ever... by anyone... The SEQ:1 version is the version that has all the valid data to be combined with SEQ:2. A REFRESH would send the combined status of SEQ:1 and SEQ:2 as its response. > So it can not be true that you have to have the history > of an object to get the recurrence-id's. It also can > not be true that the recurrence-id's are tied to the > original (0) object. As it would be impossible to > change an object that was later added with the > add method. The attendee must be able to expand > the 'A', 'B', or 'C' objects from themselves. The "original" is not the same as SEQ:0. The "original" is the most recent REQUEST that does not contain a RECURRENCE-ID for UID:XXX. SEQ:0 is a REQUEST that does not contain a RECURRENCE-ID property. Therefore, it is the "original" at that time. SEQ:1 is also a REQUEST that does not contain a RECURRENCE-ID property. Further, it is more recent than SEQ:0, and therefore it is the new "original" definition of the RECURRENCE-IDs for UID:XXX. SEQ:2 is then an ADD, therefore it gets combined with the most recent version of the original UID:XXX, which in this case is the SEQ:1 version. As a thought experiment, if SEQ:1 had been an instance reschedule instead of a REQUEST without a RECURRENCE-ID, then the most recent "original" definition would have been SEQ:0 and then the information contained in SEQ:0 would be retained. As the example was written however, at the moment of SEQ:1's incarnation, SEQ:0 become completely obsolete and complete unnecessary. The pivotal piece of prior info for the definition of RECURENCE-IDs was no contained in SEQ:1. How we doing? Making progress? -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Dec 15 13:13: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 NAA18840 for ; Mon, 15 Dec 2003 13:13:12 -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 hBFHrSib008509 for ; Mon, 15 Dec 2003 09:53:30 -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 hBFHrSM0008508 for ietf-calendar-bks; Mon, 15 Dec 2003 09:53:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFHrQib008502 for ; Mon, 15 Dec 2003 09:53:27 -0800 (PST) (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 hBFHrNYu007661 for ; Mon, 15 Dec 2003 10:53:23 -0700 (MST) Message-ID: <3FDDF513.4998A6B8@INET-Calendar.net> Date: Mon, 15 Dec 2003 10:53:23 -0700 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: request + add References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> <3FDCCEDB.CB58B505@INET-Calendar.net> <3FDCF03A.6F2775CD@INET-Calendar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > > "Mark Smith" wrote in message > news:3FDCF03A.6F2775CD@INET-Calendar.net... > > > > Michael Fair wrote: > > > > > > > > > > The example given was ADD which is NOT the object above. > > > > See the original post and section "3.2.4 ADD" in iTIP. > > > > > > I think you are misunderstanding what object it is that's being > > > described here. > > > > So the question (restated) is: > > > > Once attendee-2 gets 'B' which is an 'add' (not some other things). > > As that is a valid way to invite an attendee. > > Where in rfc2446 did you get that? > > As far as valid invites go, I only see one "valid" way to do an invite: That was the question that was asked repeatedly (B) which was a request + add, which is also the subject line you keep replying to. I am now convinced you have no intention of participating in a technical debate about this issue. If there is anyone that thinks that you can get 'B' and still thinks that you have to have prior history of an object in order to extract the recurrece-id on expand? If there are 20 changes to a uid, it is insane to expect that the next person added will have to say yes/no to 19 old dates, reply to them, only to finaly get vevent request 20 and then possibly counter. How would they know that they can not counter the first 19 until they get a no, accept and then get another sequence. I do not read that into any rfc or draft. I have over the last two months read the entire list archive and see discussions about using 'add' to describe a single instance that is part of a set that has a different location. That seems to have been one purpose to 'add'. From owner-ietf-calendar@mail.imc.org Mon Dec 15 13:21: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 NAA19124 for ; Mon, 15 Dec 2003 13:21: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 hBFI0gib008999 for ; Mon, 15 Dec 2003 10:00:44 -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 hBFI0gKG008998 for ietf-calendar-bks; Mon, 15 Dec 2003 10:00:42 -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 hBFI0fib008990 for ; Mon, 15 Dec 2003 10:00:41 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:Fo61hwNu+h9YwbeuZmlfmLa+5UON+09Y@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBFI0ZGC000328 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 15 Dec 2003 10:00:36 -0800 Message-ID: <3FDDF6C1.5040701@Royer.com> Date: Mon, 15 Dec 2003 11:00:33 -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 CC: xcal-dev@inet-consulting.com Subject: Re: xCalendar questions References: <5.2.1.1.0.20031214231327.00a4cec0@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031214231327.00a4cec0@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010005070101000906040305" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010005070101000906040305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Try: http://INET-Consulting.com/xcal.txt However that one had too many controversial things in it. The problem with a DTD is it made x-objects almost impossible. I think the next xCal should be just a simple one to one translations. <-- an outer layer so you can have multiple vcalednars> 2.0 prop value .... ... And property and parameter values backslash or entity encoded 'as is'. Properties Tim Hare wrote: > > On a semi-unrelated project, I'm trying to develop an XML DTD for > conference information. I thought it might be good to use some of the > xCalendar syntax, using the xCalendar namespace; however it appears > that the file does not exist on the IETF site. Has this work been > abandoned in favor of something else? If so, can anyone point me to > good XML calendar information? > > I'm no XML expert; I'm working from prior experience with SGML-based > markup languages in IBM's product DCF/Script. I have some other > questions related to this work, if anyone with XML experience wants to > e-mail me privately I have a couple of questions. > > Thanks > Tim Hare > Interested Bystander, Non-Inc. > -- 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 --------------ms010005070101000906040305 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 9w0BCQUxDxcNMDMxMjE1MTgwMDMzWjAjBgkqhkiG9w0BCQQxFgQUuodAY/MqFweS3iIM5gU9 PIvaZZEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAq4Sm5BSyU1kKh+9hi9ztgZCs5HdfHlhKR+OZ/FYapTxNZpAr6v68wmw8d/elYkRC FJQxOe7DMI4gcAdXW66JhKPafyI9VfnLAQJVq3ZmPmNgoVprirc7L3f4PDj4rISaNNQQJD8b zeV1v5RTwGHPqqoqdYZ69tlt408j2KMk/sFBat4/QJbcaZXap3Yl3oHBfWzZOB/F+Pb93abM wTRC08wf6sIqRUiN88+u7rivMuyzVPV3udO24uelzT2aXCGGLgpZsjDrYF787DgpFDWhlCqd O712SHQA52QDA8bey+OosD22YzxZ2PzdaPBebUS9nE8iAlsGziADPTZgGbWL6QAAAAAAAA== --------------ms010005070101000906040305-- From owner-ietf-calendar@mail.imc.org Tue Dec 16 06:05: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 GAA10766 for ; Tue, 16 Dec 2003 06:05:51 -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 hBGAeOib027909 for ; Tue, 16 Dec 2003 02:40:24 -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 hBGAeONC027908 for ietf-calendar-bks; Tue, 16 Dec 2003 02:40:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.localdomain (archive.jsoft.com [68.90.54.98]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGAeNib027900 for ; Tue, 16 Dec 2003 02:40:23 -0800 (PST) (envelope-from gary.frederick@jsoft.com) Received: from jsoft.com (roo.jsoft.com [192.168.1.52]) by localhost.localdomain (8.12.8/8.12.5) with ESMTP id hBGBQwYY004581; Tue, 16 Dec 2003 05:26:59 -0600 Message-ID: <3FDEE109.2000904@jsoft.com> Date: Tue, 16 Dec 2003 04:40:09 -0600 From: Gary Frederick User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: xcal-dev@inet-consulting.com CC: "ietf-calendar@imc.org" Subject: Re: xCalendar questions References: <5.2.1.1.0.20031214231327.00a4cec0@mail.comcast.net> <3FDDF6C1.5040701@Royer.com> In-Reply-To: <3FDDF6C1.5040701@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. Will there be a 'next xCal'? Gary Doug Royer wrote: > > > Try: > > http://INET-Consulting.com/xcal.txt > > However that one had too many controversial things in it. > > The problem with a DTD is it made x-objects almost impossible. > > I think the next xCal should be just a simple one to one translations. > > <-- an outer layer so you can have multiple > vcalednars> > > 2.0 > prop value > .... > > > ... > > > > And property and parameter values backslash or entity encoded 'as is'. > > Properties > Tim Hare wrote: > >> >> On a semi-unrelated project, I'm trying to develop an XML DTD for >> conference information. I thought it might be good to use some of the >> xCalendar syntax, using the xCalendar namespace; however it appears >> that the file does not exist on the IETF site. Has this work been >> abandoned in favor of something else? If so, can anyone point me to >> good XML calendar information? >> >> I'm no XML expert; I'm working from prior experience with SGML-based >> markup languages in IBM's product DCF/Script. I have some other >> questions related to this work, if anyone with XML experience wants to >> e-mail me privately I have a couple of questions. >> >> Thanks >> Tim Hare >> Interested Bystander, Non-Inc. >> > From owner-ietf-calendar@mail.imc.org Tue Dec 16 22:28:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22292 for ; Tue, 16 Dec 2003 22:28:12 -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 hBH3CMib068591 for ; Tue, 16 Dec 2003 19:12:22 -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 hBH3CMmc068590 for ietf-calendar-bks; Tue, 16 Dec 2003 19:12:22 -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 hBH3CFib068583 for ; Tue, 16 Dec 2003 19:12:18 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:8wI93sT4iUULZ29w7Mk2IDaeDf/YRM2h@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBH3BuGC027757 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 16 Dec 2003 19:12:05 -0800 Message-ID: <3FDFC977.8090704@Royer.com> Date: Tue, 16 Dec 2003 20:11:51 -0700 From: Doug Royer Reply-To: xcal-dev@inet-consulting.com 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: xcal-dev@inet-consulting.com CC: "ietf-calendar@imc.org" Subject: Re: xCalendar questions References: <5.2.1.1.0.20031214231327.00a4cec0@mail.comcast.net> <3FDDF6C1.5040701@Royer.com> <3FDEE109.2000904@jsoft.com> In-Reply-To: <3FDEE109.2000904@jsoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010801010808050304020603" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010801010808050304020603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes, it it is about time we restarted it. We agreed to be quiet until CAP was out. CAP is close and there is more interest in XML calendaring. I have set the reply-to address to xcal-dev, so follow-ups there please. Gary Frederick wrote: > > I agree. > > Will there be a 'next xCal'? > > Gary > > Doug Royer wrote: > >> >> >> Try: >> >> http://INET-Consulting.com/xcal.txt >> >> However that one had too many controversial things in it. >> >> The problem with a DTD is it made x-objects almost impossible. >> >> I think the next xCal should be just a simple one to one translations. >> >> <-- an outer layer so you can have multiple >> vcalednars> >> >> 2.0 >> prop value >> .... >> >> >> ... >> >> >> >> And property and parameter values backslash or entity encoded 'as is'. >> >> Properties >> Tim Hare wrote: >> >>> >>> On a semi-unrelated project, I'm trying to develop an XML DTD for >>> conference information. I thought it might be good to use some of >>> the xCalendar syntax, using the xCalendar namespace; however it >>> appears that the file does not exist on the IETF site. Has this work >>> been abandoned in favor of something else? If so, can anyone point >>> me to good XML calendar information? >>> >>> I'm no XML expert; I'm working from prior experience with SGML-based >>> markup languages in IBM's product DCF/Script. I have some other >>> questions related to this work, if anyone with XML experience wants >>> to e-mail me privately I have a couple of questions. >>> >>> Thanks >>> Tim Hare >>> Interested Bystander, Non-Inc. >>> >> -- 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 --------------ms010801010808050304020603 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 9w0BCQUxDxcNMDMxMjE3MDMxMTUyWjAjBgkqhkiG9w0BCQQxFgQU0dv1+8RYsJOzjcN03v5V wML8R2YwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAcw2BxoA4ETHVVTnKtf4M/zMqejBBEbINv14JwH2GJ0QH98HKeKb5GTf39na1T+kw be1i2nO31CtWYxVN5VThwuTlS+VdNLrD1K1wivt9+NQ2WoVhS6YPfuhj2CcI3LZw+lV4drGH zxZ6LjAJ2mTSI0SW4irWpHjsJjLquDCItS1LEIlLdspZWsY+ITfKHJCmFNrWPLjn+UABLfUf 6RkGieNjOLhhr38crDkl9ZMwhGmd8G/WPzkQ/JmNe6nML29zgJUZtc1fLCycCaiEYD9d8+fd CLTXrQLPdeVwckrkq4+TPDQ6wgDWHj5zG7pgq/65a5fmuGvcU/3P5LXrwnH9FgAAAAAAAA== --------------ms010801010808050304020603-- From owner-ietf-calendar@mail.imc.org Wed Dec 17 00:07:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25285 for ; Wed, 17 Dec 2003 00:07:43 -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 hBH4thib073972 for ; Tue, 16 Dec 2003 20:55:43 -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 hBH4thS7073971 for ietf-calendar-bks; Tue, 16 Dec 2003 20:55:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBH4tdib073963 for ; Tue, 16 Dec 2003 20:55:40 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AWTij-0002dd-00 for ; Wed, 17 Dec 2003 05:55:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AWTii-0002dU-00 for ; Wed, 17 Dec 2003 05:55:36 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AWTii-0004qo-00 for ; Wed, 17 Dec 2003 05:55:36 +0100 From: "Michael Fair" Subject: Re: request + add Date: Tue, 16 Dec 2003 20:55:20 -0800 Lines: 64 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> <3FDCCEDB.CB58B505@INET-Calendar.net> <3FDCF03A.6F2775CD@INET-Calendar.net> <3FDDF513.4998A6B8@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I vote we continue this offline. It's obvious to me that we aren't understanding each other. I'm certainly not proposing the solution you've implied results from what I presented and there's no need, in my opinion, to have the WG watch us talk past each other. Let's get on the same page, and if there is a clarification or resolution we can come back to this thread then. -- Michael -- "Mark Smith" wrote in message news:3FDDF513.4998A6B8@INET-Calendar.net... > > Michael Fair wrote: > > > > "Mark Smith" wrote in message > > news:3FDCF03A.6F2775CD@INET-Calendar.net... > > > > > > Michael Fair wrote: > > > > > > > > > > > > > The example given was ADD which is NOT the object above. > > > > > See the original post and section "3.2.4 ADD" in iTIP. > > > > > > > > I think you are misunderstanding what object it is that's being > > > > described here. > > > > > > So the question (restated) is: > > > > > > Once attendee-2 gets 'B' which is an 'add' (not some other things). > > > As that is a valid way to invite an attendee. > > > > Where in rfc2446 did you get that? > > > > As far as valid invites go, I only see one "valid" way to do an invite: > > > That was the question that was asked repeatedly (B) > which was a request + add, which is also the subject > line you keep replying to. I am now convinced you have no > intention of participating in a technical debate about > this issue. > > If there is anyone that thinks that you can get 'B' > and still thinks that you have to have prior history > of an object in order to extract the recurrece-id > on expand? > > If there are 20 changes to a uid, it is insane to expect > that the next person added will have to say yes/no to > 19 old dates, reply to them, only to finaly get vevent > request 20 and then possibly counter. How would they > know that they can not counter the first 19 until they > get a no, accept and then get another sequence. I do not > read that into any rfc or draft. I have over the last > two months read the entire list archive and see discussions > about using 'add' to describe a single instance that is part > of a set that has a different location. That seems to have > been one purpose to 'add'. > From owner-ietf-calendar@mail.imc.org Wed Dec 17 13:49:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25906 for ; Wed, 17 Dec 2003 13:49:51 -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 hBHIXOib088640 for ; Wed, 17 Dec 2003 10:33:24 -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 hBHIXOkA088638 for ietf-calendar-bks; Wed, 17 Dec 2003 10:33:24 -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 hBHIXNib088633 for ; Wed, 17 Dec 2003 10:33:23 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:mM10ragQqikGc5g0tHlGj3hi2GzBUyvG@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBHIXKGC007329 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 17 Dec 2003 10:33:21 -0800 Message-ID: <3FE0A16F.5070606@Royer.com> Date: Wed, 17 Dec 2003 11:33:19 -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: request + add (Lets try BOOKED) References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> <3FDCCEDB.CB58B505@INET-Calendar.net> <3FDCF03A.6F2775CD@INET-Calendar.net> <3FDDF513.4998A6B8@INET-Calendar.net> In-Reply-To: <3FDDF513.4998A6B8@INET-Calendar.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010206010807040007030504" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010206010807040007030504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Let try this another way - BOOKED: Your CUA connects to a public CS that serves up your favorite Symphony to see their schedule. These are BOOKED entries in that CS. There is no-METHOD, No-REQUEST, No-REPLY. BEGIN:VCALENDAR: ... ... BEGIN:VEVENT UID:byBSO.org SEQUENCE:25 ... DTSTART:December 19, 2003 7:30 PM DTEND: December 19, 2003 9:30 PM ... RDATE:December 20, 2003 3:00 PM RDATE:December 20, 2003 7:30 PM RDATE:... ... END:VEVENT Your CUA will NEVER be able to get the history of that calendar. So, if those that think that RECURRENCE-ID depends on the history of the UID pre SEQUENCE:25. How could you ever calculate the RECURRENCE-ID's? You could not. The expansion of RECURRENCE-ID's can not depend on anything except the object the CS has - and only that object. -- 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 --------------ms010206010807040007030504 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 9w0BCQUxDxcNMDMxMjE3MTgzMzE5WjAjBgkqhkiG9w0BCQQxFgQUVPBgjMwE1es2tT5HS2fv ftaogrQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEANeYYO7AW7hz0Hziu2+I2e9vF4f9f4ObaRd5MwWmRzEBX2wC1959/mHNXa67JwSt+ j/ssH/9SWPNTnDsBdlU3XuJhMUjQ2LfuLGdKZCx1zIpNt3BJ80cxhsEnpw/GyRZdguwVW48X 8elg2SioEQ0qBNLoj/tpE+v6LkBoViMWQjIgXU+jObFd62DAWOeEsKzBFd/AeHxVTF/SWBmB 4vwWmxSsLirXLaEdm2CVZcnssCchrDjgEvZ/Q7D6utGAG2kzBmKX5EVib7eKUI6v1f4u40ly UtkEo2VkxgdIYaHNhWSyNKfCcxQnkarqZu083SG0Ae2UgMLFl9gjPYJE+6uMawAAAAAAAA== --------------ms010206010807040007030504-- From owner-ietf-calendar@mail.imc.org Thu Dec 18 01:51:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25263 for ; Thu, 18 Dec 2003 01:51:11 -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 hBI6b0ib029478 for ; Wed, 17 Dec 2003 22:37:00 -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 hBI6b0kR029477 for ietf-calendar-bks; Wed, 17 Dec 2003 22:37:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI6auib029404 for ; Wed, 17 Dec 2003 22:36:58 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AWrmI-0000eU-00 for ; Thu, 18 Dec 2003 07:36:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AWrmH-0000eM-00 for ; Thu, 18 Dec 2003 07:36:53 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AWrmH-00088k-00 for ; Thu, 18 Dec 2003 07:36:53 +0100 From: "Michael Fair" Subject: Re: request + add (Lets try BOOKED) Date: Wed, 17 Dec 2003 22:36:57 -0800 Lines: 49 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> <3FDCCEDB.CB58B505@INET-Calendar.net> <3FDCF03A.6F2775CD@INET-Calendar.net> <3FDDF513.4998A6B8@INET-Calendar.net> <3FE0A16F.5070606@Royer.com> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Doug Royer" wrote in message news:3FE0A16F.5070606@Royer.com... > > Let try this another way - BOOKED: > > Your CUA connects to a public CS that serves up your favorite Symphony > to see their schedule. These are BOOKED entries in that CS. > There is no-METHOD, No-REQUEST, No-REPLY. > > BEGIN:VCALENDAR: > ... > ... > BEGIN:VEVENT > UID:byBSO.org > SEQUENCE:25 > ... > DTSTART:December 19, 2003 7:30 PM > DTEND: December 19, 2003 9:30 PM > ... > RDATE:December 20, 2003 3:00 PM > RDATE:December 20, 2003 7:30 PM > RDATE:... > ... > END:VEVENT > > Your CUA will NEVER be able to get the history of that calendar. > So, if those that think that RECURRENCE-ID depends on the > history of the UID pre SEQUENCE:25. How could you > ever calculate the RECURRENCE-ID's? You could not. > > The expansion of RECURRENCE-ID's can not depend > on anything except the object the CS has - and only > that object. Certainly, but how does this relate in the context of an ADD as Mark was suggesting? If I had subscribed to receive iMIP updates from said symphony group, and the first message I ever saw was an ADD at SEQ:26, then it will not contain the above information from SEQ:25. Right? Further, in keeping with just "the most recent information is all I need", I have absolutely no use for objects with SEQ:0-24 as Mark again seemed to imply. -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Dec 18 12:07: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 MAA02840 for ; Thu, 18 Dec 2003 12:07: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 hBIGfcib023415 for ; Thu, 18 Dec 2003 08:41:38 -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 hBIGfcnK023414 for ietf-calendar-bks; Thu, 18 Dec 2003 08:41:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net (inet-calendar.net [12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIGfbib023408 for ; Thu, 18 Dec 2003 08:41:37 -0800 (PST) (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 hBIGfXYu017724 for ; Thu, 18 Dec 2003 09:41:33 -0700 (MST) Message-ID: <3FE1D8BD.A2932E8F@INET-Calendar.net> Date: Thu, 18 Dec 2003 09:41:33 -0700 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: request + add (Lets try BOOKED) References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> <3FDCCEDB.CB58B505@INET-Calendar.net> <3FDCF03A.6F2775CD@INET-Calendar.net> <3FDDF513.4998A6B8@INET-Calendar.net> <3FE0A16F.5070606@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Fair wrote: > Further, in keeping with just "the most recent information is all > I need", I have absolutely no use for objects with SEQ:0-24 as Mark > again seemed to imply. No you have that backwards. I have always said that the recurrence-id has nothing to do with old information about a uid. From owner-ietf-calendar@mail.imc.org Thu Dec 18 14:01: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 OAA08897 for ; Thu, 18 Dec 2003 14:01: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 hBIIb1ib028339 for ; Thu, 18 Dec 2003 10:37:01 -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 hBIIb18c028338 for ietf-calendar-bks; Thu, 18 Dec 2003 10:37:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIIawib028332 for ; Thu, 18 Dec 2003 10:36:59 -0800 (PST) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AX319-0001bk-00 for ; Thu, 18 Dec 2003 19:36:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AX318-0001bb-00 for ; Thu, 18 Dec 2003 19:36:58 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AX318-0001Od-00 for ; Thu, 18 Dec 2003 19:36:58 +0100 From: "Michael Fair" Subject: Re: request + add (Lets try BOOKED) Date: Thu, 18 Dec 2003 10:37:04 -0800 Lines: 29 Message-ID: References: <3FCFA2B3.7030304@Royer.com> <88EBC259-274B-11D8-8B58-000A9599D63E@apple.com> <3FD0E97E.9070504@Royer.com> <3FD677F3.8090203@Royer.com> <7FF301EA-2B2C-11D8-ACD3-000A9599D63E@apple.com> <3FD77ED5.3040105@Royer.com> <3FD9138F.B5E9C8F4@INET-Calendar.net> <3FDA25D3.4A81571B@INET-Calendar.net> <3FDA41A3.66119A9A@INET-Calendar.net> <3FDA64AD.5FA13AEB@INET-Calendar.net> <3FDB5718.62178574@INET-Calendar.net> <3FDCCEDB.CB58B505@INET-Calendar.net> <3FDCF03A.6F2775CD@INET-Calendar.net> <3FDDF513.4998A6B8@INET-Calendar.net> <3FE0A16F.5070606@Royer.com> <3FE1D8BD.A2932E8F@INET-Calendar.net> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Mark Smith" wrote in message news:3FE1D8BD.A2932E8F@INET-Calendar.net... > > Michael Fair wrote: > > > Further, in keeping with just "the most recent information is all > > I need", I have absolutely no use for objects with SEQ:0-24 as Mark > > again seemed to imply. > > No you have that backwards. I have always said that the recurrence-id > has nothing to do with old information about a uid. Oh great! I knew we just weren't understanding each other. Glad we agree. :) So I guess the only question marks left on behavior that I'm not certain we agree on have to do with what is considered a "set-redefining" moment for recurring events, each recurring instance in addition to the UID only object tracking their own SEQUENCE values, and as a fallout of those two what the resulting RIDs are for a given SEQUENCE of messages and what the the authoritative SEQUENCE for a particular UID is. However that should probably be discussed in a separate thread as we would be moving way off the topic. -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Dec 18 18:38: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 SAA28747 for ; Thu, 18 Dec 2003 18:38:25 -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 hBINGbib042537 for ; Thu, 18 Dec 2003 15:16: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 hBINGbN9042536 for ietf-calendar-bks; Thu, 18 Dec 2003 15:16:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBINGaib042528 for ; Thu, 18 Dec 2003 15:16:36 -0800 (PST) (envelope-from lisa@xythos.com) Received: from lisalap ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Dec 2003 15:16:33 -0800 From: "Lisa Dusseault" To: Subject: FW: I-D ACTION:draft-dusseault-caldav-00.txt Date: Thu, 18 Dec 2003 15:17:10 -0800 Message-ID: <00b001c3c5bd$101ddff0$75c990c6@lisalap> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B1_01C3C57A.01FA9FF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 18 Dec 2003 23:16:33.0542 (UTC) FILETIME=[FA015260:01C3C5BC] 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_00B1_01C3C57A.01FA9FF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here's a proposal/exploration for calendar storage via WebDAV, which was solicited at the Minneapolis WG meeting. Of course a lot of detail = would need to be filled in if this were deemed worth pursuing. =20 Lisa -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, December 18, 2003 12:30 PM To: IETF-Announce: Subject: I-D ACTION:draft-dusseault-caldav-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Calendar Server Extensions for WebDAV (CalDAV) Author(s) : L. Dusseault Filename : draft-dusseault-caldav-00.txt Pages : 33 Date : 2003-12-18 =09 In the five years since [WebDAV] was standardized, at least three groups have used WebDAV as a basis to provide Internet calendar access with a minimum of development effort. This draft explores the reasons why this path might be chosen as well as the mechanisms that might enable interoperable calendar access over WebDAV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-dusseault-caldav-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-dusseault-caldav-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_00B1_01C3C57A.01FA9FF0 Content-Type: Message/External-body; name="ATT00075.dat" Content-Disposition: attachment; filename="ATT00075.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-12-18142618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dusseault-caldav-00.txt ------=_NextPart_000_00B1_01C3C57A.01FA9FF0 Content-Type: Message/External-body; name="draft-dusseault-caldav-00.txt" Content-Disposition: attachment; filename="draft-dusseault-caldav-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-12-18142618.I-D@ietf.org> ------=_NextPart_000_00B1_01C3C57A.01FA9FF0-- From herbalmartpealairr@yahoo.com Fri Dec 19 15:51:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25987 for ; Fri, 19 Dec 2003 15:51:25 -0500 (EST) Received: from ietf-calendar-bks (a148.skierniewice.mediaclub.pl [80.51.190.148]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBJKUUib068323 for ; Fri, 19 Dec 2003 12:30:31 -0800 (PST) (envelope-from herbalmartpealairr@yahoo.com) Message-ID: From: "Melvinametallo" Date: Fri, 19 Dec 2003 21:30:18 +0100 To: ietf-calendar-bks@above.proper.com Subject: Your dic_k is small? This is for you! MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
The only solution to Penis Enlargement
ONLY THIS WEEK: Add at least 3 INCHES or get your money back!

We are so sure our product works we are willing to offer a 100% money back guarantee upon purchase if you are not satisfied with the results.


---> Click Here To Learn More <---

alrltvsbynzyhddvtupedj
* Doctor approved penis enhancement formula!
* 100% natural ingredients
* Discreet shipping for your privacy
* Gain 3+ inches!
* Stop premature ejaculation!
* 100% Safe! NO side effects!


---> Learn More About This Amazing New Product! <---
wklejlbyoykqcjp


No more offers
From owner-ietf-calendar@mail.imc.org Sun Dec 21 16:41: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 QAA06617 for ; Sun, 21 Dec 2003 16:40:57 -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 hBLLLjib039478 for ; Sun, 21 Dec 2003 13:21:45 -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 hBLLLj2K039477 for ietf-calendar-bks; Sun, 21 Dec 2003 13:21:45 -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 hBLLLeib039467 for ; Sun, 21 Dec 2003 13:21:41 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:zSphFjQ5D9Ivshlt7RkwFnbl8leCbiDN@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBLLLVV0003384 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 21 Dec 2003 13:21:37 -0800 Message-ID: <3FE60EDA.9040901@Royer.com> Date: Sun, 21 Dec 2003 14:21:30 -0700 From: Doug Royer Reply-To: ietf@ietf.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:need help from the ietf list...PKI References: <01ab01c3c7df$2caf0d50$0200a8c0@DESKTOP> <3FE609AE.9020701@necom830.hpcl.titech.ac.jp> In-Reply-To: <3FE609AE.9020701@necom830.hpcl.titech.ac.jp> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000506040901070507020807" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000506040901070507020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree. With my mortgage customers (MISMO.org related) I have argued that private certs signed by their business partner is better than a cert issued by a well known cert company. Anyone can buy a cert from the well known company. A cert signed by your business partner can not be bought from any vendor. And if managed correctly they can add/delete employees and application certs real time. > > However, PKI does not help e-commerce or financial transactions, > as discussed in my recent paper: "Meaninglessness of Public > Key Cryptography for Authentication on Consumable Credential" > (presented in Japan in Japanese): > > Abstract: For electric transactions, the essential benefit > of public key cryptography over shared key cryptography is > that it is not necessary to communicate with Certificate > Authority on each transaction. However, it is meaningless > to use public key cryptography for authentication on > consumable credentials, such as authentication of remaining > credential in account for electric payment, as fraud with > tremendous damage is easily performed, unless communication > with authorities to manage the account decrease remaining > credential is required on each transaction. > > The problem of PKI without realtime management of remaining > credential is that an attacker can use 1K USD worth of certs > from 1000 different locations for 1000 seconds 1000 times a > second, total amount of damage of which is 1T USD. > > Credential can be created only with direct communication. > > Masataka Ohta > > -- 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 --------------ms000506040901070507020807 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 9w0BCQUxDxcNMDMxMjIxMjEyMTMwWjAjBgkqhkiG9w0BCQQxFgQUoDwSEbURIUyaEa/NbPCz +/nnOAkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAOLKj7dQ5Ej9xMHQg1u3C+0kJTIdLnw/UepN1DMqhnYNB2ha6OqeSKLgHpR5EgnVG tFkZ9BZNiJ2GcDjM5UPs87pYsRy290tEp25z1z4hzZl0wZLAtX7hoFlkcihsoSXPSH5sdXvj TjTz4qdDtETA0yeOBXGgyZqL3LJ3RV5pDFMq1u7gqFe1WAJ8ihjuSgq1eHgU3W9oCvvMYRzv NmYJADj4pcULFsXtNwt3bNAMtfX4Rbpnc9sqfkLt9y5wHcW0VHPT7xlDigQoo65lmaLeX3dr 02nzWv2JlpePBDgsRQfOv8ifwHoN22qyq3jNBn90m4RxPsE7efMsR3azSC69BAAAAAAAAA== --------------ms000506040901070507020807-- From owner-ietf-calendar@mail.imc.org Sun Dec 21 19:05:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11900 for ; Sun, 21 Dec 2003 19:05:34 -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 hBLNrcib044632 for ; Sun, 21 Dec 2003 15:53:38 -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 hBLNrb9t044631 for ietf-calendar-bks; Sun, 21 Dec 2003 15:53:37 -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 hBLNrZib044624 for ; Sun, 21 Dec 2003 15:53:35 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:iZEel02UjN8ISitHMPTI/kCBdi4MtD0x@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hBLNrLV0005241 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 21 Dec 2003 15:53:24 -0800 Message-ID: <3FE63267.3050608@Royer.com> Date: Sun, 21 Dec 2003 16:53:11 -0700 From: Doug Royer Reply-To: Doug@royer.com 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: internet-drafts@ietf.org Subject: [CALSCH] draft-royer-dyn-query-00.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050705000904040207070309" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050705000904040207070309 Content-Type: multipart/mixed; boundary="------------050305020805030006070308" This is a multi-part message in MIME format. --------------050305020805030006070308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit (attached) -- 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 --------------050305020805030006070308 Content-Type: text/plain; name="draft-royer-dyn-query-00.txt" Content-Disposition: inline; filename="draft-royer-dyn-query-00.txt" Content-Transfer-Encoding: quoted-printable Application Working Group Doug Royer/INET-Consulting L= LC Internet Draft December 21, 20= 03 Expires: May 2004 Variables in Dynamic Queries for iCalendar draft-royer-dyn-query-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all= provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task= Force (IETF), its areas, and its working groups. Note that other group= s may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material= or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire May 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. ABSTRACT This is a proposal to allow iCalendar dynamic query the ability to be passed down optional values to be used stored queries. 1. New parameters [CAP] allows for stored queries. Using the existing stored queri= es (VQUERY) as defined in [CAP], this describes a standard way to pass do= wn variables to those queries. 1.1 DT-RANGE Parameter Name: DT-RANGE Purpose: This property specifies a period of time for which the que= ry Royer Expires: May 2004 [Page = 1] =0C Internet Draft iCal Dynamic Query Variables December 21, 2003 should apply. Value Type: PERIOD Format Definition: The property is defined by the following notation: dt-range =3D "DT-RANGE" "=3D" period Examples: QUERYID;DT-RANGE=3D"19971015T050000Z/PT8H30M":GET-OBJECTS QUERYID;DT-RANGE=3D"19980314T233000Z/19980315T003000Z":GET-OBJECTS 1.2 MAX-OCTETS The "MAX-OCTETS" parameter is added to the "QUERYID" property value = to signify the maximum number of octets to be returned in the query. The = CS will trim the returned valued down so that only complete objects will = be sent. Each time that "MAX-OCTETS" is supplied it sets the default f= or that named "QUERYID" for the current session only and the results s= et back will be the first (0th) set. Use the "GET-SET" parameter to g= et sets greater then zero. Parameter Name: MAX-OCTETS Purpose: The property indicates the largest reply size allowed for th= is query by the CUA. If supplied the first reply always get the first s= et of components that fit within the limit. See the "GET-SET" parameter f= or information on how to get the following sets of components. Value Type: INTEGER Format Definition: The property is defined by the following notation: max-octets =3D "MAX-OCTETS" "=3D" integer Example: QUERYID;MAX-OCTETS=3D10240:GET-OBJECTS 1.3 GET-SET The "GET-SET" parameter is added to the "QUERYID" property value reque= st the next set of components be returned for the last query performed wi= th the same name. Supplied is the set number to be fetched. The s= et Royer Expires: May 2004 [Page = 2] =0C Internet Draft iCal Dynamic Query Variables December 21, 2003 numbers start with zero. The original query must have suppled a "MA= X- OCTETS" parameter and value. Parameter Name: GET-SET Purpose: Added by the CUA to inform the CS to return the next set = of components to the CUA. The first set is ZERO and continues up until = no more data is returned (See the "SETS" parameter). Requesting a s= et larger than the number of sets available will return a "VREPLY" with= a "REQUEST-STATUS" value of "3.15" invalid set number. Value Type: INTEGER Format Definition: The property is defined by the following notation: get-set =3D "GET-SET" "=3D" integer The following example gets the 15th set of components that match the QUERYID;GET-SET=3D15:GET-OBJECTS 1.4 SETS The "SETS" parameter MUST BE added to the "REQUEST-STATUS" property in= a "VREPLY" that is the result of a "VQUERY" that had the "MAX-OCTET= S" parameter added to the "QUERYID" property. It specifies the current a= nd maximum set numbers available. Parameter Name: SETS Purpose: Added by the CS to inform the CUA that of the current a= nd maximum number of sets of data available. Value Type: INTEGER multivalued. Format Definition: The property is defined by the following notation: sets =3D "SETS" "=3D" current-set "," max-set current-set =3D integer max-set =3D integer The following example tells the CUA that set '4' of '20' is bei= ng returned. Royer Expires: May 2004 [Page = 3] =0C Internet Draft iCal Dynamic Query Variables December 21, 2003 REQUEST-STATUS;SETS=3D4,20:2.0;Success And an example of an error: REQUEST-STATUS;SETS=3D4,20:3.15;Invalid set number. 1.5 GET-COMP The "GET-COMP" parameter is added to the "QUERYID" property value = to signify the component types to be returned in the query. Parameter Name: GET-COMP Purpose: Added by the CUA to inform the CS the component types to = be returned in the query. Value Type: text multivalued. Format Definition: The property is defined by the following notation: get-comp =3D "GET-COMP" "=3D" comp-name *["," comp-name ] comp-name =3D ; any valid component name including ; x- components. The following example tells the CS only to return "VEVENT" and "VTOD= O" components. QUERYID;GET-COMP=3DVEVENT,VTODO=3D10240:GET-OBJECTS 1.6 Bibliography [iCAL] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 24= 45, November 1998 ftp://ftp.isi.edu/in-notes/rfc2445.txt [iTIP] Silverberg, S., Mansour, S., Dawson, F. and Hopson, R., "iCalendar Transport-Independent Interoperability Protoco= l (iTIP) Events, BusyTime, To-dos and Journal Entries", RFC 2446, November 1998 ftp://ftp.isi.edu/in-notes/rfc244= 6.txt [iMIP] Dawson, F., Mansour, S. and Silverberg, "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 2447= , November 1998 ftp://ftp.isi.edu/in-notes/rfc2447.txt Royer Expires: May 2004 [Page = 4] =0C Internet Draft iCal Dynamic Query Variables December 21, 2003 [CAP] Royer, D., Babics, G., Hill, P. Mansour, S. "Calendar Access Protocol (CAP)", work in progress, draft-ietf-calsch-cap-12.txt 2. Author's Address Doug Royer http://INET-Consulting.com 1795 W. Broadway #266 Idaho Falls, Idaho 83402 US Phone: 208-520-4044 Fax: 866-594-8574 EMail: Doug@Royer.com URI: http://Royer.com/People/Doug Royer Expires: May 2004 [Page = 5] =0C Internet Draft iCal Dynamic Query Variables December 21, 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of a= ny intellectual property or other rights that might be claimed to perta= in to the implementation or use of the technology described in th= is document or the extent to which any license under such rights might = or might not be available; neither does it represent that it has made a= ny effort to identify any such rights. Information on the IETF's procedur= es with respect to rights in standards-track and standards-relat= ed documentation can be found in BCP-11. Copies of claims of rights ma= de available for publication and any assurances of licenses to be ma= de available, or the result of an attempt made to obtain a general licen= se or permission for the use of such proprietary rights by implementors = or users of this specification can be obtained from the IETF Secretariat.= The IETF invites any interested party to bring to its attention a= ny copyrights, patents or patent applications, or other proprietary righ= ts which may cover technology that may be required to practice th= is standard. Please address the information to the IETF Executive Directo= r. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished = to others, and derivative works that comment on or otherwise explain it = or assist in its implementation may be prepared, copied, published a= nd distributed, in whole or in part, without restriction of any kin= d, provided that the above copyright notice and this paragraph are includ= ed on all such copies and derivative works. However, this document itse= lf may not be modified in any way, such as by removing the copyright noti= ce or references to the Internet Society or other Internet organization= s, except as needed for the purpose of developing Internet standards = in which case the procedures for copyrights defined in the Intern= et Standards process must be followed, or as required to translate it in= to languages other than nglish. The limited permissions granted above are perpetual and will not = be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "= AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TA= SK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT N= OT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL N= OT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY = OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Royer Expires: May 2004 [Page = 6] =0C Internet Draft iCal Dynamic Query Variables December 21, 2003 Funding for the RFC Editor function is currently provided by t= he Internet Society. Royer Expires: May 2004 [Page = 7] =0C --------------050305020805030006070308-- --------------ms050705000904040207070309 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 9w0BCQUxDxcNMDMxMjIxMjM1MzExWjAjBgkqhkiG9w0BCQQxFgQUG4ENOpDb3uNY1YlI1VrW 8FvqnG8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAAHcj26kRYaMX1RaMLyywdefg7UUeCnI0pFHz02e7qTpEIpCM0PJyL+PpQeGid/N1 2k/lyeWCMOO+aM34zbh3A/CL8W1gw0iPjzpKXiG7L+hV74HWC3J+vZQAoUQB+EQ9bukfrko5 ozWm6pSZss6HSLK0a+24R4cVPX8HWJuEXyiV9Hn2Y4I+YStcS96Nzk0lwZl91YebavCe/0VC oSilRCEPNytEvNmcxTfMVs1Es5jeQNUCXVUCl5cfVIYqk/sBcKJWPrfeAZgdX1MnmF20rjfJ R0F3GbKDgEIjk8ZbZai61MqlCYsWfneoPAFlIKgcud1d+WFj75RhQgmDjoKOugAAAAAAAA== --------------ms050705000904040207070309--