From owner-ietf-calendar@mail.imc.org Fri Aug 1 19:56: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 TAA17886 for ; Fri, 1 Aug 2003 19:56:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71NfRqt035232 for ; Fri, 1 Aug 2003 16:41:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h71NfRT1035231 for ietf-calendar-bks; Fri, 1 Aug 2003 16:41:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71NfQqt035225 for ; Fri, 1 Aug 2003 16:41:26 -0700 (PDT) (envelope-from gsbarnes@u.washington.edu) Received: from mead8.u.washington.edu (mead8.u.washington.edu [140.142.12.148]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h71NfNxu000403 for ; Fri, 1 Aug 2003 16:41:28 -0700 Received: from localhost (gsbarnes@localhost) by mead8.u.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h71NfMfZ017296 for ; Fri, 1 Aug 2003 16:41:22 -0700 Date: Fri, 1 Aug 2003 16:41:22 -0700 (PDT) From: "G. Barnes" To: ietf-calendar@imc.org Subject: Re: CAP-11 is out 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: Here are a few problems I've found with the latest CAP draft (draft-ietf-calsch-cap-11.txt): The ABNF for a few components (e.g., VAGENDA) specifies a 'last-modified' element. I assume this is the same as RFC 2445's 'last-mod' element. The old name should be used. The DECREED property should be included in the ABNF of the property list for VCAR (section 9.3), but is not. Similarly, MAXDATE and MINDATE should be included in the ABNF of the property list for VCALSTORE, but they are not. ATT-COUNTER should be included in the property list for one or more components, but I can't figure out whether it belongs in VCALENDAR, VEVENT, or what. The 'Conformance' section of the MULTIPART property (section 8.22) says 'This property can be specified in a component', but the rest of the section makes it seem like the only component it can be used in is a VREPLY. If this is so, the Conformance section should read the same as that for, CAP-VERSION, for example. I'm mystified as to the meaning of the ITIP-VERSION property. How does a CAP server 'support' ITIP? From what I can read, CAP servers hold ITIP objects, but it is CUAs that do all the ITIP work. This property makes it sound like CAP servers do a lot more to ITIP objects than just storing, searching and deleting. Finally, it would be nice if the ABNF for VREPLY listed the properties that can only be in VREPLY components. As near as I can read, these are: CAP-VERSION CAR-LEVEL COMPONENTS ITIP-VERSION MAX-COMP-SIZE MULTIPART [? see above] QUERY-LEVEL RECUR-ACCEPTED RECUR-LIMIT RECUR-EXPAND STORES-EXPANDED Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Fri Aug 1 20:37: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 UAA18653 for ; Fri, 1 Aug 2003 20:37:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h720MTqt038991 for ; Fri, 1 Aug 2003 17:22:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h720MT1A038990 for ietf-calendar-bks; Fri, 1 Aug 2003 17:22:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h720MRqt038983 for ; Fri, 1 Aug 2003 17:22:28 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender)) by comcast.net (sccrmhc11) with SMTP id <2003080200222401100ola6ee> (Authid: TimHare); Sat, 2 Aug 2003 00:22:24 +0000 Message-Id: <5.2.1.1.0.20030801201129.009f5500@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 01 Aug 2003 20:21:41 -0400 To: ietf-calendar@above.proper.com From: Tim Hare Subject: Hello, from a new member of the list 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: Hello. I've just joined the mailing list and would like to introduce myself. I am not a developer or otherwise connected with software creation for calendaring, except possibly home-grown programs for my own use. I am a long-time user of calendaring software, having been the support at our organization for the MVS flavor of OfficeVision for several years. During that time, I acquired a lot of information about how people use calendars and schedule meetings or events, and I hope that these insights will be beneficial to projects worked on by the group. I'm also a long-time installation representative to SHARE, which hopefully gives me some insight into other companies' views on the issues, too. I am going to try to read as much of the archives as I can, to get up to speed on current projects, before posting. Feel free to e-mail me "off list" if you have any questions, at mailto:TimHare@comcast.net. This is my home e-mail address - I am doing this outside of work, due to workload concerns. Tim Hare Florida Department of Transportation From owner-ietf-calendar@mail.imc.org Fri Aug 1 21:12: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 VAA19271 for ; Fri, 1 Aug 2003 21:12:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h72126qt040939 for ; Fri, 1 Aug 2003 18:02:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h72126FB040937 for ietf-calendar-bks; Fri, 1 Aug 2003 18:02:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h72124qt040905 for ; Fri, 1 Aug 2003 18:02:04 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: Tim Hare Cc: ietf-calendar@above.proper.com, owner-ietf-calendar@mail.imc.org Subject: Re: Hello, from a new member of the list MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Fri, 1 Aug 2003 21:02:13 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 08/01/2003 09:02:07 PM, Serialize complete at 08/01/2003 09:02:07 PM Content-Type: multipart/alternative; boundary="=_alternative 0005B22C85256D76_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0005B22C85256D76_= Content-Type: text/plain; charset="us-ascii" A user! Welcome to the list. Your thoughts/opinions will be appreciated. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Tim Hare Sent by: owner-ietf-calendar@mail.imc.org 08/01/2003 20:21 To: ietf-calendar@above.proper.com cc: Subject: Hello, from a new member of the list Hello. I've just joined the mailing list and would like to introduce myself. I am not a developer or otherwise connected with software creation for calendaring, except possibly home-grown programs for my own use. I am a long-time user of calendaring software, having been the support at our organization for the MVS flavor of OfficeVision for several years. During that time, I acquired a lot of information about how people use calendars and schedule meetings or events, and I hope that these insights will be beneficial to projects worked on by the group. I'm also a long-time installation representative to SHARE, which hopefully gives me some insight into other companies' views on the issues, too. I am going to try to read as much of the archives as I can, to get up to speed on current projects, before posting. Feel free to e-mail me "off list" if you have any questions, at mailto:TimHare@comcast.net. This is my home e-mail address - I am doing this outside of work, due to workload concerns. Tim Hare Florida Department of Transportation --=_alternative 0005B22C85256D76_= Content-Type: text/html; charset="us-ascii"
A user!  Welcome to the list.  Your thoughts/opinions will be appreciated.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Tim Hare <TimHare@comcast.net>
Sent by: owner-ietf-calendar@mail.imc.org

08/01/2003 20:21

       
        To:        ietf-calendar@above.proper.com
        cc:        
        Subject:        Hello, from a new member of the list




Hello. I've just joined the mailing list and would like to introduce myself.
I am not a developer or otherwise connected with software creation for
calendaring, except possibly home-grown programs for my own use. I am a
long-time user of calendaring software, having been the support at our
organization for the MVS flavor of OfficeVision for several years. During
that time, I acquired a lot of information about how people use calendars
and schedule meetings or events, and I hope that these insights will be
beneficial to projects worked on by the group. I'm also a long-time
installation representative to SHARE, which hopefully gives me some insight
into other companies' views on the issues, too.
I am going to try to read as much of the archives as I can, to get up to
speed on current projects, before posting. Feel free to e-mail me "off
list" if you have any questions, at mailto:TimHare@comcast.net. This is my
home e-mail address - I am doing this outside of work, due to workload
concerns.
Tim Hare
Florida Department of Transportation


--=_alternative 0005B22C85256D76_=-- From owner-ietf-calendar@mail.imc.org Fri Aug 1 21:47: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 VAA19692 for ; Fri, 1 Aug 2003 21:47:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h721asqt042358 for ; Fri, 1 Aug 2003 18:36:54 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h721astO042357 for ietf-calendar-bks; Fri, 1 Aug 2003 18:36:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h721aqqt042351 for ; Fri, 1 Aug 2003 18:36:52 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h721aqEB025625 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 1 Aug 2003 18:36:54 -0700 Message-ID: <3F2B15AE.6030103@Royer.com> Date: Fri, 01 Aug 2003 19:36:46 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-11 is out References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010103060800090807010905" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010103060800090807010905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit G. Barnes wrote: > Here are a few problems I've found with the latest CAP draft > (draft-ietf-calsch-cap-11.txt): > > > The ABNF for a few components (e.g., VAGENDA) specifies a 'last-modified' > element. I assume this is the same as RFC 2445's 'last-mod' element. The > old name should be used. Thanks - fixed. > The DECREED property should be included in the ABNF of the property list > for VCAR (section 9.3), but is not. Thanks - fixed. > Similarly, MAXDATE and MINDATE should be included in the ABNF of the > property list for VCALSTORE, but they are not. Thanks - fixed. > ATT-COUNTER should be included in the property list for one or more components, > but I can't figure out whether it belongs in VCALENDAR, VEVENT, or what. Thanks - I'll update the text to say that it goes into any iTIP object that is METHOD:COUNTER. (VEVENT and VTODO) at the same level as METHOD. I'll also supply updated 2445 ABNF for 'eventc' and 'todoc' for [iCAL] and updates for related sections in 2446. > The 'Conformance' section of the MULTIPART property (section 8.22) > says 'This property can be specified in a component', but the rest of > the section makes it seem like the only component it can be used in is > a VREPLY. If this is so, the Conformance section should read the > same as that for, CAP-VERSION, for example. It only goes in a GET-CAPABILITY VREPLY. I updated the conformance section to look like the CAP-VERSION conformance. > I'm mystified as to the meaning of the ITIP-VERSION property. How does > a CAP server 'support' ITIP? From what I can read, CAP servers hold > ITIP objects, but it is CUAs that do all the ITIP work. This property > makes it sound like CAP servers do a lot more to ITIP objects than just > storing, searching and deleting. The CS processes VFREEBUSY in CS's that have RECUR-EXPAND=true. And what if 2446 is updated and it effects VFREEBUSY or some new component that the CS is supposed to process? That is why it exists. > Finally, it would be nice if the ABNF for VREPLY listed the properties > that can only be in VREPLY components. As near as I can read, these are: > > CAP-VERSION > CAR-LEVEL > COMPONENTS > ITIP-VERSION > MAX-COMP-SIZE > MULTIPART [? see above] > QUERY-LEVEL > RECUR-ACCEPTED > RECUR-LIMIT > RECUR-EXPAND > STORES-EXPANDED replyc = "BEGIN" ":" "VREPLY" CRLF any-prop-or-comp "END" ":" "VREPLY" CRLF any-prop-or-comp = ; Zero or more iana or experimental ; properties and components, in any order. It would be nice, but the ABNF would be impossible as almost anything in any order in or out of layers of components can be returned for a QUERY. Potentially EVERYTHING and I think ANYTHING can be in a VREPLY. Some of the VREPLY's can be defined and they are. Others like the QUERY reply can not be defined. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010103060800090807010905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MDIwMTM2NDZaMCMGCSqGSIb3DQEJBDEWBBTK HoUtVPNHurvp6J1VdDwqDxRN+DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQAb4LUo4Bc6VsCSUnUE/rCVQLdmPwoDP54x/Cg/adCu2MtI 738oPjpN1wVxumjsOKHwrybj4bsiIclAb1u0vHDxdkn/Xt4z8ZDpF02Tjh9NyoYEayNv8LWX /E0qEQGavEIlcx4xagxv4DMB6MaLH/ICZH+bUnmlOk53dpKUG0JLezgx+Rd5j/qjh5LbPFwR HkX11+34XeCLysCDU9YW30Eucypac+JHGS1Ia8xFu1aJH8R4sj/rJ5B4BfxiJTmnK61Z0nza NFSAvTOVGwiX+bP7Xuv11IlwjZQfNuw+4V4ruCGz3LhJZXZkWSUuh8UPgOXFFwHdvn/7/0Xj H3Hqkx4qAAAAAAAA --------------ms010103060800090807010905-- From owner-ietf-calendar@mail.imc.org Mon Aug 4 12:19:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03181 for ; Mon, 4 Aug 2003 12:19:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74G56qt014999 for ; Mon, 4 Aug 2003 09:05:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74G56Bw014997 for ietf-calendar-bks; Mon, 4 Aug 2003 09:05:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74G55qt014992 for ; Mon, 4 Aug 2003 09:05:06 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F25C68A.6020804@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-11 is out MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Aug 2003 11:43:12 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/04/2003 12:05:05 PM, Serialize complete at 08/04/2003 12:05:05 PM Content-Type: multipart/alternative; boundary="=_alternative 00561C6985256D78_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00561C6985256D78_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 07/28/2003 08:57:46 PM: > CAP Issues: > > -> Search for TBD - Its in the BEEP profile registration > suggestions welcome. 2 questions: 1: Is there a diffs of CAP-10 (17-Feb) to CAP-11? I for one have no time to reread CAP from cover to cover looking for changes. 2: What about all the other issues that have been identified in WG discussions already? Where they _all_ addressed in CAP-11 leaving just the TBD stuff to be done? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00561C6985256D78_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 07/28/2003 08:57:46 PM:
> CAP Issues:
>
> -> Search for TBD - Its in the BEEP profile registration
>                      suggestions welcome.
2 questions:

1: Is there a diffs of CAP-10 (17-Feb) to CAP-11?  I for one have no time to reread CAP from cover to cover looking for changes.
2: What about all the other issues that have been identified in WG discussions already?  Where they _all_ addressed in CAP-11 leaving just the TBD stuff to be done?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00561C6985256D78_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 4 12:19:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03198 for ; Mon, 4 Aug 2003 12:19:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74G57qt015006 for ; Mon, 4 Aug 2003 09:05:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74G571F015004 for ietf-calendar-bks; Mon, 4 Aug 2003 09:05:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74G55qu014992 for ; Mon, 4 Aug 2003 09:05:06 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: RE: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Aug 2003 11:52:38 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/04/2003 12:05:05 PM, Serialize complete at 08/04/2003 12:05:05 PM Content-Type: multipart/alternative; boundary="=_alternative 0056F95385256D78_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056F95385256D78_= Content-Type: text/plain; charset="US-ASCII" Chris Olds replied on 06/12/2003 02:49:02 PM MST: >In Bruce's model, I need to keep track of the original recurrence-id of each >instance of an event as they evolve. Its NOT my model, its the model in iCalendar. In case it was not clear, Im defending the existing model and prose from iCalendar/iTIP. iCalendar clearly says: 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. Thats not my text, thats the WGs (via the authors). Plus iTIP already mandates preserving UID / RECURRENCE-ID / SEQUENCE / DTSTAMP in Section 2.1.5 with: Hence, CUAs must persist the following component properties: "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" and "DTSTAMP" property values associated with the "Attendee's" response. Its NOT difficult to preserve a property that does not change. If you can do it for UID you can do it for RECURRENCE-ID. > In the REFRESH model, all I need to do > is get the current version of the object and I'm done. In the REFRESH (aka 'delta') model, you MUST ignore the current version of the object if you do not have the version that immediately preceedes it. Otherwise you have NO way to match the RECURRENCE-ID to the proper instance. The converse is true of the fixed RECURRENCE-ID (aka iCalendar) model. If you missed an message, no big deal. You just use the most recent one and you are done. NO EXTRA WORKFLOW IS NECESSARY. > If I have the current > version, I can use a message with a RECURRENCE-ID to update my view of the > object; if I don't have the current version, I just found that out and I can > ask for a REFRESH and I'm done. If RECURRENCE-ID changed on each reschedule then you cannot tell if you have the current version of the instance if you missed one or more reschedules! Thats the problem w/the delta model... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0056F95385256D78_= Content-Type: text/html; charset="US-ASCII"
Chris Olds replied on 06/12/2003 02:49:02 PM MST:
>In Bruce's model, I need to keep track of the original recurrence-id of each
>instance of an event as they evolve.  

Its NOT my model, its the model in iCalendar.  In case it was not clear, Im defending the existing model and prose from iCalendar/iTIP.  iCalendar clearly says:

   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.

Thats not my text, thats the WGs (via the authors).  Plus iTIP already mandates preserving UID / RECURRENCE-ID / SEQUENCE / DTSTAMP in Section 2.1.5 with:

   Hence, CUAs must persist the following component properties: "UID",
  "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP".  Furthermore, for each
  "ATTENDEE" property of a component CUAs must persist the "SEQUENCE"
  and "DTSTAMP" property values associated with the "Attendee's"
  response.

Its NOT difficult to preserve a property that does not change.  If you can do it for UID you can do it for RECURRENCE-ID.  

> In the REFRESH model, all I need to do
> is get the current version of the object and I'm done.  

In the REFRESH (aka 'delta') model, you MUST ignore the current version of the object if you do not have the version that immediately preceedes it.  Otherwise you have NO way to match the RECURRENCE-ID to the proper instance.  The converse is true of the fixed RECURRENCE-ID (aka iCalendar) model.  If you missed an message, no big deal.  You just use the most recent one and you are done.  NO EXTRA WORKFLOW IS NECESSARY.

> If I have the current
> version, I can use a message with a RECURRENCE-ID to update my view of the
> object; if I don't have the current version, I just found that out and I can
> ask for a REFRESH and I'm done.

If RECURRENCE-ID changed on each reschedule then you cannot tell if you have the current version of the instance if you missed one or more reschedules!  Thats the problem w/the delta model...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0056F95385256D78_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 4 12:21:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03277 for ; Mon, 4 Aug 2003 12:21:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74G57qt015012 for ; Mon, 4 Aug 2003 09:05:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74G57nu015011 for ietf-calendar-bks; Mon, 4 Aug 2003 09:05:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74G55qt014991 for ; Mon, 4 Aug 2003 09:05:06 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 4 Aug 2003 11:36:48 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/04/2003 12:05:05 PM, Serialize complete at 08/04/2003 12:05:05 PM Content-Type: multipart/alternative; boundary="=_alternative 0055863985256D78_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0055863985256D78_= Content-Type: text/plain; charset="US-ASCII" Satya asked on 07/31/2003 06:43:38 PM: > Is there an update on when the iCal authors will post their thinking on > the subject? I had hoped that reading the RFCs and searching the archives would have put this to rest once and for all but perhaps not for some. So let me take some time to review both the RFC text and to technically analyze why the iCalendar specified a fixed RECURRENCE-ID. This is going to be a somewhat long posting in order to cover both iCalendar, iTIP and the claims that purportedly define a changing RECURRENCE-ID model. First, lets start with a review of the RFCs. The 2 RFCs in question are 2445 (iCalendar) and 2446 (iTIP). iCalendars role is to define the various properties and property parameters as well as specify their behaviour / intent. iTIPs role is to give the iCalendar properties semantic meaning that all implementations can follow to interop. So lets start with reviewing the actual definition of RECURRENCE-ID (Section 4.8.4.4 Recurrence ID). Description: 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. [Snip] 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 "RECURRENCE-ID" property is used in conjunction with the "UID" and "SEQUENCE" property to identify a particular instance of a recurring event, to-do or journal. For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. When the definition of the recurrence set for a calendar component changes, and hence the "SEQUENCE" property value changes, the "RECURRENCE-ID" for a given recurrence instance might also change. [Snip] Some folks seem to blindly ignore the 2nd (above, 3rd in the actual RFC) paragraph which clearly and unequivocally says that when a reschedule takes place the RECURRENCE-ID value "is still set to the original" value! This of course flat out defeats the claim that "RECURRENCE-ID changes on each reschedule" as some have claimed so its easy to see why overlooking it happens. In looking at the oft cited last paragraph you will find that the key phrase is "When the definition of the recurrence set for a calendar component changes...the "RECURRENCE-ID" for a given recurrence instance might also change". The important bit that seems to be misread is " definition of the recurrence set"; it does not say "definition of the recurrence _instance_". So its likely that this is partly to blame for some misinterpreting the description to mean "Whenever the instance is rescheduled, the recurrence instance also changes" This does make a couple minor but not insignficant changes to the phrasing such as changing "might also change" into "always changes" but these changes are best ignored if you want to change the model. Of course these changes would conflict with the entire paragraph before it so some would just ignore it in favor of their reinterpreatation of the prose. However it must be noted that iCalendar clearly proscribes a "fixed" RECURRENCE-ID in at least 2 places. In addition Doug has claimed that "'original' means currently booked version" but thats nowhere near the meaning of the word original. Instead of arguing a common sense meaning Ill instead defer to Merriam-Webster who define it as: Main Entry: 2original Function: adjective Date: 14th century 1 : of, relating to, or constituting an origin or beginning : INITIAL 2 a : not secondary, derivative, or imitative b : being the first instance or source from which a copy, reproduction, or translation is or can be made So "original" means the the same as the "initial" value, NOT the "latest" or "most recent". This definition matches the paragraph in describing how RECURRENCE-ID stayed at the Friday date/time. The reason that a fixed RECURRENCE-ID was specified over a varying one will become evident as we move into analyzing iTIP so lets do that now. iTIP defines its role in relation to iCalendar as: iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. so its role is NOT to impart (or modify) any defintion to the iCalendar properties or property parameters, thats the function of iCalendar. The semantics for "group scheduling methods" are done in the various iTIP methods or messages. iTIP messages can be sent over any kind of media or using assorted methods so the protocol had to first define some guidelines to apply to all messages to properly deal with missequencing on the receiving end. That is done in Section 2.1.5 Message Sequencing, before any direct discussion of individual messages was done. In Section 2.1.5 Message Sequencing we see: 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. 2. The secondary key for referencing a component is the "SEQUENCE" property value. For components where the "UID" is the same, the component with the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values. Thus for repeating instances the primary key value used to find the instance the message refers to is the UID / RECURRENCE-ID pair. Once this pair is used to find the instance in question the SEQUENCE property can be used to determine if the message is newer or older than the one the recipient has. Or in iTIP terms, tell if the message has already been obsoleted or if it should obsolete the recipients copy. Nothing here claims that RECURRENCE-ID changes on each reschedule and in order to be fault tolerant and easily recoverable RECURRENCE-ID should not change (iCalendar prose not withstanding). This can be seen in the prose found in other sections in iTIP such as Sections 3.2.2 REQUEST, 3.2.2.1 Rescheduling an Event, 3.2.2.2 Updating or Reconfirmation of an Event, or even the often misquoted Section 4.7.2 Bad RECURRENCE-ID. Section 3 of iTIP is where the actual protocol definitions happen. Its where iTIP defines what a meeting request or response look like, etc. Section 4 of iTIP is where the authors provided assorted examples of actual iTIP messages from Section 3. As such its merely the demonstrative part of the iTIP RFC and does not carry the same weight. The authors were always grumbling about the inclusion of examples ("If we put in an example of X then everyone will code to that and not to the text" as they so often lamented in meetings, emails and here on the list) and now this has come back to haunt us based on a misreading of iCalendar and a line or two in the examples section of iTIP (not even in the defintion section of iTIP). In any case, lets continue the analysis promised. iTIP Section 3.2.2 REQUEST in part reads: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. and if you apply the rules from Section 2.1.5 to this you should get that if the UID/RECURRENCE-ID are not found in the recipients calendar then its a new REQUEST, otherwise its an update. Implicitly this concurs with iCalendar and Section 2.1.5 because if the RECURRENCE-ID changed and one or more iTIP REQUESTs were missed (or delayed!) then the recipient has NO way to properly perform this match and thus they would treat the REQUEST as a new invitation rather than a reschedule. In case that was not clear enough for some Ill try to make it as clear as I can: If I send you a REQUEST for a particular UID and RECURRENCE-ID that you do not have then you are to treat it as a new invitation by the definition of REQUEST. So you want the UID / RECURRENCE-ID values to never change from that point on or else you will think you got _another_ new invitation rather than a rescheduling of the one you already have! If RECURRENCE-ID did change on each reschedule (iCalendar prohibitions aside) then you have NO way to distinguish between a new invitation and the case where you missed one or more reschedules. This means that for the model where RECURRENCE-ID changes on each reschedule, any single delayed or missequenced REQUEST can _only_ be recovered by rescying up _all_instances_ of the repeat set! In addition if the messages were just missequenced this results in _tons_ of extra wasted workflow thrashing. Lets compare the iCalendar defined fixed RECURRENCE-ID model to the changing RECURRENCE-ID model of some and see how they deal with missequenced messages. The scenario is I invite you to an instance of a repeating meeting. After the initial invitation I reschedule it two times to accomodate other invitees. So for simplicity in references Ill refer to the initial invitation as SEQUENCE:0 and the two reschedules as SEQUENCE:1 and SEQUENCE:2 respectively. Because of network/server issues you recieve them in the order of SEQUENCE:0 then SEQUENCE:2 and then SEQUENCE:1; a not uncommon case when using email (aka iMIP). First the fixed RECURRENCE-ID model analysis: When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and 3.2.2 and determine that this is a new meeting invitation which you take some action on to get it onto your calendar. You then receive SEQUENCE:2 and you can match the UID / RECURRENCE-ID values and determine that the message is newer and that it obsoletes your current copy. You may notice that its SEQUENCE value is more than 1 different but since the higher valued SEQUENCE "obsoletes all other revisions of the component withlower values" it is not an issue that you did not see SEQUENCE:1 (yet). You can simply take action on it and send back a REPLY with the correct UID / RECURRENCE-ID / SEQUENCE:3 info on it and we are in sync. You later receive the SEQUENCE:1 REQUEST. You apply Section 2.1.5 and determine that your version is newer and as such this REQUEST is obsoleted and should be ignored. No further action is required by you since you are already in sync with me. Now for the changing RECURRENCE-ID model analysis: When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and 3.2.2 and determine that this is a new meeting invitation which you take some action on to get it onto your calendar. You then receive SEQUENCE:2 and you can NOT match the UID / RECURRENCE-ID values in your calendar so you determine that "something has gone wrong" (to borrow from the misquoted Section 4.7.2). You MUST therefore take NO action on the REQUEST since you cannot match the instance to one you currently have. You can ONLY send a REFRESH message back to me with just the UID and NO RECURRENCE-ID. This will cause me to generate another REQUEST to you "with the latest description and version of the event" (per iTIP Section 3.2.6 REFRESH). So I send you another REQUEST with the latest RECURRENCE-ID at SEQUENCE:2 which happens to _exactly_ match the REQUEST you just tossed out. If you receive this new REQUEST _before_ you get the missequenced SEQUENCE:1 REQUEST then you can _only_ repeat this loop indefinitely without recovery! In the interim the SEQUENCE:1 REQUEST arrives and you are able to apply Section 2.1.5 rules and find the correct UID / RECURRENCE-ID instance and determine that the REQUEST obsoletes the SEQUENCE:0 one you have. Now you can apply the currently obsolete SEQUENCE:1 change to your SEQUENCE:0 instance and send back a REPLY to me. I would of course detect that the UID / RECURRENCE-ID / SEQUENCE:1 REPLY is for an old copy (by applying 2.1.5) and thus I would have to ignore it and send you yet another REQUEST at SEQUENCE:2. Now that you are at SEQUENCE:1 you can safely match the UID / RECURRENCE-ID values and re-respond at SEQUENCE:3. This model has lots of drawbacks (hence why we long ago opt'd for a "fixed" RECURRENCE-ID model). They include: 1: Any missequencing of iTIP messages cannot be recovered on a single instance case. You MUST resync up ALL instances in the set, not just the instance in question. This means potentially LOTS of extra wasted workflow messaging. All just because of _1_ missquenced REQUEST (or REPLY if you invert the picture for my side as Organizer). 2: If the problem is NOT a missequencing of REQUESTs but rather recovery from a lost REQUEST (ie: an interim copy got lost in a server crash, disk failure, admin purge, etc) then it is not possible to recover when just one or some instances are involved since RECURRENCE-IDs are always involved in the REQUEST/REPLY(/COUNTER/...) messages when you correctly apply the restriction tables from iTIP. REQUEST clearly says: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. so any initial or subsequent REQUESTs MUST have a RECURRENCE-ID on them when referring to a particular instance. Had you not received the SEQUENCE:1 REQUEST at some point you would be infinitely stuck in the REFRESH/REQUEST loop above. 3: Since each instance can be reschedule independently of its siblings, it can be shown that if the RECURRENCE-ID changes it takes just 5 steps to misidentify the correct instance in question in a REPLY (on the Organizers side). For the steps, go check the archives for the 2 times its been pointed out. The same kind of fault _intolerant_ behaviour can be seen for other cases in iTIP if you lay out the scenarios (and ignore iCalendar too). Now lets visit that misquoted iTIP Examples Section 4.7.2 Bad RECURRENCE-ID lest some claim we are ignoring their citations for justifying a changing RECURRENCE-ID model. iTIP Section 4.7.2 Bad RECURRENCE-ID is intended as an example section on how to deal with problems matching UID / RECURRENCE-ID / SEQUENCE. It says "there are three cases in which an instance cannot be found." and describes them as: 1. The component with the referenced "UID" and "RECURRENCE-ID" has been found but the "SEQUENCE" number in the calendar store does not match that of the ITIP message. 2. The component with the referenced "UID" has been found, the "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be found. 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not support recurrences. Case 3 is not germane and will be ignored for this analysis. Case 1 is dealt with in: In case (1), two things can happen. If the "SEQUENCE" number of the "Attendee's" instance is larger than that in the "Organizer's" message then the "Attendee" is receiving an out-of-sequence message and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" instance is smaller, then the "Organizer" is sending out a newer version of the component and the "Attendee's" version needs to be updated. Since one or more updates have been missed, the "Attendee" SHOULD send a "REFRESH" message to the "Organizer" to get an updated version of the event. Here SEQUENCE is described as "smaller" and "larger" rather than "highest" and "lower" found in Section 2.1.5 but the implicit behaviour still matches. In order to match a UID / RECURRENCE-ID / SEQUENCE combo where the UID and RECURRENCE-ID values are "found" but the SEQUENCE value is "smaller" or "larger" then it should be intuitive that UID and RECURRENCE-ID do not change. Otherwise they could not be found to mismatch SEQUENCE! So this description matches the behaviour under Section 2.1.5. The last ine about "one or more updates have been missed" has been misused as justification for the recipient (ie: you in the above examples) having to send a REFRESH to the Organizer (ie: me...). However 2 things need to be noted here: A: The case is described as the one where UID / RECURRENCE-ID matched but SEQUENCE did NOT and B: The text says that the recipient "SHOULD" send a REFRESH, not "MUST". Now if you apply normal logic to the analysis you should see that bullet A above cannot be done in a changing RECURRENCE-ID model since the RECURRENCE-ID value changed! However this is incongruence needs to be overlooked to use Section 4.7.2 as justifying a changing RECURRENCE-ID model. Also, bullet B does not say "MUST" because it is NOT necessary! The larger/higher SEQUENCE version obsoletes all smaller/lower SEQUENCE versions and as such a REFRESH is not really necessary (except in a changing RECURRENCE-ID model). Case 2 is dealt with in: In case (2), something has gone wrong. Both the "Organizer" and the "Attendee" should have the same instances, but the "Attendee" does not have the referenced instance. In this case the "Attendee" SHOULD send a "REFRESH" to the "Organizer" to get an updated version of the event. Aha, we now have problem with the fixed RECURRENCE-ID model or do we? Actually we do not. If you receive a REQUEST for an unknown UID / RECURRENCE-ID pair then if you apply the text from Section 3.2.2 REQUEST correctly you simply view the REQUEST as a new invitation. In this case to a new instance you did not know about before. No problem here. Simply treat it as what it is, a REQUEST to another instance and workflow functions as before. Ah, we do have a problem though if we used a changing RECURRENCE-ID model. The "something has gone wrong" is that the message was missequenced. Gee, something as simple as that means there is a problem?? Thats the sign of a poor model (and one of the reasons the WG opt'd for the fixed RECURRENCE-ID model) because to recover means lots of extraneous iTIP messages in both directions. In addition it should be noted that not all Attendees are invited to all instances so the 2nd line is a bit misleading. If I want to add you to an instance (or subset of instances) of a repeating meeting Im organzing then obviously you wont have the "the same instances". I suspect that this is an artifact of editing because we do not expect / require that all attendees be invited to all instances. Also, this example also uses "SHOULD" instead of "MUST". Had the RECURRENCE-ID model been one of a changing RECURRENCE-ID value then the it would have to say "MUST" in order to attempt to resync the invitee with the Organzier. Some folks have seized on this Case as justification for a changing RECURRENCE-ID model. However they have modified it in the process by changing the "SHOULD" into a "MUST" and ignoring all of the other sections of iTIP that contradict them. Ok by now it should be clear that iCalendar and iTIP specify and use a fixed RECURRENCE-ID model. So the next thing to consider is the Working Group history on this subject and looking at how its been implemented by folks. As previously noted in recent discussions the question of a fixed or changing RECURRENCE-ID model was raised at least as far back as July 1999. The concensus then was that RECURRENCE-ID was fixed (essentially for the reasons demonstrated above). I invite anyone who still thinks that RECURRENCE-ID should changing on a reschedule to go reread the archives and search for yourself. Finally, lets take a look at how at least the RFC authors have implemented RECURRENCE-ID in their various products. Surely they would have implemented it the way the RFC intended it, yes?! If you take a look at Microsofts Outlook 98 (and higher) and Exchange you will find that all implementations (done by different development teams) all implement a fixed RECURRENCE-ID. You need to be configured for Internet Mode to get iCalendar support (or you can use the Exchange server if you configure it for iCalendar). In any case they have a fixed RECURRENCE-ID model. If you take a look at Lotus Organizer, Lotus Notes and the eSeries offerings you will find that all of them (also done by different development teams) implement a fixed RECURRENCE-ID. I do not have current access to Evolution or to Netscapes offerings but in looking over my notes from CalConnects I see that we did not have any interoperability issues with anyone participating so they must have also implemented fixed RECURRENCE-IDs. Ok, to recap this (assuming you are still with me to here): 1: iCalendar clearly and unequivocally says that on a reschedule RECURRENCE-ID does not change; it keeps the "original" value. RECURRENCE-ID "might also change" only in the case "When the definition of the recurrence _set_ for a calendar component changes" and not "When the definition of the recurrence _instance_ for a calendar component changes" 2: iTIP prose specifying Message Sequencing and messages themselves do not disagree with iCalendar. 3: iCalendar defines the RECURRENCE-ID property; iTIP defines its semantics. As such iTIP cannot redefine RECURRENCE-ID, that is not its job/function. 4: The changing or delta RECURRENCE-ID model has been demonstrated as being fault intolerant and flawed in dealing with sequencing and recovery of lost messages. 5: The WG already discussed this long ago and confirmed that RECURRENCE-ID did not change on a reschedule. 6: ALL the implementations from all the authors use a fixed RECURRENCE-ID. So either they ALL misunderstood their own model or they properly implemented it based on iCalendar and iTIP. RECURRENCE-ID is akin to "the UID for a particular instance" and as such it needs to have the similar behavior as the UID property. Otherwise iTIP workflow gets lots more complicated and verbose and so does a CUAs design. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0055863985256D78_= Content-Type: text/html; charset="US-ASCII"
Satya asked on 07/31/2003 06:43:38 PM:
> Is there an update on when the iCal authors will post their thinking on
> the subject?
I had hoped that reading the RFCs and searching the archives would have put this to rest once and for all but perhaps not for some.  So let me take some time to review both the RFC text and to technically analyze why the iCalendar specified a fixed RECURRENCE-ID.  This is going to be a somewhat long posting in order to cover both iCalendar, iTIP and the claims that purportedly define a changing RECURRENCE-ID model.

First, lets start with a review of the RFCs.  The 2 RFCs in question are 2445 (iCalendar) and 2446 (iTIP).  iCalendars role is to define the various properties and property parameters as well as specify their behaviour / intent.  iTIPs role is to give the iCalendar properties semantic meaning that all implementations can follow to interop.  So lets start with reviewing the actual definition of RECURRENCE-ID (Section 4.8.4.4 Recurrence ID).

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

[Snip]

  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 "RECURRENCE-ID" property is used in conjunction with the "UID"
  and "SEQUENCE" property to identify a particular instance of a
  recurring event, to-do or journal. For a given pair of "UID" and
  "SEQUENCE" property values, the "RECURRENCE-ID" value for a
  recurrence instance is fixed. When the definition of the recurrence
  set for a calendar component changes, and hence the "SEQUENCE"
  property value changes, the "RECURRENCE-ID" for a given recurrence
  instance might also change. [Snip]

Some folks seem to blindly ignore the 2nd (above, 3rd in the actual RFC) paragraph which clearly and unequivocally says that when a reschedule takes place the RECURRENCE-ID value "is still set to the original" value!  This of course flat out defeats the claim that "RECURRENCE-ID changes on each reschedule" as some have claimed so its easy to see why overlooking it happens.

In looking at the oft cited last paragraph you will find that the key phrase is "When the definition of the recurrence set for a calendar component changes...the "RECURRENCE-ID" for a given recurrence instance might also change".  The important bit that seems to be misread is "definition of the recurrence set"; it does not say "definition of the recurrence _instance_".   So its likely that this is partly to blame for some misinterpreting the description to mean "Whenever the instance is rescheduled, the recurrence instance also changes"  This does make a couple minor but not insignficant changes to the phrasing such as changing "might also change" into "always changes" but these changes are best ignored if you want to change the model.

Of course these changes would conflict with the entire paragraph before it so some would just ignore it in favor of their reinterpreatation of the prose.  However it must be noted that iCalendar clearly proscribes a "fixed" RECURRENCE-ID in at least 2 places.  

In addition Doug has claimed that "'original' means currently booked version" but thats nowhere near the meaning of the word original.  Instead of arguing a common sense meaning Ill instead defer to Merriam-Webster who define it as:

Main Entry: 2original
Function: adjective
Date: 14th century
1 : of, relating to, or constituting an origin or beginning : INITIAL <the original part of the house>
2 a : not secondary, derivative, or imitative b : being the first instance or source from which a copy, reproduction, or translation is or can be made

So "original" means the the same as the "initial" value, NOT the "latest" or "most recent".  This definition matches the paragraph in describing how RECURRENCE-ID stayed at the Friday date/time.  The reason that a fixed RECURRENCE-ID was specified over a varying one will become evident as we move into analyzing iTIP so lets do that now.

iTIP defines its role in relation to iCalendar as:

  iTIP complements the iCalendar object specification by adding
  semantics for group scheduling methods commonly available in current
  calendar systems.

so its role is NOT to impart (or modify) any defintion to the iCalendar properties or property parameters, thats the function of iCalendar.  The semantics for "group scheduling methods" are done in the various iTIP methods or messages.  iTIP messages can be sent over any kind of media or using assorted methods so the protocol had to first define some guidelines to apply to all messages to properly deal with missequencing  on the receiving end.  That is done in Section 2.1.5 Message Sequencing, before any direct discussion of individual messages was done.  In Section  2.1.5 Message Sequencing we see:

   1.  The primary key for referencing a particular iCalendar component
      is the "UID" property value. To reference an instance of a
      recurring component, the primary key is composed of the "UID" and
      the "RECURRENCE-ID" properties.

  2.  The secondary key for referencing a component is the "SEQUENCE"
      property value.  For components where the "UID" is the same, the
      component with the highest numeric value for the "SEQUENCE"
      property obsoletes all other revisions of the component with
      lower values.

Thus for repeating instances the primary key value used to find the instance the message refers to is the UID / RECURRENCE-ID pair.  Once this pair is used to find the instance in question the SEQUENCE property can be used to determine if the message is newer or older than the one the recipient has.  Or in iTIP terms, tell if the message has already been obsoleted or if it should obsolete the recipients copy.  Nothing here claims that RECURRENCE-ID changes on each reschedule and in order to be fault tolerant and easily recoverable RECURRENCE-ID should not change (iCalendar prose not withstanding).  This can be seen in the prose found in other sections in iTIP such as Sections 3.2.2 REQUEST, 3.2.2.1 Rescheduling an Event, 3.2.2.2 Updating or Reconfirmation of an Event, or even the often misquoted Section 4.7.2 Bad RECURRENCE-ID.

Section 3 of iTIP is where the actual protocol definitions happen.  Its where iTIP defines what a meeting request or response look like, etc.  Section 4 of iTIP is where the authors provided assorted examples of actual iTIP messages from Section 3.  As such its merely the demonstrative part of the iTIP RFC and does not carry the same weight.  The authors were always grumbling about the inclusion of examples ("If we put in an example of X then everyone will code to that and not to the text" as they so often lamented in meetings, emails and here on the list) and now this has come back to haunt us based on a misreading of iCalendar and a line or two in the examples section of iTIP (not even in the defintion section of iTIP). In any case, lets continue the analysis promised.

iTIP Section 3.2.2 REQUEST in part reads:

   The "UID" and "SEQUENCE" properties are used to distinguish the
  various uses of the "REQUEST" method. If the "UID" property value in
  the "REQUEST" is not found on the recipient's calendar, then the
  "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
  property value is found on the recipient's calendar, then the
  "REQUEST" is for a rescheduling, an update, or a reconfirm of the
  "VEVENT" calendar component.

and if you apply the rules from Section 2.1.5 to this you should get that if the UID/RECURRENCE-ID are not found in the recipients calendar then its a new REQUEST, otherwise its an update.  Implicitly this concurs with iCalendar and Section 2.1.5 because if the RECURRENCE-ID changed and one or more iTIP REQUESTs were missed (or delayed!) then the recipient has NO way to properly perform this match and thus they would treat the REQUEST as a new invitation rather than a reschedule.

In case that was not clear enough for some Ill try to make it as clear as I can: If I send you a REQUEST for a particular UID and RECURRENCE-ID that you do not have then you are to treat it as a new invitation by the definition of REQUEST.  So you want the UID / RECURRENCE-ID values to never change from that point on or else you will think you got _another_ new invitation rather than a rescheduling of the one you already have!

If RECURRENCE-ID did change on each reschedule (iCalendar prohibitions aside) then you have NO way to distinguish between a new invitation and the case where you missed one or more reschedules.  This means that for the model where RECURRENCE-ID changes on each reschedule, any single delayed or missequenced REQUEST can _only_ be recovered by rescying up _all_instances_ of the repeat set!  In addition if the messages were just missequenced this results in _tons_ of extra wasted workflow thrashing.  

Lets compare the iCalendar defined fixed RECURRENCE-ID model to the changing RECURRENCE-ID model of some and see how they deal with missequenced messages.  The scenario is I invite you to an instance of a repeating meeting.  After the initial invitation I reschedule it two times to accomodate other invitees.  So for simplicity in references Ill refer to the initial invitation as SEQUENCE:0 and the two reschedules as SEQUENCE:1 and SEQUENCE:2 respectively.  Because of network/server issues you recieve them in the order of SEQUENCE:0 then SEQUENCE:2 and then SEQUENCE:1; a not uncommon case when using email (aka iMIP).

First the fixed RECURRENCE-ID model analysis:

When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and 3.2.2 and determine that this is a new meeting invitation which you take some action on to get it onto your calendar.  

You then receive SEQUENCE:2 and you can match the UID / RECURRENCE-ID values and determine that the message is newer and that it obsoletes your current copy.  You may notice that its SEQUENCE value is more than 1 different but since the higher valued SEQUENCE "obsoletes all other revisions of the component withlower values" it is not an issue that you did not see SEQUENCE:1 (yet).  You can simply take action on it and send back a REPLY with the correct UID / RECURRENCE-ID / SEQUENCE:3 info on it and we are in sync.  

You later receive the SEQUENCE:1 REQUEST.  You apply Section 2.1.5 and determine that your version is newer and as such this REQUEST is obsoleted and should be ignored.  No further action is required by you since you are already in sync with me.

Now for the changing RECURRENCE-ID model analysis:

When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and 3.2.2 and determine that this is a new meeting invitation which you take some action on to get it onto your calendar.

You then receive SEQUENCE:2 and you can NOT match the UID / RECURRENCE-ID values in your calendar so you determine that "something has gone wrong" (to borrow from the misquoted Section 4.7.2).  You MUST therefore take NO action on the REQUEST since you cannot match the instance to one you currently have.  You can ONLY send a REFRESH message back to me with just the UID and NO RECURRENCE-ID.  This will cause me to generate another REQUEST to you "with the latest description and version of the event" (per iTIP Section 3.2.6 REFRESH).  So I send you another REQUEST with the latest RECURRENCE-ID at SEQUENCE:2 which happens to _exactly_ match the REQUEST you just tossed out.  If you receive this new REQUEST _before_ you get the missequenced SEQUENCE:1 REQUEST then you can _only_ repeat this loop indefinitely without recovery!

In the interim the SEQUENCE:1 REQUEST arrives and you are able to apply Section 2.1.5 rules and find the correct UID / RECURRENCE-ID instance and determine that the REQUEST obsoletes the SEQUENCE:0 one you have.  Now you can apply the currently obsolete SEQUENCE:1 change to your SEQUENCE:0 instance and send back a REPLY to me.  I would of course detect that the UID / RECURRENCE-ID / SEQUENCE:1 REPLY is for an old copy (by applying 2.1.5) and thus I would have to ignore it and send you yet another REQUEST at SEQUENCE:2.  Now that you are at SEQUENCE:1 you can safely match the UID / RECURRENCE-ID values and re-respond at SEQUENCE:3.

This model has lots of drawbacks (hence why we long ago opt'd for a "fixed" RECURRENCE-ID model).  They include:

1: Any missequencing of iTIP messages cannot be recovered on a single instance case.  You MUST resync up ALL instances in the set, not just the instance in question.  This means potentially LOTS of extra wasted workflow messaging.  All just because of _1_ missquenced REQUEST (or REPLY if you invert the picture for my side as Organizer).

2: If the problem is NOT a missequencing of REQUESTs but rather recovery from a lost REQUEST (ie: an interim copy got lost in a server crash, disk failure, admin purge, etc) then it is not possible to recover when just one or some instances are involved since RECURRENCE-IDs are always involved in the REQUEST/REPLY(/COUNTER/...) messages when you correctly apply the restriction tables from iTIP.  REQUEST clearly says:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise it
                           MUST NOT be present.
so any initial or subsequent REQUESTs MUST have a RECURRENCE-ID on them when referring to a particular instance.  Had you not received the SEQUENCE:1 REQUEST at some point you would be infinitely stuck in the REFRESH/REQUEST loop above.

3: Since each instance can be reschedule independently of its siblings, it can be shown that if the RECURRENCE-ID changes it takes just 5 steps to misidentify the correct instance in question in a REPLY (on the Organizers side).  For the steps, go check the archives for the 2 times its been pointed out.

The same kind of fault _intolerant_ behaviour can be seen for other cases in iTIP if you lay out the scenarios (and ignore iCalendar too).  

Now lets visit that misquoted iTIP Examples Section 4.7.2 Bad RECURRENCE-ID lest some claim we are ignoring their citations for justifying a changing RECURRENCE-ID model.  iTIP Section 4.7.2 Bad RECURRENCE-ID is intended as an example section on how to deal with problems matching UID / RECURRENCE-ID / SEQUENCE.  It says "there are three cases in which an instance cannot be found." and describes them as:

   1.  The component with the referenced "UID" and "RECURRENCE-ID" has
      been found but the "SEQUENCE" number in the calendar store does
      not match that of the ITIP message.

  2.  The component with the referenced "UID" has been found, the
      "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
      found.

  3.  The "UID" and "SEQUENCE" numbers are found but the CUA does not
      support recurrences.

Case 3 is not germane and will be ignored for this analysis.

Case 1 is dealt with in:

   In case (1), two things can happen. If the "SEQUENCE" number of the
  "Attendee's" instance is larger than that in the "Organizer's"
  message then the "Attendee" is receiving an out-of-sequence message
  and MUST ignore it.  If the "SEQUENCE" number of the "Attendee's"
  instance is smaller, then the "Organizer" is sending out a newer
  version of the component and the "Attendee's" version needs to be
  updated. Since one or more updates have been missed, the "Attendee"
  SHOULD send a "REFRESH" message to the "Organizer" to get an updated
  version of the event.

Here SEQUENCE is described as "smaller" and "larger" rather than "highest" and "lower" found in Section 2.1.5 but the implicit behaviour still matches.  In order to match a UID / RECURRENCE-ID / SEQUENCE combo where the UID and RECURRENCE-ID  values are "found" but the SEQUENCE value is "smaller" or "larger" then it should be intuitive that UID and RECURRENCE-ID do not change.  Otherwise they could not be found to mismatch SEQUENCE!  So this description matches the behaviour under Section 2.1.5.

The last ine about "one or more updates have been missed" has been misused as justification for the recipient (ie: you in the above examples) having to send a REFRESH to the Organizer (ie: me...).  However 2 things need to be noted here:

A: The case is described as the one where UID / RECURRENCE-ID matched but SEQUENCE did NOT and
B: The text says that the recipient "SHOULD" send a REFRESH, not "MUST".

Now if you apply normal logic to the analysis you should see that bullet A above cannot be done in a changing RECURRENCE-ID model since the RECURRENCE-ID value changed!   However this is incongruence needs to be overlooked to use Section 4.7.2 as justifying a changing RECURRENCE-ID model.  

Also, bullet B does not say "MUST" because it is NOT necessary! The larger/higher SEQUENCE version obsoletes all smaller/lower SEQUENCE versions and as such a REFRESH is not really necessary (except in a changing RECURRENCE-ID model).

Case 2 is dealt with in:

   In case (2), something has gone wrong.  Both the "Organizer" and the
  "Attendee" should have the same instances, but the "Attendee" does
  not have the referenced instance.  In this case the "Attendee" SHOULD
  send a "REFRESH" to the "Organizer" to get an updated version of the
  event.

Aha, we now have problem with the fixed RECURRENCE-ID model or do we?  Actually we do not.  If you receive a REQUEST for an unknown UID / RECURRENCE-ID pair then if you apply the text from Section 3.2.2 REQUEST correctly you simply view the REQUEST as a new invitation.  In this case to a new instance you did not know about before.  No problem here.  Simply treat it as what it is, a REQUEST to another instance and workflow functions as before.

Ah, we do have a problem though if we used a changing RECURRENCE-ID model.  The "something has gone wrong" is that the message was missequenced.  Gee, something as simple as that means there is a problem??  Thats the sign of a poor model (and one of the reasons the WG opt'd for the fixed RECURRENCE-ID model) because to recover means lots of extraneous iTIP messages in both directions.

In addition it should be noted that not all Attendees are invited to all instances so the 2nd line is a bit misleading.  If I want to add you to an instance (or subset of instances) of a repeating meeting Im organzing then obviously you wont have the "the same instances".  I suspect that this is an artifact of editing because we do not expect / require that all attendees be invited to all instances.

Also, this example also uses "SHOULD" instead of "MUST".  Had the RECURRENCE-ID model been one of a changing RECURRENCE-ID value then the it would have to say "MUST" in order to attempt to resync the invitee with the Organzier.  Some folks have seized on this Case as justification for a changing RECURRENCE-ID model.  However they have modified it in the process by changing the "SHOULD" into a "MUST" and ignoring all of the other sections of iTIP that contradict them.

Ok by now it should be clear that iCalendar and iTIP specify and use a fixed RECURRENCE-ID model.  So the next thing to consider is the Working Group history on this subject and looking at how its been implemented by folks.

As previously noted in recent discussions the question of a fixed or changing RECURRENCE-ID model was raised at least as far back as July 1999.  The concensus then was that RECURRENCE-ID was fixed (essentially for the reasons demonstrated above).  I invite anyone who still thinks that RECURRENCE-ID should changing on a reschedule to go reread the archives and search for yourself.

Finally, lets take a look at how at least the RFC authors have implemented RECURRENCE-ID in their various products.  Surely they would have implemented it the way the RFC intended it, yes?!  

If you take a look at Microsofts Outlook 98 (and higher) and Exchange you will find that all implementations (done by different development teams) all implement a fixed RECURRENCE-ID.  You need to be configured for Internet Mode to get iCalendar support (or you can use the Exchange server if you configure it for iCalendar).  In any case they have a fixed RECURRENCE-ID model.

If you take a look at Lotus Organizer, Lotus Notes and the eSeries offerings you will find that all of them (also done by different development teams) implement a fixed RECURRENCE-ID.

I do not have current access to Evolution or to Netscapes offerings but in looking over my notes from CalConnects I see that we did not have any interoperability issues with anyone participating so they must have also implemented fixed RECURRENCE-IDs.

Ok, to recap this (assuming you are still with me to here):

1: iCalendar clearly and unequivocally says that on a reschedule RECURRENCE-ID does not change; it keeps the "original" value.  RECURRENCE-ID "might also change" only in the case "When the definition of the recurrence _set_ for a calendar component changes" and not "When the definition of the recurrence _instance_ for a calendar component changes"
2: iTIP prose specifying Message Sequencing and messages themselves do not disagree with iCalendar.
3: iCalendar defines the RECURRENCE-ID property; iTIP defines its semantics.  As such iTIP cannot redefine RECURRENCE-ID, that is not its job/function.
4: The changing or delta RECURRENCE-ID model has been demonstrated as being fault intolerant and flawed in dealing with sequencing and recovery of lost messages.
5: The WG already discussed this long ago and confirmed that RECURRENCE-ID did not change on a reschedule.
6: ALL the implementations from all the authors use a fixed RECURRENCE-ID.  So either they ALL misunderstood their own model or they properly implemented it based on iCalendar and iTIP.

RECURRENCE-ID is akin to "the UID for a particular instance" and as such it needs to have the similar behavior as the UID property.  Otherwise iTIP workflow gets lots more complicated and verbose and so does a CUAs design.  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0055863985256D78_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 4 14:07:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06022 for ; Mon, 4 Aug 2003 14:07:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Hvnqt020963 for ; Mon, 4 Aug 2003 10:57:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74Hvnor020962 for ietf-calendar-bks; Mon, 4 Aug 2003 10:57:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from office2.jigzaw.com (adsl-68-20-84-161.dsl.chcgil.ameritech.net [68.20.84.161]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Hvlqt020956 for ; Mon, 4 Aug 2003 10:57:47 -0700 (PDT) (envelope-from shannon@jigzaw.com) Received: from colatz ([10.0.0.10]) by office2.jigzaw.com (8.9.3/8.9.3) with SMTP id MAA13939 for ; Mon, 4 Aug 2003 12:38:55 -0500 Reply-To: From: "Shannon J. Clark" To: Subject: Guardian discussion of Multiple time systems Date: Mon, 4 Aug 2003 12:57:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just a quick note to the list, something that is occurring in other standards bodies which this list should be thinking about as well. http://www.guardian.co.uk/uk_news/story/0,3604,985020,00.html The article above is on the now at least 4 different systems of time that are in use (mostly differing by the use or not of leap seconds). As the article discusses, computers "can" navigate through these, but there is a definite risk of programming errors or bugs. Shannon Shannon J. Clark President - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Aug 4 14:48:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07459 for ; Mon, 4 Aug 2003 14:48:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Ic1qt024050 for ; Mon, 4 Aug 2003 11:38:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74Ic1si024049 for ietf-calendar-bks; Mon, 4 Aug 2003 11:38:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Ic0qt024042 for ; Mon, 4 Aug 2003 11:38:00 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h74IbvEB008160 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 4 Aug 2003 11:37:59 -0700 Message-ID: <3F2EA7FF.20101@Royer.com> Date: Mon, 04 Aug 2003 12:37:51 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-11 is out References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080103070105070609080805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080103070105070609080805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 07/28/2003 08:57:46 PM: > > CAP Issues: > > > > -> Search for TBD - Its in the BEEP profile registration > > suggestions welcome. > > 2 questions: > > 1: Is there a diffs of CAP-10 (17-Feb) to CAP-11? I for one have no > time to reread CAP from cover to cover looking for changes. I'll put one up and then post its location to the WG. > 2: What about all the other issues that have been identified in WG > discussions already? Where they _all_ addressed in CAP-11 leaving just > the TBD stuff to be done? As I said in the e-mail, I am starting a list now. If anyone has a list - PLEASE post it. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080103070105070609080805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MDQxODM3NTFaMCMGCSqGSIb3DQEJBDEWBBTg 9WjNRDZZK1UJqYROjZuXiVXiGjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQCG3tIEIWKKZSc44+Gq2yjMpczsiWR3HIFsX7W18QW3+OLQ PJDLQ2EjRFD7OP8AaMYVvt++8PRWx7TNsclfflgVV4jwNUugj1c0CMx78WZBRXZ4Evq+mUEM 6iDNUevEeEuO5MtdkPw3Ew1FJzESq7LYRd3mIw5cqiHr1omuD0ERn3UoKSQ3r25I7Sv0REl5 lt1i/hWivXFoE8PMzGp22DtH46ygV8F5mNV93Bu7R2V/uvOYWWrYopyyRn1hmL1VGHN7SyE0 +oeY3eaBuwikjtlFnqMIyg0MshIMM0SPobANdIgU7sIhKvB8Du5+lXqD6AtCnF2qK55+hhWJ YeB8/zz5AAAAAAAA --------------ms080103070105070609080805-- From owner-ietf-calendar@mail.imc.org Mon Aug 4 15:00:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07892 for ; Mon, 4 Aug 2003 15:00:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74IoZqt025886 for ; Mon, 4 Aug 2003 11:50:35 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74IoZeA025884 for ietf-calendar-bks; Mon, 4 Aug 2003 11:50:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74IoYqt025875 for ; Mon, 4 Aug 2003 11:50:34 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h74IoXEB008258 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 4 Aug 2003 11:50:34 -0700 Message-ID: <3F2EAAF3.4050007@Royer.com> Date: Mon, 04 Aug 2003 12:50:27 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030806070902030807070401" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030806070902030807070401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > Satya asked on 07/31/2003 06:43:38 PM: > > Is there an update on when the iCal authors will post their thinking on > > the subject? > > > Some folks seem to blindly ignore the 2nd (above, 3rd in the actual RFC) > paragraph which clearly and unequivocally says that when a reschedule > takes place the RECURRENCE-ID value "is still set to the original" > value! Of the one being changed! Not of SEQUENCE:0 - orever. Other wish to blindly ignore ALL of the text and examples that clearly show that the paragraph you cite is for CHANGING and instance where the RECURRENCE-ID sent is the OLD one (for the set you are changing from). On this topic you have almost demanded that I answer your questions while you ignore all of mine. Not an open debate. The model in iCalendar that maps the RECURRENCE-ID to the the UID and SEQUENCE as documented works for BOTH models. Fixing the RECURRENCE-ID to be forever at the SEQUENCE:0 value and ignoring the 'set' only works for Bruce's model. In Bruces model he can not change a 2nd unrelated instance back to an original time of a separate 1st instance, so there code issues a new UID (As I understand it) then cancels the original UID (or the other way arround). Not a problem for those that tie the RECURRENCE-ID to the UID and SEQUENCE set as it will work for those. I'll stick to the method that works with both models. My testing shows that it DOES work with the major vendors. So far I have seen no evidence of any problem. Simply tie the RECURRENCE-ID to the SEQUENCE and UID as shown in multiple places in 2445 and 2446 and all works. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030806070902030807070401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNDE4NTAyN1owIwYJKoZIhvcNAQkEMRYEFJAMkQ/d Sjjl+c92mQM0R1wGSktkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADkYVDNW/5M+LqB6XOJOEejMRFP6JwBhxmmTxN4pGpbC/rhFrXup B1yN4luAt5Vd9O7iPza8hIUMByhl3WoivsD10D2ZE8Id/hC1ugRDKJ+8q3uyw6tmJTyMwldn aNATg1OOHBrAfKa393k6z40/+w3RrDdnFjH1bEunJ20DNZZwTTXu98WyU0S4BYWSwT4hW1Li kNuOggLLJgOAfbmE+qsNf3ywS3EtPelW/aFiwZUPk+wpcx2iTPMHY60SrNLwH9VqALEs8+lT HRvy47LL3fmokhovjrSlZRxz9gNfZ7zyJh7Yf72qPeK3RZ7WrdqeD7BU2e8Zl0gLn3GDnw8V 8vUAAAAAAAA= --------------ms030806070902030807070401-- From owner-ietf-calendar@mail.imc.org Mon Aug 4 15:29:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10007 for ; Mon, 4 Aug 2003 15:29:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74JJ8qt028873 for ; Mon, 4 Aug 2003 12:19:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74JJ81a028872 for ietf-calendar-bks; Mon, 4 Aug 2003 12:19:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74JJ6qt028866 for ; Mon, 4 Aug 2003 12:19:06 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h74JJ8ea006047 for ; Mon, 4 Aug 2003 13:19:08 -0600 (MDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h74JJ8hD000025 for ; Mon, 4 Aug 2003 12:19:08 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJ400DEW0BVWN@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Mon, 04 Aug 2003 12:19:07 -0700 (PDT) Date: Mon, 04 Aug 2003 12:19:09 -0700 From: Satya Vempati Subject: RE: RECURRENCE-ID discussion To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Unfortunately the RFCs are not consistent. You can quote one part of the RFC which agrees with your position, and others can quote the other parts that seem to buttress theirs. ----------------- For example, (RFC 2446, Section 3.7.1) If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. Note that after the change has occurred, the "RECURRENCE-ID" has changed to the new "DTSTART" value. ------------------- Additionally, portions of the document are not very clear and open to multiple interpretations: "When the definition of the recurrence set for a calendar component changes...the "RECURRENCE-ID" for a given recurrence instance might also change" What is meant by the "definition of a recurrece set?" One can also argue that the recurrence set changes whenever something is added to or deleted from it. Because of such inconsistencies, if we clearly understand the intent of the original authors and agree on it, the minor textual inconsistencies could be resolved amicably. -----Original Message----- From: Bruce_Kahn@notesdev.ibm.com [mailto:Bruce_Kahn@notesdev.ibm.com] Sent: Monday, August 04, 2003 8:37 AM To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion Satya asked on 07/31/2003 06:43:38 PM: > Is there an update on when the iCal authors will post their thinking on > the subject? I had hoped that reading the RFCs and searching the archives would have put this to rest once and for all but perhaps not for some. So let me take some time to review both the RFC text and to technically analyze why the iCalendar specified a fixed RECURRENCE-ID. This is going to be a somewhat long posting in order to cover both iCalendar, iTIP and the claims that purportedly define a changing RECURRENCE-ID model. First, lets start with a review of the RFCs. The 2 RFCs in question are 2445 (iCalendar) and 2446 (iTIP). iCalendars role is to define the various properties and property parameters as well as specify their behaviour / intent. iTIPs role is to give the iCalendar properties semantic meaning that all implementations can follow to interop. So lets start with reviewing the actual definition of RECURRENCE-ID (Section 4.8.4.4 Recurrence ID). Description: 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. [Snip] 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 "RECURRENCE-ID" property is used in conjunction with the "UID" and "SEQUENCE" property to identify a particular instance of a recurring event, to-do or journal. For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. When the definition of the recurrence set for a calendar component changes, and hence the "SEQUENCE" property value changes, the "RECURRENCE-ID" for a given recurrence instance might also change. [Snip] Some folks seem to blindly ignore the 2nd (above, 3rd in the actual RFC) paragraph which clearly and unequivocally says that when a reschedule takes place the RECURRENCE-ID value "is still set to the original" value! This of course flat out defeats the claim that "RECURRENCE-ID changes on each reschedule" as some have claimed so its easy to see why overlooking it happens. In looking at the oft cited last paragraph you will find that the key phrase is "When the definition of the recurrence set for a calendar component changes...the "RECURRENCE-ID" for a given recurrence instance might also change". The important bit that seems to be misread is "definition of the recurrence set"; it does not say "definition of the recurrence _instance_". So its likely that this is partly to blame for some misinterpreting the description to mean "Whenever the instance is rescheduled, the recurrence instance also changes" This does make a couple minor but not insignficant changes to the phrasing such as changing "might also change" into "always changes" but these changes are best ignored if you want to change the model. Of course these changes would conflict with the entire paragraph before it so some would just ignore it in favor of their reinterpreatation of the prose. However it must be noted that iCalendar clearly proscribes a "fixed" RECURRENCE-ID in at least 2 places. In addition Doug has claimed that "'original' means currently booked version" but thats nowhere near the meaning of the word original. Instead of arguing a common sense meaning Ill instead defer to Merriam-Webster who define it as: Main Entry: 2original Function: adjective Date: 14th century 1 : of, relating to, or constituting an origin or beginning : INITIAL 2 a : not secondary, derivative, or imitative b : being the first instance or source from which a copy, reproduction, or translation is or can be made So "original" means the the same as the "initial" value, NOT the "latest" or "most recent". This definition matches the paragraph in describing how RECURRENCE-ID stayed at the Friday date/time. The reason that a fixed RECURRENCE-ID was specified over a varying one will become evident as we move into analyzing iTIP so lets do that now. iTIP defines its role in relation to iCalendar as: iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. so its role is NOT to impart (or modify) any defintion to the iCalendar properties or property parameters, thats the function of iCalendar. The semantics for "group scheduling methods" are done in the various iTIP methods or messages. iTIP messages can be sent over any kind of media or using assorted methods so the protocol had to first define some guidelines to apply to all messages to properly deal with missequencing on the receiving end. That is done in Section 2.1.5 Message Sequencing, before any direct discussion of individual messages was done. In Section 2.1.5 Message Sequencing we see: 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. 2. The secondary key for referencing a component is the "SEQUENCE" property value. For components where the "UID" is the same, the component with the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values. Thus for repeating instances the primary key value used to find the instance the message refers to is the UID / RECURRENCE-ID pair. Once this pair is used to find the instance in question the SEQUENCE property can be used to determine if the message is newer or older than the one the recipient has. Or in iTIP terms, tell if the message has already been obsoleted or if it should obsolete the recipients copy. Nothing here claims that RECURRENCE-ID changes on each reschedule and in order to be fault tolerant and easily recoverable RECURRENCE-ID should not change (iCalendar prose not withstanding). This can be seen in the prose found in other sections in iTIP such as Sections 3.2.2 REQUEST, 3.2.2.1 Rescheduling an Event, 3.2.2.2 Updating or Reconfirmation of an Event, or even the often misquoted Section 4.7.2 Bad RECURRENCE-ID. Section 3 of iTIP is where the actual protocol definitions happen. Its where iTIP defines what a meeting request or response look like, etc. Section 4 of iTIP is where the authors provided assorted examples of actual iTIP messages from Section 3. As such its merely the demonstrative part of the iTIP RFC and does not carry the same weight. The authors were always grumbling about the inclusion of examples ("If we put in an example of X then everyone will code to that and not to the text" as they so often lamented in meetings, emails and here on the list) and now this has come back to haunt us based on a misreading of iCalendar and a line or two in the examples section of iTIP (not even in the defintion section of iTIP). In any case, lets continue the analysis promised. iTIP Section 3.2.2 REQUEST in part reads: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. and if you apply the rules from Section 2.1.5 to this you should get that if the UID/RECURRENCE-ID are not found in the recipients calendar then its a new REQUEST, otherwise its an update. Implicitly this concurs with iCalendar and Section 2.1.5 because if the RECURRENCE-ID changed and one or more iTIP REQUESTs were missed (or delayed!) then the recipient has NO way to properly perform this match and thus they would treat the REQUEST as a new invitation rather than a reschedule. In case that was not clear enough for some Ill try to make it as clear as I can: If I send you a REQUEST for a particular UID and RECURRENCE-ID that you do not have then you are to treat it as a new invitation by the definition of REQUEST. So you want the UID / RECURRENCE-ID values to never change from that point on or else you will think you got _another_ new invitation rather than a rescheduling of the one you already have! If RECURRENCE-ID did change on each reschedule (iCalendar prohibitions aside) then you have NO way to distinguish between a new invitation and the case where you missed one or more reschedules. This means that for the model where RECURRENCE-ID changes on each reschedule, any single delayed or missequenced REQUEST can _only_ be recovered by rescying up _all_instances_ of the repeat set! In addition if the messages were just missequenced this results in _tons_ of extra wasted workflow thrashing. Lets compare the iCalendar defined fixed RECURRENCE-ID model to the changing RECURRENCE-ID model of some and see how they deal with missequenced messages. The scenario is I invite you to an instance of a repeating meeting. After the initial invitation I reschedule it two times to accomodate other invitees. So for simplicity in references Ill refer to the initial invitation as SEQUENCE:0 and the two reschedules as SEQUENCE:1 and SEQUENCE:2 respectively. Because of network/server issues you recieve them in the order of SEQUENCE:0 then SEQUENCE:2 and then SEQUENCE:1; a not uncommon case when using email (aka iMIP). First the fixed RECURRENCE-ID model analysis: When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and 3.2.2 and determine that this is a new meeting invitation which you take some action on to get it onto your calendar. You then receive SEQUENCE:2 and you can match the UID / RECURRENCE-ID values and determine that the message is newer and that it obsoletes your current copy. You may notice that its SEQUENCE value is more than 1 different but since the higher valued SEQUENCE "obsoletes all other revisions of the component withlower values" it is not an issue that you did not see SEQUENCE:1 (yet). You can simply take action on it and send back a REPLY with the correct UID / RECURRENCE-ID / SEQUENCE:3 info on it and we are in sync. You later receive the SEQUENCE:1 REQUEST. You apply Section 2.1.5 and determine that your version is newer and as such this REQUEST is obsoleted and should be ignored. No further action is required by you since you are already in sync with me. Now for the changing RECURRENCE-ID model analysis: When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and 3.2.2 and determine that this is a new meeting invitation which you take some action on to get it onto your calendar. You then receive SEQUENCE:2 and you can NOT match the UID / RECURRENCE-ID values in your calendar so you determine that "something has gone wrong" (to borrow from the misquoted Section 4.7.2). You MUST therefore take NO action on the REQUEST since you cannot match the instance to one you currently have. You can ONLY send a REFRESH message back to me with just the UID and NO RECURRENCE-ID. This will cause me to generate another REQUEST to you "with the latest description and version of the event" (per iTIP Section 3.2.6 REFRESH). So I send you another REQUEST with the latest RECURRENCE-ID at SEQUENCE:2 which happens to _exactly_ match the REQUEST you just tossed out. If you receive this new REQUEST _before_ you get the missequenced SEQUENCE:1 REQUEST then you can _only_ repeat this loop indefinitely without recovery! In the interim the SEQUENCE:1 REQUEST arrives and you are able to apply Section 2.1.5 rules and find the correct UID / RECURRENCE-ID instance and determine that the REQUEST obsoletes the SEQUENCE:0 one you have. Now you can apply the currently obsolete SEQUENCE:1 change to your SEQUENCE:0 instance and send back a REPLY to me. I would of course detect that the UID / RECURRENCE-ID / SEQUENCE:1 REPLY is for an old copy (by applying 2.1.5) and thus I would have to ignore it and send you yet another REQUEST at SEQUENCE:2. Now that you are at SEQUENCE:1 you can safely match the UID / RECURRENCE-ID values and re-respond at SEQUENCE:3. This model has lots of drawbacks (hence why we long ago opt'd for a "fixed" RECURRENCE-ID model). They include: 1: Any missequencing of iTIP messages cannot be recovered on a single instance case. You MUST resync up ALL instances in the set, not just the instance in question. This means potentially LOTS of extra wasted workflow messaging. All just because of _1_ missquenced REQUEST (or REPLY if you invert the picture for my side as Organizer). 2: If the problem is NOT a missequencing of REQUESTs but rather recovery from a lost REQUEST (ie: an interim copy got lost in a server crash, disk failure, admin purge, etc) then it is not possible to recover when just one or some instances are involved since RECURRENCE-IDs are always involved in the REQUEST/REPLY(/COUNTER/...) messages when you correctly apply the restriction tables from iTIP. REQUEST clearly says: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. so any initial or subsequent REQUESTs MUST have a RECURRENCE-ID on them when referring to a particular instance. Had you not received the SEQUENCE:1 REQUEST at some point you would be infinitely stuck in the REFRESH/REQUEST loop above. 3: Since each instance can be reschedule independently of its siblings, it can be shown that if the RECURRENCE-ID changes it takes just 5 steps to misidentify the correct instance in question in a REPLY (on the Organizers side). For the steps, go check the archives for the 2 times its been pointed out. The same kind of fault _intolerant_ behaviour can be seen for other cases in iTIP if you lay out the scenarios (and ignore iCalendar too). Now lets visit that misquoted iTIP Examples Section 4.7.2 Bad RECURRENCE-ID lest some claim we are ignoring their citations for justifying a changing RECURRENCE-ID model. iTIP Section 4.7.2 Bad RECURRENCE-ID is intended as an example section on how to deal with problems matching UID / RECURRENCE-ID / SEQUENCE. It says "there are three cases in which an instance cannot be found." and describes them as: 1. The component with the referenced "UID" and "RECURRENCE-ID" has been found but the "SEQUENCE" number in the calendar store does not match that of the ITIP message. 2. The component with the referenced "UID" has been found, the "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be found. 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not support recurrences. Case 3 is not germane and will be ignored for this analysis. Case 1 is dealt with in: In case (1), two things can happen. If the "SEQUENCE" number of the "Attendee's" instance is larger than that in the "Organizer's" message then the "Attendee" is receiving an out-of-sequence message and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" instance is smaller, then the "Organizer" is sending out a newer version of the component and the "Attendee's" version needs to be updated. Since one or more updates have been missed, the "Attendee" SHOULD send a "REFRESH" message to the "Organizer" to get an updated version of the event. Here SEQUENCE is described as "smaller" and "larger" rather than "highest" and "lower" found in Section 2.1.5 but the implicit behaviour still matches. In order to match a UID / RECURRENCE-ID / SEQUENCE combo where the UID and RECURRENCE-ID values are "found" but the SEQUENCE value is "smaller" or "larger" then it should be intuitive that UID and RECURRENCE-ID do not change. Otherwise they could not be found to mismatch SEQUENCE! So this description matches the behaviour under Section 2.1.5. The last ine about "one or more updates have been missed" has been misused as justification for the recipient (ie: you in the above examples) having to send a REFRESH to the Organizer (ie: me...). However 2 things need to be noted here: A: The case is described as the one where UID / RECURRENCE-ID matched but SEQUENCE did NOT and B: The text says that the recipient "SHOULD" send a REFRESH, not "MUST". Now if you apply normal logic to the analysis you should see that bullet A above cannot be done in a changing RECURRENCE-ID model since the RECURRENCE-ID value changed! However this is incongruence needs to be overlooked to use Section 4.7.2 as justifying a changing RECURRENCE-ID model. Also, bullet B does not say "MUST" because it is NOT necessary! The larger/higher SEQUENCE version obsoletes all smaller/lower SEQUENCE versions and as such a REFRESH is not really necessary (except in a changing RECURRENCE-ID model). Case 2 is dealt with in: In case (2), something has gone wrong. Both the "Organizer" and the "Attendee" should have the same instances, but the "Attendee" does not have the referenced instance. In this case the "Attendee" SHOULD send a "REFRESH" to the "Organizer" to get an updated version of the event. Aha, we now have problem with the fixed RECURRENCE-ID model or do we? Actually we do not. If you receive a REQUEST for an unknown UID / RECURRENCE-ID pair then if you apply the text from Section 3.2.2 REQUEST correctly you simply view the REQUEST as a new invitation. In this case to a new instance you did not know about before. No problem here. Simply treat it as what it is, a REQUEST to another instance and workflow functions as before. Ah, we do have a problem though if we used a changing RECURRENCE-ID model. The "something has gone wrong" is that the message was missequenced. Gee, something as simple as that means there is a problem?? Thats the sign of a poor model (and one of the reasons the WG opt'd for the fixed RECURRENCE-ID model) because to recover means lots of extraneous iTIP messages in both directions. In addition it should be noted that not all Attendees are invited to all instances so the 2nd line is a bit misleading. If I want to add you to an instance (or subset of instances) of a repeating meeting Im organzing then obviously you wont have the "the same instances". I suspect that this is an artifact of editing because we do not expect / require that all attendees be invited to all instances. Also, this example also uses "SHOULD" instead of "MUST". Had the RECURRENCE-ID model been one of a changing RECURRENCE-ID value then the it would have to say "MUST" in order to attempt to resync the invitee with the Organzier. Some folks have seized on this Case as justification for a changing RECURRENCE-ID model. However they have modified it in the process by changing the "SHOULD" into a "MUST" and ignoring all of the other sections of iTIP that contradict them. Ok by now it should be clear that iCalendar and iTIP specify and use a fixed RECURRENCE-ID model. So the next thing to consider is the Working Group history on this subject and looking at how its been implemented by folks. As previously noted in recent discussions the question of a fixed or changing RECURRENCE-ID model was raised at least as far back as July 1999. The concensus then was that RECURRENCE-ID was fixed (essentially for the reasons demonstrated above). I invite anyone who still thinks that RECURRENCE-ID should changing on a reschedule to go reread the archives and search for yourself. Finally, lets take a look at how at least the RFC authors have implemented RECURRENCE-ID in their various products. Surely they would have implemented it the way the RFC intended it, yes?! If you take a look at Microsofts Outlook 98 (and higher) and Exchange you will find that all implementations (done by different development teams) all implement a fixed RECURRENCE-ID. You need to be configured for Internet Mode to get iCalendar support (or you can use the Exchange server if you configure it for iCalendar). In any case they have a fixed RECURRENCE-ID model. If you take a look at Lotus Organizer, Lotus Notes and the eSeries offerings you will find that all of them (also done by different development teams) implement a fixed RECURRENCE-ID. I do not have current access to Evolution or to Netscapes offerings but in looking over my notes from CalConnects I see that we did not have any interoperability issues with anyone participating so they must have also implemented fixed RECURRENCE-IDs. Ok, to recap this (assuming you are still with me to here): 1: iCalendar clearly and unequivocally says that on a reschedule RECURRENCE-ID does not change; it keeps the "original" value. RECURRENCE-ID "might also change" only in the case "When the definition of the recurrence _set_ for a calendar component changes" and not "When the definition of the recurrence _instance_ for a calendar component changes" 2: iTIP prose specifying Message Sequencing and messages themselves do not disagree with iCalendar. 3: iCalendar defines the RECURRENCE-ID property; iTIP defines its semantics. As such iTIP cannot redefine RECURRENCE-ID, that is not its job/function. 4: The changing or delta RECURRENCE-ID model has been demonstrated as being fault intolerant and flawed in dealing with sequencing and recovery of lost messages. 5: The WG already discussed this long ago and confirmed that RECURRENCE-ID did not change on a reschedule. 6: ALL the implementations from all the authors use a fixed RECURRENCE-ID. So either they ALL misunderstood their own model or they properly implemented it based on iCalendar and iTIP. RECURRENCE-ID is akin to "the UID for a particular instance" and as such it needs to have the similar behavior as the UID property. Otherwise iTIP workflow gets lots more complicated and verbose and so does a CUAs design. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Mon Aug 4 16:56:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11800 for ; Mon, 4 Aug 2003 16:56:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74KFPqt034346 for ; Mon, 4 Aug 2003 13:15:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74KFPRT034345 for ietf-calendar-bks; Mon, 4 Aug 2003 13:15:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74KFJqt034321 for ; Mon, 4 Aug 2003 13:15:19 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: Satya Vempati Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: RE: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Mon, 4 Aug 2003 16:15:19 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 08/04/2003 04:15:22 PM, Serialize complete at 08/04/2003 04:15:22 PM Content-Type: multipart/alternative; boundary="=_alternative 006F442385256D78_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F442385256D78_= Content-Type: text/plain; charset="us-ascii" I have sent another "nudge" note to the author in hopes of getting his interpretation and/or understanding of what the drafts "mean." Pretty soon I'm going to have to get into "Mom" mode and that won't be pretty. So, let's see if I can get the text/understanding from them this week. Satya Vempati Sent by: owner-ietf-calendar@mail.imc.org 08/04/2003 15:19 To: "ietf-calendar@imc.org" cc: Subject: RE: RECURRENCE-ID discussion Unfortunately the RFCs are not consistent. You can quote one part of the RFC which agrees with your position, and others can quote the other parts that seem to buttress theirs. ----------------- For example, (RFC 2446, Section 3.7.1) If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. Note that after the change has occurred, the "RECURRENCE-ID" has changed to the new "DTSTART" value. ------------------- Additionally, portions of the document are not very clear and open to multiple interpretations: "When the definition of the recurrence set for a calendar component changes...the "RECURRENCE-ID" for a given recurrence instance might also change" What is meant by the "definition of a recurrece set?" One can also argue that the recurrence set changes whenever something is added to or deleted from it. Because of such inconsistencies, if we clearly understand the intent of the original authors and agree on it, the minor textual inconsistencies could be resolved amicably. -----Original Message----- From: Bruce_Kahn@notesdev.ibm.com [mailto:Bruce_Kahn@notesdev.ibm.com] Sent: Monday, August 04, 2003 8:37 AM To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion Satya asked on 07/31/2003 06:43:38 PM: > Is there an update on when the iCal authors will post their thinking on > the subject? I had hoped that reading the RFCs and searching the archives would have put this to rest once and for all but perhaps not for some. So let me take some time to review both the RFC text and to technically analyze why the iCalendar specified a fixed RECURRENCE-ID. This is going to be a somewhat long posting in order to cover both iCalendar, iTIP and the claims that purportedly define a changing RECURRENCE-ID model. First, lets start with a review of the RFCs. The 2 RFCs in question are 2445 (iCalendar) and 2446 (iTIP). iCalendars role is to define the various properties and property parameters as well as specify their behaviour / intent. iTIPs role is to give the iCalendar properties semantic meaning that all implementations can follow to interop. So lets start with reviewing the actual definition of RECURRENCE-ID (Section 4.8.4.4 Recurrence ID). Description: 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. [Snip] 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 "RECURRENCE-ID" property is used in conjunction with the "UID" and "SEQUENCE" property to identify a particular instance of a recurring event, to-do or journal. For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. When the definition of the recurrence set for a calendar component changes, and hence the "SEQUENCE" property value changes, the "RECURRENCE-ID" for a given recurrence instance might also change. [Snip] Some folks seem to blindly ignore the 2nd (above, 3rd in the actual RFC) paragraph which clearly and unequivocally says that when a reschedule takes place the RECURRENCE-ID value "is still set to the original" value! This of course flat out defeats the claim that "RECURRENCE-ID changes on each reschedule" as some have claimed so its easy to see why overlooking it happens. In looking at the oft cited last paragraph you will find that the key phrase is "When the definition of the recurrence set for a calendar component changes...the "RECURRENCE-ID" for a given recurrence instance might also change". The important bit that seems to be misread is "definition of the recurrence set"; it does not say "definition of the recurrence _instance_". So its likely that this is partly to blame for some misinterpreting the description to mean "Whenever the instance is rescheduled, the recurrence instance also changes" This does make a couple minor but not insignficant changes to the phrasing such as changing "might also change" into "always changes" but these changes are best ignored if you want to change the model. Of course these changes would conflict with the entire paragraph before it so some would just ignore it in favor of their reinterpreatation of the prose. However it must be noted that iCalendar clearly proscribes a "fixed" RECURRENCE-ID in at least 2 places. In addition Doug has claimed that "'original' means currently booked version" but thats nowhere near the meaning of the word original. Instead of arguing a common sense meaning Ill instead defer to Merriam-Webster who define it as: Main Entry: 2original Function: adjective Date: 14th century 1 : of, relating to, or constituting an origin or beginning : INITIAL 2 a : not secondary, derivative, or imitative b : being the first instance or source from which a copy, reproduction, or translation is or can be made So "original" means the the same as the "initial" value, NOT the "latest" or "most recent". This definition matches the paragraph in describing how RECURRENCE-ID stayed at the Friday date/time. The reason that a fixed RECURRENCE-ID was specified over a varying one will become evident as we move into analyzing iTIP so lets do that now. iTIP defines its role in relation to iCalendar as: iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. so its role is NOT to impart (or modify) any defintion to the iCalendar properties or property parameters, thats the function of iCalendar. The semantics for "group scheduling methods" are done in the various iTIP methods or messages. iTIP messages can be sent over any kind of media or using assorted methods so the protocol had to first define some guidelines to apply to all messages to properly deal with missequencing on the receiving end. That is done in Section 2.1.5 Message Sequencing, before any direct discussion of individual messages was done. In Section 2.1.5 Message Sequencing we see: 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. 2. The secondary key for referencing a component is the "SEQUENCE" property value. For components where the "UID" is the same, the component with the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values. Thus for repeating instances the primary key value used to find the instance the message refers to is the UID / RECURRENCE-ID pair. Once this pair is used to find the instance in question the SEQUENCE property can be used to determine if the message is newer or older than the one the recipient has. Or in iTIP terms, tell if the message has already been obsoleted or if it should obsolete the recipients copy. Nothing here claims that RECURRENCE-ID changes on each reschedule and in order to be fault tolerant and easily recoverable RECURRENCE-ID should not change (iCalendar prose not withstanding). This can be seen in the prose found in other sections in iTIP such as Sections 3.2.2 REQUEST, 3.2.2.1 Rescheduling an Event, 3.2.2.2 Updating or Reconfirmation of an Event, or even the often misquoted Section 4.7.2 Bad RECURRENCE-ID. Section 3 of iTIP is where the actual protocol definitions happen. Its where iTIP defines what a meeting request or response look like, etc. Section 4 of iTIP is where the authors provided assorted examples of actual iTIP messages from Section 3. As such its merely the demonstrative part of the iTIP RFC and does not carry the same weight. The authors were always grumbling about the inclusion of examples ("If we put in an example of X then everyone will code to that and not to the text" as they so often lamented in meetings, emails and here on the list) and now this has come back to haunt us based on a misreading of iCalendar and a line or two in the examples section of iTIP (not even in the defintion section of iTIP). In any case, lets continue the analysis promised. iTIP Section 3.2.2 REQUEST in part reads: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. and if you apply the rules from Section 2.1.5 to this you should get that if the UID/RECURRENCE-ID are not found in the recipients calendar then its a new REQUEST, otherwise its an update. Implicitly this concurs with iCalendar and Section 2.1.5 because if the RECURRENCE-ID changed and one or more iTIP REQUESTs were missed (or delayed!) then the recipient has NO way to properly perform this match and thus they would treat the REQUEST as a new invitation rather than a reschedule. In case that was not clear enough for some Ill try to make it as clear as I can: If I send you a REQUEST for a particular UID and RECURRENCE-ID that you do not have then you are to treat it as a new invitation by the definition of REQUEST. So you want the UID / RECURRENCE-ID values to never change from that point on or else you will think you got _another_ new invitation rather than a rescheduling of the one you already have! If RECURRENCE-ID did change on each reschedule (iCalendar prohibitions aside) then you have NO way to distinguish between a new invitation and the case where you missed one or more reschedules. This means that for the model where RECURRENCE-ID changes on each reschedule, any single delayed or missequenced REQUEST can _only_ be recovered by rescying up _all_instances_ of the repeat set! In addition if the messages were just missequenced this results in _tons_ of extra wasted workflow thrashing. Lets compare the iCalendar defined fixed RECURRENCE-ID model to the changing RECURRENCE-ID model of some and see how they deal with missequenced messages. The scenario is I invite you to an instance of a repeating meeting. After the initial invitation I reschedule it two times to accomodate other invitees. So for simplicity in references Ill refer to the initial invitation as SEQUENCE:0 and the two reschedules as SEQUENCE:1 and SEQUENCE:2 respectively. Because of network/server issues you recieve them in the order of SEQUENCE:0 then SEQUENCE:2 and then SEQUENCE:1; a not uncommon case when using email (aka iMIP). First the fixed RECURRENCE-ID model analysis: When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and 3.2.2 and determine that this is a new meeting invitation which you take some action on to get it onto your calendar. You then receive SEQUENCE:2 and you can match the UID / RECURRENCE-ID values and determine that the message is newer and that it obsoletes your current copy. You may notice that its SEQUENCE value is more than 1 different but since the higher valued SEQUENCE "obsoletes all other revisions of the component withlower values" it is not an issue that you did not see SEQUENCE:1 (yet). You can simply take action on it and send back a REPLY with the correct UID / RECURRENCE-ID / SEQUENCE:3 info on it and we are in sync. You later receive the SEQUENCE:1 REQUEST. You apply Section 2.1.5 and determine that your version is newer and as such this REQUEST is obsoleted and should be ignored. No further action is required by you since you are already in sync with me. Now for the changing RECURRENCE-ID model analysis: When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and 3.2.2 and determine that this is a new meeting invitation which you take some action on to get it onto your calendar. You then receive SEQUENCE:2 and you can NOT match the UID / RECURRENCE-ID values in your calendar so you determine that "something has gone wrong" (to borrow from the misquoted Section 4.7.2). You MUST therefore take NO action on the REQUEST since you cannot match the instance to one you currently have. You can ONLY send a REFRESH message back to me with just the UID and NO RECURRENCE-ID. This will cause me to generate another REQUEST to you "with the latest description and version of the event" (per iTIP Section 3.2.6 REFRESH). So I send you another REQUEST with the latest RECURRENCE-ID at SEQUENCE:2 which happens to _exactly_ match the REQUEST you just tossed out. If you receive this new REQUEST _before_ you get the missequenced SEQUENCE:1 REQUEST then you can _only_ repeat this loop indefinitely without recovery! In the interim the SEQUENCE:1 REQUEST arrives and you are able to apply Section 2.1.5 rules and find the correct UID / RECURRENCE-ID instance and determine that the REQUEST obsoletes the SEQUENCE:0 one you have. Now you can apply the currently obsolete SEQUENCE:1 change to your SEQUENCE:0 instance and send back a REPLY to me. I would of course detect that the UID / RECURRENCE-ID / SEQUENCE:1 REPLY is for an old copy (by applying 2.1.5) and thus I would have to ignore it and send you yet another REQUEST at SEQUENCE:2. Now that you are at SEQUENCE:1 you can safely match the UID / RECURRENCE-ID values and re-respond at SEQUENCE:3. This model has lots of drawbacks (hence why we long ago opt'd for a "fixed" RECURRENCE-ID model). They include: 1: Any missequencing of iTIP messages cannot be recovered on a single instance case. You MUST resync up ALL instances in the set, not just the instance in question. This means potentially LOTS of extra wasted workflow messaging. All just because of _1_ missquenced REQUEST (or REPLY if you invert the picture for my side as Organizer). 2: If the problem is NOT a missequencing of REQUESTs but rather recovery from a lost REQUEST (ie: an interim copy got lost in a server crash, disk failure, admin purge, etc) then it is not possible to recover when just one or some instances are involved since RECURRENCE-IDs are always involved in the REQUEST/REPLY(/COUNTER/...) messages when you correctly apply the restriction tables from iTIP. REQUEST clearly says: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. so any initial or subsequent REQUESTs MUST have a RECURRENCE-ID on them when referring to a particular instance. Had you not received the SEQUENCE:1 REQUEST at some point you would be infinitely stuck in the REFRESH/REQUEST loop above. 3: Since each instance can be reschedule independently of its siblings, it can be shown that if the RECURRENCE-ID changes it takes just 5 steps to misidentify the correct instance in question in a REPLY (on the Organizers side). For the steps, go check the archives for the 2 times its been pointed out. The same kind of fault _intolerant_ behaviour can be seen for other cases in iTIP if you lay out the scenarios (and ignore iCalendar too). Now lets visit that misquoted iTIP Examples Section 4.7.2 Bad RECURRENCE-ID lest some claim we are ignoring their citations for justifying a changing RECURRENCE-ID model. iTIP Section 4.7.2 Bad RECURRENCE-ID is intended as an example section on how to deal with problems matching UID / RECURRENCE-ID / SEQUENCE. It says "there are three cases in which an instance cannot be found." and describes them as: 1. The component with the referenced "UID" and "RECURRENCE-ID" has been found but the "SEQUENCE" number in the calendar store does not match that of the ITIP message. 2. The component with the referenced "UID" has been found, the "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be found. 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not support recurrences. Case 3 is not germane and will be ignored for this analysis. Case 1 is dealt with in: In case (1), two things can happen. If the "SEQUENCE" number of the "Attendee's" instance is larger than that in the "Organizer's" message then the "Attendee" is receiving an out-of-sequence message and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" instance is smaller, then the "Organizer" is sending out a newer version of the component and the "Attendee's" version needs to be updated. Since one or more updates have been missed, the "Attendee" SHOULD send a "REFRESH" message to the "Organizer" to get an updated version of the event. Here SEQUENCE is described as "smaller" and "larger" rather than "highest" and "lower" found in Section 2.1.5 but the implicit behaviour still matches. In order to match a UID / RECURRENCE-ID / SEQUENCE combo where the UID and RECURRENCE-ID values are "found" but the SEQUENCE value is "smaller" or "larger" then it should be intuitive that UID and RECURRENCE-ID do not change. Otherwise they could not be found to mismatch SEQUENCE! So this description matches the behaviour under Section 2.1.5. The last ine about "one or more updates have been missed" has been misused as justification for the recipient (ie: you in the above examples) having to send a REFRESH to the Organizer (ie: me...). However 2 things need to be noted here: A: The case is described as the one where UID / RECURRENCE-ID matched but SEQUENCE did NOT and B: The text says that the recipient "SHOULD" send a REFRESH, not "MUST". Now if you apply normal logic to the analysis you should see that bullet A above cannot be done in a changing RECURRENCE-ID model since the RECURRENCE-ID value changed! However this is incongruence needs to be overlooked to use Section 4.7.2 as justifying a changing RECURRENCE-ID model. Also, bullet B does not say "MUST" because it is NOT necessary! The larger/higher SEQUENCE version obsoletes all smaller/lower SEQUENCE versions and as such a REFRESH is not really necessary (except in a changing RECURRENCE-ID model). Case 2 is dealt with in: In case (2), something has gone wrong. Both the "Organizer" and the "Attendee" should have the same instances, but the "Attendee" does not have the referenced instance. In this case the "Attendee" SHOULD send a "REFRESH" to the "Organizer" to get an updated version of the event. Aha, we now have problem with the fixed RECURRENCE-ID model or do we? Actually we do not. If you receive a REQUEST for an unknown UID / RECURRENCE-ID pair then if you apply the text from Section 3.2.2 REQUEST correctly you simply view the REQUEST as a new invitation. In this case to a new instance you did not know about before. No problem here. Simply treat it as what it is, a REQUEST to another instance and workflow functions as before. Ah, we do have a problem though if we used a changing RECURRENCE-ID model. The "something has gone wrong" is that the message was missequenced. Gee, something as simple as that means there is a problem?? Thats the sign of a poor model (and one of the reasons the WG opt'd for the fixed RECURRENCE-ID model) because to recover means lots of extraneous iTIP messages in both directions. In addition it should be noted that not all Attendees are invited to all instances so the 2nd line is a bit misleading. If I want to add you to an instance (or subset of instances) of a repeating meeting Im organzing then obviously you wont have the "the same instances". I suspect that this is an artifact of editing because we do not expect / require that all attendees be invited to all instances. Also, this example also uses "SHOULD" instead of "MUST". Had the RECURRENCE-ID model been one of a changing RECURRENCE-ID value then the it would have to say "MUST" in order to attempt to resync the invitee with the Organzier. Some folks have seized on this Case as justification for a changing RECURRENCE-ID model. However they have modified it in the process by changing the "SHOULD" into a "MUST" and ignoring all of the other sections of iTIP that contradict them. Ok by now it should be clear that iCalendar and iTIP specify and use a fixed RECURRENCE-ID model. So the next thing to consider is the Working Group history on this subject and looking at how its been implemented by folks. As previously noted in recent discussions the question of a fixed or changing RECURRENCE-ID model was raised at least as far back as July 1999. The concensus then was that RECURRENCE-ID was fixed (essentially for the reasons demonstrated above). I invite anyone who still thinks that RECURRENCE-ID should changing on a reschedule to go reread the archives and search for yourself. Finally, lets take a look at how at least the RFC authors have implemented RECURRENCE-ID in their various products. Surely they would have implemented it the way the RFC intended it, yes?! If you take a look at Microsofts Outlook 98 (and higher) and Exchange you will find that all implementations (done by different development teams) all implement a fixed RECURRENCE-ID. You need to be configured for Internet Mode to get iCalendar support (or you can use the Exchange server if you configure it for iCalendar). In any case they have a fixed RECURRENCE-ID model. If you take a look at Lotus Organizer, Lotus Notes and the eSeries offerings you will find that all of them (also done by different development teams) implement a fixed RECURRENCE-ID. I do not have current access to Evolution or to Netscapes offerings but in looking over my notes from CalConnects I see that we did not have any interoperability issues with anyone participating so they must have also implemented fixed RECURRENCE-IDs. Ok, to recap this (assuming you are still with me to here): 1: iCalendar clearly and unequivocally says that on a reschedule RECURRENCE-ID does not change; it keeps the "original" value. RECURRENCE-ID "might also change" only in the case "When the definition of the recurrence _set_ for a calendar component changes" and not "When the definition of the recurrence _instance_ for a calendar component changes" 2: iTIP prose specifying Message Sequencing and messages themselves do not disagree with iCalendar. 3: iCalendar defines the RECURRENCE-ID property; iTIP defines its semantics. As such iTIP cannot redefine RECURRENCE-ID, that is not its job/function. 4: The changing or delta RECURRENCE-ID model has been demonstrated as being fault intolerant and flawed in dealing with sequencing and recovery of lost messages. 5: The WG already discussed this long ago and confirmed that RECURRENCE-ID did not change on a reschedule. 6: ALL the implementations from all the authors use a fixed RECURRENCE-ID. So either they ALL misunderstood their own model or they properly implemented it based on iCalendar and iTIP. RECURRENCE-ID is akin to "the UID for a particular instance" and as such it needs to have the similar behavior as the UID property. Otherwise iTIP workflow gets lots more complicated and verbose and so does a CUAs design. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F442385256D78_= Content-Type: text/html; charset="us-ascii"
I have sent another "nudge" note to the author in hopes of getting his interpretation and/or understanding of what the drafts "mean."   Pretty soon I'm going to have to get into "Mom" mode and that won't be pretty.  So, let's see if I can get the text/understanding from them this week.  


Satya Vempati <satyanarayana.vempati@sun.com>
Sent by: owner-ietf-calendar@mail.imc.org

08/04/2003 15:19

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        RE: RECURRENCE-ID discussion




Unfortunately the RFCs are not consistent. You can quote one part of the
RFC which agrees with your position, and others can quote the other parts
that seem to buttress theirs.
-----------------
For example, (RFC 2446, Section 3.7.1)
If the "Organizer" wishes to
change the "DTSTART", the original "DTSTART" value is used for
"RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
reflect the change. Note that after the change has occurred, the
"RECURRENCE-ID" has changed to the new "DTSTART" value.
-------------------
Additionally, portions of the document are not very clear and open to
multiple interpretations:
"When the definition of the recurrence set for a calendar component
changes...the "RECURRENCE-ID" for a given recurrence instance might also
change"
What is meant by the "definition of a recurrece set?" One can also argue
that the recurrence set changes whenever something is added to or deleted
from it.
Because of such inconsistencies, if we clearly understand the intent of
the original authors and agree on it, the minor textual inconsistencies
could be resolved amicably.
-----Original Message-----
From: Bruce_Kahn@notesdev.ibm.com [mailto:Bruce_Kahn@notesdev.ibm.com]
Sent: Monday, August 04, 2003 8:37 AM
To: ietf-calendar@imc.org
Subject: Re: RECURRENCE-ID discussion


Satya asked on 07/31/2003 06:43:38 PM:
> Is there an update on when the iCal authors will post their thinking on
> the subject?
I had hoped that reading the RFCs and searching the archives would have
put this to rest once and for all but perhaps not for some.  So let me
take some time to review both the RFC text and to technically analyze why
the iCalendar specified a fixed RECURRENCE-ID.  This is going to be a
somewhat long posting in order to cover both iCalendar, iTIP and the
claims that purportedly define a changing RECURRENCE-ID model.
First, lets start with a review of the RFCs.  The 2 RFCs in question are
2445 (iCalendar) and 2446 (iTIP).  iCalendars role is to define the
various properties and property parameters as well as specify their
behaviour / intent.  iTIPs role is to give the iCalendar properties
semantic meaning that all implementations can follow to interop.  So lets
start with reviewing the actual definition of RECURRENCE-ID (Section
4.8.4.4 Recurrence ID).
Description: 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.

[Snip]
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 "RECURRENCE-ID" property is used in conjunction with the "UID"
and "SEQUENCE" property to identify a particular instance of a
recurring event, to-do or journal. For a given pair of "UID" and
"SEQUENCE" property values, the "RECURRENCE-ID" value for a
recurrence instance is fixed. When the definition of the recurrence
set for a calendar component changes, and hence the "SEQUENCE"
property value changes, the "RECURRENCE-ID" for a given recurrence
instance might also change. [Snip]

Some folks seem to blindly ignore the 2nd (above, 3rd in the actual RFC)
paragraph which clearly and unequivocally says that when a reschedule
takes place the RECURRENCE-ID value "is still set to the original" value!
This of course flat out defeats the claim that "RECURRENCE-ID changes on
each reschedule" as some have claimed so its easy to see why overlooking
it happens.
In looking at the oft cited last paragraph you will find that the key
phrase is "When the definition of the recurrence set for a calendar
component changes...the "RECURRENCE-ID" for a given recurrence instance
might also change".  The important bit that seems to be misread is
"definition of the recurrence set"; it does not say "definition of the
recurrence _instance_".   So its likely that this is partly to blame for
some misinterpreting the description to mean "Whenever the instance is
rescheduled, the recurrence instance also changes"  This does make a
couple minor but not insignficant changes to the phrasing such as changing
"might also change" into "always changes" but these changes are best
ignored if you want to change the model.
Of course these changes would conflict with the entire paragraph before it
so some would just ignore it in favor of their reinterpreatation of the
prose.  However it must be noted that iCalendar clearly proscribes a
"fixed" RECURRENCE-ID in at least 2 places.
In addition Doug has claimed that "'original' means currently booked
version" but thats nowhere near the meaning of the word original.  Instead
of arguing a common sense meaning Ill instead defer to Merriam-Webster who
define it as:
Main Entry: 2original
Function: adjective
Date: 14th century
1 : of, relating to, or constituting an origin or beginning : INITIAL <the
original part of the house>
2 a : not secondary, derivative, or imitative b : being the first instance
or source from which a copy, reproduction, or translation is or can be
made
So "original" means the the same as the "initial" value, NOT the "latest"
or "most recent".  This definition matches the paragraph in describing how
RECURRENCE-ID stayed at the Friday date/time.  The reason that a fixed
RECURRENCE-ID was specified over a varying one will become evident as we
move into analyzing iTIP so lets do that now.
iTIP defines its role in relation to iCalendar as:
iTIP complements the iCalendar object specification by adding
semantics for group scheduling methods commonly available in current
calendar systems.

so its role is NOT to impart (or modify) any defintion to the iCalendar
properties or property parameters, thats the function of iCalendar.  The
semantics for "group scheduling methods" are done in the various iTIP
methods or messages.  iTIP messages can be sent over any kind of media or
using assorted methods so the protocol had to first define some guidelines
to apply to all messages to properly deal with missequencing  on the
receiving end.  That is done in Section 2.1.5 Message Sequencing, before
any direct discussion of individual messages was done.  In Section  2.1.5
Message Sequencing we see:
1.  The primary key for referencing a particular iCalendar component
is the "UID" property value. To reference an instance of a
recurring component, the primary key is composed of the "UID" and
the "RECURRENCE-ID" properties.

2.  The secondary key for referencing a component is the "SEQUENCE"
property value.  For components where the "UID" is the same, the
component with the highest numeric value for the "SEQUENCE"
property obsoletes all other revisions of the component with
lower values.

Thus for repeating instances the primary key value used to find the
instance the message refers to is the UID / RECURRENCE-ID pair.  Once this
pair is used to find the instance in question the SEQUENCE property can be
used to determine if the message is newer or older than the one the
recipient has.  Or in iTIP terms, tell if the message has already been
obsoleted or if it should obsolete the recipients copy.  Nothing here
claims that RECURRENCE-ID changes on each reschedule and in order to be
fault tolerant and easily recoverable RECURRENCE-ID should not change
(iCalendar prose not withstanding).  This can be seen in the prose found
in other sections in iTIP such as Sections 3.2.2 REQUEST, 3.2.2.1
Rescheduling an Event, 3.2.2.2 Updating or Reconfirmation of an Event, or
even the often misquoted Section 4.7.2 Bad RECURRENCE-ID.
Section 3 of iTIP is where the actual protocol definitions happen.  Its
where iTIP defines what a meeting request or response look like, etc.
Section 4 of iTIP is where the authors provided assorted examples of
actual iTIP messages from Section 3.  As such its merely the demonstrative
part of the iTIP RFC and does not carry the same weight.  The authors were
always grumbling about the inclusion of examples ("If we put in an example
of X then everyone will code to that and not to the text" as they so often
lamented in meetings, emails and here on the list) and now this has come
back to haunt us based on a misreading of iCalendar and a line or two in
the examples section of iTIP (not even in the defintion section of iTIP).
In any case, lets continue the analysis promised.
iTIP Section 3.2.2 REQUEST in part reads:
The "UID" and "SEQUENCE" properties are used to distinguish the
various uses of the "REQUEST" method. If the "UID" property value in
the "REQUEST" is not found on the recipient's calendar, then the
"REQUEST" is for a new "VEVENT" calendar component. If the "UID"
property value is found on the recipient's calendar, then the
"REQUEST" is for a rescheduling, an update, or a reconfirm of the
"VEVENT" calendar component.

and if you apply the rules from Section 2.1.5 to this you should get that
if the UID/RECURRENCE-ID are not found in the recipients calendar then its
a new REQUEST, otherwise its an update.  Implicitly this concurs with
iCalendar and Section 2.1.5 because if the RECURRENCE-ID changed and one
or more iTIP REQUESTs were missed (or delayed!) then the recipient has NO
way to properly perform this match and thus they would treat the REQUEST
as a new invitation rather than a reschedule.
In case that was not clear enough for some Ill try to make it as clear as
I can: If I send you a REQUEST for a particular UID and RECURRENCE-ID that
you do not have then you are to treat it as a new invitation by the
definition of REQUEST.  So you want the UID / RECURRENCE-ID values to
never change from that point on or else you will think you got _another_
new invitation rather than a rescheduling of the one you already have!
If RECURRENCE-ID did change on each reschedule (iCalendar prohibitions
aside) then you have NO way to distinguish between a new invitation and
the case where you missed one or more reschedules.  This means that for
the model where RECURRENCE-ID changes on each reschedule, any single
delayed or missequenced REQUEST can _only_ be recovered by rescying up
_all_instances_ of the repeat set!  In addition if the messages were just
missequenced this results in _tons_ of extra wasted workflow thrashing.
Lets compare the iCalendar defined fixed RECURRENCE-ID model to the
changing RECURRENCE-ID model of some and see how they deal with
missequenced messages.  The scenario is I invite you to an instance of a
repeating meeting.  After the initial invitation I reschedule it two times
to accomodate other invitees.  So for simplicity in references Ill refer
to the initial invitation as SEQUENCE:0 and the two reschedules as
SEQUENCE:1 and SEQUENCE:2 respectively.  Because of network/server issues
you recieve them in the order of SEQUENCE:0 then SEQUENCE:2 and then
SEQUENCE:1; a not uncommon case when using email (aka iMIP).
First the fixed RECURRENCE-ID model analysis:
When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and
3.2.2 and determine that this is a new meeting invitation which you take
some action on to get it onto your calendar.
You then receive SEQUENCE:2 and you can match the UID / RECURRENCE-ID
values and determine that the message is newer and that it obsoletes your
current copy.  You may notice that its SEQUENCE value is more than 1
different but since the higher valued SEQUENCE "obsoletes all other
revisions of the component withlower values" it is not an issue that you
did not see SEQUENCE:1 (yet).  You can simply take action on it and send
back a REPLY with the correct UID / RECURRENCE-ID / SEQUENCE:3 info on it
and we are in sync.
You later receive the SEQUENCE:1 REQUEST.  You apply Section 2.1.5 and
determine that your version is newer and as such this REQUEST is obsoleted
and should be ignored.  No further action is required by you since you are
already in sync with me.
Now for the changing RECURRENCE-ID model analysis:
When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and
3.2.2 and determine that this is a new meeting invitation which you take
some action on to get it onto your calendar.
You then receive SEQUENCE:2 and you can NOT match the UID / RECURRENCE-ID
values in your calendar so you determine that "something has gone wrong"
(to borrow from the misquoted Section 4.7.2).  You MUST therefore take NO
action on the REQUEST since you cannot match the instance to one you
currently have.  You can ONLY send a REFRESH message back to me with just
the UID and NO RECURRENCE-ID.  This will cause me to generate another
REQUEST to you "with the latest description and version of the event" (per
iTIP Section 3.2.6 REFRESH).  So I send you another REQUEST with the
latest RECURRENCE-ID at SEQUENCE:2 which happens to _exactly_ match the
REQUEST you just tossed out.  If you receive this new REQUEST _before_ you
get the missequenced SEQUENCE:1 REQUEST then you can _only_ repeat this
loop indefinitely without recovery!
In the interim the SEQUENCE:1 REQUEST arrives and you are able to apply
Section 2.1.5 rules and find the correct UID / RECURRENCE-ID instance and
determine that the REQUEST obsoletes the SEQUENCE:0 one you have.  Now you
can apply the currently obsolete SEQUENCE:1 change to your SEQUENCE:0
instance and send back a REPLY to me.  I would of course detect that the
UID / RECURRENCE-ID / SEQUENCE:1 REPLY is for an old copy (by applying
2.1.5) and thus I would have to ignore it and send you yet another REQUEST
at SEQUENCE:2.  Now that you are at SEQUENCE:1 you can safely match the
UID / RECURRENCE-ID values and re-respond at SEQUENCE:3.
This model has lots of drawbacks (hence why we long ago opt'd for a
"fixed" RECURRENCE-ID model).  They include:
1: Any missequencing of iTIP messages cannot be recovered on a single
instance case.  You MUST resync up ALL instances in the set, not just the
instance in question.  This means potentially LOTS of extra wasted
workflow messaging.  All just because of _1_ missquenced REQUEST (or REPLY
if you invert the picture for my side as Organizer).
2: If the problem is NOT a missequencing of REQUESTs but rather recovery
from a lost REQUEST (ie: an interim copy got lost in a server crash, disk
failure, admin purge, etc) then it is not possible to recover when just
one or some instances are involved since RECURRENCE-IDs are always
involved in the REQUEST/REPLY(/COUNTER/...) messages when you correctly
apply the restriction tables from iTIP.  REQUEST clearly says:
RECURRENCE-ID   0 or 1  only if referring to an instance of a
recurring calendar component.  Otherwise it
MUST NOT be present.

so any initial or subsequent REQUESTs MUST have a RECURRENCE-ID on them
when referring to a particular instance.  Had you not received the
SEQUENCE:1 REQUEST at some point you would be infinitely stuck in the
REFRESH/REQUEST loop above.
3: Since each instance can be reschedule independently of its siblings, it
can be shown that if the RECURRENCE-ID changes it takes just 5 steps to
misidentify the correct instance in question in a REPLY (on the Organizers
side).  For the steps, go check the archives for the 2 times its been
pointed out.
The same kind of fault _intolerant_ behaviour can be seen for other cases
in iTIP if you lay out the scenarios (and ignore iCalendar too).
Now lets visit that misquoted iTIP Examples Section 4.7.2 Bad
RECURRENCE-ID lest some claim we are ignoring their citations for
justifying a changing RECURRENCE-ID model.  iTIP Section 4.7.2 Bad
RECURRENCE-ID is intended as an example section on how to deal with
problems matching UID / RECURRENCE-ID / SEQUENCE.  It says "there are
three cases in which an instance cannot be found." and describes them as:
1.  The component with the referenced "UID" and "RECURRENCE-ID" has
been found but the "SEQUENCE" number in the calendar store does
not match that of the ITIP message.

2.  The component with the referenced "UID" has been found, the
"SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
found.

3.  The "UID" and "SEQUENCE" numbers are found but the CUA does not
support recurrences.

Case 3 is not germane and will be ignored for this analysis.
Case 1 is dealt with in:
In case (1), two things can happen. If the "SEQUENCE" number of the
"Attendee's" instance is larger than that in the "Organizer's"
message then the "Attendee" is receiving an out-of-sequence message
and MUST ignore it.  If the "SEQUENCE" number of the "Attendee's"
instance is smaller, then the "Organizer" is sending out a newer
version of the component and the "Attendee's" version needs to be
updated. Since one or more updates have been missed, the "Attendee"
SHOULD send a "REFRESH" message to the "Organizer" to get an updated
version of the event.

Here SEQUENCE is described as "smaller" and "larger" rather than "highest"
and "lower" found in Section 2.1.5 but the implicit behaviour still
matches.  In order to match a UID / RECURRENCE-ID / SEQUENCE combo where
the UID and RECURRENCE-ID  values are "found" but the SEQUENCE value is
"smaller" or "larger" then it should be intuitive that UID and
RECURRENCE-ID do not change.  Otherwise they could not be found to
mismatch SEQUENCE!  So this description matches the behaviour under
Section 2.1.5.
The last ine about "one or more updates have been missed" has been misused
as justification for the recipient (ie: you in the above examples) having
to send a REFRESH to the Organizer (ie: me...).  However 2 things need to
be noted here:
A: The case is described as the one where UID / RECURRENCE-ID matched but
SEQUENCE did NOT and
B: The text says that the recipient "SHOULD" send a REFRESH, not "MUST".
Now if you apply normal logic to the analysis you should see that bullet A
above cannot be done in a changing RECURRENCE-ID model since the
RECURRENCE-ID value changed!   However this is incongruence needs to be
overlooked to use Section 4.7.2 as justifying a changing RECURRENCE-ID
model.
Also, bullet B does not say "MUST" because it is NOT necessary! The
larger/higher SEQUENCE version obsoletes all smaller/lower SEQUENCE
versions and as such a REFRESH is not really necessary (except in a
changing RECURRENCE-ID model).
Case 2 is dealt with in:
In case (2), something has gone wrong.  Both the "Organizer" and the
"Attendee" should have the same instances, but the "Attendee" does
not have the referenced instance.  In this case the "Attendee" SHOULD
send a "REFRESH" to the "Organizer" to get an updated version of the
event.

Aha, we now have problem with the fixed RECURRENCE-ID model or do we?
Actually we do not.  If you receive a REQUEST for an unknown UID /
RECURRENCE-ID pair then if you apply the text from Section 3.2.2 REQUEST
correctly you simply view the REQUEST as a new invitation.  In this case
to a new instance you did not know about before.  No problem here.  Simply
treat it as what it is, a REQUEST to another instance and workflow
functions as before.
Ah, we do have a problem though if we used a changing RECURRENCE-ID model.
The "something has gone wrong" is that the message was missequenced.
Gee, something as simple as that means there is a problem??  Thats the
sign of a poor model (and one of the reasons the WG opt'd for the fixed
RECURRENCE-ID model) because to recover means lots of extraneous iTIP
messages in both directions.
In addition it should be noted that not all Attendees are invited to all
instances so the 2nd line is a bit misleading.  If I want to add you to an
instance (or subset of instances) of a repeating meeting Im organzing then
obviously you wont have the "the same instances".  I suspect that this is
an artifact of editing because we do not expect / require that all
attendees be invited to all instances.
Also, this example also uses "SHOULD" instead of "MUST".  Had the
RECURRENCE-ID model been one of a changing RECURRENCE-ID value then the it
would have to say "MUST" in order to attempt to resync the invitee with
the Organzier.  Some folks have seized on this Case as justification for a
changing RECURRENCE-ID model.  However they have modified it in the
process by changing the "SHOULD" into a "MUST" and ignoring all of the
other sections of iTIP that contradict them.
Ok by now it should be clear that iCalendar and iTIP specify and use a
fixed RECURRENCE-ID model.  So the next thing to consider is the Working
Group history on this subject and looking at how its been implemented by
folks.
As previously noted in recent discussions the question of a fixed or
changing RECURRENCE-ID model was raised at least as far back as July 1999.
The concensus then was that RECURRENCE-ID was fixed (essentially for the
reasons demonstrated above).  I invite anyone who still thinks that
RECURRENCE-ID should changing on a reschedule to go reread the archives
and search for yourself.
Finally, lets take a look at how at least the RFC authors have implemented
RECURRENCE-ID in their various products.  Surely they would have
implemented it the way the RFC intended it, yes?!
If you take a look at Microsofts Outlook 98 (and higher) and Exchange you
will find that all implementations (done by different development teams)
all implement a fixed RECURRENCE-ID.  You need to be configured for
Internet Mode to get iCalendar support (or you can use the Exchange server
if you configure it for iCalendar).  In any case they have a fixed
RECURRENCE-ID model.
If you take a look at Lotus Organizer, Lotus Notes and the eSeries
offerings you will find that all of them (also done by different
development teams) implement a fixed RECURRENCE-ID.
I do not have current access to Evolution or to Netscapes offerings but in
looking over my notes from CalConnects I see that we did not have any
interoperability issues with anyone participating so they must have also
implemented fixed RECURRENCE-IDs.
Ok, to recap this (assuming you are still with me to here):
1: iCalendar clearly and unequivocally says that on a reschedule
RECURRENCE-ID does not change; it keeps the "original" value.
RECURRENCE-ID "might also change" only in the case "When the definition of
the recurrence _set_ for a calendar component changes" and not "When the
definition of the recurrence _instance_ for a calendar component changes"
2: iTIP prose specifying Message Sequencing and messages themselves do not
disagree with iCalendar.
3: iCalendar defines the RECURRENCE-ID property; iTIP defines its
semantics.  As such iTIP cannot redefine RECURRENCE-ID, that is not its
job/function.
4: The changing or delta RECURRENCE-ID model has been demonstrated as
being fault intolerant and flawed in dealing with sequencing and recovery
of lost messages.
5: The WG already discussed this long ago and confirmed that RECURRENCE-ID
did not change on a reschedule.
6: ALL the implementations from all the authors use a fixed RECURRENCE-ID.
So either they ALL misunderstood their own model or they properly
implemented it based on iCalendar and iTIP.
RECURRENCE-ID is akin to "the UID for a particular instance" and as such
it needs to have the similar behavior as the UID property.  Otherwise iTIP
workflow gets lots more complicated and verbose and so does a CUAs design.

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


--=_alternative 006F442385256D78_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 4 17:11:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12252 for ; Mon, 4 Aug 2003 17:11:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74L2Lqt037677 for ; Mon, 4 Aug 2003 14:02:21 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74L2LF3037676 for ietf-calendar-bks; Mon, 4 Aug 2003 14:02:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74L2Jqt037670 for ; Mon, 4 Aug 2003 14:02:20 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h74L2JEB009767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 4 Aug 2003 14:02:20 -0700 Message-ID: <3F2EC9D5.9060801@Royer.com> Date: Mon, 04 Aug 2003 15:02:13 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Bug/issue tracking Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010906020605000805010502" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010906020605000805010502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I will be tracking all CAP issues/bugs with 'BUGZILLA' the free bug tracking tool. --> I'll also periodically update the CALSCH.ORG website with the summary. For those interested the bug data base is open to anyone - free. http://INET-Consulting.com/bugzilla Your can create your own account by clicking on: Open a new Bugzilla account The 'Product' is 'IETF drafts and RFCs'. Once logged into bugzilla, you can query for existing bugs and create new ones. To search select 'IETF drafts and RFCs' then click the 'Search' button 3/4 of the way to the bottom. Its more an an engineering tool, but it will allow me to track and sort issues. For example, bug '23' is Greg Barns email, and the text can be added and updated as the fixes are added and updated. The other 'products' are restricted and will only give you a limited view (although it looks to be fully open). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010906020605000805010502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNDIxMDIxM1owIwYJKoZIhvcNAQkEMRYEFOB4oi09 QSz0u//QcFOVlaHuAKF8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJ8hKZmqrIwheykmvTck4dxclX8jHVq6HErtYkgldHKPygr3oohN R92NdTMf6BjTRFT9He6VNnEpJAWWD5EqmVM0oEPsNyA5Z1GpBIYz0eMabncewF4q6GeHvZe+ Wm71rlTSmurd2mOg24ZDK0TSPDFlUrntKUEei0EcIwHXMt/Ab2QpCYsDxJK5y6TMhqoEa7li jqqlbtu+E3d/E831foPIKOrAQpZrrclYP/80UFJKH4aMtHEluMmyOu8bGXPuTI8ic8Dyyrmc 2W2snDIGW/sJO9fpy+CqPPw9D1+nJ1nq/D96CCQqQKhM8IOgrTyuvMM288nIjNTR505vUEr3 dcwAAAAAAAA= --------------ms010906020605000805010502-- From owner-ietf-calendar@mail.imc.org Mon Aug 4 17:59:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12918 for ; Mon, 4 Aug 2003 17:59:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Lpiqt039507 for ; Mon, 4 Aug 2003 14:51:44 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74LpiVk039506 for ietf-calendar-bks; Mon, 4 Aug 2003 14:51:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Lphqt039500 for ; Mon, 4 Aug 2003 14:51:43 -0700 (PDT) (envelope-from gsbarnes@u.washington.edu) Received: from mead6.u.washington.edu (mead6.u.washington.edu [140.142.12.146]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h74LpaCK017057 for ; Mon, 4 Aug 2003 14:51:41 -0700 Received: from localhost (gsbarnes@localhost) by mead6.u.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h74Lpa4M025272 for ; Mon, 4 Aug 2003 14:51:36 -0700 Date: Mon, 4 Aug 2003 14:51:35 -0700 (PDT) From: "G. Barnes" To: ietf-calendar@imc.org Subject: Re: CAP-11 is out In-Reply-To: <3F2B15AE.6030103@Royer.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 1 Aug 2003, Doug Royer wrote: > G. Barnes wrote: > > I'm mystified as to the meaning of the ITIP-VERSION property. How does > > a CAP server 'support' ITIP? From what I can read, CAP servers hold > > ITIP objects, but it is CUAs that do all the ITIP work. This property > > makes it sound like CAP servers do a lot more to ITIP objects than just > > storing, searching and deleting. > > The CS processes VFREEBUSY in CS's that have RECUR-EXPAND=true. > > And what if 2446 is updated and it effects VFREEBUSY or some > new component that the CS is supposed to process? That is why it exists. Thanks for your reply, Doug. (Un)fortunately, they only lead to more questions. I'm assuming by your reply above that you're referring mostly to Section 10.8.1, Searching for VFREEBUSY, and the recent VFREEBUSY mailing list discussion that ended with this message: Re: free-busy QUERY - summary (I think) http://www.imc.org/ietf-calendar/mail-archive/msg07848.html It's unclear to me how much of the message made it into the draft, and how much was meant to. For example: In the message, you propose that if RECUR-EXPAND=true, then VFREEBUSY PUBLISH messages should be thrown away after sending a success reply. I don't know if that is in the draft, or if it was supposed to be. In the message, you also propose that if RECUR-EXPAND=true, the server should immediately reply to a CMD:CREATE/METHOD:REQUEST for VFREEBUSY with the freebusy info in a VREPLY. I don't know if that's a requirement, a suggestion, or what. Anyway, on to less weighty matters: In the discussion in Section 10.8.1, it is specified what to do if searching for STATE()='BOOKED' and STATE()='UNPROCESSED when RECUR-EXPAND is true. What if STATE is unspecified? Normally, I gather, this would search both BOOKED and UNPROCESSED objects. But it seems to me that in this case, the semantics for these two states are so different this can only be an error. [Alternatively, it could be that one must specify STATE in all queries, but I don't see that requirement anywhere, and there's probably a case I haven't thought of where it's handy to be able to do so.] Section 8.32 RECUR-EXPAND refers repeatedly to the "EXPAND" parameter. But EXPAND is a property, not a parameter. Section 5 first says CAP URLs must begin with 'cap', then says they don't (i.e., they can be relative). The ABNF also requires absolute URLs, when it should allow both. Shouldn't CAP URL be listed as a new property value data type (and be used as the type of the TARGET property instead of URI)? Given the object model in Section 3.2, it seems that there should be restrictions on the TARGET properties for certain component/command combinations. For example, VEVENTS can only appear in VAGENDAs, so you shouldn't be able to CREATE a VEVENT with the target cap://cal.example.com . But apart from 3.2, I don't see any such discussion elsewhere. For example, in the description of the TARGET property or the CREATE command, or just a general reference back to 3.2 in the description of CMD (Section 10.1). It seems to me that the diagram in 3.2 is important enough that it needs to be reinforced somewhere in Section 10.1 Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Mon Aug 4 19:22:55 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15421 for ; Mon, 4 Aug 2003 19:22:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Mv4qt042406 for ; Mon, 4 Aug 2003 15:57:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74Mv4bf042404 for ietf-calendar-bks; Mon, 4 Aug 2003 15:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Mv2qt042399 for ; Mon, 4 Aug 2003 15:57:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h74Mv1EB010984 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 4 Aug 2003 15:57:03 -0700 Message-ID: <3F2EE4B8.4070201@Royer.com> Date: Mon, 04 Aug 2003 16:56:56 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-11 is out (VFREEBUSY) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000504090909000908060009" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000504090909000908060009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit G. Barnes wrote: > On Fri, 1 Aug 2003, Doug Royer wrote: > > >>G. Barnes wrote: > > >>>I'm mystified as to the meaning of the ITIP-VERSION property. How does >>>a CAP server 'support' ITIP? From what I can read, CAP servers hold >>>ITIP objects, but it is CUAs that do all the ITIP work. This property >>>makes it sound like CAP servers do a lot more to ITIP objects than just >>>storing, searching and deleting. >> >>The CS processes VFREEBUSY in CS's that have RECUR-EXPAND=true. >> >>And what if 2446 is updated and it effects VFREEBUSY or some >>new component that the CS is supposed to process? That is why it exists. > > > Thanks for your reply, Doug. (Un)fortunately, they only lead to > more questions. > > I'm assuming by your reply above that you're referring mostly to > Section 10.8.1, Searching for VFREEBUSY, and the recent VFREEBUSY > mailing list discussion that ended with this message: > > Re: free-busy QUERY - summary (I think) > http://www.imc.org/ietf-calendar/mail-archive/msg07848.html > I was referring to your question which was: I'm mystified as to the meaning of the ITIP-VERSION property. How does a CAP server 'support' ITIP? From what I can read, CAP servers hold ITIP objects, but it is CUAs that do all the ITIP work. This property makes it sound like CAP servers do a lot more to ITIP objects than just storing, searching and deleting. > Re: free-busy QUERY - summary (I think) > http://www.imc.org/ietf-calendar/mail-archive/msg07848.html > > It's unclear to me how much of the message made it into the draft, > and how much was meant to. For example: > > In the message, you propose that if RECUR-EXPAND=true, then > VFREEBUSY PUBLISH messages should be thrown away after sending a success > reply. I don't know if that is in the draft, or if it was supposed to > be. Please read the draft before posting comments on it:-) It really could not take that long in a text viewing tool to search for text or produce diff files :-) > In the message, you also propose that if RECUR-EXPAND=true, the server > should immediately reply to a CMD:CREATE/METHOD:REQUEST for VFREEBUSY > with the freebusy info in a VREPLY. I don't know if that's a requirement, > a suggestion, or what. When you read CAP-11 (The subject of your email you posted) did you find it? > Anyway, on to less weighty matters: > > In the discussion in Section 10.8.1, it is specified what to do if > searching for STATE()='BOOKED' and STATE()='UNPROCESSED when RECUR-EXPAND > is true. What if STATE is unspecified? Normally, I gather, this would > search both BOOKED and UNPROCESSED objects. But it seems to me that in this > case, the semantics for these two states are so different this can only be > an error. [Alternatively, it could be that one must specify STATE in all > queries, but I don't see that requirement anywhere, and there's probably > a case I haven't thought of where it's handy to be able to do so.] If you do not specify STATE() you get both. The objects returned must comply to RFC-244[46], so each unique METHOD would be in a separate VCALENDAR object. As that is an RFC-2445 restriction that was fought over and was a big debate, I did not want to reopen old wounds. I'll add to "6.1.1.5 STATE()": If not specified in a query then both "BOOKED" and "UNPROCESSED" data is returned. Each unique "METHOD" property must be in a separate MIME object per the [iCAL] section 3.2 restriction. > Section 8.32 RECUR-EXPAND refers repeatedly to the "EXPAND" parameter. > But EXPAND is a property, not a parameter. Fixed - thanks. > Section 5 first says CAP URLs must begin with 'cap', then says they > don't (i.e., they can be relative). The ABNF also requires absolute > URLs, when it should allow both. I'll change: ...There is no implied structure in a Relative CALID. ... Relative CAP URLs are permitted and are resolved according to the rules defined in Section 5 of RFC 2396. To: ...There is no implied structure in a Relative CALID (relcalid) .... A 'relcalid' is permitted and is resolved according to the rules defined in Section 5 of RFC 2396. I do no see why it would be a new value type. > Shouldn't CAP URL be listed as a new property value data type (and be > used as the type of the TARGET property instead of URI)? I'll change: target = "TARGET" other-params ":" capurl CRLF To: target = "TARGET" other-params ":" ( capurl / relcalid ) CRLF > Given the object model in Section 3.2, it seems that there should be > restrictions on the TARGET properties for certain component/command > combinations. For example, VEVENTS can only appear in VAGENDAs, so > you shouldn't be able to CREATE a VEVENT with the target > cap://cal.example.com . But apart from 3.2, I don't see any such discussion > elsewhere. For example, in the description of the TARGET property or the > CREATE command, or just a general reference back to 3.2 in the description > of CMD (Section 10.1). It seems to me that the diagram in 3.2 is important > enough that it needs to be reinforced somewhere in Section 10.1 3.2 says: Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar properties. Seems clear to me. I have removed several text sections in CAP that seem redundant - at the request of this WG and to reduce the draft down to 141 pages. With the RECURRENCE-ID debate going on, it seems to me that not replicating data, text, and information will reduce the chance of misunderstandings later. I'll change (10.1.4): Formal Definition: A "CREATE" command is defined by the following notation: To: Formal Definition: A "CREATE" command is defined by the following notation and the hierarchy restrictions as defined in Section 3.2: -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000504090909000908060009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNDIyNTY1NlowIwYJKoZIhvcNAQkEMRYEFKm3cTCJ BxgpS9Bg0cpEj+VCn+JeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEI3LGu2RICWXZmavo3yq5DHGLyD5zK+9qnN0/FXy92bXI1pFq0K RzSbotT+2qzowYaJd41rx23iy/FlyNXTGm0L5nnl8QbyUb3G396t+79glT5IIghI54IbmfDR yAXiADGpiJ/lFw+bL4wN+XZtJivw0Xbn+71i/Jiz11UyJgyDBxHi5uqrdxUF0/wZk8Q9w3s8 W6OYE7d6cb1+d+y2YBA752aX9PfD4UqJgLTWn/9cu0Ek9lDS0By2910ynabQOnTb+TLbnezx EtTBgERQkDNhorAxmgVEiOs5u+y6/0DxmrD0ohAlhKR27kSgg8Ou8tUBBuOONhUu/Aj6/41e C3kAAAAAAAA= --------------ms000504090909000908060009-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 00:52:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20020 for ; Tue, 5 Aug 2003 00:52:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h754dbqt057213 for ; Mon, 4 Aug 2003 21:39:37 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h754dbjw057212 for ietf-calendar-bks; Mon, 4 Aug 2003 21:39:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h754daqt057207 for ; Mon, 4 Aug 2003 21:39:36 -0700 (PDT) (envelope-from gsbarnes@u.washington.edu) Received: from mead4.u.washington.edu (mead4.u.washington.edu [140.142.12.172]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h754dXoa026033 for ; Mon, 4 Aug 2003 21:39:39 -0700 Received: from localhost (gsbarnes@localhost) by mead4.u.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h754dWjg018868 for ; Mon, 4 Aug 2003 21:39:32 -0700 Date: Mon, 4 Aug 2003 21:39:32 -0700 (PDT) From: "G. Barnes" To: ietf-calendar@imc.org Subject: Re: CAP-11 is out (VFREEBUSY) In-Reply-To: <3F2EE4B8.4070201@Royer.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 4 Aug 2003, Doug Royer wrote: > G. Barnes wrote: > > On Fri, 1 Aug 2003, Doug Royer wrote: > >>G. Barnes wrote: > >>>I'm mystified as to the meaning of the ITIP-VERSION property. How does > >>>a CAP server 'support' ITIP? From what I can read, CAP servers hold > >>>ITIP objects, but it is CUAs that do all the ITIP work. This property > >>>makes it sound like CAP servers do a lot more to ITIP objects than just > >>>storing, searching and deleting. > >>The CS processes VFREEBUSY in CS's that have RECUR-EXPAND=true. Having read any text in the draft that appears near the word 'RECUR-EXPAND' numerous times now, I can see no such requirement in CAP. Could you please tell me what you're referring to? > > In the message, you propose that if RECUR-EXPAND=true, then > > VFREEBUSY PUBLISH messages should be thrown away after sending a success > > reply. I don't know if that is in the draft, or if it was supposed to > > be. > > Please read the draft before posting comments on it:-) > It really could not take that long in a text viewing tool > to search for text or produce diff files :-) I see now that this proposal made it into the draft, in the last sentence of the first paragraph of 10.8.1: For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "TRUE" and have the "VFREEBUSY" component in the "COMPONENTS" value in the "CAPABILITY" reply, the CS MUST dynamically create the results of a search for the "VFREEBUSY" component at search time when searching for STATE() = 'BOOKED' items. If searching for STATE() = 'UNPROCESSED' items then the [iTIP] object are returned. For these CSs it is the the CS is responsibility and not the CUAs responsibility to provide the correct "VFREEBUSY" information for a calendar. If a CUA performs a "CREATE" "VFREEBUSY" the CS MUST return success and not store the "VFREEBUSY" component. But I'm still confused. If such a CS does not store VFREEBUSY components, which "[iTIP] objects are returned" when searching for STATE()='UNPROCESSED' items? It can't be VFREEBUSY objects, as there are none to return. Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Tue Aug 5 12:41: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 MAA18252 for ; Tue, 5 Aug 2003 12:41:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75GOnqt023732 for ; Tue, 5 Aug 2003 09:24:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75GOndZ023731 for ietf-calendar-bks; Tue, 5 Aug 2003 09:24:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75GOmqt023724 for ; Tue, 5 Aug 2003 09:24:48 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: Satya Vempati Cc: ietf-calendar@imc.org Subject: RE: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Aug 2003 12:14:11 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/05/2003 12:24:37 PM, Serialize complete at 08/05/2003 12:24:37 PM Content-Type: multipart/alternative; boundary="=_alternative 0058EEEA85256D79_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058EEEA85256D79_= Content-Type: text/plain; charset="US-ASCII" Satya wrote on 08/04/2003 03:19:09 PM: > Unfortunately the RFCs are not consistent. You can quote one part of the > RFC which agrees with your position, and others can quote the other parts > that seem to buttress theirs. > ----------------- > For example, (RFC 2446, Section 3.7.1) > > If the "Organizer" wishes to > change the "DTSTART", the original "DTSTART" value is used for > "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values > reflect the change. Note that after the change has occurred, the > "RECURRENCE-ID" has changed to the new "DTSTART" value. 2 things that are being forgotten so Ill repeat 'em again: 1: This exact citation was the one Dan Hickman asked about back in July 1999 and the WG discussed. We agreed that it was in error. Given that of 250+ pages of RFCs and you find 2 sentences that contradict the rest is not an overwhelming contradiction. We had 5+ authors working on different parts of 3 RFCs so 2 lines out of 250+ is not that significant. There are no other conflicting citations that Ive seen so far and ALL the others citations support each other. 2: The lines you cite is part of iTIP. iTIP provides the semantics for the iCalendar defined properties. iTIP cannot change the iCalendar defintion of the property or its behaviour; thats NOT its function. > Additionally, portions of the document are not very clear and open to > multiple interpretations: > > "When the definition of the recurrence set for a calendar component > changes...the "RECURRENCE-ID" for a given recurrence instance might also > change" > > What is meant by the "definition of a recurrece set?" One can also argue > that the recurrence set changes whenever something is added to or deleted > from it. A: What about the paragraph you forgot to cite? The one that expressly says on a reschedule of an instance the RECURRNECE-ID stays at its original value? Is that unclear or open to multiple interpretations? B: We have _always_ been discussing the case of rescheduling instances, at least thats always been the scenario Ive used and focused on (and Ive always tried to keep others from mixing the scenarios). Changing the definition of the recurrence set by doing an adding or removing instances is exactly what that sentence was about. However rescheduling an instance is doing NEITHER! And as you seem to agree, adding or removing/deleting instances clearly says that the RECURRENCE-ID value "might also change". For example, if I add a new non-conflicting instance to the existing set then there is no need for my RECURRENCE-ID to change obviously. Do NOT fall into Dougs misinterpreation that rescheduling an instance is the same as changing the repeat instance set defintion, its not. > Because of such inconsistencies 1 already WG discussed and declared bad iTIP bit from at least 1999 is not anything new or a major inconsistancy in the RFCs. The other phrase you mention is not an inconsistancy in my reading; the only problem is how some can misread "the definition of the recurrence set" as being "the definition of the recurrence instance" but thats not the RFCs fault nor is it an inconsistancy. It sounds like you only need a short note from the authors to this effect and you'd then accept the fixed RECURRENCE-ID model. Would that be accurate? > , if we clearly understand the intent of > the original authors and agree on it, the minor textual inconsistencies > could be resolved amicably. I always try to be as polite but sometimes frustration seeps in. I have showed: 1: Multiple supporting citations in both iCalendar and iTIP that describe and support a fixed RECURRENCE-ID model 2: Why the fixed RECURRENCE-ID model works well and is quite fault tolerant. 3: That the RFCs overwhelmingly describe and implicitly use a fixed RECURRENCE-ID model. 4: Several of the major flaws inherent in a changing RECURRENCE-ID model. Yet some folks still persist in saying that 1-2 lines in iTIP justify that iCalendar/iTIP uses a delta RECURRENCE-ID model. Wouldnt you get a littel frustrated too after several weeks of this? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 0058EEEA85256D79_= Content-Type: text/html; charset="US-ASCII"
Satya wrote on 08/04/2003 03:19:09 PM:
> Unfortunately the RFCs are not consistent. You can quote one part of the
> RFC which agrees with your position, and others can quote the other parts
> that seem to buttress theirs.
> -----------------
> For example, (RFC 2446, Section 3.7.1)
>  
> If the "Organizer" wishes to
> change the "DTSTART", the original "DTSTART" value is used for
> "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
> reflect the change. Note that after the change has occurred, the
> "RECURRENCE-ID" has changed to the new "DTSTART" value.
2 things that are being forgotten so Ill repeat 'em again:

1: This exact citation was the one Dan Hickman asked about back in July 1999 and the WG discussed.  We agreed that it was in error.  Given that of 250+ pages of RFCs and you find 2 sentences that contradict the rest is not an overwhelming contradiction.  We had 5+ authors working on different parts of 3 RFCs so 2 lines out of 250+ is not that significant.  There are no other conflicting citations that Ive seen so far and ALL the others citations support each other.

2: The lines you cite is part of iTIP.  iTIP provides the semantics for the iCalendar defined properties.  iTIP cannot change the iCalendar defintion of the property or its behaviour; thats NOT its function.

> Additionally, portions of the document are not very clear and open to
> multiple interpretations:
>  
> "When the definition of the recurrence set for a calendar component
> changes...the "RECURRENCE-ID" for a given recurrence instance might also
> change"
>  
> What is meant by the "definition of a recurrece set?" One can also argue
> that the recurrence set changes whenever something is added to or deleted
> from it.
A: What about the paragraph you forgot to cite?  The one that expressly says on a reschedule of an instance the RECURRNECE-ID stays at its original value?  Is that unclear or open to multiple interpretations?

B: We have _always_ been discussing the case of rescheduling instances, at least thats always been the scenario Ive used and focused on (and Ive always tried to keep others from mixing the scenarios).  Changing the definition of the recurrence set by doing an adding or removing instances is exactly what that sentence was about.  However rescheduling an instance is doing NEITHER!  And as you seem to agree, adding or removing/deleting  instances clearly says that the RECURRENCE-ID value "might also change".  For example, if I add a new non-conflicting instance to the existing set then there is no need for my RECURRENCE-ID to change obviously.  

Do NOT fall into Dougs misinterpreation that rescheduling an instance is the same as changing the repeat instance set defintion, its not.

> Because of such inconsistencies

1 already WG discussed and declared bad iTIP bit from at least 1999 is not anything new or a major inconsistancy in the RFCs.  The other phrase you mention is not an inconsistancy in my reading; the only problem is how some can misread "the definition of the recurrence set" as being "the definition of the recurrence instance" but thats not the RFCs fault nor is it an inconsistancy.  

It sounds like you only need a short note from the authors to this effect and you'd then accept the fixed RECURRENCE-ID model.  Would that be accurate?

>                                  , if we clearly understand the intent of
> the original authors and agree on it, the minor textual inconsistencies
> could be resolved amicably.
I always try to be as polite but sometimes frustration seeps in.  I have showed:

1: Multiple supporting citations in both iCalendar and iTIP that describe and support a fixed RECURRENCE-ID model
2: Why the fixed RECURRENCE-ID model works well and is quite fault tolerant.  
3: That the RFCs overwhelmingly describe and implicitly use a fixed RECURRENCE-ID model.  
4: Several of the major flaws inherent in a changing RECURRENCE-ID model.  

Yet some folks still persist in saying that 1-2 lines in iTIP justify that iCalendar/iTIP uses a delta RECURRENCE-ID model.  Wouldnt you get a littel frustrated too after several weeks of this?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 0058EEEA85256D79_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 13:33: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 NAA19865 for ; Tue, 5 Aug 2003 13:33:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75HGvqt025159 for ; Tue, 5 Aug 2003 10:16:57 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75HGvLr025158 for ietf-calendar-bks; Tue, 5 Aug 2003 10:16:57 -0700 (PDT) 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.9/8.12.8) with ESMTP id h75HGuqt025151 for ; Tue, 5 Aug 2003 10:16:56 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h75HGqgn017865; Tue, 5 Aug 2003 10:16:52 -0700 (PDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h75HGqaJ025010; Tue, 5 Aug 2003 10:16:52 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJ500186PC40M@ha13sca-mail1.sfbay.sun.com>; Tue, 05 Aug 2003 10:16:52 -0700 (PDT) Date: Tue, 05 Aug 2003 10:16:54 -0700 From: Satya Vempati Subject: RE: RECURRENCE-ID discussion To: "Bruce_Kahn@notesdev.ibm.com" Cc: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT <> That is correct. Then we can work out the details for ourselves. -----Original Message----- From: Bruce_Kahn@notesdev.ibm.com [mailto:Bruce_Kahn@notesdev.ibm.com] Sent: Tuesday, August 05, 2003 9:14 AM To: Satya Vempati Cc: ietf-calendar@imc.org Subject: RE: RECURRENCE-ID discussion Satya wrote on 08/04/2003 03:19:09 PM: > Unfortunately the RFCs are not consistent. You can quote one part of the > RFC which agrees with your position, and others can quote the other parts > that seem to buttress theirs. > ----------------- > For example, (RFC 2446, Section 3.7.1) > > If the "Organizer" wishes to > change the "DTSTART", the original "DTSTART" value is used for > "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values > reflect the change. Note that after the change has occurred, the > "RECURRENCE-ID" has changed to the new "DTSTART" value. 2 things that are being forgotten so Ill repeat 'em again: 1: This exact citation was the one Dan Hickman asked about back in July 1999 and the WG discussed. We agreed that it was in error. Given that of 250+ pages of RFCs and you find 2 sentences that contradict the rest is not an overwhelming contradiction. We had 5+ authors working on different parts of 3 RFCs so 2 lines out of 250+ is not that significant. There are no other conflicting citations that Ive seen so far and ALL the others citations support each other. 2: The lines you cite is part of iTIP. iTIP provides the semantics for the iCalendar defined properties. iTIP cannot change the iCalendar defintion of the property or its behaviour; thats NOT its function. > Additionally, portions of the document are not very clear and open to > multiple interpretations: > > "When the definition of the recurrence set for a calendar component > changes...the "RECURRENCE-ID" for a given recurrence instance might also > change" > > What is meant by the "definition of a recurrece set?" One can also argue > that the recurrence set changes whenever something is added to or deleted > from it. A: What about the paragraph you forgot to cite? The one that expressly says on a reschedule of an instance the RECURRNECE-ID stays at its original value? Is that unclear or open to multiple interpretations? B: We have _always_ been discussing the case of rescheduling instances, at least thats always been the scenario Ive used and focused on (and Ive always tried to keep others from mixing the scenarios). Changing the definition of the recurrence set by doing an adding or removing instances is exactly what that sentence was about. However rescheduling an instance is doing NEITHER! And as you seem to agree, adding or removing/deleting instances clearly says that the RECURRENCE-ID value "might also change". For example, if I add a new non-conflicting instance to the existing set then there is no need for my RECURRENCE-ID to change obviously. Do NOT fall into Dougs misinterpreation that rescheduling an instance is the same as changing the repeat instance set defintion, its not. > Because of such inconsistencies 1 already WG discussed and declared bad iTIP bit from at least 1999 is not anything new or a major inconsistancy in the RFCs. The other phrase you mention is not an inconsistancy in my reading; the only problem is how some can misread "the definition of the recurrence set" as being "the definition of the recurrence instance" but thats not the RFCs fault nor is it an inconsistancy. It sounds like you only need a short note from the authors to this effect and you'd then accept the fixed RECURRENCE-ID model. Would that be accurate? > , if we clearly understand the intent of > the original authors and agree on it, the minor textual inconsistencies > could be resolved amicably. I always try to be as polite but sometimes frustration seeps in. I have showed: 1: Multiple supporting citations in both iCalendar and iTIP that describe and support a fixed RECURRENCE-ID model 2: Why the fixed RECURRENCE-ID model works well and is quite fault tolerant. 3: That the RFCs overwhelmingly describe and implicitly use a fixed RECURRENCE-ID model. 4: Several of the major flaws inherent in a changing RECURRENCE-ID model. Yet some folks still persist in saying that 1-2 lines in iTIP justify that iCalendar/iTIP uses a delta RECURRENCE-ID model. Wouldnt you get a littel frustrated too after several weeks of this? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. From owner-ietf-calendar@mail.imc.org Tue Aug 5 13:33: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 NAA19891 for ; Tue, 5 Aug 2003 13:33:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75HIrqt025213 for ; Tue, 5 Aug 2003 10:18:53 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75HIrBU025212 for ietf-calendar-bks; Tue, 5 Aug 2003 10:18:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75HIpqt025206 for ; Tue, 5 Aug 2003 10:18:51 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h75HInEB018985 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Aug 2003 10:18:52 -0700 Message-ID: <3F2FE6F3.20405@Royer.com> Date: Tue, 05 Aug 2003 11:18:43 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-11 is out (VFREEBUSY) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060303040900040509040603" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060303040900040509040603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit G. Barnes wrote: > > For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "TRUE" and > have the "VFREEBUSY" component in the "COMPONENTS" value in the > "CAPABILITY" reply, the CS MUST dynamically create the results of a search > for the "VFREEBUSY" component at search time when searching for STATE() = > 'BOOKED' items. If searching for STATE() = 'UNPROCESSED' items then the > [iTIP] object are returned. For these CSs it is the the CS is > responsibility and not the CUAs responsibility to provide the correct > "VFREEBUSY" information for a calendar. If a CUA performs a "CREATE" > "VFREEBUSY" the CS MUST return success and not store the "VFREEBUSY" > component. > > But I'm still confused. If such a CS does not store VFREEBUSY components, > which "[iTIP] objects are returned" when searching for STATE()='UNPROCESSED' > items? It can't be VFREEBUSY objects, as there are none to return. For CS's that have EXPAND=TRUE and this WG wants the VFREEBUSY 'BOOKED' results to be dynamic. Correct? When *ever* would the VFREEBUSY 'UNPROCESSED' *EVER* be used? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060303040900040509040603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MDUxNzE4NDRaMCMGCSqGSIb3DQEJBDEWBBTa gkWRnmJt/GVObx12BbDdEe6OxDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQAsepuNagNmgSc5gVrwfewnQ59QOeAiPDs+5TPi3rmubZHR 6RlrHHTylqUqA3U6qrWB8TA+Kdea/HKN9++ozyVIcfVDqBf/9LTTjjzr5xp6/H7YzzshH4ey jT/VRydImhg5ALgfieWUy2MM2Zb5zQ79NhZp/eBgq89/Q7Pwtk1QZOR1AprgFQt2m+kRFfQ1 1pSZ1lcPjnavM4n5tTboG1v934udx5BKZXa8ONQAxuRRKVlP3OZ4iznYWQEULb1/mkjdKAWm t8RFxTf9XSGi5NacokO/49TH/s1IloPSNQ/zWyMwDxDOOnzENwD5Yh2a07Q/pKnGOPtV8b4B 5egjIs+VAAAAAAAA --------------ms060303040900040509040603-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 13:43: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 NAA20130 for ; Tue, 5 Aug 2003 13:43:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75HQHqt025447 for ; Tue, 5 Aug 2003 10:26:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75HQHeR025446 for ietf-calendar-bks; Tue, 5 Aug 2003 10:26:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75HQFqt025435 for ; Tue, 5 Aug 2003 10:26:15 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h75HQC94009767 for ; Tue, 5 Aug 2003 10:26:12 -0700 (PDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h75HQCaJ029659 for ; Tue, 5 Aug 2003 10:26:12 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJ5001W8PRO0M@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Tue, 05 Aug 2003 10:26:12 -0700 (PDT) Date: Tue, 05 Aug 2003 10:26:13 -0700 From: Satya Vempati Subject: RE: RECURRENCE-ID discussion To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT <> That is correct. Then we can work out the details for ourselves. -----Original Message----- From: Bruce_Kahn@notesdev.ibm.com [mailto:Bruce_Kahn@notesdev.ibm.com] Sent: Tuesday, August 05, 2003 9:14 AM To: Satya Vempati Cc: ietf-calendar@imc.org Subject: RE: RECURRENCE-ID discussion Satya wrote on 08/04/2003 03:19:09 PM: > Unfortunately the RFCs are not consistent. You can quote one part of the > RFC which agrees with your position, and others can quote the other parts > that seem to buttress theirs. > ----------------- > For example, (RFC 2446, Section 3.7.1) > > If the "Organizer" wishes to > change the "DTSTART", the original "DTSTART" value is used for > "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values > reflect the change. Note that after the change has occurred, the > "RECURRENCE-ID" has changed to the new "DTSTART" value. 2 things that are being forgotten so Ill repeat 'em again: 1: This exact citation was the one Dan Hickman asked about back in July 1999 and the WG discussed. We agreed that it was in error. Given that of 250+ pages of RFCs and you find 2 sentences that contradict the rest is not an overwhelming contradiction. We had 5+ authors working on different parts of 3 RFCs so 2 lines out of 250+ is not that significant. There are no other conflicting citations that Ive seen so far and ALL the others citations support each other. 2: The lines you cite is part of iTIP. iTIP provides the semantics for the iCalendar defined properties. iTIP cannot change the iCalendar defintion of the property or its behaviour; thats NOT its function. > Additionally, portions of the document are not very clear and open to > multiple interpretations: > > "When the definition of the recurrence set for a calendar component > changes...the "RECURRENCE-ID" for a given recurrence instance might also > change" > > What is meant by the "definition of a recurrece set?" One can also argue > that the recurrence set changes whenever something is added to or deleted > from it. A: What about the paragraph you forgot to cite? The one that expressly says on a reschedule of an instance the RECURRNECE-ID stays at its original value? Is that unclear or open to multiple interpretations? B: We have _always_ been discussing the case of rescheduling instances, at least thats always been the scenario Ive used and focused on (and Ive always tried to keep others from mixing the scenarios). Changing the definition of the recurrence set by doing an adding or removing instances is exactly what that sentence was about. However rescheduling an instance is doing NEITHER! And as you seem to agree, adding or removing/deleting instances clearly says that the RECURRENCE-ID value "might also change". For example, if I add a new non-conflicting instance to the existing set then there is no need for my RECURRENCE-ID to change obviously. Do NOT fall into Dougs misinterpreation that rescheduling an instance is the same as changing the repeat instance set defintion, its not. > Because of such inconsistencies 1 already WG discussed and declared bad iTIP bit from at least 1999 is not anything new or a major inconsistancy in the RFCs. The other phrase you mention is not an inconsistancy in my reading; the only problem is how some can misread "the definition of the recurrence set" as being "the definition of the recurrence instance" but thats not the RFCs fault nor is it an inconsistancy. It sounds like you only need a short note from the authors to this effect and you'd then accept the fixed RECURRENCE-ID model. Would that be accurate? > , if we clearly understand the intent of > the original authors and agree on it, the minor textual inconsistencies > could be resolved amicably. I always try to be as polite but sometimes frustration seeps in. I have showed: 1: Multiple supporting citations in both iCalendar and iTIP that describe and support a fixed RECURRENCE-ID model 2: Why the fixed RECURRENCE-ID model works well and is quite fault tolerant. 3: That the RFCs overwhelmingly describe and implicitly use a fixed RECURRENCE-ID model. 4: Several of the major flaws inherent in a changing RECURRENCE-ID model. Yet some folks still persist in saying that 1-2 lines in iTIP justify that iCalendar/iTIP uses a delta RECURRENCE-ID model. Wouldnt you get a littel frustrated too after several weeks of this? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. From owner-ietf-calendar@mail.imc.org Tue Aug 5 13:57: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 NAA20565 for ; Tue, 5 Aug 2003 13:56:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75Herqt025874 for ; Tue, 5 Aug 2003 10:40:53 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75HerhF025873 for ietf-calendar-bks; Tue, 5 Aug 2003 10:40:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75Hepqt025866 for ; Tue, 5 Aug 2003 10:40:51 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h75HemEB019151 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Aug 2003 10:40:51 -0700 Message-ID: <3F2FEC1B.1040506@Royer.com> Date: Tue, 05 Aug 2003 11:40:43 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010702090004050708080607" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010702090004050708080607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Satya wrote on 08/04/2003 03:19:09 PM: > > Unfortunately the RFCs are not consistent. You can quote one part of the > > RFC which agrees with your position, and others can quote the other parts > > that seem to buttress theirs. > > ----------------- > > For example, (RFC 2446, Section 3.7.1) > > > > If the "Organizer" wishes to > > change the "DTSTART", the original "DTSTART" value is used for > > "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values > > reflect the change. Note that after the change has occurred, the > > "RECURRENCE-ID" has changed to the new "DTSTART" value. > > 2 things that are being forgotten so Ill repeat 'em again: > > 1: This exact citation was the one Dan Hickman asked about back in July > 1999 and the WG discussed. We agreed that it was in error. No, some think it is in error, including you. That does not make 2445 incorrect. It makes it a point to debate. > Given that > of 250+ pages of RFCs and you find 2 sentences that contradict the rest > is not an overwhelming contradiction. We had 5+ authors working on > different parts of 3 RFCs so 2 lines out of 250+ is not that > significant. There are no other conflicting citations that Ive seen so > far and ALL the others citations support each other. Except the ones you delete from posts and never reply to? Below in your post you declare that there is contention, here you claim that you have not seen any? Please explain. > 2: The lines you cite is part of iTIP. iTIP provides the semantics for > the iCalendar defined properties. iTIP cannot change the iCalendar > defintion of the property or its behaviour; thats NOT its function. Yes it can, that is part of the IETF process. That is *this* debate and we *are* discussing iCAL changes not only on this topic but in non controversial ways discussing iCAL-rev-next. Some including me say that they are all consistent as original means the original one you are changing from, not sequence:0. > > Additionally, portions of the document are not very clear and open to > > multiple interpretations: > > > > "When the definition of the recurrence set for a calendar component > > changes...the "RECURRENCE-ID" for a given recurrence instance might also > > change" > > > > What is meant by the "definition of a recurrece set?" One can also argue > > that the recurrence set changes whenever something is added to or deleted > > from it. > > A: What about the paragraph you forgot to cite? The one that expressly > says on a reschedule of an instance the RECURRNECE-ID stays at its > original value? Is that unclear or open to multiple interpretations? No, and you have never addressed those, you just declare that one paragraph overrides all others rather than admit that it means the original one being changed from and not the original sequence:0 instance. > B: We have _always_ been discussing the case of rescheduling instances, > at least thats always been the scenario Ive used and focused on (and Ive > always tried to keep others from mixing the scenarios). Changing the > definition of the recurrence set by doing an adding or removing > instances is exactly what that sentence was about. However rescheduling > an instance is doing NEITHER! And as you seem to agree, adding or > removing/deleting instances clearly says that the RECURRENCE-ID value > "might also change". For example, if I add a new non-conflicting > instance to the existing set then there is no need for my RECURRENCE-ID > to change obviously. > > Do NOT fall into Dougs misinterpreation that rescheduling an instance is > the same as changing the repeat instance set defintion, its not. You have never replied to those citations or questions. You just keep asserting that you know that one paragraph overrides all others and that your repeated assertion that 'original == sequence:0'. Even when no such text exists. It means the original 'set' before the change and not sequence:0. Then all text is consistent. > > Because of such inconsistencies > > 1 already WG discussed and declared bad iTIP bit from at least 1999 is > not anything new or a major inconsistancy in the RFCs. The other phrase > you mention is not an inconsistancy in my reading; the only problem is > how some can misread "the definition of the recurrence set" as being > "the definition of the recurrence instance" but thats not the RFCs fault > nor is it an inconsistancy. > > It sounds like you only need a short note from the authors to this > effect and you'd then accept the fixed RECURRENCE-ID model. Would that > be accurate? It's not the EDITORS opinion that counts, its the WG's. As much hard work as they put into the RFCs, it is a WG document. > > , if we clearly understand the intent of > > the original authors and agree on it, the minor textual inconsistencies > > could be resolved amicably. > > I always try to be as polite but sometimes frustration seeps in. I have > showed: > > 1: Multiple supporting citations in both iCalendar and iTIP that > describe and support a fixed RECURRENCE-ID model There are multiple citations that disagree with you. Could you please explain rather than ignore those? > 2: Why the fixed RECURRENCE-ID model works well and is quite fault > tolerant. Would you please reply to my posting about how your model is broken? > 3: That the RFCs overwhelmingly describe and implicitly use a fixed > RECURRENCE-ID model. Yet the citations you refuse to debate disagree with you. Including iTIP which you admit above disagrees with you. > 4: Several of the major flaws inherent in a changing RECURRENCE-ID model. All of which have been addressed and you have ignored all such posts. > Yet some folks still persist in saying that 1-2 lines in iTIP justify > that iCalendar/iTIP uses a delta RECURRENCE-ID model. Wouldnt you get a > littel frustrated too after several weeks of this? Yet you refuse to acknowledge that even in your email here that I am responding to - iTIP disagrees with you. Yet you refuse to acknowledge the other text here that has been cited that disagrees with you. Is it possible that you are misreading that one paragraph? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010702090004050708080607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNTE3NDA0M1owIwYJKoZIhvcNAQkEMRYEFC7SxJPd JGxuPZqVvcgFwr6WNbC6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBABeWa33c2PbbzNCuuUST4Z3ieaTuJWMOmgIac7aumf9FTa6xljdG 89SDZNEGXuwzi/e0KjY/cPQ9GZiczIIYKju4Df6CBKualHfEwLdJ+OgXjj74/69Dg3l40KCl afNSm0OP6RA0gpAaHnBx7JCfKVBgY5qDZ5u3q/g+QGj8EW3S2IQpdqim4Sx2oHjMO/cBOj6A Yyi/4P16CW+ahRhrD1Vy8iDcULj8J68nlC/hBHur9za1Gm8KnM70W0AiOyn7k/c0bZMHSkiX mvf/T46o6fVFWCiFtrtA76Ai/PvJqSGfIihd/G9z386UmkzQeEOK7kaGAaflMwQmHrzetWvE wgcAAAAAAAA= --------------ms010702090004050708080607-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 14:20: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 OAA20993 for ; Tue, 5 Aug 2003 14:20:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75I7iqt026752 for ; Tue, 5 Aug 2003 11:07:44 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75I7i4E026751 for ietf-calendar-bks; Tue, 5 Aug 2003 11:07:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75I7hqt026742 for ; Tue, 5 Aug 2003 11:07:43 -0700 (PDT) (envelope-from mark@WebServiceSolutions.com) Received: from lin.home2.mark (CPE0080c6e8c57c-CM014500005442.cpe.net.cable.rogers.com [24.157.60.247]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 438C84FED for ; Tue, 5 Aug 2003 14:07:38 -0400 (EDT) Content-Type: text/plain; charset="us-ascii" From: Mark Swanson Organization: Web Service Solutions, Inc. To: "ietf-calendar@imc.org" Subject: No active 2445 author is a big problem Date: Tue, 5 Aug 2003 14:08:12 -0400 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200308051408.12862.mark@WebServiceSolutions.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h75I7hqt026747 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, Perhaps I don't understand the process well enough, but... I'm surprised that the IETF would let a document on the standards track exist without at least one participating author (or someone with a maintainership role). It would seem that an author/maintainer could rule on 2445 inconsistencies, 2445 would be fixed, and people could move on. Over the years some major problems have been identified with 2445 yet no new document with the proposed fixes has emerged - even when unanimous acceptance (with zero dissent) occurs wrt the proposed fix. I'm hoping I am misunderstanding something because it would seem this issue will prevent 2445 from ever becoming a standard. Thanks. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web start (JNLP): http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Tue Aug 5 14:27: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 OAA21495 for ; Tue, 5 Aug 2003 14:27:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75IIQqt027050 for ; Tue, 5 Aug 2003 11:18:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75IIQ38027049 for ietf-calendar-bks; Tue, 5 Aug 2003 11:18:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.9/8.12.8) with SMTP id h75IIOqt027042 for ; Tue, 5 Aug 2003 11:18:25 -0700 (PDT) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003080514284124913 for ; Tue, 05 Aug 2003 14:28:41 -0400 Received: from centive.com ([10.10.48.105]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Aug 2003 14:15:38 -0400 Message-ID: <3F2FF44A.7020500@centive.com> Date: Tue, 05 Aug 2003 14:15:38 -0400 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: No active 2445 author is a big problem References: <200308051408.12862.mark@WebServiceSolutions.com> In-Reply-To: <200308051408.12862.mark@WebServiceSolutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2003 18:15:38.0864 (UTC) FILETIME=[92CFD700:01C35B7D] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Swanson wrote: >I'm surprised that the IETF would let a document on the standards track exist >without at least one participating author (or someone with a maintainership >role). It would seem that an author/maintainer could rule on 2445 >inconsistencies, 2445 would be fixed, and people could move on. > No. Authors have no authority. It's up to the working group to rule on inconsistencies. -- /===========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===========================================================| |A computer without Windows is like a chocolate cake without| |mustard. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 5 14:41: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 OAA22504 for ; Tue, 5 Aug 2003 14:41:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75IUgqt027754 for ; Tue, 5 Aug 2003 11:30:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75IUghH027753 for ietf-calendar-bks; Tue, 5 Aug 2003 11:30:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75IUgqt027745 for ; Tue, 5 Aug 2003 11:30:42 -0700 (PDT) (envelope-from gsbarnes@u.washington.edu) Received: from mead8.u.washington.edu (mead8.u.washington.edu [140.142.12.148]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h75IUcCK017202 for ; Tue, 5 Aug 2003 11:30:38 -0700 Received: from localhost (gsbarnes@localhost) by mead8.u.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h75IUbxP033156 for ; Tue, 5 Aug 2003 11:30:37 -0700 Date: Tue, 5 Aug 2003 11:30:37 -0700 (PDT) From: "G. Barnes" To: ietf-calendar@imc.org Subject: Re: CAP-11 is out (VFREEBUSY) In-Reply-To: <3F2FE6F3.20405@Royer.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 5 Aug 2003, Doug Royer wrote: > G. Barnes wrote: > > For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "TRUE" and > > have the "VFREEBUSY" component in the "COMPONENTS" value in the > > "CAPABILITY" reply, the CS MUST dynamically create the results of a search > > for the "VFREEBUSY" component at search time when searching for STATE() = > > 'BOOKED' items. If searching for STATE() = 'UNPROCESSED' items then the > > [iTIP] object are returned. For these CSs it is the the CS is > > responsibility and not the CUAs responsibility to provide the correct > > "VFREEBUSY" information for a calendar. If a CUA performs a "CREATE" > > "VFREEBUSY" the CS MUST return success and not store the "VFREEBUSY" > > component. > > But I'm still confused. If such a CS does not store VFREEBUSY components, > > which "[iTIP] objects are returned" when searching for STATE()='UNPROCESSED' > > items? It can't be VFREEBUSY objects, as there are none to return. > For CS's that have EXPAND=TRUE and this WG wants the VFREEBUSY 'BOOKED' > results to be dynamic. Correct? > > When *ever* would the VFREEBUSY 'UNPROCESSED' *EVER* be used? I'm just trying to understand the draft, so I'm hardly an expert. But that search doesn't make a lot of sense to me. I can't say whether it should return 'no matches', or return an error. Assuming it doesn't make sense, the paragraph is pretty misleading and should be changed: it implies that something is returned when such a search is done. I'll take a stab at fixing it: If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the "VFREEBUSY" component in the "COMPONENTS" value in a reply to the "GET-CAPABILITY" command, then it is the CS's responsibility and not the CUA's responsibility to provide the correct "VFREEBUSY" information for a calendar. Therefore, If a CUA issues a "CREATE" "VFREEBUSY", such a CS MUST return success and not store the "VFREEBUSY" component. Such a CS MUST dynamically create the results of a search for "VFREEBUSY" components at search time when searching for STATE() = 'BOOKED' items. If a CUA searches for "VFREEBUSY" components with STATE() = 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components. If a CUA searches for "VFREEBUSY" components without specifying the STATE, such a CS MUST return the same result as if STATE()='BOOKED' had been specified. -------------------------------------------------------- I'm a little unclear as to whether a 'VREPLY with no components' is the proper way to return 'no matches', and I may have violated a formatting convention or two, but otherwise that seems to cover everything. Alternatively, if the UNPROCESSED search should cause an error, the third clause could be changed to: If a CUA searches for "VFREEBUSY" components with STATE() = 'UNPROCESSED', such a CS MUST return REQUEST-STATUS with code 6.3 (bad args). I don't know if 6.3 would be the proper return status; it's the closest fit I could find from Section 10.11. I assume you will answer my first question later? Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Tue Aug 5 15:14: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 PAA24637 for ; Tue, 5 Aug 2003 15:14:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75J3dqt029031 for ; Tue, 5 Aug 2003 12:03:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75J3dni029030 for ietf-calendar-bks; Tue, 5 Aug 2003 12:03:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75J3cqt029022 for ; Tue, 5 Aug 2003 12:03:38 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F2EAAF3.4050007@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Aug 2003 14:57:22 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/05/2003 03:03:20 PM, Serialize complete at 08/05/2003 03:03:20 PM Content-Type: multipart/alternative; boundary="=_alternative 0067DF4D85256D79_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067DF4D85256D79_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 08/04/2003 02:50:27 PM: > > Some folks seem to blindly ignore the 2nd (above, 3rd in the actual RFC) > > paragraph which clearly and unequivocally says that when a reschedule > > takes place the RECURRENCE-ID value "is still set to the original" > > value! > > Of the one being changed! Not of SEQUENCE:0 - orever. The text cited clearly says that RECURRENCE-ID does not change on a reschedule contrary to what Doug has claimed. As such the RECURRENCE-ID on each subsequent would stay the same as the one it had originally at SEQUENCE:0 when it was originally created. This is a fixed model of RECURRENCE-ID, NOT one where it changes on each reschedule as Doug has claimed. Still Im not clear on what he means by "Not of SEQUENCE:0 - orever.". The RECURRENCE-ID at SEQUENCE:1 will be the same RECURRENCE-ID as it had at SEQUENCE:0 since it does not change on the reschedule and will be the the same at SEQUENCE:1000 (excluding addition/deletions to the repeat set). > Other wish to blindly ignore ALL of the text and examples that > clearly show that the paragraph you cite is for CHANGING and instance > where the RECURRENCE-ID sent is the OLD one (for the set you are > changing from). Doug, has NOT shown any that says RECURRENCE-ID changes on each reschedule! He has only cited Section 4.7.2 Bad RECURRENCE-ID in iTIP and he apparently misread whats there at that. Examples are NOT definitive sources in the RFCs and he knows that. The ABNF and prose supercede in authority any example and they always have. Plus he still ignores the fact that "iTIP complements the iCalendar object specification by adding semantics" to iCalendar data. It does NOT redefine iCalendar properties; that is the function of the iCalendar RFC ("provides for the definition of iCalendar object methods"). No matter how you try to spin it, iCalendar flat out says that the RECURRENCE-ID is "fixed" and does not change on the reschedule: 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. Also, if you check out iTIP Section 4.4.2 Modify A Recurring Instance it says NOTHING about RECURRENCE-ID changing on a reschedule. It shows the RECURRENCE-ID value of July 1 for rescheduling the July 1 instance to July 3. I see nothing that says that RECURRENCE-ID is "the currently booked instance and not the SEQUENCE:1 (original)" as Doug has repeatedly claimed. In fact I checked all the examples in iTIP and NONE of them have ANY prose even remotely saying that the RECURRENCE-ID used on each reschedule is "the currently booked instance and not the SEQUENCE:1 (original)" (By the way, the original value for an instance would be the SEQUENCE:0 one for all the scenarios we've used so far; we have not done any adding or removing of instances to get from SEQUENCE:0 to SEQUENCE:1.) > On this topic you have almost demanded that I answer your questions > while you ignore all of mine. Not an open debate. In order for us to debate a highly contentions claim like "The RFCs says RECURRENCE-ID changes on each reschedule" you need to be able to cite the bits that support this. So far the ONLY reference you have provided was to eventually refer to an example section of iTIP (Section 4.7.2). If you actually read the section though it actually describes a case where a fixed RECURRENCE-ID is used. First I tried to address Dougs claim using examples. I asked for 3+ weeks when the original thread started for simple iTIP examples to show how you could recover from a missed reschedule REQUEST for a single instance since I claimed its not possible. I provided iTIP fragments to support my claims and examples but he never did (and still have not to date). When Arnaud and others asked for them Doug still did not provided them; he merely coined a new term that caused confusion (Thanks again Arnaud for helping clarify this). In the end he tacitly agreed that resyncing the missed instance is NOT possible; his solution was to resync them ALL (even unaffected instances). I have provided plenty of iTIP fragments on how a fixed RECURRENCE-ID model works and how fault tolerant it is when doing message sequencing. I have provide explicit iCalendar and iTIP references that all support this. I have even done an analysis of why the delta/changing RECURRENCE-ID was abandoned by the WG long ago by describing the flaws inherent in it. Along the way Ive had questions about Dougs assumptions that to date have never been answered. I have attempted to stay focused on the central claim and not be digressed by unrelated scenarios or questions so I have not answered each and every one of Dougs questions. I dont think it necessary since they are unrelated to debunking the claim of a changing RECURRENCE-ID model in the RFCs. > The model in iCalendar that maps the RECURRENCE-ID to the the UID > and SEQUENCE as documented works for BOTH models. Fixing the > RECURRENCE-ID to be forever at the SEQUENCE:0 value and ignoring > the 'set' only works for Bruce's model. Fist off, its not my model; its iCalendars: 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. is straight from the RFC, Section 4.8.4.4, Page 108. Secondly the RECURRENCE-ID value is described as "The date/time value is set to the time when the original recurrence instance would occur". I see no text in iCalendar "that maps the RECURRENCE-ID to the the UID and SEQUENCE" since the value is a date/time (or date) and not some amalgam of UID/SEQUENCE. Perhaps Doug thinks "used in conjunction with the "UID" and "SEQUENCE"" means that RECURRENCE-ID values are 'mapped'. Perhaps he is still fixated on Case 2 from iTIP Section 4.7.2 and is neglecting the message sequencing rules that apply to all iTIP messages where it clearly says that UID and RECURRENCE-ID are used before SEQUENCE is. This also agrees with Case 1 from the same section. (Refer to my full analysis from yesterday for more details on this if need be.) In addition since we have not been talking about changing the recurrence sets defintion, merely rescheduling instances around, the RECURRENCE-ID will be fixed for all SEQUENCE values. The only time that iCalendar says RECURRENCE-ID "might also change" is "When the definition of the recurrence set for a calendar component changes" (and thats also iCalendars text, not just me guessing). > In Bruces model he can not change a 2nd unrelated instance back to > an original time of a separate 1st instance, so there code issues a > new UID (As I understand it) then cancels the original UID (or the other way > arround). Not a problem for those that tie the RECURRENCE-ID to > the UID and SEQUENCE set as it will work for those. Im not discussing the way any particular engine handles some CUs action; Im trying to stick to an analysis of the text in iCalendar and iTIP. However perhaps a more concrete example will help so let try one. If my UID and RECURRENCE-ID stay fixed then I can _always_ uniquely and correctly identify the instance in question and perform any workflow on it I need to. If I miss a message (SEQUENCE of 2+ differnece) I can quickly and simply recover. This is 100% NOT possible w/the delta RECURRENCE-ID model. This is one of the factors why we long ago decided on a fixed RECURRENCE-ID model (and the RFCs bear this out). The only way to recover in the changing RECURRENCE-ID model is to blast away ALL instances and have the invitee recreate them ALL!! Not very efficient for 1 missed or missequenced message is it? Doug incorrectly states that with fixed RECURRENCE-ID you "can not change a 2nd unrelated instance back to an original time of a separate 1st instance". With a fixed RECURRENCE-ID model I can easily reschedule 2 separate instances in the set to swap with each other and easily keep all REPLYs in sync with my versions. With a changing RECURRENCE-ID model it can be shown that in 5 simple steps I can toally confuse the Organizer when trying to match REPLYs to the right instances. With the fixed RECURRENCE-ID model its perfectly normal and workable to have: BEGIN:VEVENT UID:12345@foo.com SEQUENCE:3 ORGANIZER:Mailto:Bruce@foo.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Bruce@foo.com ATTENDEE:Mailto:Pat@bar.com DTSTART:20030805T210000Z DTEND:20030805T220000Z RECURRENCE-ID:20030804T210000Z STATUS:TENTATIVE END:VEVENT BEGIN:VEVENT UID:12345@foo.com SEQUENCE:8 ORGANIZER:Mailto:Bruce@foo.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Bruce@foo.com ATTENDEE:Mailto:Pat@bar.com DTSTART:20030804T210000Z DTEND:20030804T220000Z RECURRENCE-ID:20030805T210000Z STATUS:CONFIRMED END:VEVENT and I can quickly and easily match the right REPLY from Pat to the correct instance because the UID and RECURRENCE-ID are the primary keys and never change. If I get SEQUENCE:5 REPLY for RECURRENCE-ID:20030805T210000Z I know that Pat is referring to an old copy of the instance that originally occurred on 05-Aug-2003 @ 21:00Z but she is responding to an obsolete version of it so I simply resend her a REQUEST with the current version and Im done. If we use a changing RECURRENCE-ID model then I have NO 100% accurate way to match a SEQUENCE:5 REPLY for RECURRENCE-ID:20030805T210000Z to the correct instance she was responding to. The ONLY solution is therefore to resend ALL current instance definitions and let _her_ sort 'em out. Of course Id have to craft a REQUEST that sent not only some 'base' defintion but also the individual differences (different SEQUENCE, SUBJECTs, DESCRIPTIONs, etc). She would then have the fun job of removing and recreating it all on her end. All because I have no way to match her REPLY to my instances OR because 2 messages got missequenced en-route. iCalendar says that RECURRENCE-ID is "is used in conjunction with the "UID" and "SEQUENCE" property to identify a specific instance of a recurring...calendar component.". iTIP agrees with this. However none of this says that RECURRENCE-ID changes on a reschedule. In fact iCalendar says that it does NOT (and iTIP for the most part concurs). > I'll stick to the method that works with both models. If you change the RECURRENCE-ID on each reschedule you do then you are in direct vioaltion of iCalendar. Im trying to keep you (and others) from making that mistake. > My testing shows that it DOES work with the major vendors. If you tested with Microsoft or IBM products then you should have seen that all use a fixed RECURRENCE-ID. Thats because thats what the WG decided on, whats in iCalendar and what is more efficient and fault tolerant. > So far I have seen no evidence of any problem. Simply tie the > RECURRENCE-ID to the SEQUENCE and UID as shown in multiple places > in 2445 and 2446 and all works. I have provided at least 2 explicit examples where it breaks down or causes massive C&S workflow thrashing thats easily avoided. I have provided an analysis of why the WG went with a fixed RECURRENCE-ID over a changing one and how the RFCs support this. Ive also shown that the iCalendar RFC clearly defines a fixed RECURRENCE-ID for the simple reschedule case. If you chose NOT to adhere to the RFCs then thats your decision. However your decision is NON-conformant to the RFCs and no matter how long you claim "it works" or that the RFCs say the model is NOT a fixed RECURRENCE-ID (contrary to actual RFC text) you are still in violation of the RFC. I would hope that you would conform to the RFCs instead of clinging to 1 poorly described case in an example section of iTIP but thats your choice Doug. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0067DF4D85256D79_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 08/04/2003 02:50:27 PM:
> > Some folks seem to blindly ignore the 2nd (above, 3rd in the actual RFC)
> > paragraph which clearly and unequivocally says that when a reschedule
> > takes place the RECURRENCE-ID value "is still set to the original"
> > value!
>
> Of the one being changed! Not of SEQUENCE:0 - orever.
The text cited clearly says that RECURRENCE-ID does not change on a reschedule contrary to what Doug has claimed.  As such the RECURRENCE-ID on each subsequent would stay the same as the one it had originally at SEQUENCE:0 when it was originally created.  This is a fixed model of RECURRENCE-ID, NOT one where it changes on each reschedule as Doug has claimed.

Still Im not clear on what he means by "Not of SEQUENCE:0 - orever.".  The RECURRENCE-ID at SEQUENCE:1 will be the same RECURRENCE-ID as it had at SEQUENCE:0 since it does not change on the reschedule and will be the the same at SEQUENCE:1000 (excluding addition/deletions to the repeat set).

> Other wish to blindly ignore ALL of the text and examples that
> clearly show that the paragraph you cite is for CHANGING and instance
> where the RECURRENCE-ID sent is the OLD one (for the set you are
> changing from).
Doug, has NOT shown any that says RECURRENCE-ID changes on each reschedule!  He has only cited Section 4.7.2 Bad RECURRENCE-ID in iTIP and he apparently misread whats there at that.  Examples are NOT definitive sources in the RFCs and he knows that.  The ABNF and prose supercede in authority any example and they always have.

Plus he still ignores the fact that "iTIP complements the iCalendar object specification by adding semantics" to iCalendar data.  It does NOT redefine iCalendar properties; that is the function of the iCalendar RFC ("provides for the definition of iCalendar object methods").

No matter how you try to spin it, iCalendar flat out says that the RECURRENCE-ID is "fixed" and does not change on the reschedule:

   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.

Also, if you check out iTIP Section 4.4.2 Modify A Recurring Instance it says NOTHING about RECURRENCE-ID changing on a reschedule.  It shows the RECURRENCE-ID value of July 1 for rescheduling the July 1 instance to July 3.  I see nothing that says that RECURRENCE-ID is "the currently booked instance and not the SEQUENCE:1 (original)" as Doug has repeatedly claimed.

In fact I checked all the examples in iTIP and NONE of them have ANY prose even remotely saying that the RECURRENCE-ID used on each reschedule is "the currently booked instance and not the SEQUENCE:1 (original)"  (By the way, the original value for an instance would be the SEQUENCE:0 one for all the scenarios we've used so far; we have not done any adding or removing of instances to get from SEQUENCE:0 to SEQUENCE:1.)

> On this topic you have almost demanded that I answer your questions
> while you ignore all of mine. Not an open debate.
In order for us to debate a highly contentions claim like "The RFCs says RECURRENCE-ID changes on each reschedule" you need to be able to cite the bits that support this.  So far the ONLY reference you have provided was to eventually refer to an example section of iTIP (Section 4.7.2).  If you actually read the section though it actually describes a case where a fixed RECURRENCE-ID is used.

First I tried to address Dougs claim using examples.  I asked for 3+ weeks when the original thread started for simple iTIP examples to show how you could recover from a missed reschedule REQUEST for a single instance since I claimed its not possible.  I provided iTIP fragments to support my claims and examples but he never did (and still have not to date).  When Arnaud and others asked for them Doug still did not provided them; he merely coined a new term that caused confusion (Thanks again Arnaud for helping clarify this).  

In the end he tacitly agreed that resyncing the missed instance is NOT possible; his solution was to resync them ALL (even unaffected instances).

I have provided plenty of iTIP fragments on how a fixed RECURRENCE-ID model works and how fault tolerant it is when doing message sequencing.  I have provide explicit iCalendar and iTIP references that all support this.  I have even done an analysis of why the delta/changing RECURRENCE-ID was abandoned by the WG long ago by describing the flaws inherent in it.  Along the way Ive had questions about Dougs assumptions that to date have never been answered.  

I have attempted to stay focused on the central claim and not be digressed by unrelated scenarios or questions so I have not answered each and every one of Dougs questions.  I dont think it necessary since they are unrelated to debunking the claim of a changing RECURRENCE-ID model in the RFCs.

> The model in iCalendar that maps the RECURRENCE-ID to the the UID
> and SEQUENCE as documented works for BOTH models. Fixing the
> RECURRENCE-ID to be forever at the SEQUENCE:0 value and ignoring
> the 'set' only works for Bruce's model.
Fist off, its not my model; its iCalendars:

   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.

is straight from the RFC, Section 4.8.4.4, Page 108.  

Secondly the RECURRENCE-ID value is described as "The date/time value is set to the time when the original recurrence instance would occur".  I see no text in iCalendar "that maps the RECURRENCE-ID to the the UID and SEQUENCE" since the value is a date/time (or date) and not some amalgam of UID/SEQUENCE.  Perhaps Doug thinks "used in conjunction with the "UID" and "SEQUENCE"" means that RECURRENCE-ID values are 'mapped'.  Perhaps he is still fixated on Case 2 from iTIP Section 4.7.2 and is neglecting the message sequencing rules that apply to all iTIP messages where it clearly says that UID and RECURRENCE-ID are used before SEQUENCE is.  This also agrees with Case 1 from the same section.  (Refer to my full analysis from yesterday for more details on this if need be.)

In addition since we have not been talking about changing the recurrence sets defintion, merely rescheduling instances around, the RECURRENCE-ID will be fixed for all SEQUENCE values.  The only time that iCalendar says RECURRENCE-ID "might also change" is "When the definition of the recurrence set for a calendar component changes" (and thats also iCalendars text, not just me guessing).  

> In Bruces model he can not change a 2nd unrelated instance back to
> an original time of a separate 1st instance, so there code issues a
> new UID (As I understand it) then cancels the original UID (or the other way
> arround). Not a problem for those that tie the RECURRENCE-ID to
> the UID and SEQUENCE set as it will work for those.
Im not discussing the way any particular engine handles some CUs action; Im trying to stick to an analysis of the text in iCalendar and iTIP.  However perhaps a more concrete example will help so let try one.

If my UID and RECURRENCE-ID  stay fixed then I can _always_ uniquely and correctly identify the instance in question and perform any workflow on it I need to.  If I miss a message (SEQUENCE of 2+ differnece) I can quickly and simply recover.  This is 100% NOT possible w/the delta RECURRENCE-ID model.  This is one of the factors why we long ago decided on a fixed RECURRENCE-ID model (and the RFCs bear this out).  The only way to recover in the changing RECURRENCE-ID model is to blast away ALL instances and have the invitee recreate them ALL!!  Not very efficient for 1 missed or missequenced message is it?

Doug incorrectly states that with fixed RECURRENCE-ID you "can not change a 2nd unrelated instance back to an original time of a separate 1st instance".  With a fixed RECURRENCE-ID model I can easily reschedule 2 separate instances in the set to swap with each other and easily keep all REPLYs in sync with my versions.  With a changing RECURRENCE-ID model it can be shown that in 5 simple steps I can toally confuse the Organizer when trying to match REPLYs to the right instances.   With the fixed RECURRENCE-ID model its perfectly normal and workable to have:

BEGIN:VEVENT
UID:12345@foo.com
SEQUENCE:3
ORGANIZER:Mailto:Bruce@foo.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Bruce@foo.com
ATTENDEE:Mailto:Pat@bar.com
DTSTART:20030805T210000Z
DTEND:20030805T220000Z
RECURRENCE-ID:20030804T210000Z
STATUS:TENTATIVE
END:VEVENT
BEGIN:VEVENT
UID:12345@foo.com
SEQUENCE:8
ORGANIZER:Mailto:Bruce@foo.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Bruce@foo.com
ATTENDEE:Mailto:Pat@bar.com
DTSTART:20030804T210000Z
DTEND:20030804T220000Z
RECURRENCE-ID:20030805T210000Z
STATUS:CONFIRMED
END:VEVENT
and I can quickly and easily match the right REPLY from Pat to the correct instance because the UID and RECURRENCE-ID are the primary keys and never change.  If I get SEQUENCE:5 REPLY for RECURRENCE-ID:20030805T210000Z I know that Pat is referring to an old copy of the instance that originally occurred on 05-Aug-2003 @ 21:00Z but she is responding to an obsolete version of it so I simply resend her a REQUEST with the current version and Im done.

If we use a changing RECURRENCE-ID model then I have NO 100% accurate way to match a SEQUENCE:5 REPLY for RECURRENCE-ID:20030805T210000Z to the correct instance she was responding to.  The ONLY solution is therefore to resend ALL current instance definitions and let _her_ sort 'em out.  Of course Id have to craft a REQUEST that sent not only some 'base' defintion but also the individual differences (different SEQUENCE, SUBJECTs, DESCRIPTIONs, etc).  She would then have the fun job of removing and recreating it all on her end.  All because I have no way to match her REPLY to my instances OR because 2 messages got missequenced en-route.

iCalendar says that RECURRENCE-ID is "is used in conjunction with the "UID" and "SEQUENCE" property to identify a specific instance of a recurring...calendar component.".  iTIP agrees with this.  However none of this says that RECURRENCE-ID changes on a reschedule.  In fact iCalendar says that it does NOT (and iTIP for the most part concurs).

> I'll stick to the method that works with both models.
If you change the RECURRENCE-ID on each reschedule you do then you are in direct vioaltion of iCalendar.  Im trying to keep you (and others) from making that mistake.

> My testing shows that it DOES work with the major vendors.
If you tested with Microsoft or IBM products then you should have seen that all use a fixed RECURRENCE-ID.  Thats because thats what the WG decided on, whats in iCalendar and what is more efficient and fault tolerant.  

> So far I have seen no evidence of any problem. Simply tie the
> RECURRENCE-ID to the SEQUENCE and UID as shown in multiple places
> in 2445 and 2446 and all works.
I have provided at least 2 explicit examples where it breaks down or causes massive C&S workflow thrashing thats easily avoided.  

I have provided an analysis of why the WG went with a fixed RECURRENCE-ID over a changing one and how the RFCs support this.  

Ive also shown that the iCalendar RFC clearly defines a fixed RECURRENCE-ID for the simple reschedule case.  

If you chose NOT to adhere to the RFCs then thats your decision.  However your decision is NON-conformant to the RFCs and no matter how long you claim "it works" or that the RFCs say the model is NOT a fixed RECURRENCE-ID (contrary to actual RFC text) you are still in violation of the RFC.  I would hope that you would conform to the RFCs instead of clinging to 1 poorly described case in an example section of iTIP but thats your choice Doug.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0067DF4D85256D79_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 15:23:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25193 for ; Tue, 5 Aug 2003 15:23:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75JDPqt029620 for ; Tue, 5 Aug 2003 12:13:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75JDPv0029619 for ietf-calendar-bks; Tue, 5 Aug 2003 12:13:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75JDNqt029604 for ; Tue, 5 Aug 2003 12:13:23 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: Mark Swanson Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: No active 2445 author is a big problem MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 5 Aug 2003 15:13:20 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 08/05/2003 03:13:25 PM, Serialize complete at 08/05/2003 03:13:25 PM Content-Type: multipart/alternative; boundary="=_alternative 0069976085256D79_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069976085256D79_= Content-Type: text/plain; charset="us-ascii" Actually, there are RFC's where the authors are dead and there is no working group around. What happens usually in that case is an "interested party" makes changes to the RFC, submits it as a new draft and the IETF decides to either pass it to a working group or form one. And yes, there are changes that need to be made to the existing RFC's. There are several that have come out of interop testing and probably a few more that will come out of the next one that should happen in a few months. What's missing right now is a volunteer for editor. Any one can be an editor - what will happen is we need to resubmit the three RFCs - 2445, 2446 and 2447 - with their changes, for last call to the IETF. They will then get new RFC numbers and will say internally that the drafts supercede 2445, 2446, and 2447. I can probably put together a list (with some volunteers help) on what needs to be changed - then, if people tell me exact wording, I'm even willing to be the editor. But I am not a calendaring vendor or programmer. I sort of know what's going on by osmosis now - I am, and have always been, a user who happens to run this group. Bruce Kahn is our Methods Reviewer - he is not an author nor is he an editor - nor can he be one, based on business requirements and responsibilities. He can, however, review what is submitted as replacement drafts. I think if we can get a group of three-four people, interested in fixing these drafts, we can get them done relatively quickly. Volunteers? Anyone willing to gamble on me being the editor - you basically tell me what to say and I'll put it in. I'll post the text here on the list - and you guys can shoot at the target for all your worth. Cool? Mark Swanson Sent by: owner-ietf-calendar@mail.imc.org 08/05/2003 14:08 To: "ietf-calendar@imc.org" cc: Subject: No active 2445 author is a big problem Hello, Perhaps I don't understand the process well enough, but... I'm surprised that the IETF would let a document on the standards track exist without at least one participating author (or someone with a maintainership role). It would seem that an author/maintainer could rule on 2445 inconsistencies, 2445 would be fixed, and people could move on. Over the years some major problems have been identified with 2445 yet no new document with the proposed fixes has emerged - even when unanimous acceptance (with zero dissent) occurs wrt the proposed fix. I'm hoping I am misunderstanding something because it would seem this issue will prevent 2445 from ever becoming a standard. Thanks. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web start (JNLP): http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp --=_alternative 0069976085256D79_= Content-Type: text/html; charset="us-ascii"
Actually, there are RFC's where the authors are dead and there is no working group around.  What happens usually in that case is an "interested party" makes changes to the RFC, submits it as a new draft and the IETF decides to either pass it to a working group or form one.  

And yes, there are changes that need to be made to the existing RFC's.  There are several that have come out of interop testing and probably a few more that will come out of the next one that should happen in a few months.  What's missing right now is a volunteer for editor.  Any one can be an editor - what will happen is we need to resubmit the three RFCs - 2445, 2446 and 2447 - with their changes, for last call to the IETF.  They will then get new RFC numbers and will say internally that the drafts supercede 2445, 2446, and 2447.  I can probably put together a list (with some volunteers help) on what needs to be changed - then, if people tell me exact wording, I'm even willing to be the editor.  But I am not a calendaring vendor or programmer.  I sort of know what's going on by osmosis now - I am, and have always been, a user who happens to run this group.  Bruce Kahn is our Methods Reviewer - he is! not an author nor is he an editor - nor can he be one, based on business requirements and responsibilities.  He can, however, review what is submitted as replacement drafts.  

I think if we can get a group of three-four people, interested in fixing these drafts, we can get them done relatively quickly.

Volunteers?  Anyone willing to gamble on me being the editor - you basically tell me what to say and I'll put it in.  I'll post the text here on the list - and you guys can shoot at the target for all your worth.  Cool?


Mark Swanson <mark@WebServiceSolutions.com>
Sent by: owner-ietf-calendar@mail.imc.org

08/05/2003 14:08

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        No active 2445 author is a big problem




Hello,
Perhaps I don't understand the process well enough, but...
I'm surprised that the IETF would let a document on the standards track exist
without at least one participating author (or someone with a maintainership
role). It would seem that an author/maintainer could rule on 2445
inconsistencies, 2445 would be fixed, and people could move on.
Over the years some major problems have been identified with 2445 yet no new
document with the proposed fixes has emerged - even when unanimous acceptance
(with zero dissent) occurs wrt the proposed fix.
I'm hoping I am misunderstanding something because it would seem this issue
will prevent 2445 from ever becoming a standard.
Thanks.
--
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
Java Web start (JNLP):
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp


--=_alternative 0069976085256D79_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 16:34: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 QAA27750 for ; Tue, 5 Aug 2003 16:34:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75KGtqt034854 for ; Tue, 5 Aug 2003 13:16:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75KGt1O034853 for ietf-calendar-bks; Tue, 5 Aug 2003 13:16:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75KGrqt034848 for ; Tue, 5 Aug 2003 13:16:54 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h75KGqEB020362 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Aug 2003 13:16:54 -0700 Message-ID: <3F3010AF.2070305@Royer.com> Date: Tue, 05 Aug 2003 14:16:47 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050907080701000101050108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050907080701000101050108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 08/04/2003 02:50:27 PM: > > > Some folks seem to blindly ignore the 2nd (above, 3rd in the actual > RFC) > > > paragraph which clearly and unequivocally says that when a reschedule > > > takes place the RECURRENCE-ID value "is still set to the original" > > > value! > > > > Of the one being changed! Not of SEQUENCE:0 - orever. > > The text cited clearly says ... And Bruce still does not answer any of the questions or debate any posted soultions... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050907080701000101050108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNTIwMTY0N1owIwYJKoZIhvcNAQkEMRYEFE0gXzSP 5nvk8IfQ4sWoJEbGBxxhMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIFfA0Jb75ELEMDS054Zt2QH9GP7hnB4uAp6+y98yxLR3bUZq0w0 tzPRfmPCRXyXynL9R7grZ0QpzsxsyRZ+rrpwDla+YRNoG0MFdeUBptEqyQeSRJ+U3dwO9fFU 4ePvrG9sPnkIuoENUKil8GxG2znp20m1GmVAhRCHhXRR0oikQpf9ujcY1wKt2c9Y5/uxF2qD 6/yk5kTipG2wD7irH7zfVLTQKYLQeJVV91H8gJ+HllLhwZ3KOVWnjiRFTysHH8okuS/F4OlS VMCdCmFyAm5aPLXWwh/pNcnGjmf+fTTlxxD8guOLBmSQozDmv0BYEfLegRysSD7HIjZRPFQO jggAAAAAAAA= --------------ms050907080701000101050108-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 17:03: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 RAA28836 for ; Tue, 5 Aug 2003 17:03:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75KrYqt036089 for ; Tue, 5 Aug 2003 13:53:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75KrXgQ036088 for ietf-calendar-bks; Tue, 5 Aug 2003 13:53:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75KrWqt036083 for ; Tue, 5 Aug 2003 13:53:32 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h75KrVEB020639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Aug 2003 13:53:33 -0700 Message-ID: <3F301946.1050300@Royer.com> Date: Tue, 05 Aug 2003 14:53:26 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-11 is out (VFREEBUSY) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020002030900070400070308" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020002030900070400070308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thank you. If there are no objections I'll use the text you supplied. G. Barnes wrote: > > I'm just trying to understand the draft, so I'm hardly an expert. But that > search doesn't make a lot of sense to me. I can't say whether it should > return 'no matches', or return an error. > > Assuming it doesn't make sense, the paragraph is pretty > misleading and should be changed: it implies that something is returned > when such a search is done. I'll take a stab at fixing it: > > If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains > the "VFREEBUSY" component in the "COMPONENTS" value in a reply > to the "GET-CAPABILITY" command, then it is the CS's responsibility > and not the CUA's responsibility to provide the correct "VFREEBUSY" > information for a calendar. Therefore, > > If a CUA issues a "CREATE" "VFREEBUSY", such a CS MUST return > success and not store the "VFREEBUSY" component. > > Such a CS MUST dynamically create the results of a search for > "VFREEBUSY" components at search time when searching for STATE() = > 'BOOKED' items. > > If a CUA searches for "VFREEBUSY" components with STATE() = > 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components. > > If a CUA searches for "VFREEBUSY" components without specifying > the STATE, such a CS MUST return the same result as if > STATE()='BOOKED' had been specified. > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020002030900070400070308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNTIwNTMyNlowIwYJKoZIhvcNAQkEMRYEFI1Tlpx6 LSQl6oUsJb/j8PvxjUfzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEIVLs/+h2tG6Ip1mjYXqEvJQefku9fOZWsl5zJ77vkOOiEr9j99 MqUUsYGVd3DtpREFKDIgIOhZGvwYyplXoJxu19x+IkurpQSeV6mIKRuKK7wg9AyNmjTffqom /f1dd5WSv5WYAv0M6Dx9WA7Jppp+NFtZhN+2o7Z7/1teul6OL3dyaXNK+lZXCMM3uWTL8ntV sUfVZtR0y9pJXHyzo0LlDitq3d/lRx3MOfeF9Sd/olQxSk6Jtax7fEsywnmMch3RCIlcI9su 9WpLdDUqIYrUFZ8iGSQrGI91uaF9Nj7GoXA4C9614CaHVMW2QB+HESTILYXMolJL0GBR8dv2 2o8AAAAAAAA= --------------ms020002030900070400070308-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 17:14: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 RAA29019 for ; Tue, 5 Aug 2003 17:14:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75L4cqt037159 for ; Tue, 5 Aug 2003 14:04:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75L4bh1037158 for ietf-calendar-bks; Tue, 5 Aug 2003 14:04:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75L4bqt037142 for ; Tue, 5 Aug 2003 14:04:37 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F2FE6F3.20405@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-11 is out (VFREEBUSY) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Aug 2003 16:50:33 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/05/2003 05:04:13 PM, Serialize complete at 08/05/2003 05:04:13 PM Content-Type: multipart/alternative; boundary="=_alternative 00723C3285256D79_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00723C3285256D79_= Content-Type: text/plain; charset="US-ASCII" Doug asked on 08/05/2003 01:18:43 PM: > When *ever* would the VFREEBUSY 'UNPROCESSED' *EVER* be used? 2 cases come to mind: 1: Some CUA did a CMD:CREATE of a VFREEBUSY into your queue (much like they CREATE an METHOD:REQUEST VEVENT to invite you) 2: If there is iMIP delivery into the users queue then you have to get 'em out somehow. I suspect that anything that can be CREATEd in your queue needs to be able to get searched for so you can remove 'em, process 'em, etc. Although we dont have iMIP -> CAP designed now, it may be possible in the future (CAP creation is not the only way to get 'em into your queue essentially). 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 00723C3285256D79_= Content-Type: text/html; charset="US-ASCII"
Doug asked on 08/05/2003 01:18:43 PM:
> When *ever* would the VFREEBUSY 'UNPROCESSED' *EVER* be used?
2 cases come to mind:

1: Some CUA did a CMD:CREATE of a VFREEBUSY into your queue (much like they CREATE an METHOD:REQUEST VEVENT to invite you)
2: If there is iMIP delivery into the users queue then you have to get 'em out somehow.  

I suspect that anything that can be CREATEd in your queue needs to be able to get searched for so you can remove 'em, process 'em, etc.  Although we dont have iMIP -> CAP designed now, it may be possible in the future (CAP creation is not the only way to get 'em into your queue essentially).

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 00723C3285256D79_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 17:15: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 RAA29061 for ; Tue, 5 Aug 2003 17:15:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75L4cqt037168 for ; Tue, 5 Aug 2003 14:04:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75L4cDT037167 for ietf-calendar-bks; Tue, 5 Aug 2003 14:04:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75L4bqu037142 for ; Tue, 5 Aug 2003 14:04:37 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F2FEC1B.1040506@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Aug 2003 16:45:50 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/05/2003 05:04:14 PM, Serialize complete at 08/05/2003 05:04:14 PM Content-Type: multipart/alternative; boundary="=_alternative 0071CDB885256D79_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071CDB885256D79_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 08/05/2003 01:40:43 PM: > > 1: This exact citation was the one Dan Hickman asked about back in July > > 1999 and the WG discussed. We agreed that it was in error. > > No, some think it is in error, including you. That does not make > 2445 incorrect. It makes it a point to debate. iTIP provides semantics to iCalendar and as such it cannot be redefining iCalendar to suite its needs. Those 2 lines conflict w/all the rest of the RFCs but they do not mean that ALL the other prose is wrong. Thats like the flea wagging the dog. I do not agree that RECURRENCE-ID changes on a reschedule and I did not back in 1999. I agree with Dan Hickman that RECURRENCE-ID was supposed to be fixed and nowhere during that 1999 discussion did I disagree. To be accurate, at no point during that thread did anyone disagree with Dans comment "I thought we decided to leave the RECURRENCE-ID the same." including you. Originally a changing RECURRENCE-ID was the design that the WG had and at one point I _may_ have thought it was ok but I took an analytical approach to it and to the protocol and saw its many flaws and realized that if part of my primary key for sequencing changes every time there was too much room for failure and inconsistancy. This is why a fixed RECURRENCE-ID was the model we finally put into iCalendar. Ignore all the parts in all the RFCs that say this if you like but that wont change the published RFCs that definitely use a "fixed" RECURRENCE-ID model (when doing normal rescheduling, etc). You can also ignore my lengthy analysis if you like but I dont hear you saying that it was wrong. You can disagree w/the fixed RECURRENCE-ID model all you like but thats whats in the RFCs. > > Given that > > of 250+ pages of RFCs and you find 2 sentences that contradict the rest > > is not an overwhelming contradiction. We had 5+ authors working on > > different parts of 3 RFCs so 2 lines out of 250+ is not that > > significant. There are no other conflicting citations that Ive seen so > > far and ALL the others citations support each other. > > Except the ones you delete from posts and never reply to? Oh a question. Better remember to answer 'em all lest Doug think Im ignoring him or dont want to debate just the issues... Umm, Im not the one who deletes conflicting lines of citations when responding. In fact Doug has yet to even acknowledge that iCalendar says that RECURRENCE-ID stays at the original (aka 1st) value and does not change on a reschedule. Every time you've used a citation Ive tried to make sure it was entirely in perspective. Im not the one ignoring the iTIP prose on Message Sequencing or describing the separate methods. Im not the one ignoring: 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. Does that say that the RECURRENCE-ID changes to the new Thursday value or does it say that it "is still set to the origianl" value? Im also the one who noted that iCalendar says RECURRENCE-ID "might also change" "When the definition of the recurrence set for a calendar component changes" so Im cant be accused of ignoring that possiblitiy. (Actually accusuing is easy, demonstrating is not...) Perhaps because that line about when RECURRENCE-ID may change also has "and hence the "SEQUENCE" property value changes" some folks are of the notion that _every_ time SEQUENCE changes RECURRENCE-ID MUST also change. That does not logically follow since SEQUENCE can also be changed if the changes "to other properties can also force the sequence number to be incremented." and a CUA can ref SEQUENCE anytime it wants (even for fixing a typo, sic). By extension then a simple typo change could cause RECURRENCE-ID to change because SEQUENCE changed. Yech! > Below > in your post you declare that there is contention, here you claim > that you have not seen any? Please explain. I didnt use the phrase contention so Im not sure where you think I saw some. I noted that we already covered that exact iTIP citation from Satya back in 1999 (noone disagreed then that we had alrady agreed by July 1999 that RECURRENCE-ID was fixed) and that its the only line in iTIP that contradicts iCalendar and the rest of iTIP. > Yes it can, that is part of the IETF process. That is *this* debate > and we *are* discussing iCAL changes not only on this topic but in non > controversial ways discussing iCAL-rev-next. 1: iTIP does NOT define/redefine iCalendar properties or their actions! That is not its role. iCalendar is the "definition of a common format" and iTIP "complements the iCalendar object specification by adding semantics". You dont change the defintions when you provide semantics; you update the actual defintions. Thats why we separated iCalendar from iTIP in the first place. 2: We are _NOT_ and have never been discussing _changes_ to iCalendar! I am contesting your still unproven claim that iCalendar/iTIP _currently_ define a delta RECURRENCE-ID model! I have used both RFC citation AND model analysis to disprove this but you just dont want to accept it. If you want to propose changes to iCalendar and disguise it as a necessary CAP need then thats a different discussion. As a vendor (and Method Reviewer for the existing RFCs) Ill object to a total reversal of the iCalendar model especially given there is no demonstrable need for it and that the current model has been implemented by many and works. If you built some prototype based on some misreading of the existing RFCs and want to change the model just because its easier for you than redesigning/recoding then thats not my problem. > Some including me say that they are all consistent as original > means the original one you are changing from, not sequence:0. Thats not the ways its defined in English nor the way its used in iCalendar. Your misuse of original is really "the latest" or "the most recent" or "the current" no matter how you try to spin it. > > A: What about the paragraph you forgot to cite? The one that expressly > > says on a reschedule of an instance the RECURRNECE-ID stays at its > > original value? Is that unclear or open to multiple interpretations? > > No, and you have never addressed those, you just declare that one > paragraph overrides all others rather than admit that it means > the original one being changed from and not the original sequence:0 > instance. Doug, get real. Go to http://www.m-w.com/ and look up the work "original" then we can talk. When legal documents refer to the "original owner" they do not mean "the latest owner" or "the current owner". (Gee that would be great for some property disputes yes!!?) When advertising touts "The Original Widget" they are not talking about the latest clone widget product. When someone asks you where you are originally from they aren't asking where you just came from. When people say "Originally I went studied Chemistry but I changed my major to Computer" they dont mean they first studied Computers and then Chemistry. > > Do NOT fall into Dougs misinterpreation that rescheduling an instance is > > the same as changing the repeat instance set defintion, its not. > > You have never replied to those citations or questions. Ive answered your questions so far. How about the same? You just keep ignoring the fact that iCalendar says RECURRENCE-ID is "fixed" by now trying to weasle around the meaning of the word "original". Even if you want to play weasel on that meaning the rest of the example paragraph demonstrates it: 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. Just in case you dont understand "original" the highlighed part should clue you in; the value DID NOT CHANGE to the new Thursday one! > You just keep > asserting that you know that one paragraph overrides all others > and that your repeated assertion that 'original == sequence:0'. Even > when no such text exists. It means the original 'set' before the change > and not sequence:0. Then all text is consistent. For the case where I create a repeating meeting set and then proceed to do workflow (the one Ive always used and referred to) then the original RECURRENCE-ID value will be the one from SEQUENCE:0. This was always the case under discussion despite you attempts to muddy the discussion with different scenarios. Your 6+ week refusal to acknowledge the text above and now this attempt to say "original" means "the latest version" (paraphrased for actual intent) is just ludicrous. Now are you going to tell me that the highlighted bits above dont really mean the SEQUENCE:0 RECURRENCE-ID value (Friday) is preserved at SEQUENCE:1 (Thursday) because it doesnt put explicit SEQUENCE values in the text? Prior to now you have merely said "its in the RFCs" (slightly paraphrased) or referred just to iTIP Section 4.7.2, an example section in ITIP at that and you never ever pointed to iCalendar as justification for your claim of a changing RECURRENCE-ID on a simple reschedule. If you had actually thought that "original" meant what it did you would have immediately used that as a justification but you cant so you didnt. > It's not the EDITORS opinion that counts, its the WG's. As much hard > work as they put into the RFCs, it is a WG document. And the WG passes the drafts that the Editors put out. As such they provide both input to the Editors and they review the outputs before they move on. As such its NOT just the Editors who agree with the fixed RECURRENCE-ID model, it was the entire WG! > There are multiple citations that disagree with you. Could you > please explain rather than ignore those? There is ONLY 1 citation so far thats been provided and that was Satays. Ive already pointed out that we dealt with it in 1999. I repeatedly covered your single citation of Section 4.7.2 Bad RECURRENCE-ID and even shown how it agrees with a fixed RECURRENCE-ID. What other citations have I missed? > > 2: Why the fixed RECURRENCE-ID model works well and is quite fault > > tolerant. > > Would you please reply to my posting about how your model is broken? Its not my model, its the one from RFC 2445 and I did reply to it. I notice you have NOT responded to my comparison/analysis of the changing vs fixed RECURRENCE-ID. Instead you try to wiggle around the meaning of "original"... Ill take it then that you agree w/my analysis of the flaws/weaknesses in the changing RECURRENCE-ID model (above and beyond the fact that iCalendar says that its "fixed"). > > 3: That the RFCs overwhelmingly describe and implicitly use a fixed > > RECURRENCE-ID model. > > Yet the citations you refuse to debate disagree with you. Including > iTIP which you admit above disagrees with you. The 2 lines from the bottom of iTIP Section 3.7.1 Working With Recurrence Instances are old news and I did cover them again. Umm I get it; 2 lines = 2 citations... Ok must be Dougs defintion of citations but thats ok. He even double includes them at the end. Those 2 lines have been hashed over before and still do not have the same weight as the actual defition from iCalendar no matter how much you wish for it. > > 4: Several of the major flaws inherent in a changing RECURRENCE-ID model. > > All of which have been addressed and you have ignored all such posts. Ignored all such posts? Hahaha, I just have to laugh now. Im the one who described the weaknesses inherent in the changing RECURRENCE-ID model. I showed how the fixed RECURRENCE-ID has no such weakness. Im the one who showed how easy it is to thrash or stuck in a changing RECURRENCE-ID model and that the same problems do not happen in a fixed RECURRENCE-ID model. What did I ignore? > Yet you refuse to acknowledge that even in your email here that I am > responding to - iTIP disagrees with you. What have I refused to acknowledge? Ive already noted that there are 2 lines in iTIP that we already discussed in 1999 and that they alone do not justify your claims. 2 lines vs 250+ pages and iCalendar defintions to the contrary; yep that sounds like a ringing justification of your claims. Im NOT the one who has misunderstood the meaning of "definition of the recurrence set" nor the defintion of the word "fixed" nor the meaning of the word "original" in: 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. Nor have I now tried to reframe the assertion in the guise of iCalendar changes for CAPs benefit/need. > Is it possible that you are misreading that one paragraph? Lets reread that paragraph (plus a bit more) again shall we: 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. [Snip, snip] When the definition of the recurrence set for a calendar component changes, and hence the "SEQUENCE" property value changes, the "RECURRENCE-ID" for a given recurrence instance might also change. Umm, no I dont think so. Im rescheduling an instance in the set so the RECURRENCE-ID value "is still set to the original" value. Even if I look at iTIP and Section 4.4.2 Modify A Recurring Instance I see no mention or example that shows RECURRENCE-ID changing. So, if you want to claim that iCalendar / iTIP _currently_ have a changing RECURRENCE-ID model then show it. If you want to redefine the model under the guise of "discussing iCAL changes" relevant to CAP then say so (and dont forget to justify why a model change is necessary). Bruce PS: Fourth time asking: Doug, do you think that 1 SEQUENCE property/value is shared among all instances of the repeat set or does each instance have its own SEQUENCE value? =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0071CDB885256D79_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 08/05/2003 01:40:43 PM:
> > 1: This exact citation was the one Dan Hickman asked about back in July
> > 1999 and the WG discussed.  We agreed that it was in error.
>
> No, some think it is in error, including you. That does not make
> 2445 incorrect. It makes it a point to debate.
iTIP provides semantics to iCalendar and as such it cannot be redefining iCalendar to suite its needs.  Those 2 lines conflict w/all the rest of the RFCs but they do not mean that ALL the other prose is wrong.  Thats like the flea wagging the dog.

I do not agree that RECURRENCE-ID changes on a reschedule and I did not back in 1999.  I agree with Dan Hickman that RECURRENCE-ID was supposed to be fixed and nowhere during that 1999 discussion did I disagree.  To be accurate, at no point during that thread did anyone disagree with Dans comment "I thought we decided to leave the RECURRENCE-ID the same." including you.

Originally a changing RECURRENCE-ID was the design that the WG had and at one point I _may_ have thought it was ok but I took an analytical approach to it and to the protocol and saw its many flaws and realized that if part of my primary key for sequencing changes every time there was too much room for failure and inconsistancy.  This is why a fixed RECURRENCE-ID was the model we finally put into iCalendar.

Ignore all the parts in all the RFCs that say this if you like but that wont change the published RFCs that definitely use a "fixed" RECURRENCE-ID model (when doing normal rescheduling, etc).

You can also ignore my lengthy analysis if you like but I dont hear you saying that it was wrong.  

You can disagree w/the fixed RECURRENCE-ID model all you like but thats whats in the RFCs.

> >  Given that
> > of 250+ pages of RFCs and you find 2 sentences that contradict the rest
> > is not an overwhelming contradiction.  We had 5+ authors working on
> > different parts of 3 RFCs so 2 lines out of 250+ is not that
> > significant.  There are no other conflicting citations that Ive seen so
> > far and ALL the others citations support each other.
>
> Except the ones you delete from posts and never reply to?

Oh a question.  Better remember to answer 'em all lest Doug think Im ignoring him or dont want to debate just the issues...  

Umm, Im not the one who deletes conflicting lines of citations when responding.  In fact Doug has yet to even acknowledge that iCalendar says that RECURRENCE-ID stays at the original (aka 1st) value and does not change on a reschedule.  

Every time you've used a citation Ive tried to make sure it was entirely in perspective.  Im not the one ignoring the iTIP prose on Message Sequencing or describing the separate methods.  Im not the one ignoring:

   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.

Does that say that the RECURRENCE-ID changes to the new Thursday value or does it say that it "is still set to the origianl" value?

Im also the one who noted that iCalendar says RECURRENCE-ID "might also change" "When the definition of the recurrence set for a calendar component changes" so Im cant be accused of ignoring that possiblitiy.  (Actually accusuing is easy, demonstrating is not...)  Perhaps because that line about when RECURRENCE-ID may change also has "and hence the "SEQUENCE" property value changes" some folks are of the notion that _every_ time SEQUENCE changes RECURRENCE-ID MUST also change.  That does not logically follow since SEQUENCE can also be changed if the changes "to other properties can also force the sequence number to be incremented." and a CUA can ref SEQUENCE anytime it wants (even for fixing a typo, sic).  By extension then a simple typo change could cause RECURRENCE-ID to change because SEQUENCE changed.  Yech!

>                                                           Below
> in your post you declare that there is contention, here you claim
> that you have not seen any? Please explain.
I didnt use the phrase contention so Im not sure where you think I saw some.  

I noted that we already covered that exact iTIP citation from Satya back in 1999 (noone disagreed then that we had alrady agreed by July 1999 that RECURRENCE-ID was fixed) and that its the only line in iTIP that contradicts iCalendar and the rest of iTIP.  

> Yes it can, that is part of the IETF process. That is *this* debate
> and we *are* discussing iCAL changes not only on this topic but in non
> controversial ways discussing iCAL-rev-next.
1: iTIP does NOT define/redefine iCalendar properties or their actions!  That is not its role.  iCalendar is the "definition of a common format" and iTIP "complements the iCalendar object specification by adding semantics".  You dont change the defintions when you provide semantics; you update the actual defintions.  Thats why we separated iCalendar from iTIP in the first place.

2: We are _NOT_ and have never been discussing _changes_ to iCalendar!  I am contesting your still unproven claim that iCalendar/iTIP _currently_ define a delta RECURRENCE-ID model!  I have used both RFC citation AND model analysis to disprove this but you just dont want to accept it.

If you want to propose changes to iCalendar and disguise it as a necessary CAP need then thats a different discussion.  As a vendor (and Method Reviewer for the existing RFCs) Ill object to a total reversal of the iCalendar model especially given there is no demonstrable need for it and that the current model has been implemented by many and works.  

If you built some prototype based on some misreading of the existing RFCs and want to change the model just because its easier for you than redesigning/recoding then thats not my problem.  

> Some including me say that they are all consistent as original
> means the original one you are changing from, not sequence:0.
Thats not the ways its defined in English nor the way its used in iCalendar.  Your misuse of original is really "the latest" or "the most recent" or "the current" no matter how you try to spin it.

> > A: What about the paragraph you forgot to cite?  The one that expressly
> > says on a reschedule of an instance the RECURRNECE-ID stays at its
> > original value?  Is that unclear or open to multiple interpretations?
>
> No, and you have never addressed those, you just declare that one
> paragraph overrides all others rather than admit that it means
> the original one being changed from and not the original sequence:0
> instance.
Doug, get real.

Go to http://www.m-w.com/ and look up the work "original" then we can talk.  

When legal documents refer to the "original owner" they do not mean "the latest owner" or "the current owner".  (Gee that would be great for some property disputes yes!!?)
When advertising touts "The Original Widget" they are not talking about the latest clone widget product.  
When someone asks you where you are originally from they aren't asking where you just came from.
When people say "Originally I went studied Chemistry but I changed my major to Computer" they dont mean they first studied Computers and then Chemistry.

> > Do NOT fall into Dougs misinterpreation that rescheduling an instance is
> > the same as changing the repeat instance set defintion, its not.
>
> You have never replied to those citations or questions.

Ive answered your questions so far.  How about the same?

You just keep ignoring the fact that iCalendar says RECURRENCE-ID is "fixed" by now trying to weasle around the meaning of the word "original".  Even if you want to play weasel on that meaning the rest of the example paragraph demonstrates it:

   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.

Just in case you dont understand "original" the highlighed part should clue you in; the value DID NOT CHANGE to the new Thursday one!

>                                           You just keep
> asserting that you know that one paragraph overrides all others
> and that your repeated assertion that 'original == sequence:0'. Even
> when no such text exists. It means the original 'set' before the change
> and not sequence:0. Then all text is consistent.
For the case where I create a repeating meeting set and then proceed to do workflow (the one Ive always used and referred to) then the original RECURRENCE-ID value will be the one from SEQUENCE:0.  This was always the case under discussion despite you attempts to muddy the discussion with different scenarios.

Your 6+ week refusal to acknowledge the text above and now this attempt to say "original" means "the latest version" (paraphrased for actual intent) is just ludicrous.  Now are you going to tell me that the highlighted bits above dont really mean the SEQUENCE:0 RECURRENCE-ID value (Friday) is preserved at SEQUENCE:1 (Thursday) because it doesnt put explicit SEQUENCE values in the text?

Prior to now you have merely said "its in the RFCs" (slightly paraphrased) or referred just to iTIP Section 4.7.2, an example section in ITIP at that and you never ever pointed to iCalendar as justification for your claim of a changing RECURRENCE-ID on a simple reschedule.  If you had actually thought that "original" meant what it did you would have immediately used that as a justification but you cant so you didnt.

> It's not the EDITORS opinion that counts, its the WG's. As much hard
> work as they put into the RFCs, it is a WG document.
And the WG passes the drafts that the Editors put out.  As such they provide both input to the Editors and they review the outputs before they move on.  As such its NOT just the Editors who agree with the fixed RECURRENCE-ID model, it was the entire WG!

> There are multiple citations that disagree with you. Could you
> please explain rather than ignore those?
There is ONLY 1 citation so far thats been provided and that was Satays.  Ive already pointed out that we dealt with it in 1999.  I repeatedly covered your single citation of Section 4.7.2 Bad RECURRENCE-ID and even shown how it agrees with a fixed RECURRENCE-ID.  What other citations have I missed?  

> > 2: Why the fixed RECURRENCE-ID model works well and is quite fault
> > tolerant.  
>
> Would you please reply to my posting about how your model is broken?
Its not my model, its the one from RFC 2445 and I did reply to it.  

I notice you have NOT responded to my comparison/analysis of the changing vs fixed RECURRENCE-ID.  Instead you try to wiggle around the meaning of "original"...  Ill take it then that you agree w/my analysis of the flaws/weaknesses in the changing RECURRENCE-ID model (above and beyond the fact that iCalendar says that its "fixed").

> > 3: That the RFCs overwhelmingly describe and implicitly use a fixed
> > RECURRENCE-ID model.  
>
> Yet the citations you refuse to debate disagree with you. Including
> iTIP which you admit above disagrees with you.
The 2 lines from the bottom of iTIP Section 3.7.1 Working With Recurrence Instances are old news and I did cover them again.  Umm I get it; 2 lines = 2 citations...  Ok must be Dougs defintion of citations but thats ok.  He even double includes them at the end.

Those 2 lines have been hashed over before and still do not have the same weight as the actual defition from iCalendar no matter how much you wish for it.

> > 4: Several of the major flaws inherent in a changing RECURRENCE-ID model.  
>
> All of which have been addressed and you have ignored all such posts.
Ignored all such posts? Hahaha, I just have to laugh now.

Im the one who described the weaknesses inherent in the changing RECURRENCE-ID model.  I showed how the fixed RECURRENCE-ID has no such weakness.  Im the one who showed how easy it is to thrash or stuck in a changing RECURRENCE-ID model and that the same problems do not happen in a fixed RECURRENCE-ID model.

What did I ignore?

> Yet you refuse to acknowledge that even in your email here that I am
> responding to - iTIP disagrees with you.
What have I refused to acknowledge?  

Ive already noted that there are 2 lines in iTIP that we already discussed in 1999 and that they alone do not justify your claims.  2 lines vs 250+ pages and iCalendar defintions to the contrary; yep that sounds like a ringing justification of your claims.

Im NOT the one who has misunderstood the meaning of "definition of the recurrence set" nor the defintion of the word "fixed" nor the meaning of the word "original" in:

   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.
Nor have I now tried to reframe the assertion in the guise of iCalendar changes for CAPs benefit/need.  

> Is it possible that you are misreading that one paragraph?
Lets reread that paragraph (plus a bit more) again shall we:

   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.
[Snip, snip]
                               When the definition of the recurrence
  set for a calendar component changes, and hence the "SEQUENCE"
  property value changes, the "RECURRENCE-ID" for a given recurrence
  instance might also change.

Umm, no I dont think so.  Im rescheduling an instance in the set so the RECURRENCE-ID value "is still set to the original" value.  Even if I look at iTIP and Section 4.4.2 Modify A Recurring Instance I see no mention or example that shows RECURRENCE-ID changing.  

So, if you want to claim that iCalendar / iTIP _currently_ have a changing RECURRENCE-ID model then show it.  If you want to redefine the model under the guise of "discussing iCAL changes" relevant to CAP then say so (and dont forget to justify why a model change is necessary).

Bruce
PS: Fourth time asking: Doug, do you think that 1 SEQUENCE property/value is shared among all instances of the repeat set or does each instance have its own SEQUENCE value?
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0071CDB885256D79_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 17:59: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 RAA00069 for ; Tue, 5 Aug 2003 17:59:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75Lmoqt042089 for ; Tue, 5 Aug 2003 14:48:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75Lmowl042088 for ietf-calendar-bks; Tue, 5 Aug 2003 14:48:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75Lmnqt042083 for ; Tue, 5 Aug 2003 14:48:49 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F3010AF.2070305@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Aug 2003 17:27:22 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/05/2003 05:48:50 PM, Serialize complete at 08/05/2003 05:48:50 PM Content-Type: multipart/alternative; boundary="=_alternative 00759AEC85256D79_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00759AEC85256D79_= Content-Type: text/plain; charset="US-ASCII" Doug whined on 08/05/2003 04:16:47 PM: > And Bruce still does not answer any of the questions or debate > any posted soultions... Clearly you are just playing spoiler attempting to waste cycles. I asked for clarification of your "Of the one being changed! Not of SEQUENCE:0 - orever." but dont see it. Plus its not my job to prove your bogus assertions about a changing RECURRENCE-ID model. iCalendar defines a "fixed" (go to http://www.m-w.com/ if you dont understand that word either) RECURRENCE-ID model and iTIP supports that. As previously noted the WG alrady covered the 2 lines of iTIP that try to redefine RECURRENCE-ID and there was no disagreement (not even by you!) to "we decided to leave the RECURRENCE-ID the same." We collectively did agree (by the lack of disagreement over that statement or by vocally agreement) so this is old news. In fact the only real conflicting line in iTIP is the last one that Satay (not you) referenced when it says: Note that after the change has occurred, the "RECURRENCE-ID" has changed to the new "DTSTART" value. The other (preceeding) line actually agrees w/iCalendar: If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" property [Snip] but that would assume that you understand what the word "original" means. So I must ammend my 2 lines vs 250+ pages comparison to be 1 line vs 250+ pages to the contrary. Yep, that sounds real compelling... 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 00759AEC85256D79_= Content-Type: text/html; charset="US-ASCII"
Doug whined on 08/05/2003 04:16:47 PM:
> And Bruce still does not answer any of the questions or debate
> any posted soultions...
Clearly you are just playing spoiler attempting to waste cycles.  I asked for clarification of your "Of the one being changed! Not of SEQUENCE:0 - orever." but dont see it.

Plus its not my job to prove your bogus assertions about a changing RECURRENCE-ID model.  iCalendar defines a "fixed" (go to http://www.m-w.com/ if you dont understand that word either) RECURRENCE-ID model and iTIP supports that.  As previously noted the WG alrady covered the 2 lines of iTIP that try to redefine RECURRENCE-ID and there was no disagreement (not even by you!) to "we decided to leave the RECURRENCE-ID the same."

We collectively did agree (by the lack of disagreement over that statement or by vocally agreement) so this is old news.  In fact the only real conflicting line in iTIP is the last one that Satay (not you) referenced when it says:

               Note that after the change has occurred, the
  "RECURRENCE-ID" has changed to the new "DTSTART" value.

The other (preceeding) line actually agrees w/iCalendar:

                                  If the "Organizer" wishes to
  change the "DTSTART", the original "DTSTART" value is used for
  "RECURRENCE-ID" property [Snip]

but that would assume that you understand what the word "original" means.  So I must ammend my 2 lines vs 250+ pages comparison to be 1 line vs 250+ pages to the contrary.  Yep, that sounds real compelling...

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 00759AEC85256D79_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 5 19: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 TAA02928 for ; Tue, 5 Aug 2003 19:23:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75NCKqt044547 for ; Tue, 5 Aug 2003 16:12:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75NCK2b044546 for ietf-calendar-bks; Tue, 5 Aug 2003 16:12:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75NCIqt044541 for ; Tue, 5 Aug 2003 16:12:18 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h75NCHEB021708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Aug 2003 16:12:19 -0700 Message-ID: <3F3039CC.2050101@Royer.com> Date: Tue, 05 Aug 2003 17:12:12 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080204000408000509080509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080204000408000509080509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug whined on 08/05/2003 04:16:47 PM: > > And Bruce still does not answer any of the questions or debate > > any posted soultions... > > Clearly you are just playing spoiler attempting to waste cycles. No Bruce. I answered all of your questions and you ignored all of mine. I proposed solutions to all of your quandaries, you ignored all of them. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080204000408000509080509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNTIzMTIxMlowIwYJKoZIhvcNAQkEMRYEFP5fmqc/ smgXF0lxVtm/+HzZr8a+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGAvJnLFHJAkAyDS7RcwVqx8mVYSWZvHhYvs9MccA24B9WKr7gMF a1XNW0pdVEYoMcbBEmJ/ALYA40xk59oTRL7JsIySWye/DQObxPB83HEW/jOgU6fxsEmGS4FE DZ+PaYMUWz0W+T0v8TuH1YPVbelSfG6IKLQZ95eoEHVISTzg5wJ8dTGkrvlbwj8WJIcuW4h2 JSgUHru9ragNgix0LdzeC4wTpVNw29c08ahG+p99YfNtnwmM5TvBmt0ZzR7guQFcwLU17tjz uAe7FJ5V4hoFEJhGP/SkKJ87qOsNStdjdB7z2ei5IHuCKd5iVarn94WqtPj/Zh8JWvRQNGWS 2UwAAAAAAAA= --------------ms080204000408000509080509-- From owner-ietf-calendar@mail.imc.org Wed Aug 6 18:41: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 SAA08945 for ; Wed, 6 Aug 2003 18:41:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76MR0qt049230 for ; Wed, 6 Aug 2003 15:27:00 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h76MR0FU049229 for ietf-calendar-bks; Wed, 6 Aug 2003 15:27:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76MQxqt049224 for ; Wed, 6 Aug 2003 15:26:59 -0700 (PDT) (envelope-from kees@osdl.org) Received: (from kees@localhost) by mail.osdl.org (8.11.6/8.11.6) id h76MQus00386 for ietf-calendar@above.proper.com; Wed, 6 Aug 2003 15:26:56 -0700 Date: Wed, 6 Aug 2003 15:26:56 -0700 From: Kees Cook To: ietf-calendar@above.proper.com Subject: cap-11 questions Message-ID: <20030806152656.E13676@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Open Source Development Lab Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello! I just sent a bugzilla bug in with a number of typos and grammar fixes I noted when I read through the CAP draft: http://inet-consulting.com/bugzilla/show_bug.cgi?id=29 In addition to that, I had a few comments and questions... Section 4.2.2: I think the CARID:READBUSYTIMEINFO example would be a better example with "GRANT:*@example.com", which would default to a higher level of privacy, in case anyone implements that CARID directly from the text. Section 10.2: 'The "GENERATE-UID" command returns one or more unique identifiers which MUST BE globally unique.' Is that globally unique to the CS or to the VAGENDA? (Or, did I miss the definition of what "globally" meant?) Has any thought been given to spam control? In my worst nightmares, I can see calendaring becoming as cluttered with spam as regular email. It would be nice to help design in some stronger control over that kind of thing by default. It seems to me that the default permissions for "schedulers" should be "can not send me invites". Can you imagine if spam showed up in your daily calendar in addition to your mail box? :) How is serialization dealt with by the CS? I don't see anything in the draft that talks about having multiple readers and writers of the same VAGENDA. Depending on the VQUERYs sent, it seems that CUA could step on eachother. For example, a CEO and their assistant working on the same item and sending changes at the same time. -- Kees Cook Open Souce Development Lab kees@osdl.org From owner-ietf-calendar@mail.imc.org Wed Aug 6 23:52: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 XAA16462 for ; Wed, 6 Aug 2003 23:52:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h773eRqt061739 for ; Wed, 6 Aug 2003 20:40:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h773eQmT061738 for ietf-calendar-bks; Wed, 6 Aug 2003 20:40:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h773ePqt061722 for ; Wed, 6 Aug 2003 20:40:25 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender)) by comcast.net (sccrmhc13) with SMTP id <2003080703402201600gpgkhe> (Authid: TimHare); Thu, 7 Aug 2003 03:40:22 +0000 Message-Id: <5.2.1.1.0.20030806225717.009edcd0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 06 Aug 2003 23:39:15 -0400 To: "ietf-calendar@imc.org" From: Tim Hare Subject: Re: RECURRENCE-ID discussion In-Reply-To: <3F3039CC.2050101@Royer.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not going to quote all of the discussion about RECURRENCE-ID, but I am going to try to offer a semi-"user" perspective, and perhaps through my ignorance of all the issues, try to obtain some clarity for myself (others' mileage may vary of course). To me, the problem is not necessarily with the RFC, but with the terms used to describe an item on the calendar. Each item has a unique UID, _unless_ it's part of a recurrence set, then they all have the same UID but different RECURRENCE-IDs, as I understand it, so it appears to the uninformed that we have two different uniqueness values for calendar items. This to me as a "user" and sometime-programmer, makes the semantics (if I'm using that term correctly here) confusing at best. What if each and every item on a calendar had a unique identifier, which I am going to call 'X-ID' for this argument to avoid confusion with the others, and items had an optional property called X-RID, which was a recurrence _set_ identifier, but not a uniqueness value for the items. 1. Updating/deleting any one part of a recurrence set would be accomplished using X-ID as the key of that item, which does not change because it uniquely identifies the item (I'm thinking of the calendar store as a "database" and X-ID as the "key" of items in the database). 2. Applying changes to one whole recurrence set would be accomplished by using commands which did not specify an X-ID, but did specify a "filter" consisting of the X-RID. The protocol would require the CS to apply the update to all matching items (UPDATE Fields from CS WHERE X-RID = "some value"). Removing an entire recurrence set would work much the same way. You could even change the recurrence set on all the identifiers matching a certain value, since it would not be a "key" to the calendar store. Now, that makes perfect sense to me from a "layman's" perspective so I'm sure there's something I'm overlooking - but I think part of the problem with the discussion has been trying to make UID and RECURRENCE-ID do the same job - provide the unique identifer for one item in the CS. If we _must_ use these terms, then the uniqueness identifer for an item in a calendar store is really the concatenation of both values, perhaps using NULL as the recurrence identifier for non-recurring items. Then an item is uniquely identified by UID.NULL or UID.RECURRENCE-ID The _combination_ of these values, which is the "key" for the item, shouldn't change (in my opinion) so that the same ID always means the same item. As I said - feel free to point out my errors, I'm relatively new to this... but does this help at all? From owner-ietf-calendar@mail.imc.org Thu Aug 7 01:36:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18784 for ; Thu, 7 Aug 2003 01:36:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h775NTqt066163 for ; Wed, 6 Aug 2003 22:23:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h775NRjP066159 for ietf-calendar-bks; Wed, 6 Aug 2003 22:23:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h775NPqt066153 for ; Wed, 6 Aug 2003 22:23:26 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19kd2o-0005FB-00 for ; Thu, 07 Aug 2003 07:10:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19kcsb-00052p-00 for ; Thu, 07 Aug 2003 07:00:01 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Wed, 6 Aug 2003 22:00:22 -0700 Lines: 178 Message-ID: References: <3F3039CC.2050101@Royer.com> X-Complaints-To: usenet@main.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: [This seemed to have gotten lost in transit so I'm reposting. I apologize if any of you receive it twice.] At the risk of furthering Doug's rather discredited pulpit, but to ensure that I understand what Doug is trying to say, I agree with Bruce that Doug's comment in response to one of Bruce's examples didn't seem to make sense but almost sounded reasonable. So I really thouroughly tried to go through and pick up the context from the mindset of a changing RECURRENCE-ID model. I think I understood what he was trying to say, but when I tried to actually go through and see what messages in a changing RECURRENCE-ID model would like it, I found that using either Doug's or Bruce's interpretation of "original", that the net result was the SEQUENCE: 0 RECURRENCE-ID was always the one to be used. I encourage Doug to please look this over and point any flaws in my logic or understanding of the prose. The argument basically boils down to the fact that in order to end up at a changing RECURRENCE-ID model, the CS or CUA has to take a proactive leap that the prose doesn't tell it to take. Below is what I did that had me arrive at this conclusion. I believe the context for the confusion was the following: " Description: 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. [Snip] 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 "RECURRENCE-ID" property is used in conjunction with the "UID" and "SEQUENCE" property to identify a particular instance of a recurring event, to-do or journal. For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. When the definition of the recurrence set for a calendar component changes, and hence the "SEQUENCE" property value changes, the "RECURRENCE-ID" for a given recurrence instance might also change. [Snip] " To which Bruce declared (slightly modified for clarity): > Some folks seem to blindly ignore the 2nd paragraph above, > (which is the 3rd paragraph in the actual RFC text) > which clearly and unequivocally says that when a reschedule > takes place the RECURRENCE-ID value "is still set to the original" > value! To which Doug responded: Of the one being changed! Not of SEQUENCE:0 - orever. Now I think this means that Doug is trying to say that the RECURRENCE-ID is set to the original value of the instance being modified which with a changing RECURRENCE-ID could be different. But I find it impossible for Doug to support this claim because as far as I can see there is no where in the text that allows one to set a before and after RECURRENCE-ID. So the only way to get a differing RECURRENCE-ID is for CS/CUA to proactively change it on its own accord which the message never specifies to do. If we followed the logic as either Bruce or Doug put it forth we find it impossible to get a changing RECURRENCE-ID: I first create an event: UID: 1 SEQUENCE: 0 RECURRENCE-ID: 20030805T180000Z DTSTART: 20030805T180000Z Now to update this I have to reference it, no one here disagrees that the RECURRENCE-ID used in the SEQUENCE: 1 message will be identical to the SEQUENCE: 0 message. UID: 1 SEQUENCE: 1 RECURRENCE-ID: 20030805T180000Z DTSTART: 20030806T150000Z [For readability sake I'm going to drop the date part of the IDs becuase only times are significant.] So now we go to update it again. If we look at the objects themselves. I specified that SEQUENCE: 1 of UID: 1, RECURRENCE-ID: ...T180000Z would DTSTART at ...T150000Z. Note that no where in this object did I ever say, "oh and by the way here's a new RECURRENCE-ID". So now we go to move it again. Here's where the disagreement is. In a fixed RECURRENCE-ID model the answer is ...T180000Z. In a changing RECURRENCE-ID model the answer is purported to be ...T150000Z but as we will see in a second it is impossible to arrive at that answer without proactive and rather magical intervention on the part of the CS/CUA. We know what Bruce's interpretation says, so for sanity's sake to put this to rest, let's use Doug's. Doug's interpretation says that we use the original RECURRENCE-ID of the instance we are trying to modify. Looking at the instance I'm trying to modify, which is the SEQUENCE: 1 version of the object, I see that the original value of RECURRENCE-ID is ...T180000Z. I didn't tell the CS/CUA to change the RECURRENCE-ID, so unless the CS/CUA did that on its own it will be the value I set it to. Further, unless we redefine the word "original" to mean "CS/CUA modified" (which I don't think any of us could accept) the RECURRENCE-ID of that instance remains ...T180000Z which is also the same as SEQ: 0 by virtue of propogation through SEQ: 1. So the object to update the SEQUENCE: 1 version of the instance must be: UID: 1 SEQUENCE: 2 RECURRENCE-ID: 20030805T180000Z DTSTART: 20030806T210000Z So now I want to change it a third time. We go through the logic again and we see that the original value for RECURRENCE-ID in the SEQUENCE: 2 version of the object is: ...T180000Z Which also happens to be the same as the SEQUENCE: 1 version, which also happens to be the same as the SEQUENCE: 0 version. Which of course leads us to the obvious that, barring some proactive action on the part of the CS/CUA to change the RECURRENCE-ID away from what the object specified, it is impossible to escape using the SEQUENCE: 0 value since that value will be propogated using either Bruce's or Doug's interpretation of paragraph 2 in the definition. -- Michael -- "Doug Royer" wrote in message news:3F3039CC.2050101@Royer.com... > > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > Doug whined on 08/05/2003 04:16:47 PM: > > > And Bruce still does not answer any of the questions or debate > > > any posted soultions... > > > > Clearly you are just playing spoiler attempting to waste cycles. > > No Bruce. I answered all of your questions and you ignored all of mine. > > I proposed solutions to all of your quandaries, you ignored all of them. > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Thu Aug 7 13:50: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 NAA24050 for ; Thu, 7 Aug 2003 13:50:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77HZRqt034702 for ; Thu, 7 Aug 2003 10:35:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77HZRJe034701 for ietf-calendar-bks; Thu, 7 Aug 2003 10:35:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77HZPqt034696 for ; Thu, 7 Aug 2003 10:35:25 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77HXxEB006897 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 10:34:00 -0700 Message-ID: <3F328D81.6020505@Royer.com> Date: Thu, 07 Aug 2003 11:33:53 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F3039CC.2050101@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050906040806080304000309" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050906040806080304000309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > If we followed the logic as either Bruce or Doug put it forth > we find it impossible to get a changing RECURRENCE-ID: > > I first create an event: > > UID: 1 > SEQUENCE: 0 > RECURRENCE-ID: 20030805T180000Z > DTSTART: 20030805T180000Z You can't create that VEVENT. You do not create a VEVENT with a RECURRENCE-ID. Now assuming that you meant that you created a VEVENT with that DTSTART, then later you wanted to refer to that instance of that VEVENT, then that would be the RECURRENCE-ID you would use to refer to that instance. The RECURRENCE-ID is use to refer to an existing instance. > Now to update this I have to reference it, no one here > disagrees that the RECURRENCE-ID used in the SEQUENCE: 1 > message will be identical to the SEQUENCE: 0 message. > > UID: 1 > SEQUENCE: 1 > RECURRENCE-ID: 20030805T180000Z > DTSTART: 20030806T150000Z > > [For readability sake I'm going to drop the date part of > the IDs becuase only times are significant.] > > So now we go to update it again. If we look at the objects > themselves. I specified that SEQUENCE: 1 of UID: 1, > RECURRENCE-ID: ...T180000Z would DTSTART at ...T150000Z. > Note that no where in this object did I ever say, "oh and > by the way here's a new RECURRENCE-ID". So now we go > to move it again. Here's where the disagreement is. You do not need to say 'oh and by the way here's a new RECURRENCE-ID' because iCAL says: Purpose: This property is used in conjunction with the "UID" and "SEQUENCE" property to identify a specific instance of a recurring "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property value is the effective value of the "DTSTART" property of the recurrence instance. So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID for that single instance object SEQUENCE:1 is the effective value of the "DTSTART" property - ...T150000Z and not ..T180000Z. So after that point if you do an update to RECURRENEC-ID ..T180000Z, there would be no object with that effective DTSTART date and thus no RECURRENCE-ID to match. In Bruces model you can NEVER add someone to the series of recurring VEVENT after any change that effects the effective DTSTART value of any instance as they could never be able to resolve the RECURRENCE-ID because they never had SEQUENCE:0. For a single VEVENT REQUEST with three instance (COUNT=3 in a RRULE). It has three RECURRENCE-ID's none of which were ever explicitly created. So if the original REQUEST looks like this: METHOD:REQUEST SEQUENCE:0 DTSTART:20030805T180000Z RRULE:FREQ=HOURLY;COUNT=3 LOCATION:A Would have 3 RECURRENCE-ID's: ...T180000Z 1st instance (effective DTSTART) ...T190000Z 2nd instance (effective DTSTART) ...T200000Z 3rd instance (effective DTSTART) So now the ORGANIZER wants to change the 2nd instance to ..T193000Z. So per iTIP they could send a new REQUEST SEQUENCE:1 : METHOD:REQUEST SEQUENCE:1 DTSTART:..T193000Z RECURRNCE-ID:..T190000Z So once the CUA accepts the new SEQUENCE:1 object, the object still has three RECURRENCE-ID's: ...T180000Z 1st instance (effective DTSTART) ...T193000Z 2nd instance (effective DTSTART) ...T200000Z 3rd instance (effective DTSTART) As the RECURRENCE-ID is the effective DTSTART value of the instance. Now change the 3rd instance of the SEQUENCE:1 object to ...T190000Z and move its LOCATION to 'B'. METHOD:REQUEST SEQUENCE:2 DTSTART:..T200000Z RECURRNCE-ID:..T190000Z LOCATION:B So once the CUA accepts the new SEQUENCE:2 object, the object still has three RECURRENCE-ID's (new effective DTSTART times): ...T180000Z 1st instance (effective DTSTART) ...T190000Z 2nd instance (effective DTSTART) (used to be the 3rd instance) ...T193000Z 3rd instance (effective DTSTART) (used to be the 2nd instance) Now change the SEQUENCE:2 2nd instance to ...T200000Z: METHOD:REQUEST SEQUENCE:3 DTSTART:..T190000Z RECURRNCE-ID:..T200000Z Now in Bruce's model, your broken because you just moved the SEQUENCE:0, LOCATION:A meeting to ...T200000Z to LOCATION:A. When in fact the move was to move the LOCAION:B meeting. Bruce's reply is to throw the object away and start over because its impossible to resolve. > Now I think this means that Doug is trying to say that > the RECURRENCE-ID is set to the original value of the instance > being modified which with a changing RECURRENCE-ID could be > different. But I find it impossible for Doug to support > this claim because as far as I can see there is no where in > the text that allows one to set a before and after RECURRENCE-ID. > So the only way to get a differing RECURRENCE-ID is for CS/CUA > to proactively change it on its own accord which the message > never specifies to do. You do not change RECURRENCE-ID's directly. You update the object in ways that alter the effective DTSTART value for an instance. And as its effective DTSTART value is changed, thus its RECRRENCE-ID changes to match its effective DTSTART value. And: (iTIP) An instance of a recurring event is assigned a unique identification, "RECURRENCE-ID" property, when that instance is renegotiated. Negotiation may be necessary when a substantive change to the event or to-do has be made (such as changing the start time, end time, due date or location). The "Organizer" can identify a specific recurrence instance using the "RECURRENCE-ID" property. The property value is equal to the date/time of the instance. If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. Note that after the change has occurred, the "RECURRENCE-ID" has changed to the new "DTSTART" value. You do not 'set' the 'before' and 'after' RECURRENCE-ID, you alter the effective DTSTART directly by updating one or more instances and the RECURRENCE-ID is defined to match the new effective DSTART. Another way to change the RECURRENCE-ID's is to alter the times an existing VEVENT. So if the SEQUENCE:0 object were: METHOD:REQUEST SEQUENCE:0 DTSTART:20030805T180000Z RRULE:FREQ=HOURLY;COUNT=3 LOCATION:A Would have 3 RECURRENCE-ID's: ...T180000Z 1st instance (effective DTSTART) ...T190000Z 2nd instance (effective DTSTART) ...T200000Z 3rd instance (effective DTSTART) If the ORGANIZER sent a SEQUENCE:1 : METHOD:REQUEST SEQUENCE:1 DTSTART:20030805T180000Z (same as the SEQUENCE:0 value) RRULE:FREQ=HOURLY;COUNT=3;INTERVAL=2 LOCATION:A The SEQUENCE:1 object would 3 RECURRENCE-ID's 2 of which are different than the SEQUENEC:0 object: ...T180000Z 1st instance (effective DTSTART) ...T200000Z 2nd instance (effective DTSTART) ...T220000Z 3rd instance (effective DTSTART) The ORGANIZER moved two instances and their effective DTSTART values (RECURRENCE-ID). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050906040806080304000309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzE3MzM1NFowIwYJKoZIhvcNAQkEMRYEFOykhSeg /8SD901irAJeli3jHyxtMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBACcQgzgCSD2oAKM9kLGSHfOLippI5rco8lgrK6egnvP60uEnzUKm PKqw0uutDW+S/orHerGSNX6Uu1sDOjfxopxeUmxcvdjSkfHM2JCB5tTBenMQMb9IO+n8vcp4 wM8uwpepUq/JDXSVsfWVJZ2qzmeBuy9Wu1q4ZUsFxO5/LKRv8UGXj2ccJ6sblS8ShGdoQ2wR EzCMTocB1cYB0vVC+v3+6NZjj6lhlKspEE0ITn9E/JFOZatOXoW8KJScbH9AWQAUPyY1Rayi eKSUBA57k9NRrGcWzxf/xXIaryKTfZT3i87/gdfJ192jta+cl3tMsOBmlho8PizwMTPQI9G4 FXIAAAAAAAA= --------------ms050906040806080304000309-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 14:23:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25558 for ; Thu, 7 Aug 2003 14:23:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77IGFqt036291 for ; Thu, 7 Aug 2003 11:16:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77IGFCE036290 for ietf-calendar-bks; Thu, 7 Aug 2003 11:16:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77IGEqt036285 for ; Thu, 7 Aug 2003 11:16:14 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h77IGFx8026918 for ; Thu, 7 Aug 2003 12:16:15 -0600 (MDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h77IGFaJ002133 for ; Thu, 7 Aug 2003 11:16:15 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJ900EQCHF396@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Thu, 07 Aug 2003 11:16:15 -0700 (PDT) Date: Thu, 07 Aug 2003 18:16:16 +0000 From: Satya Vempati Subject: RE: RECURRENCE-ID discussion To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-language: en-USA Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id h77IGEqt036286 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Doug Royer wrote: <> Unless I am missing something, from the ABNF of VEVENT, VEVENT can have a recurid. ------------------------------------------- eventprop = *( ; the following are optional, ; but MUST NOT occur more than once class / created / description / dtstart / geo / last-mod / location / organizer / priority / dtstamp / seq / status / summary / transp / uid / url / recurid / ; either ’dtend’ or ’duration’ may appear in ; a ’eventprop’, but ’dtend’ and ’duration’ ; MUST NOT occur in the same ’eventprop’ dtend / duration / ; the following are optional, ; and MAY occur more than once attach / attendee / categories / comment / contact / exdate / exrule / rstatus / related / resources / rdate / rrule / x-prop ) -----Original Message----- From: Doug Royer [mailto:Doug@royer.com] Sent: Thursday, August 07, 2003 5:34 PM To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion Michael Fair wrote: > If we followed the logic as either Bruce or Doug put it forth > we find it impossible to get a changing RECURRENCE-ID: > > I first create an event: > > UID: 1 > SEQUENCE: 0 > RECURRENCE-ID: 20030805T180000Z > DTSTART: 20030805T180000Z You can't create that VEVENT. You do not create a VEVENT with a RECURRENCE-ID. Now assuming that you meant that you created a VEVENT with that DTSTART, then later you wanted to refer to that instance of that VEVENT, then that would be the RECURRENCE-ID you would use to refer to that instance. The RECURRENCE-ID is use to refer to an existing instance. > Now to update this I have to reference it, no one here > disagrees that the RECURRENCE-ID used in the SEQUENCE: 1 > message will be identical to the SEQUENCE: 0 message. > > UID: 1 > SEQUENCE: 1 > RECURRENCE-ID: 20030805T180000Z > DTSTART: 20030806T150000Z > > [For readability sake I'm going to drop the date part of > the IDs becuase only times are significant.] > > So now we go to update it again. If we look at the objects > themselves. I specified that SEQUENCE: 1 of UID: 1, > RECURRENCE-ID: ...T180000Z would DTSTART at ...T150000Z. > Note that no where in this object did I ever say, "oh and > by the way here's a new RECURRENCE-ID". So now we go > to move it again. Here's where the disagreement is. You do not need to say 'oh and by the way here's a new RECURRENCE-ID' because iCAL says: Purpose: This property is used in conjunction with the "UID" and "SEQUENCE" property to identify a specific instance of a recurring "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property value is the effective value of the "DTSTART" property of the recurrence instance. So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID for that single instance object SEQUENCE:1 is the effective value of the "DTSTART" property - ...T150000Z and not ..T180000Z. So after that point if you do an update to RECURRENEC-ID ..T180000Z, there would be no object with that effective DTSTART date and thus no RECURRENCE-ID to match. In Bruces model you can NEVER add someone to the series of recurring VEVENT after any change that effects the effective DTSTART value of any instance as they could never be able to resolve the RECURRENCE-ID because they never had SEQUENCE:0. For a single VEVENT REQUEST with three instance (COUNT=3 in a RRULE). It has three RECURRENCE-ID's none of which were ever explicitly created. So if the original REQUEST looks like this: METHOD:REQUEST SEQUENCE:0 DTSTART:20030805T180000Z RRULE:FREQ=HOURLY;COUNT=3 LOCATION:A Would have 3 RECURRENCE-ID's: ...T180000Z 1st instance (effective DTSTART) ...T190000Z 2nd instance (effective DTSTART) ...T200000Z 3rd instance (effective DTSTART) So now the ORGANIZER wants to change the 2nd instance to ..T193000Z. So per iTIP they could send a new REQUEST SEQUENCE:1 : METHOD:REQUEST SEQUENCE:1 DTSTART:..T193000Z RECURRNCE-ID:..T190000Z So once the CUA accepts the new SEQUENCE:1 object, the object still has three RECURRENCE-ID's: ...T180000Z 1st instance (effective DTSTART) ...T193000Z 2nd instance (effective DTSTART) ...T200000Z 3rd instance (effective DTSTART) As the RECURRENCE-ID is the effective DTSTART value of the instance. Now change the 3rd instance of the SEQUENCE:1 object to ...T190000Z and move its LOCATION to 'B'. METHOD:REQUEST SEQUENCE:2 DTSTART:..T200000Z RECURRNCE-ID:..T190000Z LOCATION:B So once the CUA accepts the new SEQUENCE:2 object, the object still has three RECURRENCE-ID's (new effective DTSTART times): ...T180000Z 1st instance (effective DTSTART) ...T190000Z 2nd instance (effective DTSTART) (used to be the 3rd instance) ...T193000Z 3rd instance (effective DTSTART) (used to be the 2nd instance) Now change the SEQUENCE:2 2nd instance to ...T200000Z: METHOD:REQUEST SEQUENCE:3 DTSTART:..T190000Z RECURRNCE-ID:..T200000Z Now in Bruce's model, your broken because you just moved the SEQUENCE:0, LOCATION:A meeting to ...T200000Z to LOCATION:A. When in fact the move was to move the LOCAION:B meeting. Bruce's reply is to throw the object away and start over because its impossible to resolve. > Now I think this means that Doug is trying to say that > the RECURRENCE-ID is set to the original value of the instance > being modified which with a changing RECURRENCE-ID could be > different. But I find it impossible for Doug to support > this claim because as far as I can see there is no where in > the text that allows one to set a before and after RECURRENCE-ID. > So the only way to get a differing RECURRENCE-ID is for CS/CUA > to proactively change it on its own accord which the message > never specifies to do. You do not change RECURRENCE-ID's directly. You update the object in ways that alter the effective DTSTART value for an instance. And as its effective DTSTART value is changed, thus its RECRRENCE-ID changes to match its effective DTSTART value. And: (iTIP) An instance of a recurring event is assigned a unique identification, "RECURRENCE-ID" property, when that instance is renegotiated. Negotiation may be necessary when a substantive change to the event or to-do has be made (such as changing the start time, end time, due date or location). The "Organizer" can identify a specific recurrence instance using the "RECURRENCE-ID" property. The property value is equal to the date/time of the instance. If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. Note that after the change has occurred, the "RECURRENCE-ID" has changed to the new "DTSTART" value. You do not 'set' the 'before' and 'after' RECURRENCE-ID, you alter the effective DTSTART directly by updating one or more instances and the RECURRENCE-ID is defined to match the new effective DSTART. Another way to change the RECURRENCE-ID's is to alter the times an existing VEVENT. So if the SEQUENCE:0 object were: METHOD:REQUEST SEQUENCE:0 DTSTART:20030805T180000Z RRULE:FREQ=HOURLY;COUNT=3 LOCATION:A Would have 3 RECURRENCE-ID's: ...T180000Z 1st instance (effective DTSTART) ...T190000Z 2nd instance (effective DTSTART) ...T200000Z 3rd instance (effective DTSTART) If the ORGANIZER sent a SEQUENCE:1 : METHOD:REQUEST SEQUENCE:1 DTSTART:20030805T180000Z (same as the SEQUENCE:0 value) RRULE:FREQ=HOURLY;COUNT=3;INTERVAL=2 LOCATION:A The SEQUENCE:1 object would 3 RECURRENCE-ID's 2 of which are different than the SEQUENEC:0 object: ...T180000Z 1st instance (effective DTSTART) ...T200000Z 2nd instance (effective DTSTART) ...T220000Z 3rd instance (effective DTSTART) The ORGANIZER moved two instances and their effective DTSTART values (RECURRENCE-ID). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Thu Aug 7 15:41: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 PAA29726 for ; Thu, 7 Aug 2003 15:41:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77JX2qt041333 for ; Thu, 7 Aug 2003 12:33:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77JX2eM041332 for ietf-calendar-bks; Thu, 7 Aug 2003 12:33:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77JX1qt041327 for ; Thu, 7 Aug 2003 12:33:01 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F328D81.6020505@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Aug 2003 15:26:06 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 03:32:52 PM, Serialize complete at 08/07/2003 03:32:52 PM Content-Type: multipart/alternative; boundary="=_alternative 006A91F785256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A91F785256D7B_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 08/07/2003 01:33:53 PM: > > I first create an event: > > > > UID: 1 > > SEQUENCE: 0 > > RECURRENCE-ID: 20030805T180000Z > > DTSTART: 20030805T180000Z [Snip] > The RECURRENCE-ID is use to refer to an existing instance. Umm, we never said that in 2445. In fact, if you create the instances at SEQUENCE:0 then by definition you are gonna be creating the RECURRENCE-IDs at that time too... You dont create the instance in the set w/o assigning RECURRENCE-IDs otherwise you wont be able to match REPLYs to particular instances until you reschedule them (to SEQUENCE:1). Also, that was a perfectly valid iTIP fragment for a SEQUENCE:0 REQUEST for a particular instance. After all its referring to a particular instance and iTIP has the restriction table of: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. and since its referring to an instnace of a recurring component, it MUST be there... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006A91F785256D7B_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 08/07/2003 01:33:53 PM:
> > I first create an event:
> >
> > UID: 1
> > SEQUENCE: 0
> > RECURRENCE-ID: 20030805T180000Z
> > DTSTART: 20030805T180000Z
[Snip]
> The RECURRENCE-ID is use to refer to an existing instance.
Umm, we never said that in 2445.  In fact, if you create the instances at SEQUENCE:0 then by definition you are gonna be creating the RECURRENCE-IDs at that time too...  You dont create the instance in the set w/o assigning RECURRENCE-IDs otherwise you wont be able to match REPLYs to particular instances until you reschedule them (to SEQUENCE:1).

Also, that was a perfectly valid iTIP fragment for a SEQUENCE:0 REQUEST for a particular instance.  After all its referring to a particular instance and iTIP has the restriction table of:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise it
                           MUST NOT be present.
and since its referring to an instnace of a recurring component, it MUST be there...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006A91F785256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 15:49: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 PAA29991 for ; Thu, 7 Aug 2003 15:49:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77JgHqt041585 for ; Thu, 7 Aug 2003 12:42:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77JgHQh041584 for ietf-calendar-bks; Thu, 7 Aug 2003 12:42:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77JgFqt041577 for ; Thu, 7 Aug 2003 12:42:15 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77JgEEB007828 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 12:42:15 -0700 Message-ID: <3F32AB90.6030908@Royer.com> Date: Thu, 07 Aug 2003 13:42:08 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090508060008000408020509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090508060008000408020509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: > Doug Royer wrote: > > < with a RECURRENCE-ID.>> > > > Unless I am missing something, from the ABNF of VEVENT, VEVENT can have a > recurid. .... Yes and if it were not in the ABNF, you could never use RECURRENCE-ID in a VEVENT. The ABNF does not mean that all options are always valid. The iTIP restriction table for a PUBLISH and REQUEST says: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. So, when creating a new VEVENT you can not be referring to an instance that does not yet exist. As soon as the object exists it has an implied RECURRENCE-ID for each effective DTSTART of each instance. The RECURRENCE-ID property is used to indicate which instance in a recurring set the object is referring. The only times that RECURRENCE-ID can exist in a VEVENT is: When REPLYing to an existing instance and if present indicates that the sender is only replying to that named instance. Updating an existing instance in an existing recurrence set. CANCELing an instance in an existing recurrence set. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090508060008000408020509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MDcxOTQyMDhaMCMGCSqGSIb3DQEJBDEWBBRB Om/inmBXSzt+0ij3pugVjgBbSTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQANHXzktPLCIfrrF6z7cjOp/VQRKwXpG4iRE4NeKuR4qPe2 kJMFxatcvpfVOjNlAzquJMcFgUMlv2F/86LpEearunvBGeVVDNHOqt8YBogazSKpe/A5PWoL SkAJF35XhGNXu+TABdzEuo0dGCEBbJ5gQslA+cJa0cQrcSbofUuAhK2h5I/048+eVbv4Xram ORqpYTFGjmG/fM2/VJRvavxkFms/7PAByBkIzOsI5sDWaD88BbZB6y88Ua9PsAv+YL1TYHaT GDo84qudd6Y6RpUQ7uvZA8KUQitdyeypE4M0KaK0WeYarXeK30Jn61P7o2EtBRV/TiVylg9z /Zcnu85ZAAAAAAAA --------------ms090508060008000408020509-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 15:50:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00043 for ; Thu, 7 Aug 2003 15:50:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77JhVqt041624 for ; Thu, 7 Aug 2003 12:43:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77JhVAs041623 for ietf-calendar-bks; Thu, 7 Aug 2003 12:43:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77JhUqt041613 for ; Thu, 7 Aug 2003 12:43:31 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F328D81.6020505@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Aug 2003 15:42:52 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 03:43:22 PM, Serialize complete at 08/07/2003 03:43:22 PM Content-Type: multipart/alternative; boundary="=_alternative 006C1AD585256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C1AD585256D7B_= Content-Type: text/plain; charset="US-ASCII" Dogu replied on 08/07/2003 01:33:53 PM: > You do not need to say 'oh and by the way here's a new RECURRENCE-ID' > because iCAL says: > > Purpose: This property is used in conjunction with the "UID" and > "SEQUENCE" property to identify a specific instance of a recurring > "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property > value is the effective value of the "DTSTART" property of the > recurrence instance. > > So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID > for that single instance object SEQUENCE:1 is the effective value > of the "DTSTART" property - ...T150000Z and not ..T180000Z. Show us where iCalendar says that the RECURRENCE-ID values are assigned at SEQUENCE:1. If you create the set at SEQUENCE:0 then the id would have to be assigned at that time, not after a rescheduling of that instance. > In Bruces model you can NEVER add someone to the series > of recurring VEVENT after any change that effects the > effective DTSTART value Huh?? You are really not getting the fixed model I think. If the RECURRENCE-IDs used never change then adding someone is no big deal. Take a look... If for some reason I wanted to add you to an instance of: UID: 1 SEQUENCE: 10 RECURRENCE-ID: 20030805T180000Z DTSTART: 20030816T150000Z then I send you just that. Your REPLY would use the same UID / RECURRENCE-ID / SEQUENCE value that someone who is aready invited would and we would all be on the same page. Where is it broken?? > of any instance as they could never > be able to resolve the RECURRENCE-ID because they never > had SEQUENCE:0. So?? The value is the same at SEQUENCE:10 as it is as SEQUENCE:0. If you correctly apply the iTIP Section 3.2.2 REQUEST rules: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. then you would treat it as a new invitation (which it is) to UID:1 / RECURRENCE-ID:20030805T180000Z / SEQUENCE:10 and that info comes back in your REPLY reflecting your response. It does not matter that you never saw the SEQUENCE 0 thru 9 versions, the SEQUENCE:10 version obsoletes them anyway. If I had invited you at SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can correctly apply the iTIP message sequencing rules to detect that the message is obsolete and thus you ignore it (and the missequenced 9 too). Now, if the RECURRENCE-ID value changed on each reschedule (along with SEQUENCE) then when you get UID:1 / RECURRENCE-ID:20030815T190000Z / SEQUENCE:8 you have no way to accurate match this REQUEST to the instance you already have since the UID / RECURRENCE-ID primary key matches nothing you have. As such, you would mistakenly treat this stale REQUEST as a new invitation to a different instance. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006C1AD585256D7B_= Content-Type: text/html; charset="US-ASCII"
Dogu replied on 08/07/2003 01:33:53 PM:
> You do not need to say 'oh and by the way here's a new RECURRENCE-ID'
> because iCAL says:
>
>     Purpose: This property is used in conjunction with the "UID" and
>     "SEQUENCE" property to identify a specific instance of a recurring
>     "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
>     value is the effective value of the "DTSTART" property of the
>     recurrence instance.
>
> So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID
> for that single instance object SEQUENCE:1 is the effective value
> of the "DTSTART" property - ...T150000Z and not ..T180000Z.
Show us where iCalendar says that the RECURRENCE-ID values are assigned at SEQUENCE:1.  If you create the set at SEQUENCE:0 then the id would have to be assigned at that time, not after a rescheduling of that instance.

> In Bruces model you can NEVER add someone to the series
> of recurring VEVENT after any change that effects the
> effective DTSTART value

Huh??  You are really not getting the fixed model I think.  If the RECURRENCE-IDs used never change then adding someone is no big deal.  Take a look...

If for some reason I wanted to add you to an instance of:

UID: 1
SEQUENCE: 10
RECURRENCE-ID: 20030805T180000Z
DTSTART: 20030816T150000Z
then I send you just that.  Your REPLY would use the same UID / RECURRENCE-ID / SEQUENCE value that someone who is aready invited would and we would all be on the same page.  Where is it broken??

>                   of any instance as they could never
> be able to resolve the RECURRENCE-ID because they never
> had SEQUENCE:0.
So??  The value is the same at SEQUENCE:10 as it is as SEQUENCE:0.  If you correctly apply the iTIP Section 3.2.2 REQUEST rules:

   The "UID" and "SEQUENCE" properties are used to distinguish the
  various uses of the "REQUEST" method. If the "UID" property value in
  the "REQUEST" is not found on the recipient's calendar, then the
  "REQUEST" is for a new "VEVENT" calendar component.

then you would treat it as a new invitation (which it is) to UID:1 / RECURRENCE-ID:20030805T180000Z / SEQUENCE:10 and that info comes back in your REPLY reflecting your response.  

It does not matter that you never saw the SEQUENCE 0 thru 9 versions, the SEQUENCE:10 version obsoletes them anyway.  If I had invited you at SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can correctly apply the iTIP message sequencing rules to detect that the message is obsolete and thus you ignore it (and the missequenced 9 too).

Now, if the RECURRENCE-ID value changed on each reschedule (along with SEQUENCE) then when you get UID:1 / RECURRENCE-ID:20030815T190000Z / SEQUENCE:8 you have no way to accurate match this REQUEST to the instance you already have since the UID / RECURRENCE-ID primary key matches nothing you have.  As such, you would mistakenly treat this stale REQUEST as a new invitation to a different instance.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006C1AD585256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 16:04: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 QAA00466 for ; Thu, 7 Aug 2003 16:04:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Jteqt042458 for ; Thu, 7 Aug 2003 12:55:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77JteHA042457 for ietf-calendar-bks; Thu, 7 Aug 2003 12:55:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Jtcqt042452 for ; Thu, 7 Aug 2003 12:55:38 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77JtbEB007945 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 12:55:39 -0700 Message-ID: <3F32AEB4.3030707@Royer.com> Date: Thu, 07 Aug 2003 13:55:32 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070203030008080902080908" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070203030008080902080908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > ... then by definition you are gonna be creating the > RECURRENCE-IDs at that time too... We agree, you can not create a VEVENT with a RECURRENCE-ID property in it. > Also, that was a perfectly valid iTIP fragment for a SEQUENCE:0 REQUEST > for a particular instance. After all its referring to a particular > instance and iTIP has the restriction table of: He actually said: "I first create an event: UID: 1 SEQUENCE: 0 RECURRENCE-ID: 20030805T180000Z DTSTART: 20030805T180000Z ..." And you can not create a VEVENT with a RECURRENCE-ID property in it. > RECURRENCE-ID 0 or 1 only if referring to an instance of a > recurring calendar component. Otherwise it > MUST NOT be present. > > and since its referring to an instnace of a recurring component, it MUST > be there... For REPLY, Single instance update, moving an instance, canceling and instance, but not creating a recurrence set even when the recurrence set has only one instance. This was covered by Frank/Steve on this list as part of the pre-iTIP debates. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070203030008080902080908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzE5NTUzMlowIwYJKoZIhvcNAQkEMRYEFGLV/Zho xHz4/fVqsj3L6JWtztsCMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAKqc6HAZVWxFFxu6+6j5sjdUWLCPMHpSWpsOFT6De8Eom4jNQM28 DAinhIMKdN/967gxfMN6EjWHGiDvIYFJFwWLO+cVUh3uVHJVaslmvgBqANCd1Kb/6PgzlXgE qgS3ZFzr374zT3hQeegz07+4Sn81V8jrtrDpNo865ud20WhD3KmpdYvLpy8ygj4v0rdzYuCq uhwL1CowoMbX/yoynd4XkfqkCzdFbJa1o80VHwKOP494HMwoUmVkAcvoAJBXbolI/bjVEbFa aEIAMcI9hL6NP6ngNSYj/jql76cZRQ2+XdxstDbUhJgROSmy+ht/WEtbKGOpJEtsYCfs5bSD WqsAAAAAAAA= --------------ms070203030008080902080908-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 16:17: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 QAA00953 for ; Thu, 7 Aug 2003 16:17:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77K9gqt042870 for ; Thu, 7 Aug 2003 13:09:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77K9gs3042869 for ietf-calendar-bks; Thu, 7 Aug 2003 13:09:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77K9eqt042864 for ; Thu, 7 Aug 2003 13:09:41 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77K9dEB008131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 13:09:41 -0700 Message-ID: <3F32B1FE.2040403@Royer.com> Date: Thu, 07 Aug 2003 14:09:34 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060805080805090005090801" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060805080805090005090801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Dogu replied on 08/07/2003 01:33:53 PM: > > You do not need to say 'oh and by the way here's a new RECURRENCE-ID' > > because iCAL says: > > > > Purpose: This property is used in conjunction with the "UID" and > > "SEQUENCE" property to identify a specific instance of a recurring > > "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property > > value is the effective value of the "DTSTART" property of the > > recurrence instance. > > > > So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID > > for that single instance object SEQUENCE:1 is the effective value > > of the "DTSTART" property - ...T150000Z and not ..T180000Z. > > Show us where iCalendar says that the RECURRENCE-ID values are assigned > at SEQUENCE:1. If you create the set at SEQUENCE:0 then the id would > have to be assigned at that time, not after a rescheduling of that > instance. Show me anywhere where in any RFC it says you can ignore: (iCAL) ...When the definition of the recurrence set for a calendar component changes, and hence the "SEQUENCE" property value changes, the "RECURRENCE-ID" for a given recurrence instance might also change. ... If you change just the LOCATION for example the RECURRENCE-ID does not CHANGE even when the SEQUENCE changes. If you change the effective DTSTART value for a given recurrence instance (THE RECURRENCE-ID for that instance), then the RECURRECE-ID changes. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060805080805090005090801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIwMDkzNFowIwYJKoZIhvcNAQkEMRYEFC1fb7lF rxRs/nljCUHwTFWdgsitMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBALiJnAqEhsCFdrWURikHrMgNg2IsmbHZa2iPtXXQFOU0w2NNf/Ev eqR4R9yt0/3fZmTZo9laCUaAJURrAlsvPHaMWC2sZYuZp3GlVTkBtoZV4hI0CljzV2AD/bGr +2Roi2s150O91MjiKX8cgH1Pn4vPaYFbf5+FiXB0IrC9cDZ4+A+9Yr81JSSU62+wIsZQyU/5 4ojqQrxDI9wLJ/dVDGUNeXF3z84z4wOU+XZGfGZB1VqNbjULG/qaoYWUTpUa3MS5/JDaK2/N en7m09iTh5c0rnsjwkP2jLKE6fXQafZfw9YDcahEV36HhQ+OB+m97XWBnw70BQ1PrP3m2uSM VqkAAAAAAAA= --------------ms060805080805090005090801-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 16:18: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 QAA00989 for ; Thu, 7 Aug 2003 16:18:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77KB4qt042937 for ; Thu, 7 Aug 2003 13:11:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77KB3XH042936 for ietf-calendar-bks; Thu, 7 Aug 2003 13:11:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77KB2qt042930 for ; Thu, 7 Aug 2003 13:11:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77KAxEB008154 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 13:11:03 -0700 Message-ID: <3F32B24E.6080506@Royer.com> Date: Thu, 07 Aug 2003 14:10:54 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060100080604020802030905" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060100080604020802030905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > In Bruces model you can NEVER add someone to the series > > of recurring VEVENT after any change that effects the > > effective DTSTART value > > Huh?? You are really not getting the fixed model I think. If the > RECURRENCE-IDs used never change then adding someone is no big deal. > Take a look... > > If for some reason I wanted to add you to an instance of: > > UID: 1 > SEQUENCE: 10 > RECURRENCE-ID: 20030805T180000Z > DTSTART: 20030816T150000Z > > then I send you just that. Your REPLY would use the same UID / > RECURRENCE-ID / SEQUENCE value that someone who is aready invited would > and we would all be on the same page. Where is it broken?? That example of mine was NOT to a single instance - what's your point? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060100080604020802030905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIwMTA1NFowIwYJKoZIhvcNAQkEMRYEFE2Jh9Wi emllp4z+k3V3uBOE/nCCMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAFk9GpP6zT6UdAIACk5xa9kpdWxM75bXg6knBnqAJeBFc7sjIyRp 2f4VM9UXG8m3pdjwrxv6MaMklxS6zIbVlKWWBW/+6oldDYA1MWvlBmSn0fnoybUNT5+V+SiS /wdG3l6N3SYbxOmXOwNPtmgJ1xPs+CdfaK5nDzLTm2GnfZMr4AwDHSFv6sKUyoIYQ6wwf98L +rmA5+UfgXBUW5585v+Gg/oqnEBKfEFcPmTvi26J6RPut4C/+eqM9rYlwowCuE/SovXr9Kif YWpWwZr+EI9e6nXZzV/U9O9w2reiSiBuAv47sD2pMNn22ehaoPia34gYs8EhPY5PGVDiHJmF 3zYAAAAAAAA= --------------ms060100080604020802030905-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 16:22: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 QAA01131 for ; Thu, 7 Aug 2003 16:22:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77KCdqt043019 for ; Thu, 7 Aug 2003 13:12:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77KCdnk043018 for ietf-calendar-bks; Thu, 7 Aug 2003 13:12:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77KCbqt043013 for ; Thu, 7 Aug 2003 13:12:37 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77KCbEB008171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 13:12:38 -0700 Message-ID: <3F32B2AF.8070309@Royer.com> Date: Thu, 07 Aug 2003 14:12:31 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030406010106020607000703" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030406010106020607000703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > > of any instance as they could never > > be able to resolve the RECURRENCE-ID because they never > > had SEQUENCE:0. > > So?? The value is the same at SEQUENCE:10 as it is as SEQUENCE:0. If > you correctly apply the iTIP Section 3.2.2 REQUEST rules: Not in the example provied if you read the entire email. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030406010106020607000703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIwMTIzMVowIwYJKoZIhvcNAQkEMRYEFE1bUN4L 7vb324+kITZWRvH2rVIyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBALvTaa1Yvo5A667w6CsoAbFNOoP2yWJMxqJmLIJtYh1XwkVGKMgq A/BFn52KPpZg6g6ILbiH94Xi+PR93+Cj8GfIR775T1eO5wy84NR3cUChDDZqMJd1l3mFgYm6 rkBHOGONuHgmCD6nkMlNClJFIQRwpVcZ6BaFRL39PB0TpS/umCQFR33R9o3ax0sNQqk5kmOh 2FrL4b42JMiy4iyGPtDze5ESw3dHVPBieIlCZCLvBfnWDe2V59bXivZPTAt7lMRngqpHwMFY s4w0gpVXHPKepGk54JKdAKSCuq9QNW55aT4u+JmU1c+1utIElcQHqIb+gl2KuQ7FinbNtV2e gYQAAAAAAAA= --------------ms030406010106020607000703-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 16:27: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 QAA01324 for ; Thu, 7 Aug 2003 16:27:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77KJdqt043264 for ; Thu, 7 Aug 2003 13:19:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77KJdlY043263 for ietf-calendar-bks; Thu, 7 Aug 2003 13:19:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77KJcqt043253 for ; Thu, 7 Aug 2003 13:19:38 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32AB90.6030908@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Aug 2003 16:17:24 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 04:19:27 PM, Serialize complete at 08/07/2003 04:19:27 PM Content-Type: multipart/alternative; boundary="=_alternative 006F440885256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F440885256D7B_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 08/07/2003 03:42:08 PM: > So, when creating a new VEVENT you can not be referring to an instance > that does not yet exist. As soon as the object exists it has an > implied RECURRENCE-ID for each effective DTSTART of each instance. And so after Ive created it in my calendar (at SEQUENCE:0) I can then invite Satay to a particular instance only by using its RECURRENCE-ID in the REQUEST. > The only times that RECURRENCE-ID can exist in a VEVENT is: > > When REPLYing to an existing instance and if present indicates > that the sender is only replying to that named instance. > > Updating an existing instance in an existing recurrence set. > > CANCELing an instance in an existing recurrence set. Umm, you forgot inviting someone initially to an instance of a recurrence set. REPLY is them responding to it, not my initial REQUEST where its perfectly valid (and necessary). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F440885256D7B_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 08/07/2003 03:42:08 PM:
> So, when creating a new VEVENT you can not be referring to an instance
> that does not yet exist. As soon as the object exists it has an
> implied RECURRENCE-ID for each effective DTSTART of each instance.
And so after Ive created it in my calendar (at SEQUENCE:0) I can then invite Satay to a particular instance only by using its RECURRENCE-ID in the REQUEST.

> The only times that RECURRENCE-ID can exist in a VEVENT is:
>
>     When REPLYing to an existing instance and if present indicates
>     that the sender is only replying to that named instance.
>
>     Updating an existing instance in an existing recurrence set.
>
>     CANCELing an instance in an existing recurrence set.
Umm, you forgot inviting someone initially to an instance of a recurrence set.  REPLY is them responding to it, not my initial REQUEST where its perfectly valid (and necessary).
Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006F440885256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 16:44: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 QAA01918 for ; Thu, 7 Aug 2003 16:44:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77KZHqt044768 for ; Thu, 7 Aug 2003 13:35:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77KZH6L044767 for ietf-calendar-bks; Thu, 7 Aug 2003 13:35:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77KZFqt044759 for ; Thu, 7 Aug 2003 13:35:16 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77KZEEB008345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 13:35:16 -0700 Message-ID: <3F32B7FD.5090701@Royer.com> Date: Thu, 07 Aug 2003 14:35:09 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040706050300020203010701" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040706050300020203010701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > It does not matter that you never saw the SEQUENCE 0 thru 9 versions, > the SEQUENCE:10 version obsoletes them anyway. If I had invited you at > SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can > correctly apply the iTIP message sequencing rules to detect that the > message is obsolete and thus you ignore it (and the missequenced 9 too). So if SEQUNCE:10 is the following REQUEST VEVENT and is the FIRST one to which I am invited: SEQUENCE:10 RDATE: Jan-1 RDATE: Jan-2 RDATE: Jan-3 Now I get a request to change the RECURRENCE-ID:Jan-4 to Jan-5 because the original (SEQUENCE:0) RECURRENCE-ID for one of the above instances was Jan-4. It is useless trash to the CUA at that point. If updates and cancels do not apply to the current object (latest REPLY'd UID/SEQUENCE/RECURRENE-ID set) and if a RECURRENCE-ID has changed from the original (SEQUENCE:0) object, you can never send me updates to instances as I do not have the original (SEQUENEC:0) object in order to process the update or cancel. Is all that can be known is that one might match the same effective DTSATRT value of SEQUENCE:10, but in the examples you keep cutting out in your replies to my email - you can break/fake the CUA into changing an incorrect instance LOCATION if you fixate on SEQUENCE:0 instance times. The RECURRENCE-ID changes as the booked UID/RECURRENCE-ID/SEQUENCE changes. Else you can not add new ATTENDEEs if there has been or will be a change to an effective DTSTART instance *if* your model is correct. Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040706050300020203010701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIwMzUwOVowIwYJKoZIhvcNAQkEMRYEFD/BfXh/ kZOvs80V7ADqXI5Dd9t/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAAceUQCy9KPk3Jxsx29HGB/T1OgCRxGPP5uelrOV5Nv1DVwKcVJt wGZM0FYcEzg6d8/pvbYDzsvG9Yo4yu7xUePQGtiDQhWgopSbXwzN5Llj3YdLFOqUjBE/ovPY GLZbg1svhNIQ27PbSr7jgiEagv53b0qK7KgoUJfa5qXGGTuVJPTLrwO+iMrDsPyw+pY1xTHE MiSmzHZ5RAbXKXR19qHPhJUZUUg0mb31PiDl//IY4Z2oHq+rQOa7jMPHFFqx5/IxKDPurm33 A4yYN7mzrJ5snDshVfwI7VJjJJ4uaSDqC5OyKa317jf1iMrUWlyUr9xPNa3sqvo5b0OuY1OD RcAAAAAAAAA= --------------ms040706050300020203010701-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 16:55: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 QAA02158 for ; Thu, 7 Aug 2003 16:55:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Kjmqt046186 for ; Thu, 7 Aug 2003 13:45:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77Kjmur046185 for ietf-calendar-bks; Thu, 7 Aug 2003 13:45:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Kjlqt046168 for ; Thu, 7 Aug 2003 13:45:47 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32AEB4.3030707@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Aug 2003 16:42:54 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 04:45:35 PM, Serialize complete at 08/07/2003 04:45:35 PM Content-Type: multipart/alternative; boundary="=_alternative 007199CF85256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007199CF85256D7B_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 08/07/2003 03:55:32 PM: > > ... then by definition you are gonna be creating the > > RECURRENCE-IDs at that time too... > > We agree, you can not create a VEVENT with a RECURRENCE-ID property in it. Umm, I dont think you got my meaning. If you create the VEVENT recurrence instances at SEQUENCE:0 then by defintion you've assigned each instance its RECURRENCE-ID then. You had said that it didnt happen until SEQUENCE:1. When I actually create the instances in my calendar Im going to create them w/the UID and RECURRENCE-ID values to identify the recurrence set and the particular instance. As such they get created in the Organziers calendar at SEQUENCE:0. They also get created and assigned in each invitees calendar when they create the instance set in their calendars when they get my SEQUENCE:0 REQUEST. Right? > He actually said: > > "I first create an event: > UID: 1 > SEQUENCE: 0 > RECURRENCE-ID: 20030805T180000Z > DTSTART: 20030805T180000Z ..." > > And you can not create a VEVENT with a RECURRENCE-ID property in it. You certainly can Doug. If I want to invite you to a particular instance of a repeat set I would exactly send that iTIP fragment. You dont get the instances you are not invited to; you'd have no way to know you were not being invited to them! > For REPLY, Single instance update, moving an instance, canceling and > instance, but not creating a recurrence set even when the recurrence > set has only one instance. Err, that restriction table snippet came from iTIP Section 3.2.2 REQUEST and clearly matches the iTIP note: . Reschedule an existing event; Just because we didnt espressly write "Reschedule an existing event [or a particular instance or range of instances of a repeating event]" every time does not mean it does not work refer to just a particular instance only. If we had done this then iTIP would have been 4 times larger. It should be understood that whever we referred to "an event" we meant "an event or an instance of a repeating event or the entire set of instances in a repeating event" with the releveant gramatical changes. As such when the text says: If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. it implicitly should read: If the "UID" and "RECURRENCE-ID" property values in the "REQUEST" are not found on the recipient's calendar, then the "REQUEST" is for a new instance of a repeating "VEVENT" calendar component. when you are talking about an instance of a repeating set. You can add the omitted verbage when dealing with RANGEes if you like... In any case, a RECURRENCE-ID on a REQUEST is valid and expected when referring to a particular instance. Oh I think I see now. Noone said it was a 1 instance set, at least that not what I got from a quick reading of the original posting. Yes, I do agree that a non-repeating component has NO RECURRENCE-ID value if thats what you meant. iCalendar addresses this with: Conformance: This property can be specified in an iCalendar object containing a recurring calendar component. If its non-recurring, then the property does not belong (although its kina loose phrasing with "can be" instead of "can only be" but we cant catch 'em all). There is no simple way to specify this in the ABNF so we opt'd for conformance prose here. However I took his example to be referring to a single instance of some arbitrary repeating instance. In any case, what I said before and above holds true for any REQUEST when dealing with a particular instance of a recurrence set. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007199CF85256D7B_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 08/07/2003 03:55:32 PM:
>  > ... then by definition you are gonna be creating the
> > RECURRENCE-IDs at that time too...
>
> We agree, you can not create a VEVENT with a RECURRENCE-ID property in it.
Umm, I dont think you got my meaning.  If you create the VEVENT recurrence instances at SEQUENCE:0 then by defintion you've assigned each instance its RECURRENCE-ID then.  You had said that it didnt happen until SEQUENCE:1.

When I actually create the instances in my calendar Im going to create them w/the UID and RECURRENCE-ID values to identify the recurrence set and the particular instance.  As such they get created in the Organziers calendar at SEQUENCE:0.  They also get created and assigned in each invitees calendar when they create the instance set in their calendars when they get my SEQUENCE:0 REQUEST.  Right?

> He actually said:
>
>    "I first create an event:
>     UID: 1
>     SEQUENCE: 0
>     RECURRENCE-ID: 20030805T180000Z
>     DTSTART: 20030805T180000Z   ..."
>
> And you can not create a VEVENT with a RECURRENCE-ID property in it.
You certainly can Doug.  If I want to invite you to a particular instance of a repeat set I would exactly send that iTIP fragment.  

You dont get the instances you are not invited to; you'd have no way to know you were not being invited to them!

> For REPLY, Single instance update, moving an instance, canceling and
> instance, but not creating a recurrence set even when the recurrence
> set has only one instance.
Err, that restriction table snippet came from iTIP Section 3.2.2 REQUEST and clearly matches the iTIP note:

     .  Reschedule an existing event;

Just because we didnt espressly write "Reschedule an existing event [or a particular instance or range of instances of a repeating event]" every time does not mean it does not work refer to just a particular instance only.  If we had done this then iTIP would have been 4 times larger.  It should be understood that whever we referred to "an event" we meant "an event or an instance of a repeating event or the entire set of instances in a repeating event" with the releveant gramatical changes.  As such when the text says:

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

it implicitly should read:

                                    If the "UID" and "RECURRENCE-ID"
   property values in the "REQUEST" are not found on the recipient's
   calendar, then the "REQUEST" is for a new instance of a repeating
   "VEVENT" calendar component.

when you are talking about an instance of a repeating set.  You can add the omitted verbage when dealing with RANGEes if you like...  In any case, a RECURRENCE-ID on a REQUEST  is valid and expected when referring to a particular instance.

Oh I think I see now.  Noone said it was a 1 instance set, at least that not what I got from a quick reading of the original posting.

Yes, I  do agree that a non-repeating component has NO RECURRENCE-ID value if thats what you meant.  iCalendar addresses this with:

   Conformance: This property can be specified in an iCalendar object
  containing a recurring calendar component.

If its non-recurring, then the property does not belong (although its kina loose phrasing with "can be" instead of "can only be" but we cant catch 'em all).  There is no simple way to specify this in the ABNF so we opt'd for conformance prose here.

However I took his example to be referring to a single instance of some arbitrary repeating instance.   In any case, what I said before and above holds true for any REQUEST when dealing with a particular instance of a recurrence set.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007199CF85256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 16:59:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02334 for ; Thu, 7 Aug 2003 16:59:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Kqnqt047130 for ; Thu, 7 Aug 2003 13:52:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77KqnAv047129 for ietf-calendar-bks; Thu, 7 Aug 2003 13:52:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Kqmqt047121 for ; Thu, 7 Aug 2003 13:52:48 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77KqlEB008494 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 13:52:49 -0700 Message-ID: <3F32BC1A.9050909@Royer.com> Date: Thu, 07 Aug 2003 14:52:42 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040808040605070803050905" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040808040605070803050905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 08/07/2003 03:42:08 PM: > > So, when creating a new VEVENT you can not be referring to an instance > > that does not yet exist. As soon as the object exists it has an > > implied RECURRENCE-ID for each effective DTSTART of each instance. > > And so after Ive created it in my calendar (at SEQUENCE:0) I can then > invite Satay to a particular instance only by using its RECURRENCE-ID in > the REQUEST. Only after his CUA has replied to SEQUENCE:0, will he know what the RECURRENCE-ID for SEQUENCE:0 is. So the first invitation to him can not contain both a RECRURRENE-ID and DTSTART, else it looks *exactly* like an iTIP modification to an instance to an existing VEVENT for which he does not have. As that is how you modify an existing VEVENT instance - supply the RECURRENCE-ID and DTSTART properties in a REQUEST - per iTIP. If it did not contain a RECURRENCE-ID, then as he did not have that UID it would look like a new REQUEST for a new object. But the fact that you add RECURRENCE-ID is how you say iTIP modify. > > The only times that RECURRENCE-ID can exist in a VEVENT is: > > > > When REPLYing to an existing instance and if present indicates > > that the sender is only replying to that named instance. > > > > Updating an existing instance in an existing recurrence set. > > > > CANCELing an instance in an existing recurrence set. > > Umm, you forgot inviting someone initially to an instance of a > recurrence set. REPLY is them responding to it, not my initial REQUEST > where its perfectly valid (and necessary). You forgot that iTIP an iCAL have no such concept in the way you have presented it. You keep sending out iTIP modify objects and calling them a new invitation for an ATTENDEE. That may be how your product does it, it is not in iTIP or iCAL. If you want to invite someone to an instance of a VEVENT that the you have in your calendar, create a VEVENT REQUEST object and send it to them. No RECURRENCE-ID needed. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040808040605070803050905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIwNTI0MlowIwYJKoZIhvcNAQkEMRYEFJX7Wc9r pBevo47hkT8URNOyaUp+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAFSXv14ypm1PnJjHZaYI+F0UAXqsVryLaM44zEwKMlKWKzK66/NZ J7th/zMqW2FrBpdgKUbHikKHH2FhCQrEvwMM6VgWchj87VuobW1w/6FAaMr8819UmD/Echlj agQ+qKppYj/pSlq83bBsglirCjVcfxsFpmgnXnsaZYC+cihFJDc4FAazSgIaS+4ySQt9YOqr R2YJevYa0bnQ69J3eKuHvzYsJMBJ7viPCuD5AvD2oX1vcu9BgvzBncF3oEegftROsJ78VkTK 0KWUWIVoL4VzcqbOpdJI2l8QMZmW8tlvt98B9VFwrSAiUYCYtCoB6tN5HLcX49eLEhcvz+iE qRoAAAAAAAA= --------------ms040808040605070803050905-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:13: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 RAA03237 for ; Thu, 7 Aug 2003 17:13:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77L6Pqt048514 for ; Thu, 7 Aug 2003 14:06:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77L6P6d048512 for ietf-calendar-bks; Thu, 7 Aug 2003 14:06:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77L6Nqt048450 for ; Thu, 7 Aug 2003 14:06:23 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77L6MEB008608 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 14:06:24 -0700 Message-ID: <3F32BF48.8000804@Royer.com> Date: Thu, 07 Aug 2003 15:06:16 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050806010900050201030502" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050806010900050201030502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug responded on 08/07/2003 03:55:32 PM: > > > ... then by definition you are gonna be creating the > > > RECURRENCE-IDs at that time too... > > > > We agree, you can not create a VEVENT with a RECURRENCE-ID property > in it. > > Umm, I dont think you got my meaning. If you create the VEVENT > recurrence instances at SEQUENCE:0 then by defintion you've assigned > each instance its RECURRENCE-ID then. You had said that it didnt happen > until SEQUENCE:1. I said no such thing. I said: So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID for that single instance object SEQUENCE:1 is the effective value of the "DTSTART" property - ...T150000Z and not ..T180000Z. I made no mention of the SEQUENCE:0 RECURRENCE-ID which is known to the ATTENDEE CUA after (or when) then REPLY to the SEQUENCE:0 object is made. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050806010900050201030502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIxMDYxNlowIwYJKoZIhvcNAQkEMRYEFKKYO5yz WUXLd2P9AlbOWPepPbQlMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEwljcD9zM2xgvIk/pu/lwKoxXT2iizZ0u0yWDjJzuyUeaEj3Yeu 4roPUEA4QgmjkttdT5YjMexwbGmqsJUPY+2ZBGOjAMdbSEqBn66R2G2LCyj6EA8gZ4A98JKf piHwTHLUXUQ7YsHmz6HmWNpTA/WOs4ZTyPFIsVBYLRF2WyiaPnw98OLWUELmqBfSYUVW2YjI VINJcgKuX3jIYio9F+7yCwL1ihLLZbiodUjyFTxY9vFhz7GFegIuYo7N0kFrSMcRlH1S1AVd 5KD6A/MXVzfEBR0HWZ0z7aqLpPVl32PORbZJF+jEY6wnLkfdNpaj2W5adLuOrBg8p2EG7+Jf WbMAAAAAAAA= --------------ms050806010900050201030502-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:16: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 RAA03297 for ; Thu, 7 Aug 2003 17:16:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77L93qt048825 for ; Thu, 7 Aug 2003 14:09:03 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77L93GZ048824 for ietf-calendar-bks; Thu, 7 Aug 2003 14:09:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77L92qt048816 for ; Thu, 7 Aug 2003 14:09:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77L91EB008620 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 14:09:03 -0700 Message-ID: <3F32BFE8.8040004@Royer.com> Date: Thu, 07 Aug 2003 15:08:56 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000205070802050109040803" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000205070802050109040803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > And you can not create a VEVENT with a RECURRENCE-ID property in it. > > You certainly can Doug. If I want to invite you to a particular > instance of a repeat set I would exactly send that iTIP fragment. > > You dont get the instances you are not invited to; you'd have no way to > know you were not being invited to them! And it does not contain a RECURRENCE-ID, else it is not a new invitation, its a iTIP modify to an existing VEVENT. So, no you can not. If it contains a RECURRENCE-ID and a DTSTART and METHOD:REQUEST, then it is a modification to an existing VEVENT, not a new invitation. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000205070802050109040803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIxMDg1NlowIwYJKoZIhvcNAQkEMRYEFDqgneQt rK5pHruDzTFyixpqjSoBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAHn/pJ43B99tlT6wDB6hMXQyAJOe0360dvD4bKvVJf6sIeYsTILc XgZV1RdWdrlTZGQvMIYEzXSFFuN9bm3z7RgmhGa79d2ciQ9f0+JKdO8LSDOOk4kmN8BDHg0z XYDmYRl93GjeWkEHq3Q/NDW1NYANwBn4hksT8d9iYj3F9n6tSyuujoaSCviwVBN48B2i5SWZ oroT8yg2DePIVA6jrwwtPXApCQ15PNofs5D/QX3cHq9oq0B692bUZQqKsNsqw9baKbukHZlb aU0dSJRGt6opf1+FJ11ThDubFnVaymkr8mDVCMqV3x1cIBV3PwziajcrntHRMciuc3YFb6zb gWEAAAAAAAA= --------------ms000205070802050109040803-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:21:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03514 for ; Thu, 7 Aug 2003 17:21:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LCkqt049332 for ; Thu, 7 Aug 2003 14:12:46 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77LCkT5049331 for ietf-calendar-bks; Thu, 7 Aug 2003 14:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LCiqt049324 for ; Thu, 7 Aug 2003 14:12:44 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77LChEB008654 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 14:12:45 -0700 Message-ID: <3F32C0C6.1040804@Royer.com> Date: Thu, 07 Aug 2003 15:12:38 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090204000200040305090801" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090204000200040305090801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > know you were not being invited to them! > > > For REPLY, Single instance update, moving an instance, canceling and > > instance, but not creating a recurrence set even when the recurrence > > set has only one instance. > > Err, that restriction table snippet came from iTIP Section 3.2.2 REQUEST > and clearly matches the iTIP note: > > . Reschedule an existing event; > > Just because we didnt espressly write "Reschedule an existing event [or > a particular instance or range of instances of a repeating event]" every > time does not mean it does not work refer to just a particular instance > only. Yes you can also use RANGE if that is what you meant to say. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090204000200040305090801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIxMTIzOFowIwYJKoZIhvcNAQkEMRYEFETbogV1 N19vN7lqau8hKSFKXLMcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAF2a8/7DxIFa1vDZMiroEK3swlO27Z47wNeyfNklLoHI4DTN51xT 370ZIly1/oxYEekW4Y3UddD+lNooltxYg6bXSvmfIreu7QD1Et/uz2kKieameAOnb3D4rSF+ zA4TF84UmtA85TBtseu3NmuMBUh46T+pRBmDwhZcihjIoJv5W3HY9J0HwYoK8Bam0FUFjLDT cvlUnsTcYw/n/T6kXWV+64EUiuas5cxCzGE9Fd7pCgkuKyyfETSQme6fAN1d7eZmenKZ3wl/ YVfoq4WMeUDY8zQDRY9fCWFbDird84Wjk25ho+DuWuuqHz4m+sMC7nUr8bhtYIjg5GcPx3fm GwEAAAAAAAA= --------------ms090204000200040305090801-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:21: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 RAA03532 for ; Thu, 7 Aug 2003 17:21:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LC5qt049284 for ; Thu, 7 Aug 2003 14:12:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77LC5gY049280 for ietf-calendar-bks; Thu, 7 Aug 2003 14:12:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LC4qt049258 for ; Thu, 7 Aug 2003 14:12:04 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32B2AF.8070309@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Aug 2003 17:10:04 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 05:11:51 PM, Serialize complete at 08/07/2003 05:11:51 PM Content-Type: multipart/alternative; boundary="=_alternative 007416A485256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007416A485256D7B_= Content-Type: text/plain; charset="US-ASCII" Doug pondered on 08/07/2003 04:12:31 PM: > > So?? The value is the same at SEQUENCE:10 as it is as SEQUENCE:0. If > > you correctly apply the iTIP Section 3.2.2 REQUEST rules: > > Not in the example provied if you read the entire email. All SEQUENCE values examples above 8 were my own. That should have been clear from reading the entire posting. I can repost if need be with proper cavat... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007416A485256D7B_= Content-Type: text/html; charset="US-ASCII"
Doug pondered on 08/07/2003 04:12:31 PM:
> > So??  The value is the same at SEQUENCE:10 as it is as SEQUENCE:0.  If
> > you correctly apply the iTIP Section 3.2.2 REQUEST rules:
>
> Not in the example provied if you read the entire email.
All SEQUENCE values examples above 8 were my own.  That should have been clear from reading the entire posting.  I can repost if need be with proper cavat...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007416A485256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:21: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 RAA03550 for ; Thu, 7 Aug 2003 17:21:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LC5qt049283 for ; Thu, 7 Aug 2003 14:12:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77LC5kI049281 for ietf-calendar-bks; Thu, 7 Aug 2003 14:12:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LC4qt049257 for ; Thu, 7 Aug 2003 14:12:04 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32B1FE.2040403@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Aug 2003 17:08:04 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 05:11:51 PM, Serialize complete at 08/07/2003 05:11:51 PM Content-Type: multipart/alternative; boundary="=_alternative 0073E78D85256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073E78D85256D7B_= Content-Type: text/plain; charset="US-ASCII" Doug fired back on 08/07/2003 04:09:34 PM: > > Show us where iCalendar says that the RECURRENCE-ID values are assigned > > at SEQUENCE:1. If you create the set at SEQUENCE:0 then the id would > > have to be assigned at that time, not after a rescheduling of that > > instance. > > Show me anywhere where in any RFC it says you can ignore: > > (iCAL) > ...When the definition of the recurrence > set for a calendar component changes, and hence the "SEQUENCE" > property value changes, the "RECURRENCE-ID" for a given recurrence > instance might also change. ... Whats to ignore? Nothing even remotely comes close to your SEQUENCE:1 claim. I still see NOTHING in your citation that says RECURRENCE-ID values are assigned at SEQUENCE:1 and not at SEQUENCE:0 no matter how hard I try to ignore it.. If I create the repeating set at SEQUENCE:0 then Im also assigning the RECURRENCE-IDs then. Otherwise I cannot add any new ATTENDEEs unless I change SEQUENCE to 1 by your logic. Plus, Im creating the instances now, NOT changing them (or more accurately changing the "defintion of the recurrece _set_". Besides, rescheduling an instance is not redefining the set, its moving the instance around. After all, if the instances are created at SEQUENCE:0 then they each have their own original DTSTART values for everyone invited to use when adding to their calendars. Otherwise how could I reschedule just 1 instance the original ATTTENDEEs know about if my now SEQUENCE:1 instance has a RECURRENCE-ID that I only just assigned? Assigning the RECURRENCE-ID at SEQUENCE:0 also allows ATTENDEEs to REPLY to particular instances too. For example, I know I cant make the 4th instance so I can immediately send a REPLY with PARTSTAT=DECLINE for that particular RECURRENCE-ID. If you had not created the RECURRENCE-ID values when you created the instances at SEQUENCE:0 then you have no way to match up my 100% valid REPLY (at SEQUENCE:0) to the correct instance. You'd have to rev SEQUENCE to 1 and resend the REQUEST to me so I can once again decline... > If you change just the LOCATION for example the RECURRENCE-ID does > not CHANGE even when the SEQUENCE changes. Not true. I wont quote all of 2445 on this (Section 4.8.7.4 Sequence Number, p 131) but I will point out that SEQUENCE is required to change on certain conditions but it is NOT LIMITED to those cases only. The relevant bit you may have overlooked is: In addition, changes made by the "Organizer" to other properties can also force the sequence number to be incremented. The "Organizer" CUA MUST increment the sequence number when ever it makes changes to properties in the calendar component that the "Organizer" deems will jeopardize the validity of the participation status of the "Attendees". The Organizer may decide that changing LOCATION:Boston to LOCATION:Miami may is a reason to jeopardize participation and thus MUST rev SEQUENCE. This decision is not just limited to LOCATION though, it could be nearly any other factor (or set of factors). We _never_ said SEQUENCE can or should _only_ be revd for the explicit set of changes you are thinking of; we just mandated it MUST for them but allowed it to be reved in other cases too. > If you change the > effective DTSTART value for a given recurrence instance (THE > RECURRENCE-ID for that instance), then the RECURRECE-ID changes. I guess you are ignoring: 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. or perhaps you just didnt see it before... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0073E78D85256D7B_= Content-Type: text/html; charset="US-ASCII"
Doug fired back on 08/07/2003 04:09:34 PM:
> > Show us where iCalendar says that the RECURRENCE-ID values are assigned
> > at SEQUENCE:1.  If you create the set at SEQUENCE:0 then the id would
> > have to be assigned at that time, not after a rescheduling of that
> > instance.
>
> Show me anywhere where in any RFC it says you can ignore:
>
>    (iCAL)
>     ...When the definition of the recurrence
>     set for a calendar component changes, and hence the "SEQUENCE"
>     property value changes, the "RECURRENCE-ID" for a given recurrence
>     instance might also change. ...
Whats to ignore?  Nothing even remotely comes close to your SEQUENCE:1 claim.  I still see NOTHING in your citation that says RECURRENCE-ID values are assigned at SEQUENCE:1 and not at SEQUENCE:0 no matter how hard I try to ignore it..  

If I create the repeating set at SEQUENCE:0 then Im also assigning the RECURRENCE-IDs then.  Otherwise I cannot add any new ATTENDEEs unless I change SEQUENCE to 1 by your logic.  Plus, Im creating the instances now, NOT changing them (or more accurately changing the "defintion of the recurrece _set_".  Besides, rescheduling an instance is not redefining the set, its moving the instance around.

After all, if the instances are created at SEQUENCE:0 then they each have their own original DTSTART values for everyone invited to use when adding to their calendars.  Otherwise how could I reschedule just 1 instance the original ATTTENDEEs know about if my now SEQUENCE:1 instance has a RECURRENCE-ID that I only just assigned?

Assigning the RECURRENCE-ID at SEQUENCE:0 also allows ATTENDEEs to REPLY to particular instances too.  For example, I know I cant make the 4th instance so I can immediately send a REPLY with PARTSTAT=DECLINE for that particular RECURRENCE-ID.  If you had not created the RECURRENCE-ID values when you created the instances at SEQUENCE:0 then you have no way to match up my 100% valid REPLY (at SEQUENCE:0) to the correct instance.  You'd have to rev SEQUENCE to 1 and resend the REQUEST to me so I can once again decline...

> If you change just the LOCATION for example the RECURRENCE-ID does
> not CHANGE even when the SEQUENCE changes.

Not true.  I wont quote all of 2445 on this (Section 4.8.7.4 Sequence Number, p 131) but I will point out that SEQUENCE is required to change on certain conditions but it is NOT LIMITED to those cases only.  The relevant bit you may have overlooked is:

   In addition, changes made by the "Organizer" to other properties can
  also force the sequence number to be incremented. The "Organizer" CUA
  MUST increment the sequence number when ever it makes changes to
  properties in the calendar component that the "Organizer" deems will
  jeopardize the validity of the participation status of the
  "Attendees".

The Organizer may decide that changing LOCATION:Boston to LOCATION:Miami may is a reason to jeopardize participation and thus MUST rev SEQUENCE.  This decision is not just limited to LOCATION though, it could be nearly any other factor (or set of factors).  We _never_ said SEQUENCE can or should _only_ be revd for the explicit set of changes you are thinking of; we just mandated it MUST for them but allowed it to be reved in other cases too.

>                                             If you change the
> effective DTSTART value for a given recurrence instance (THE
> RECURRENCE-ID for that instance), then the RECURRECE-ID changes.
I guess you are ignoring:

   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.

or perhaps you just didnt see it before...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0073E78D85256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:25:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03662 for ; Thu, 7 Aug 2003 17:25:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LHpqt049608 for ; Thu, 7 Aug 2003 14:17:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77LHpia049606 for ietf-calendar-bks; Thu, 7 Aug 2003 14:17:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LHoqt049601 for ; Thu, 7 Aug 2003 14:17:50 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77LHmEB008684 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 14:17:51 -0700 Message-ID: <3F32C1F7.10209@Royer.com> Date: Thu, 07 Aug 2003 15:17:43 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040609040804080700060304" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040609040804080700060304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > Oh I think I see now. Noone said it was a 1 instance set, at least that > not what I got from a quick reading of the original posting. > > Yes, I do agree that a non-repeating component has NO RECURRENCE-ID > value if thats what you meant. iCalendar addresses this with: And the ORIGINAL SEQUENCE:0 FULL object can not contain a RECURRENCE-ID. And if it does contain a RECURRENCE-ID, then it is a object modify as defined by iTIP and not an new invitation. > > However I took his example to be referring to a single instance of some > arbitrary repeating instance. In any case, what I said before and > above holds true for any REQUEST when dealing with a particular instance > of a recurrence set. Do you disagree that iTIP says that if it has a RECURRENCE-ID and METHOD:REQUEST that it is a modify and not a new invitation? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040609040804080700060304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIxMTc0M1owIwYJKoZIhvcNAQkEMRYEFOnpjiou 9hg+lQayyusndjCZh+zeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGcnbY9I8AIT/J9OncYDmHqvhmMkAL5ZOCPmC9IWjAulP9VwhWTy xlpUQg6AEUHGEFRNcNQkhpkPBAFMlXSVQ7KjLY8csmnS5vlDr8Ra4cH9fFf0s+ide4TBxrVl e/cmtb+rAeTE0ubbw4YBnzTPRHpwr7Ew8l3z1ndt4suVXp7m3sRQh1K/8+c1KHR7qhuIeBO2 nD5ibk/v4hkQ3uktcoyupUp+4xbTCgWR/AMVhxhnN70TtHYrPWRvsvKJtkVXpTQd6TkXbMo3 8rxzYx0JDYBesxG0g0sffOOZuVOi1AWGPr4dcuovpyy/KnV37sWWFVTb2PEF/uq1iy+jUnH6 If8AAAAAAAA= --------------ms040609040804080700060304-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:39: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 RAA04334 for ; Thu, 7 Aug 2003 17:39:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LWWqt050705 for ; Thu, 7 Aug 2003 14:32:32 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77LWWpf050704 for ietf-calendar-bks; Thu, 7 Aug 2003 14:32:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LWVqt050699 for ; Thu, 7 Aug 2003 14:32:31 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77LWUEB008824 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 14:32:32 -0700 Message-ID: <3F32C569.6070907@Royer.com> Date: Thu, 07 Aug 2003 15:32:25 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010206030200080901060000" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010206030200080901060000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug pondered on 08/07/2003 04:12:31 PM: > > > So?? The value is the same at SEQUENCE:10 as it is as SEQUENCE:0. If > > > you correctly apply the iTIP Section 3.2.2 REQUEST rules: > > > > Not in the example provied if you read the entire email. > > All SEQUENCE values examples above 8 were my own. That should have been > clear from reading the entire posting. I can repost if need be with > proper cavat... Except you were replying to my email - not yours. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010206030200080901060000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIxMzIyNVowIwYJKoZIhvcNAQkEMRYEFKUerFvr hpCNuaoOoK3pR7div/JlMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAMEYAMmVLSXnMzK7meJkUTB4T/NG6LN3k1KfcVpRYzIczJJI4mId zsz0avy7h5/AsiaNfcGsz+1pQK/SRJgjuLdfOOplMUXgBwvbtPTzpi39IBluKTfztzHSHnsN h0DSjroAQ+Ro8Cm6L905gS1RiIVJI+BpGvF9yU0Jf0TJSa0F+hKH1LcIBOyHPvpGLBZJohkH lCzbqU1F9sYho3FTj9KbLvhYeNrcIHpzO/dGtIcHhfVJ3VOdPb6EihL6UExJK6yLmz7jw8f2 zBXctaSBiz6mBVaGF5frYfVFg/9j32Cvr/Mk1w/ESOyYL6mocv5HOEJLwLEgn2eFj04rYBIX SIwAAAAAAAA= --------------ms010206030200080901060000-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:40: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 RAA04380 for ; Thu, 7 Aug 2003 17:40:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LY1qt051171 for ; Thu, 7 Aug 2003 14:34:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77LY1nP051170 for ietf-calendar-bks; Thu, 7 Aug 2003 14:34:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LY0qt051165 for ; Thu, 7 Aug 2003 14:34:00 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77LXwEB008829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 14:34:01 -0700 Message-ID: <3F32C5C1.7020100@Royer.com> Date: Thu, 07 Aug 2003 15:33:53 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080101080709080708030305" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080101080709080708030305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug fired back on 08/07/2003 04:09:34 PM: > > > Show us where iCalendar says that the RECURRENCE-ID values are > assigned > > > at SEQUENCE:1. If you create the set at SEQUENCE:0 then the id would > > > have to be assigned at that time, not after a rescheduling of that > > > instance. > > > > Show me anywhere where in any RFC it says you can ignore: > > > > (iCAL) > > ...When the definition of the recurrence > > set for a calendar component changes, and hence the "SEQUENCE" > > property value changes, the "RECURRENCE-ID" for a given recurrence > > instance might also change. ... > > Whats to ignore? Your ignoring the fact it changes. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080101080709080708030305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIxMzM1M1owIwYJKoZIhvcNAQkEMRYEFC+Mlbt5 RfwEfOZ0psAhtlyxEsGiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAHNs12smg4ueDXKuoIxScfVSAUIb/BV0USB7MIEMf+fwpogPc4X6 REm2EKSkQZSnLEtbTbiYPu5LKDo7/h/32c3z9raPlRBpKXbVOfCAM+MUE7J7fExzTvuX2yyc 1zDNMPCkiL71V1s0BIRbwmrUtsZ01rVGunNHqVEVyEnHlqt9Op05G8M/72ZIMUZytYpjw/UX LF2Zz2rrZBzap9vFj64FiyQzQCnzWOdh5VniljEVKCJ8OA7sr4HLg9ZpMrsXG6+mxcgEO9UN SBHKKYCQlilDT4aMe/pJ3baATrgsj1d9TkEC/DDomXDQsHWDcGTWTuwjdTyrhiuWcFEVJgfk fz8AAAAAAAA= --------------ms080101080709080708030305-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:51: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 RAA04608 for ; Thu, 7 Aug 2003 17:51:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Lhaqt051665 for ; Thu, 7 Aug 2003 14:43:36 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77Lha0w051664 for ietf-calendar-bks; Thu, 7 Aug 2003 14:43:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77LhZqt051656 for ; Thu, 7 Aug 2003 14:43:35 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32B24E.6080506@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Aug 2003 17:19:58 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 05:43:20 PM, Serialize complete at 08/07/2003 05:43:20 PM Content-Type: multipart/alternative; boundary="=_alternative 0074FE7485256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0074FE7485256D7B_= Content-Type: text/plain; charset="US-ASCII" Doug didnt get it on 08/07/2003 04:10:54 PM: > > > In Bruces model you can NEVER add someone to the series > > > of recurring VEVENT after any change that effects the > > > effective DTSTART value > > > > Huh?? You are really not getting the fixed model I think. If the > > RECURRENCE-IDs used never change then adding someone is no big deal. > > Take a look... > > > > If for some reason I wanted to add you to an instance of: > > > > UID: 1 > > SEQUENCE: 10 > > RECURRENCE-ID: 20030805T180000Z > > DTSTART: 20030816T150000Z > > > > then I send you just that. Your REPLY would use the same UID / > > RECURRENCE-ID / SEQUENCE value that someone who is aready invited would > > and we would all be on the same page. Where is it broken?? > > That example of mine was NOT to a single instance - what's your point? The point I was making is that its 100% easy and straight forward adding ANY ATTENDEE at ANY time after SEQUENCE:0 in "my" (aka iCalendars) model. I just moved SEQUENCE ahead to 10 to reuse the fragments already in play but I see that easily confused some folks. Sorry about that. Lets see if I can rephrase the point for you: Adding new ATTENDEEs at ANY TIME is no problem with a fixed RECURRENCE-ID model; your claim of "you can NEVER add someone to the series...after any change" is just flat out wrong. Yep, that about rephrases it just right. Above was an example of how easy it is to add someone to a single instance, I simply send them a REQUEST using the current definition and thats it. Adding them to the set is just as easy. I showed how easy it was last month when Arnaud asked for examples. To save time and effort Ill let you go check the archives for 'em if you are still unsure how it can be done. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0074FE7485256D7B_= Content-Type: text/html; charset="US-ASCII"
Doug didnt get it on 08/07/2003 04:10:54 PM:
> > > In Bruces model you can NEVER add someone to the series
> > > of recurring VEVENT after any change that effects the
> > > effective DTSTART value
> >
> > Huh??  You are really not getting the fixed model I think.  If the
> > RECURRENCE-IDs used never change then adding someone is no big deal.
> >  Take a look...
> >
> > If for some reason I wanted to add you to an instance of:
> >
> > UID: 1
> > SEQUENCE: 10
> > RECURRENCE-ID: 20030805T180000Z
> > DTSTART: 20030816T150000Z
> >
> > then I send you just that.  Your REPLY would use the same UID /
> > RECURRENCE-ID / SEQUENCE value that someone who is aready invited would
> > and we would all be on the same page.  Where is it broken??
>
> That example of mine was NOT to a single instance - what's your point?
The point I was making is that its 100% easy and straight forward adding ANY ATTENDEE at ANY time after SEQUENCE:0 in "my" (aka iCalendars) model.  I just moved SEQUENCE ahead to 10 to reuse the fragments already in play but I see that easily confused some folks.  Sorry about that.

Lets see if I can rephrase the point for you: Adding new ATTENDEEs at ANY TIME is no problem with a fixed RECURRENCE-ID model; your claim of "you can NEVER add someone to the series...after any change" is just flat out wrong.  Yep, that about rephrases it just right.

Above was an example of how easy it is to add someone to a single instance, I simply send them a REQUEST using the current definition and thats it.  Adding them to the set is just as easy.  I showed how easy it was last month when Arnaud asked for examples.  To save time and effort Ill let you go check the archives for 'em if you are still unsure how it can be done.  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0074FE7485256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 17:57: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 RAA04717 for ; Thu, 7 Aug 2003 17:57:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Lneqt051908 for ; Thu, 7 Aug 2003 14:49:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77Lnedb051906 for ietf-calendar-bks; Thu, 7 Aug 2003 14:49:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Lndqt051887 for ; Thu, 7 Aug 2003 14:49:40 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F32C1F7.10209@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_07162003NP July 16, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 7 Aug 2003 17:52:42 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 05:49:24 PM, Serialize complete at 08/07/2003 05:49:24 PM Content-Type: multipart/alternative; boundary="=_alternative 0077825C85256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0077825C85256D7B_= Content-Type: text/plain; charset="US-ASCII" Do you disagree that iTIP says that if it has a RECURRENCE-ID and METHOD:REQUEST that it is a modify and not a new invitation? This blatantly FALSE. The request method makes no such distinction. If you receive a request and it is not on your calendar, you must treat it as an invitation. The presence of a repeat-id makes it an invitation to an instance of a repeat set. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 08/07/2003 05:17 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: RECURRENCE-ID discussion Bruce_Kahn@notesdev.ibm.com wrote: > > > Oh I think I see now. Noone said it was a 1 instance set, at least that > not what I got from a quick reading of the original posting. > > Yes, I do agree that a non-repeating component has NO RECURRENCE-ID > value if thats what you meant. iCalendar addresses this with: And the ORIGINAL SEQUENCE:0 FULL object can not contain a RECURRENCE-ID. And if it does contain a RECURRENCE-ID, then it is a object modify as defined by iTIP and not an new invitation. > > However I took his example to be referring to a single instance of some > arbitrary repeating instance. In any case, what I said before and > above holds true for any REQUEST when dealing with a particular instance > of a recurrence set. Do you disagree that iTIP says that if it has a RECURRENCE-ID and METHOD:REQUEST that it is a modify and not a new invitation? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 0077825C85256D7B_= Content-Type: text/html; charset="US-ASCII"
Do you disagree that iTIP says that if it has a RECURRENCE-ID and
METHOD:REQUEST that it is a modify and not a new invitation?

This blatantly FALSE.

The request method makes no such distinction.
If you receive a request and it is not on your calendar, you must treat it as an invitation.
The presence of a repeat-id makes it an invitation to an instance of a repeat set.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

08/07/2003 05:17 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: RECURRENCE-ID discussion







Bruce_Kahn@notesdev.ibm.com wrote:
>
>
> Oh I think I see now.  Noone said it was a 1 instance set, at least that
> not what I got from a quick reading of the original posting.
>
> Yes, I  do agree that a non-repeating component has NO RECURRENCE-ID
> value if thats what you meant.  iCalendar addresses this with:

And the ORIGINAL SEQUENCE:0 FULL object can not contain a RECURRENCE-ID.
And if it does contain a RECURRENCE-ID, then it is a object modify
as defined  by iTIP and not an new invitation.

>
> However I took his example to be referring to a single instance of some
> arbitrary repeating instance.   In any case, what I said before and
> above holds true for any REQUEST when dealing with a particular instance
> of a recurrence set.

Do you disagree that iTIP says that if it has a RECURRENCE-ID and
METHOD:REQUEST that it is a modify and not a new invitation?

--

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

                We Do Standards - You Need Standards
--=_alternative 0077825C85256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 18:13: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 SAA06009 for ; Thu, 7 Aug 2003 18:13:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77M5mqt052540 for ; Thu, 7 Aug 2003 15:05:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77M5moo052539 for ietf-calendar-bks; Thu, 7 Aug 2003 15:05:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77M5kqt052533 for ; Thu, 7 Aug 2003 15:05:46 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77M5kEB009054 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 15:05:47 -0700 Message-ID: <3F32CD34.5030102@Royer.com> Date: Thu, 07 Aug 2003 16:05:40 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050100090108080407080407" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050100090108080407080407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > The point I was making is that its 100% easy and straight forward adding > ANY ATTENDEE at ANY time after SEQUENCE:0 in "my" (aka iCalendars) > model. I just moved SEQUENCE ahead to 10 to reuse the fragments already > in play but I see that easily confused some folks. Sorry about that. > > Lets see if I can rephrase the point for you: Adding new ATTENDEEs at > ANY TIME is no problem with a fixed RECURRENCE-ID model; your claim of > "you can NEVER add someone to the series...after any change" is just > flat out wrong. Yep, that about rephrases it just right. And what about the example I sent to this list that shows how your model broken in that area? You know the one that showed that new attendess in your model can not process instance changes unless they just happen to be the same as the SEQUENCE:0 instances? > Above was an example of how easy it is to add someone to a single > instance, I simply send them a REQUEST using the current definition and > thats it. Adding them to the set is just as easy. I showed how easy it > was last month when Arnaud asked for examples. To save time and effort > Ill let you go check the archives for 'em if you are still unsure how it > can be done. Except all of your examples were how to modify an existing VEVENT and you called it inviting a new attendee. There is no problem to solve, just send them a VEVENT with NO RECURRENCE-ID as all of the examples in iCAL and iTIP show and every thing works. There is no need to invent a new way to invite an ATTENDEE. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050100090108080407080407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIyMDU0MFowIwYJKoZIhvcNAQkEMRYEFBcUZWQc mbiA/MMDxOPTTRaJzwYjMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAESlFFq8D6wNC/sMoQ9ZG0BSss5TsLmrFXtxukguhWCVx7KfAiO9 AeCC0RFshwcRc5oo6QfOegQHv3WzNWirciV/8wz8wtxlv1DobrWzDe9hevyRkPPDDO6/EnTf FYqaeUZppk6l5WNY9gaFk5DLt3Iu3rooZ3JZlMJymuMGJ9QbXXJs7cMrMdcBMujidHfM+s8F QtlihwF6DY45bm31w2klO+2g+CKX/O1FRsqlBpwNvoG44LSbVCmOKVA2BkGv/Gg6+T+Ujv0M mv3TShYTN6Ub7YsbshqUUz7bfrsV3mNgyu3FSLQJmNv3L8iGHGOjKNULuyowA9oZEI5+2FFD AewAAAAAAAA= --------------ms050100090108080407080407-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 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 SAA06757 for ; Thu, 7 Aug 2003 18:23:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MG0qt052894 for ; Thu, 7 Aug 2003 15:16:00 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77MG0eR052893 for ietf-calendar-bks; Thu, 7 Aug 2003 15:16:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MFwqt052888 for ; Thu, 7 Aug 2003 15:15:58 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77MFwEB009120 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 15:15:59 -0700 Message-ID: <3F32CF99.9040901@Royer.com> Date: Thu, 07 Aug 2003 16:15:53 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000800000908090701030405" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000800000908090701030405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Do you disagree that iTIP says that if it has a RECURRENCE-ID and > METHOD:REQUEST that it is a modify and not a new invitation? > > This blatantly FALSE. > > The request method makes no such distinction. > If you receive a request and it is not on your calendar, you must treat > it as an invitation. Nope - iTIP - Modify A Recurring Instance, look for: ...Note the use of "RECURRENCE-ID" property and "SEQUENCE" property in the second request. And i iTIP - Working With Recurrence Instances, at and near: ...If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. Note that after the change has occurred, the "RECURRENCE-ID" has changed to the new "DTSTART" value. If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification. > The presence of a repeat-id makes it an invitation to an instance of a > repeat set. Can you cite any text? Or is that just another take my word for it assertion? Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000800000908090701030405 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIyMTU1M1owIwYJKoZIhvcNAQkEMRYEFF2jmG9a NFW/EdjlWXY0lED+J2lDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAKmX5cSq271CfpJLUNmkxqJOVvfQTEtfeUd1RSQKtI7qVZ2rbkp1 WglqHr+ApavNY+Mp8aInix2N6h64iA38sT8fWiCdLcmoCrPq+NBNepjOJl0cBBjyIu+aAvXw BudSaEIxgrlXQ0U850ldcFeDNKDs7N0D9ymmcjX5etcNoPGjJ+c9/WFBj+S2hksSnEkjNtkH aG7KmJpMoi5j0qrlYFXNu61aYjmKJHKv4T91j6ptjQ41o0h1y2FPlZr+JVr8vevIFZSmAqEg 8gCmsfJZsRtHdmfS89NHuNp6Mo3cfaaOP3UPIih+5F8pfkpNnLqmrcmXWh/an7k8UuAke9st QowAAAAAAAA= --------------ms000800000908090701030405-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 18: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 SAA07470 for ; Thu, 7 Aug 2003 18:47:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MZQqt053510 for ; Thu, 7 Aug 2003 15:35:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77MZQGF053509 for ietf-calendar-bks; Thu, 7 Aug 2003 15:35:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MZPqt053504 for ; Thu, 7 Aug 2003 15:35:25 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F32CD34.5030102@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_07162003NP July 16, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 7 Aug 2003 18:38:33 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 06:35:08 PM, Serialize complete at 08/07/2003 06:35:08 PM Content-Type: multipart/alternative; boundary="=_alternative 007BB51585256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007BB51585256D7B_= Content-Type: text/plain; charset="US-ASCII" >And what about the example I sent to this list that shows how >your model broken in that area? You know the one that showed >that new attendess in your model can not process instance >changes unless they just happen to be the same as the SEQUENCE:0 instances? Of course nothing works if you send your changing recurrence ids. This is not the iCalendar RFC 2445 model. 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. 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 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. RECURRENCE-ID ARE SUPPOSE TO BE THE "ORIGINAL" dates of the "ORIGINAL" repeat set. If you send your changing values as recurrence ids to a properly coded iCalendar, of course you will not work correctly. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 08/07/2003 06:05 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: RECURRENCE-ID discussion Bruce_Kahn@notesdev.ibm.com wrote: > The point I was making is that its 100% easy and straight forward adding > ANY ATTENDEE at ANY time after SEQUENCE:0 in "my" (aka iCalendars) > model. I just moved SEQUENCE ahead to 10 to reuse the fragments already > in play but I see that easily confused some folks. Sorry about that. > > Lets see if I can rephrase the point for you: Adding new ATTENDEEs at > ANY TIME is no problem with a fixed RECURRENCE-ID model; your claim of > "you can NEVER add someone to the series...after any change" is just > flat out wrong. Yep, that about rephrases it just right. And what about the example I sent to this list that shows how your model broken in that area? You know the one that showed that new attendess in your model can not process instance changes unless they just happen to be the same as the SEQUENCE:0 instances? > Above was an example of how easy it is to add someone to a single > instance, I simply send them a REQUEST using the current definition and > thats it. Adding them to the set is just as easy. I showed how easy it > was last month when Arnaud asked for examples. To save time and effort > Ill let you go check the archives for 'em if you are still unsure how it > can be done. Except all of your examples were how to modify an existing VEVENT and you called it inviting a new attendee. There is no problem to solve, just send them a VEVENT with NO RECURRENCE-ID as all of the examples in iCAL and iTIP show and every thing works. There is no need to invent a new way to invite an ATTENDEE. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 007BB51585256D7B_= Content-Type: text/html; charset="US-ASCII"
>And what about the example I sent to this list that shows how
>your model broken in that area? You know the one that showed
>that new attendess in your model can not process instance
>changes unless they just happen to be the same as the SEQUENCE:0 instances?

Of course nothing works if you send your changing recurrence ids.   This is not the iCalendar RFC 2445 model.


  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.

  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 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.
RECURRENCE-ID ARE SUPPOSE TO BE THE     "ORIGINAL"    dates of the  "ORIGINAL"  repeat set.
If you send your changing  values as recurrence ids to a properly coded iCalendar, of course you will not work correctly.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

08/07/2003 06:05 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: RECURRENCE-ID discussion







Bruce_Kahn@notesdev.ibm.com wrote:

> The point I was making is that its 100% easy and straight forward adding
> ANY ATTENDEE at ANY time after SEQUENCE:0 in "my" (aka iCalendars)
> model.  I just moved SEQUENCE ahead to 10 to reuse the fragments already
> in play but I see that easily confused some folks.  Sorry about that.
>
> Lets see if I can rephrase the point for you: Adding new ATTENDEEs at
> ANY TIME is no problem with a fixed RECURRENCE-ID model; your claim of
> "you can NEVER add someone to the series...after any change" is just
> flat out wrong.  Yep, that about rephrases it just right.

And what about the example I sent to this list that shows how
your model broken in that area? You know the one that showed
that new attendess in your model can not process instance
changes unless they just happen to be the same as the SEQUENCE:0 instances?

> Above was an example of how easy it is to add someone to a single
> instance, I simply send them a REQUEST using the current definition and
> thats it.  Adding them to the set is just as easy.  I showed how easy it
> was last month when Arnaud asked for examples.  To save time and effort
> Ill let you go check the archives for 'em if you are still unsure how it
> can be done.  

Except all of your examples were how to modify an existing VEVENT
and you called it inviting a new attendee. There is no problem
to solve, just send them a VEVENT with NO RECURRENCE-ID as all
of the examples in iCAL and iTIP show and every thing works.
There is no need to invent a new way to invite an ATTENDEE.

--

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

                We Do Standards - You Need Standards
--=_alternative 007BB51585256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 18:55:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07625 for ; Thu, 7 Aug 2003 18:55:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MlVqt053847 for ; Thu, 7 Aug 2003 15:47:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77MlVC1053845 for ietf-calendar-bks; Thu, 7 Aug 2003 15:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MlUqt053836 for ; Thu, 7 Aug 2003 15:47:30 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32BC1A.9050909@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Aug 2003 18:41:47 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 06:47:12 PM, Serialize complete at 08/07/2003 06:47:12 PM Content-Type: multipart/alternative; boundary="=_alternative 007C7C3A85256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007C7C3A85256D7B_= Content-Type: text/plain; charset="US-ASCII" Doug thought on 08/07/2003 04:52:42 PM: > > > So, when creating a new VEVENT you can not be referring to an instance > > > that does not yet exist. As soon as the object exists it has an > > > implied RECURRENCE-ID for each effective DTSTART of each instance. > > > > And so after Ive created it in my calendar (at SEQUENCE:0) I can then > > invite Satay to a particular instance only by using its RECURRENCE-ID in > > the REQUEST. > > Only after his CUA has replied to SEQUENCE:0, will he know > what the RECURRENCE-ID for SEQUENCE:0 is. So the first invitation > to him can not contain both a RECRURRENE-ID and DTSTART, else > it looks *exactly* like an iTIP modification to an instance to an > existing VEVENT for which he does not have. Wrong. You clearly do not understand iTIP Section 3.2.2 REQUEST and the relevant subsections. Section 3.2.2 tells you how to distinguish betweeen a new invitation and an update/reschedule. That text that does is: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. So, if Satays CUA does not find UID / RECURRENCE-ID pair then by the 2nd sentence it will treat it like an invitation (or as iTIP says the ""REQUEST" is for a new "VEVENT" calendar component"; aka an invitation). Had it found the UID / RECURRENCE-ID pair then by the last line it would treat it like an update. This case is further detailed in iTIP Section 3.2.2.1 Rescheduling an Event. > As that is how you > modify an existing VEVENT instance - supply the RECURRENCE-ID > and DTSTART properties in a REQUEST - per iTIP. That is also how you invite someone to the particular instance. Thats why we have: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. in the REQUEST restriction table. Since Im inviting Satay to a particular instance only, the RECURRENCE-ID value must be there. Otherwise its referring to the entire set of instances which Satay was NOT invited to. > If it did not contain a RECURRENCE-ID, then as he did not have > that UID it would look like a new REQUEST for a new object. But the fact > that you add RECURRENCE-ID is how you say iTIP modify. Nowhere in iTIP does it say that RECURRENCE-ID is ONLY allowed when 'modifying' (or updating to use the iTIP terminology) an instance. The REQUEST is used for both the invite and the update/reschedule. This overloading of REQUEST was a WG decision and as such it means that the meaning on the recipients side depends on the sequence the messages arrive in. If I send 2 REQUESTs and they arrive in reverse order then the 1st one that arrives looks like the 'invitation' and the 2nd one looks like a stale message (after Ive processed the 1st to arrive that was actually the reschedule) even though thats now how they appeared to someone who receives them in the order sent. With a fixed model, its no big deal. With a delta model its grounds for confusion (and thus the need to carpet bomb all instances, see other post). In any case, nowhere in iTIP did we ever say that you do not send RECURRENCE-ID on an initial invitation. Besides, you have to send it if you only intend to invite them to the instance, thats what the restriction table say. Ahh, you dont see "MUST if referring to an instnace..." so you think its not supposed to be there on the invite??... > > > The only times that RECURRENCE-ID can exist in a VEVENT is: > > > > > > When REPLYing to an existing instance and if present indicates > > > that the sender is only replying to that named instance. > > > > > > Updating an existing instance in an existing recurrence set. > > > > > > CANCELing an instance in an existing recurrence set. > > > > Umm, you forgot inviting someone initially to an instance of a > > recurrence set. REPLY is them responding to it, not my initial REQUEST > > where its perfectly valid (and necessary). > > You forgot that iTIP an iCAL have no such concept in the way you have > presented it. You keep sending out iTIP modify objects and calling > them a new invitation for an ATTENDEE. That may be how your product > does it, it is not in iTIP or iCAL. Thats how you try to confuse others here by misinterpreting things but thats not the way things work in iCalendar or iTIP (or several implementations). I case you haven't seen iTIP Section 3.2.2 REQUEST, let me try to help explain the use of the iTIP REQUEST method. It says, in part: The "REQUEST" method in a "VEVENT" component provides the following scheduling functions: . Invite "Attendees" to an event; . Reschedule an existing event; . Response to a REFRESH request; . Update the details of an existing event, without rescheduling it; . Update the status of "Attendees" of an existing event, without rescheduling it; . Reconfirm an existing event, without rescheduling it; as such, the REQUEST I send may be the initial invitation and the a reschedule from my POV. However, the recipent POV may interpret the reschedule as the initial invitation and the missequenced invitation as an obsolete message. Its all in how the messages arrive at the recipients side. Thats why we created Section 2.1.5 Message Sequencing and why we added the subsections of 3.2.2.[1..7]. > If you want to invite someone to an instance of a VEVENT that the you > have in your calendar, create a VEVENT REQUEST object and send it to them. > No RECURRENCE-ID needed. If its for an instance of a recurrence set then absolutely its needed. Otherwise you are referring to the entire set and NOT to an instance. This is also how you can do separate instance invitations to the same ATTENDEE at different times and NOT have to 'carpet bomb' their version and cause C&S workflow thrashing with other ATTENDEEs. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007C7C3A85256D7B_= Content-Type: text/html; charset="US-ASCII"
Doug thought on 08/07/2003 04:52:42 PM:
> >  > So, when creating a new VEVENT you can not be referring to an instance
> >  > that does not yet exist. As soon as the object exists it has an
> >  > implied RECURRENCE-ID for each effective DTSTART of each instance.
> >
> > And so after Ive created it in my calendar (at SEQUENCE:0) I can then
> > invite Satay to a particular instance only by using its RECURRENCE-ID in
> > the REQUEST.
>
> Only after his CUA has replied to SEQUENCE:0, will he know
> what the RECURRENCE-ID for SEQUENCE:0 is. So the first invitation
> to him can not contain both a RECRURRENE-ID and DTSTART, else
> it looks *exactly* like an iTIP modification to an instance to an
> existing VEVENT for which he does not have.

Wrong.  You clearly do not understand iTIP Section 3.2.2 REQUEST and the relevant subsections.  Section 3.2.2 tells you how to distinguish betweeen a new invitation and an update/reschedule.  That text that does is:

   The "UID" and "SEQUENCE" properties are used to distinguish the
  various uses of the "REQUEST" method. If the "UID" property value in
  the "REQUEST" is not found on the recipient's calendar, then the
  "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
  property value is found on the recipient's calendar, then the
  "REQUEST" is for a rescheduling, an update, or a reconfirm of the
  "VEVENT" calendar component.

So, if Satays CUA does not find UID / RECURRENCE-ID pair then by the 2nd sentence it will treat it like an invitation (or as iTIP says the ""REQUEST" is for a new "VEVENT" calendar component"; aka an invitation).  Had it found the UID / RECURRENCE-ID pair then by the last line it would treat it like an update.   This case is further detailed in iTIP Section 3.2.2.1 Rescheduling an Event.

>                                            As that is how you
> modify an existing VEVENT instance - supply the RECURRENCE-ID
> and DTSTART properties in a REQUEST - per iTIP.
That is also how you invite someone to the particular instance.  Thats why we have:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise it
                           MUST NOT be present.

in the REQUEST restriction table.  Since Im inviting Satay to a particular instance only, the RECURRENCE-ID value must be there.  Otherwise its referring to the entire set of instances which Satay was NOT invited to.  

> If it did not contain a RECURRENCE-ID, then as he did not have
> that UID it would look like a new REQUEST for a new object. But the fact
> that you add RECURRENCE-ID is how you say iTIP modify.
Nowhere in iTIP does it say that RECURRENCE-ID is ONLY allowed when 'modifying' (or updating to use the iTIP terminology) an instance.  The REQUEST is used for both the invite and the update/reschedule.  This overloading of REQUEST was a WG decision and as such it means that the meaning on the recipients side depends on the sequence the messages arrive in.

If I send 2 REQUESTs and they arrive in reverse order then the 1st one that arrives looks like the 'invitation' and the 2nd one looks like a stale message (after Ive processed the 1st to arrive that was actually the reschedule) even though thats now how they appeared to someone who receives them in the order sent.

With a fixed model, its no big deal.  With a delta model its grounds for confusion (and thus the need to carpet bomb all instances, see other post).

In any case, nowhere in iTIP did we ever say that you do not send RECURRENCE-ID on an initial invitation.  Besides, you have to send it if you only intend to invite them to the instance, thats what the restriction table say.  Ahh, you dont see "MUST if referring to an instnace..." so you think its not supposed to be there on the invite??...

> >  > The only times that RECURRENCE-ID can exist in a VEVENT is:
> >  >
> >  >     When REPLYing to an existing instance and if present indicates
> >  >     that the sender is only replying to that named instance.
> >  >
> >  >     Updating an existing instance in an existing recurrence set.
> >  >
> >  >     CANCELing an instance in an existing recurrence set.
> >
> > Umm, you forgot inviting someone initially to an instance of a
> > recurrence set.  REPLY is them responding to it, not my initial REQUEST
> > where its perfectly valid (and necessary).
>
> You forgot that iTIP an iCAL have no such concept in the way you have
> presented it. You keep sending out iTIP modify objects and calling
> them a new invitation for an ATTENDEE. That may be how your product
> does it, it is not in iTIP or iCAL.
Thats how you try to confuse others here by misinterpreting things but thats not the way things work in iCalendar or iTIP (or several implementations).

I case you haven't seen iTIP Section 3.2.2 REQUEST, let me try to help explain the use of the iTIP REQUEST method.  It says, in part:

   The "REQUEST" method in a "VEVENT" component provides the following
  scheduling functions:

    .  Invite "Attendees" to an event;
    .  Reschedule an existing event;
    .  Response to a REFRESH request;
    .  Update the details of an existing event, without rescheduling it;
    .  Update the status of "Attendees" of an existing event, without
       rescheduling it;
    .  Reconfirm an existing event, without rescheduling it;

as such, the REQUEST I send may be the initial invitation and the a reschedule from my POV.  However, the recipent POV may interpret the reschedule as the initial invitation and the missequenced invitation as an obsolete message.  Its all in how the messages arrive at the recipients side.  Thats why we created Section 2.1.5 Message Sequencing and why we added the subsections of 3.2.2.[1..7].

> If you want to invite someone to an instance of a VEVENT that the you
> have in your calendar, create a VEVENT REQUEST object and send it to them.
> No RECURRENCE-ID needed.
If its for an instance of a recurrence set then absolutely its needed.  Otherwise you are referring to the entire set and NOT to an instance.  This is also how you can do separate instance invitations to the same ATTENDEE at different times and NOT have to 'carpet bomb' their version and cause C&S workflow thrashing with other ATTENDEEs.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007C7C3A85256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 18:55: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 SAA07641 for ; Thu, 7 Aug 2003 18:55:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MlVqt053848 for ; Thu, 7 Aug 2003 15:47:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77MlVng053846 for ietf-calendar-bks; Thu, 7 Aug 2003 15:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MlUqt053835 for ; Thu, 7 Aug 2003 15:47:30 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32B7FD.5090701@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Aug 2003 18:17:46 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/07/2003 06:47:12 PM, Serialize complete at 08/07/2003 06:47:12 PM Content-Type: multipart/alternative; boundary="=_alternative 007A493685256D7B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007A493685256D7B_= Content-Type: text/plain; charset="US-ASCII" Doug was confused on 08/07/2003 04:35:09 PM: > > It does not matter that you never saw the SEQUENCE 0 thru 9 versions, > > the SEQUENCE:10 version obsoletes them anyway. If I had invited you at > > SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can > > correctly apply the iTIP message sequencing rules to detect that the > > message is obsolete and thus you ignore it (and the missequenced 9 too). > > So if SEQUNCE:10 is the following REQUEST VEVENT and is the FIRST > one to which I am invited: > > SEQUENCE:10 > RDATE: Jan-1 > RDATE: Jan-2 > RDATE: Jan-3 My example was for a particular instance at SEQUENCE:10 and your response was for the entire set I assume. This is mixing apples and kiwis. We've been discussing how instances are affected so lets try to stay focused shall we. However, since Doug suggested the example I think it important to analyze it for those who may not grasp the subtler problems or issues inherent in it. This example is for a world where the RECURRENCE-ID changes on each reschedule because the Organizer is asking the recipient to create the entire set w/the given RDATEs as RECURRENCE-IDs. Implicit in this are several assumptions like: 1: All instances share the exact same information and have no variations. In the real world I rarely hear of any repeating meetings that always exactly the same. At least the DESCRIPTION or something is usually different but perhaps I live in a bubble... 2: Updating or inviting to a particular instance is error prone because of message sequencing issues. Thus you have to take this kind of "carpet bombing" approach to flush out any potential instances the invitee already has. All because there is no way to match RECURRENCE-IDs at different SEQUENCE values when they in fact are the same instance. 3: If this fragment is to add a new ATTENDEE to all the instances (or a set of instances) then its assuming that all instances share the same SEQUENCE value. (Do they Doug???) Since each instance can have its own workflow independent of its peers and thus have different SEQUENCE values, doing this kind of setting SEQUENCE to 1 instances value means _all_ responses (REPLYs, COUNTERs, etc) from _all_ current ATTENDEEs at previously valid SEQUENCE values are NO LONGER VALID AND MUST BE renegotiated. #3 is quite significant so lets focus on it for a minute shall we. Lets say that RECURRENCE-ID:Jan-1 is at SEQUENCE:6, RECURRENCE-ID:Jan-2 is at SEQUENCE:10 and RECURRENCE-ID:Jan-3 is currently at SEQUENCE:4 since each can be has was negotiated separately. In order for the Dougs fragment to be usable by an invitee it means therefore then that the Organizer must rev the SEQUENCE values of all instances below SEQUENCE:10 up to 10. This means that any REPLYs (sic) current invitees send back that ordinarily would be valid (and thus accepted by the Organizer) are now 'obsolete' because they contain SEQUENCE:6 (for Jan-1) or SEQUENCE:4 (for Jan-3) which are now deemed "obsolete" by iTIP. As such they MUST be ignored (per iTIP) and a new REQUEST must be sent to the existing invitees too.. All this even though the ONLY thing that happened was that a new invitee got added. No reschedules happened, the Organizer just needed a fast way to get the recurrence set onto the new invitees calendar. Sounds like a great reason to invalidate all other REPLYs that would otherwise be acceptable. > Now I get a request to change the RECURRENCE-ID:Jan-4 to Jan-5 > because the original (SEQUENCE:0) RECURRENCE-ID for one of the > above instances was Jan-4. It is useless trash to the CUA at that point. Yep, its an example for the delta RECURRENCE-ID world. What he says is not legit in the fixed RECURRENCE-ID world and the fragment at top is equally malformed for the fixed model. Go see last months explcit examples if you want to see the details on how easy and non-destructive adding new invitees to an existing set is. > If updates and cancels do not apply to the current object (latest > REPLY'd UID/SEQUENCE/RECURRENE-ID set) You get the ordering wrong. iTIP says use UID / RECURRENCE-ID as primary keys and then you use SEQUENCE as the secondary key. This from Section 2.1.5 in case you need to check it out (or ignore it). You use UID / RECURRENCE-ID to find the specific instance. If you do not find a match then if you correctly apply iTIP 3.2.2 REQUEST you'd say that the UID / RECURRENCE-ID was not found and treat this as an initial invitation for the particular instance. If you find a match THEN you use SEQUENCE to see if your copy is obsolete or not. If your copy is obsolete (or you had to further use DTSTAMP to detect this) then you apply iTIP 3.2.2.1 Rescheduling an Event and treat it as the reschedule that it is. > and if a RECURRENCE-ID has changed > from the original (SEQUENCE:0) object, you can never send me updates > to instances as I do not have the original (SEQUENEC:0) object in > order to process the update or cancel. I guess you did not see iTIP Section 3.2.2 REQUEST when it says: If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. Since this is referring to a recurrance instance you should use "UID" / "RECURRENCE-ID" in place of "UID" in the text above (by Section 2.1.5 Message Sequencing bullet 1). If you do not find the UID / RECURRENCE-ID then its an invitation to the instance in question. No stuggling, no mess, no fuss, no ambiguity. > Is all that can be known is that one > might match the same effective DTSATRT value of SEQUENCE:10, but in the > examples you keep cutting out in your replies to my email - you can > break/fake the CUA into changing an incorrect instance LOCATION if > you fixate on SEQUENCE:0 instance times. It sounded like there was going to be a quesiton there but I only see a comment. If Im not redefining the recurrence set, merely rescheduling instances or adding ATTENDEEs then the RECURRENCE-ID will be the same at SEQUENCE:10 as it is for SEQUENCE:0. In additon adding a new ATTENDEE to any / all instances is SIMPLE and EASY without causing thrashing with the existing ATTENDEEs. The same cannot be said for the changing RECURRENCE-ID model. (See above for why.) > The RECURRENCE-ID changes as the booked UID/RECURRENCE-ID/SEQUENCE > changes. Else you can not add new ATTENDEEs if there has been > or will be a change to an effective DTSTART instance *if* your > model is correct. I gave full examples last month of exactly how a new ATTENDEE gets added after the fact to one or all instances so clearly you do not understand the examples or the explainations so far. The same examples can be used for the 'some' instances case too so dont try to claim that either. What I think some folks fail to realize is the behaviour implications of your model so I strongly urge everyone to be sure the points at the top are well understood, they should give you plenty of concern over using a 'delta' RECURRENCE-ID model. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007A493685256D7B_= Content-Type: text/html; charset="US-ASCII"
Doug was confused on 08/07/2003 04:35:09 PM:
> > It does not matter that you never saw the SEQUENCE 0 thru 9 versions,
> > the SEQUENCE:10 version obsoletes them anyway.  If I had invited you at
> > SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can
> > correctly apply the iTIP message sequencing rules to detect that the
> > message is obsolete and thus you ignore it (and the missequenced 9 too).
>
> So if SEQUNCE:10 is the following REQUEST VEVENT and is the FIRST
> one to which I am invited:
>
>    SEQUENCE:10
>    RDATE: Jan-1
>    RDATE: Jan-2
>    RDATE: Jan-3
My example was for a particular instance at SEQUENCE:10 and your response was for the entire set I assume.  This is mixing apples and kiwis.  We've been discussing how instances are affected so lets try to stay focused shall we.

However, since Doug suggested the example I think it important to analyze it for those who may not grasp the subtler problems or issues inherent in it.  This example is for a world where the RECURRENCE-ID changes on each reschedule because the Organizer is asking the recipient to create the entire set w/the given RDATEs as RECURRENCE-IDs.  Implicit in this are several assumptions like:

1: All instances share the exact same information and have no variations.  In the real world I rarely hear of any repeating meetings that always exactly the same.  At least the DESCRIPTION or something is usually different but perhaps I live in a bubble...

2: Updating or inviting to a particular instance is error prone because of message sequencing issues.  Thus you have to take this kind of "carpet bombing" approach to flush out any potential instances the invitee already has.  All because there is no way to match RECURRENCE-IDs at different SEQUENCE values when they in fact are the same instance.

3: If this fragment is to add a new ATTENDEE to all the instances (or a set of instances) then its assuming that all instances share the same SEQUENCE value.  (Do they Doug???)  Since each instance can have its own workflow independent of its peers and thus have different SEQUENCE values, doing this kind of setting SEQUENCE to 1 instances value means _all_ responses (REPLYs, COUNTERs, etc)  from _all_ current ATTENDEEs at previously valid SEQUENCE values are NO LONGER VALID AND MUST BE renegotiated.  

#3 is quite significant so lets focus on it for a minute shall we.  

Lets say that RECURRENCE-ID:Jan-1 is at SEQUENCE:6, RECURRENCE-ID:Jan-2 is at SEQUENCE:10 and RECURRENCE-ID:Jan-3 is currently at SEQUENCE:4  since each can be has was negotiated separately.  In order for the Dougs fragment to be usable by an invitee it means therefore then that the Organizer must rev the SEQUENCE values of all instances below SEQUENCE:10 up to 10.  This means that any REPLYs (sic) current invitees send back that ordinarily would be valid (and thus accepted by the Organizer) are now 'obsolete' because they contain SEQUENCE:6 (for Jan-1) or SEQUENCE:4 (for Jan-3) which are now deemed "obsolete" by iTIP.  As such they MUST be ignored (per iTIP) and a new REQUEST must be sent to the existing invitees too..  

All this even though the ONLY thing that happened was that a new invitee got added.  No reschedules happened, the Organizer just needed a fast way to get the recurrence set onto the new invitees calendar.  Sounds like a great reason to invalidate all other REPLYs that would otherwise be acceptable.  

> Now I get a request to change the RECURRENCE-ID:Jan-4 to Jan-5
> because the original (SEQUENCE:0) RECURRENCE-ID for one of the
> above instances was Jan-4. It is useless trash to the CUA at that point.
Yep, its an example for the delta RECURRENCE-ID world.  What he says is not legit in the fixed RECURRENCE-ID world and the fragment at top is equally malformed for the fixed model.  Go see last months explcit examples if you want to see the details on how easy and non-destructive adding new invitees to an existing set is.

> If updates and cancels do not apply to the current object (latest
> REPLY'd UID/SEQUENCE/RECURRENE-ID set)

You get the ordering wrong.  iTIP says use UID / RECURRENCE-ID as primary keys and then you use SEQUENCE as the secondary key.  This from Section 2.1.5 in case you need to check it out (or ignore it).

You use UID / RECURRENCE-ID to find the specific instance.  If you do not find a match then if you correctly apply iTIP 3.2.2 REQUEST you'd say that the UID / RECURRENCE-ID was not found and treat this as an initial invitation for the particular instance.  If you find a match THEN you use SEQUENCE to see if your copy is obsolete or not.  If your copy is obsolete (or you had to further use DTSTAMP to detect this) then you apply iTIP 3.2.2.1 Rescheduling an Event and treat it as the reschedule that it is.

>                                        and if a RECURRENCE-ID has changed
> from the original (SEQUENCE:0) object, you can never send me updates
> to instances as I do not have the original (SEQUENEC:0) object in
> order to process the update or cancel.

I guess you did not see iTIP Section 3.2.2 REQUEST when it says:

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

Since this is referring to a recurrance instance you should use "UID" / "RECURRENCE-ID" in place of "UID" in the text above (by Section 2.1.5 Message Sequencing bullet 1).  If you do not find the UID / RECURRENCE-ID then its an invitation to the instance in question.  No stuggling, no mess, no fuss, no ambiguity.

>                                        Is all that can be known is that one
> might match the same effective DTSATRT value of SEQUENCE:10, but in the
> examples you keep cutting out in your replies to my email - you can
> break/fake the CUA into changing an incorrect instance LOCATION if
> you fixate on SEQUENCE:0 instance times.
It sounded like there was going to be a quesiton there but I only see a comment.  

If Im not redefining the recurrence set, merely rescheduling instances or adding ATTENDEEs then the RECURRENCE-ID will be the same at SEQUENCE:10 as it is for SEQUENCE:0.  In additon adding a new ATTENDEE to any / all instances is SIMPLE and EASY without causing thrashing with the existing ATTENDEEs.  The same cannot be said for the changing RECURRENCE-ID model.  (See above for why.)

> The RECURRENCE-ID changes as the booked UID/RECURRENCE-ID/SEQUENCE
> changes. Else you can not add new ATTENDEEs if there has been
> or will be a change to an effective DTSTART instance *if* your
> model is correct.
I gave full examples last month of exactly how a new ATTENDEE gets added after the fact to one or all instances so clearly you do not understand the examples or the explainations so far.  The same examples can be used for the 'some' instances case too so dont try to claim that either.

What I think some folks fail to realize is the behaviour implications of your model so I strongly urge everyone to be sure the points at the top are well understood, they should give you plenty of concern over using a 'delta' RECURRENCE-ID model.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007A493685256D7B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 19:32: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 TAA08496 for ; Thu, 7 Aug 2003 19:32:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77NO8qt055202 for ; Thu, 7 Aug 2003 16:24:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77NO8TE055201 for ietf-calendar-bks; Thu, 7 Aug 2003 16:24:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77NO7qt055193 for ; Thu, 7 Aug 2003 16:24:07 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77NO5EB009599 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 16:24:07 -0700 Message-ID: <3F32DF90.1000706@Royer.com> Date: Thu, 07 Aug 2003 17:24:00 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080000010000050708020701" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080000010000050708020701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > >And what about the example I sent to this list that shows how > >your model broken in that area? You know the one that showed > >that new attendess in your model can not process instance > >changes unless they just happen to be the same as the SEQUENCE:0 > instances? > > Of course nothing works if you send your changing recurrence ids. This > is not the iCalendar RFC 2445 model. How about responding to the email that showed why your model is broken? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080000010000050708020701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIzMjQwMFowIwYJKoZIhvcNAQkEMRYEFIJha4Yo 3HRs3eoN58Mo+vHinxWZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEUIJyMQX/Wkn0vA4Na3VK9sLkYQIunC6W0A/COlVbygEjhFYg+/ KzSf4+N2KIDiPcIlaE4F3XGCT8KquxoCjoFGwP4Df02w808uUsjYWvTEn39/CaHhOun8uVUP 4jnHUhqReSx0WdVBDo3jOKuBTQQNKORdxz4tFKNhbkexm/fCLoBUbxS1vFiH0h3OWw6xiAAR cPq2JU+83rBJ2/sEXhVha0fZZJxBr7O94ZpAPAItHkIscTKfHO931jwhKxlQb40HF8TrSanj xesx5KlXvbjX15ZDW+G9acT1QGyc5U46QjZYRGM3Fw5tVioqNQxsu9d82BrnE93Y3RRJmseu 3X8AAAAAAAA= --------------ms080000010000050708020701-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 19:35: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 TAA08567 for ; Thu, 7 Aug 2003 19:35:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77NSRqt056335 for ; Thu, 7 Aug 2003 16:28:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77NSRio056334 for ietf-calendar-bks; Thu, 7 Aug 2003 16:28:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77NSPqt056329 for ; Thu, 7 Aug 2003 16:28:26 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77NSOEB009627 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 16:28:27 -0700 Message-ID: <3F32E092.3030301@Royer.com> Date: Thu, 07 Aug 2003 17:28:18 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010303010103000208070906" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010303010103000208070906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug thought on 08/07/2003 04:52:42 PM: > > > > So, when creating a new VEVENT you can not be referring to an > instance > > > > that does not yet exist. As soon as the object exists it has an > > > > implied RECURRENCE-ID for each effective DTSTART of each instance. > > > > > > And so after Ive created it in my calendar (at SEQUENCE:0) I can then > > > invite Satay to a particular instance only by using its > RECURRENCE-ID in > > > the REQUEST. > > > > Only after his CUA has replied to SEQUENCE:0, will he know > > what the RECURRENCE-ID for SEQUENCE:0 is. So the first invitation > > to him can not contain both a RECRURRENE-ID and DTSTART, else > > it looks *exactly* like an iTIP modification to an instance to an > > existing VEVENT for which he does not have. > > Wrong. You clearly do not understand iTIP Section 3.2.2 REQUEST and the > relevant subsections. Section 3.2.2 tells you how to distinguish > betweeen a new invitation and an update/reschedule. That text that does > is: > > The "UID" and "SEQUENCE" properties are used to distinguish the > various uses of the "REQUEST" method. If the "UID" property value in > the "REQUEST" is not found on the recipient's calendar, then the > "REQUEST" is for a new "VEVENT" calendar component. If the "UID" > property value is found on the recipient's calendar, then the > "REQUEST" is for a rescheduling, an update, or a reconfirm of the > "VEVENT" calendar component. And your still ignoring the part of iTIP that says to modify an event add the RECURRENCE-ID. So if you add a RECURRENCE-ID and then it looks *exactly* like an iTIP modification there is NO way to tell if you missed something. That model will not work. Is there ANY text in iCAL or iTIP that says there are two ways to invite someone, one that works all of the time including for single instance (without a RECURRECE-ID) that the one you keep asserting is your way? I anyone can send a REQUEST to an ATTENDEE for ANY time, why do you insist that RECURRECE-ID need be added? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010303010103000208070906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIzMjgxOFowIwYJKoZIhvcNAQkEMRYEFIcknafE bKBYc9u+Yjqv39mHNOdlMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAFEJJHkCQL1sabc02a4b9pq+WNZRvR7eLkRDGgpnU4o6Oo2LQ/yp t45CgAmOrXavyRLA2pvWbMi+P+fEXyw5UK2kYeHdHn7OaO/Up54BbGfqvdsiDQ/F6KL1HjWC i3CUTjLNMqCM+axcSJ7qW3vYxAWHcs9fIHixPBziQTWu3b6blr33wbQ/65FcodMG3s1PZ+KK DPdGsVrR2tuIedFU86ER9eRcokh+pwz5t/DloPpyta4+Mc81/XdqYdnifiC9Gc1z/qOSNTbt Q014YXN/Ml3w55GZ/uTpOGZ866N/ujNTBBy4auAqJstLPktZel3fACOjB7r6FKP4FcahFgl3 bYsAAAAAAAA= --------------ms010303010103000208070906-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 19:38: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 TAA08620 for ; Thu, 7 Aug 2003 19:38:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77NVuqt056449 for ; Thu, 7 Aug 2003 16:31:56 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77NVu12056448 for ietf-calendar-bks; Thu, 7 Aug 2003 16:31:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77NVsqt056443 for ; Thu, 7 Aug 2003 16:31:54 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h77NVsEB009654 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 16:31:56 -0700 Message-ID: <3F32E165.5090904@Royer.com> Date: Thu, 07 Aug 2003 17:31:49 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010108010104010108080209" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010108010104010108080209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug was confused on 08/07/2003 04:35:09 PM: > > > It does not matter that you never saw the SEQUENCE 0 thru 9 versions, > > > the SEQUENCE:10 version obsoletes them anyway. If I had invited > you at > > > SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can > > > correctly apply the iTIP message sequencing rules to detect that the > > > message is obsolete and thus you ignore it (and the missequenced 9 > too). > > > > So if SEQUNCE:10 is the following REQUEST VEVENT and is the FIRST > > one to which I am invited: > > > > SEQUENCE:10 > > RDATE: Jan-1 > > RDATE: Jan-2 > > RDATE: Jan-3 > > My example was for a particular instance at SEQUENCE:10 and your > response was for the entire set I assume. This is mixing apples and > kiwis. We've been discussing how instances are affected so lets try to > stay focused shall we. No, I am showing why your model does not work. Please respond to the text submitted. Why will you not respont to the problem that I submitted? Why? Your model is broken Bruce. You can not update that VEVENT can you Bruce? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010108010104010108080209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwNzIzMzE0OVowIwYJKoZIhvcNAQkEMRYEFJ1g+hFS Vftt+e2y+/6/CzjDwFvqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAG2NQ4UUpJU9JX2B6M5chLkBTLBCByQFewBPnzGPiqWFLo6HqII8 Y/ggCWqDHbquOi+L1z3nyZGWeQLbFcWNU2iQFrsd55Royfyckfa4bJ3q5bHm13npGzE97dAg 6EkJy3tisrLbrIUZtiOFlWLZr/bMhs/uG5RbPXkiWE1cbIPOFd+PETB3yeA1jaqZizjsLwz6 uQCBM54Tp0n3p2Ek9B+jL7nPR+HQLTo6ufNG47Wmb1YbKnes6h6ZuHQGw3Tvt0Iq9kYa5SMC TsYUxDLPno/+cXhI/IJ1KXGonOL/Yy+Ziw4kZoJmnitYHtpDuhk5QclzVzl8VnKWZ5NuFF0P TwUAAAAAAAA= --------------ms010108010104010108080209-- From owner-ietf-calendar@mail.imc.org Thu Aug 7 23:27: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 XAA13830 for ; Thu, 7 Aug 2003 23:27:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h783ILqt065830 for ; Thu, 7 Aug 2003 20:18:21 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h783IL2t065829 for ietf-calendar-bks; Thu, 7 Aug 2003 20:18:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h783IJqt065823 for ; Thu, 7 Aug 2003 20:18:19 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender)) by comcast.net (rwcrmhc13) with SMTP id <20030808031816015006il35e> (Authid: TimHare); Fri, 8 Aug 2003 03:18:16 +0000 Message-Id: <5.2.1.1.0.20030807223915.009f6cd0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 07 Aug 2003 23:16:48 -0400 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: RECURRENCE-ID discussion In-Reply-To: <3F32E165.5090904@Royer.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: OK - after some more of this back-and-forth on the RECURRENCE-ID discussion, and from some other reading and side e-mail pointing out to me that all occurrences of a recurrence set are not necessarily instantiated in the CS (for example infinitely recurring events), I now feel a little differently about some of this. Someone posted an example where you change the time for one of the "parts" of a recurrence set. To me that showed that the RECURRENCE-ID _does_ change, IF its identifier is defined as in the spec - basically the DTSTART of the instance. It _has_ to change, under that definition, if the time of the instance changes. This to me makes it easier for the CUA to determine the RECURRENCE-ID of an event (merely pick the starting timestamp) when making requests; this also explains to me that UID is the one and only "key" to my hypothetical CS "database". I think it _may_ cause some synchronization issues when a CUA and CS/CUA are looking at the same recurrence set but with different recurrence IDs [if A thinks the set consists of (x,y,z) and B thinks the set consists of (x,y,q)] but I _think_ the use of SEQUENCE resolves who wins in a "debate" situation. Now - whose model did I just say was OK and whose did I say was broken? I've been getting lost on that count. Have we been discussing the protocol, or potential implementations? Tim Hare Senior Systems Programmer Florida Department of Transportation From owner-ietf-calendar@mail.imc.org Fri Aug 8 03:39: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 DAA02275 for ; Fri, 8 Aug 2003 03:39:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h787V9qt087522 for ; Fri, 8 Aug 2003 00:31:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h787V9kd087521 for ietf-calendar-bks; Fri, 8 Aug 2003 00:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h787V7qt087514 for ; Fri, 8 Aug 2003 00:31:08 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19l1hx-0005U9-00 for ; Fri, 08 Aug 2003 09:30:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19l1gm-0005Qi-00 for ; Fri, 08 Aug 2003 09:29:28 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Fri, 8 Aug 2003 00:15:03 -0700 Lines: 38 Message-ID: References: <3F3039CC.2050101@Royer.com> <3F328D81.6020505@Royer.com> X-Complaints-To: usenet@main.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: Not that clarification helps at this point but here goes anyway. "Doug Royer" wrote in message news:3F328D81.6020505@Royer.com... > > > Michael Fair wrote: > > > If we followed the logic as either Bruce or Doug put it forth > > we find it impossible to get a changing RECURRENCE-ID: > > > > I first create an event: > > > > UID: 1 > > SEQUENCE: 0 > > RECURRENCE-ID: 20030805T180000Z > > DTSTART: 20030805T180000Z > > You can't create that VEVENT. You do not create a VEVENT > with a RECURRENCE-ID. Now assuming that you meant that > you created a VEVENT with that DTSTART, then later > you wanted to refer to that instance of that VEVENT, > then that would be the RECURRENCE-ID you would use > to refer to that instance. > > The RECURRENCE-ID is use to refer to an existing instance. The snippet was used in the context of establishing the instance I was going to be manipulating. I could have just as well said "First lets establish the instance we are going to play with". However, the mindset I had when writing that snippet was inviting a new ATTENDEE (the reader) to that particular instance of an existing recurring event. -- Michael -- From owner-ietf-calendar@mail.imc.org Fri Aug 8 03:40: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 DAA02293 for ; Fri, 8 Aug 2003 03:40:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h787TKqt087295 for ; Fri, 8 Aug 2003 00:29:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h787TJZr087294 for ietf-calendar-bks; Fri, 8 Aug 2003 00:29:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h787THqt087287 for ; Fri, 8 Aug 2003 00:29:18 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19l1g4-0005Pv-00 for ; Fri, 08 Aug 2003 09:28:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19l1g2-0005Pj-00 for ; Fri, 08 Aug 2003 09:28:42 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Thu, 7 Aug 2003 23:53:34 -0700 Lines: 258 Message-ID: References: <5.2.1.1.0.20030807223915.009f6cd0@mail.comcast.net> X-Complaints-To: usenet@main.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: > Now - whose model did I just say was OK and whose did I say was broken? > I've been getting lost on that count. Have we been discussing the protocol, > or potential implementations? At the moment you're in the delta RECURRENCE-ID camp otherwise known as Doug's camp on this thread. We've been discussing update semantics for recurring event instances. Most(All?) the major existing (not potential) implementations use the fixed REUCRRENCE-ID model. This is really the only tenable implementation and in addition is also very elegant (simple and efficient). Bruce's first email of 8/4/2003 does an extremely good job at pointing out the numerous flaws in the model where the RECURRENCE-ID changes. I should note here that I actually switched camps as a result of his email and ever since the world has gotten a lot clearer. ;) The RECURRENCE-ID doesn't have to change if an instance gets updated. There is one section of iTip that actually blatantly says that it does change, but when taken in the context of the rest of the protocols and actually having to implement it becomes very clear that this text is an error and needs to be updated. As Bruce has so eloquently pointed out if the RECURRENCE-ID changes, then a whole lot of things start to go wrong very easily, thrashing (lots of feedback loops trying to get resynchronized) abounds, and the whole system becomes very fragile overall in the presence of missed/lost messages. iTip very explicitly in multiple places all over the place goes through great pains to describe an implementation that is very tolerant of missed/lost messages and using a changing RECURRENCE-ID blatantly violates that principal. The lines in iTip, which those in the fixed RECURRENCE-ID camp have declared as an error and are invalid and MUST be ignored are: The property value is equal to the date/time of the instance. If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. Note that after the change has occurred, the "RECURRENCE-ID" has changed to the new "DTSTART" value. This should read something to the effect of: The property value is equal to the date/time of the orginal SEQUENCE: 0 instance. If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for the "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. Note that after the change has occurred, the "RECURRENCE-ID" is still at its original SEQUENCE: 0 value. While I would never advocate such a thing be done without serious deliberation, Bruce's first email of 8/4/2003 does such a good job of explaining how iCal is designed to function as a fixed RECURRENCE-ID (both technically and lexically) that the only conclusion I am left with is that those lines that are referrenced by the delta RECURRENCE-ID camp are really the only support for such a model and is incosistent with the intent of the protocol. Doug has currently asserted that certain things are impossible to do with a fixed RECURRENCE-ID model, but so far I have found all of his claims to be in error. The list is still busy responding to his claims but it is taking a while to sort it out. He has one particular example where he says: In Bruce's model you can NEVER add someone to the series of recurring VEVENT after any change that effects the effective DTSTART value of any instance as they could never be able to resolve the RECURRENCE-ID because they never had SEQUENCE:0. His claim seems to be based on at least two very false assumptions. The first mentioned above that an end user needs the SEQUENCE: 0 version in order to locate the instance in question, and from one of his other posts that a RECURRENCE-ID cannot exist in the creation of a VEVENT because its presence means an update to an instance that already exists when it actually doesn't exist. I'm not going to quote text just yet, but in following the reponses to these assertions by both Bruce, and Robert it was very clear to me that it is never required that a CUA have the SEQUENCE: 0 version in order to participate in a VEVENT series and/or instance thereof. To add an Attendee to an entire series you simply add the attendee to the latest SEQUENCE version of the UID with no RECURRENCE-ID and then send along with it all recurrences instances that have been updated and have SEQUENCE > 0 with the Attendee added. To invite an Attendee to a single recurrence instance you simply send them a copy of the latest UID/RECURRENCE-ID/SEQUENCE version with the attendee added and be done with it. Using a fixed RECURRENCE-ID model each instance has a fixed, unique, and permanent RECURRENCE-ID that is always the same regardless of which SEQUENCE version of the instance you happen to receive. The RECURRENCE-ID is listed in every instance object and that ID can accurately, permanently, and unambiguously identify each and every instance within the set regardless of missed messages, out of order processing, or other communication failure. If a VEVENT should show up that the existing calander isn't aware of then per the iTip rules that Bruce has referenced the CUA just poofs it into existence and starts working with it. It is treated as the initial invite and goes from there. As a result of the fixed RECURRENCE-ID model, any future or past messages the CUA might get that refer to that particular instance are easily, quickly, and unambiguously identified and processed. Using a delta RECURRENCE-ID model this kind of interaction (out of order processing) becomes very ugly very quickly. The single most blatant counter to any thought of using a delta RECURRENCE-ID is that it is completely intolerant of missing any message that modifies the start time of an instance. Contrary to the fixed RECURRENCE-ID model where these messages are processed with nothing but a passing notice that they were out of order. See Bruce's first 8/4/2003 email for details. Making the fixed model a technically more elegant model, you combine this with the numerous references that iTip must operate in the face of failed communication and a changing RECURRENCE-ID model quickly because an unworkable solution. There is an exception to the permanently fixed part above. If you should change the set, most likely because you changed the RULES that create the set, then the RECURRENCE-IDs may change (for instance, the VEVENT object said every Friday, and you changed it to every Monday - as a result of this, the new fixed RECURRENCE-ID for each instance will now reflect Mondays, and not Fridays as it was previously). However, this conversation is not dealing with changing the set description of the master VEVENT, it's dealing with updating instances that occur when that set description is instantiated. So in that limited context, the RECURRENCE-IDs are permanent. His second assertion, that the presence of a RECURRENCE-ID means an update to an existing instance, is also false as he puts it forth. iTip is very clear about what to do if the UID/RECURRENCE-ID pair exist in the calander store. You treat it as an update to this existing event. However, you have to fall back to other rules if the pair do not exist. Doug seems to have fallen into the belief that if you receive a message that has a UID/RECURRENCE-ID and you do not have an existing UID/RECURRENCE-ID to match that message that it is an iTip error. This is simply not true. The technical issues of both that there are absolutely cases where a RECURRENCE-ID MUST exist in the creation of a VEVENT and the technical requirement of being able to process out of order and lost messages aside, there are no sections in iTip that support his claims. He claims: " The only times that RECURRENCE-ID can exist in a VEVENT is: When REPLYing to an existing instance and if present indicates that the sender is only replying to that named instance. Updating an existing instance in an existing recurrence set. CANCELing an instance in an existing recurrence set. " He's probably not wrong about this, however he's using to narrow a vision of when a CUA might receive these messages and doesn't seem to realize that there are other portions of the text that tell a CUA how to handle unexpected messages. For instance the second item about updating. He's right in that I would be sending out an update to an existing instance of a recurring set, however he's wrong in that you the recipient would already know about it. An instance of a recurring event is a VEVENT in its own right. There is nothing that I have found in the text to make me believe otherwise and both technical implementation and comments by others smarter than I about this concur. Doug seems to believe that an instance of a recurring event only exists if the CUA happens to know about the master template. And indeed, everything he claims to be impossible seems to follow from this belief. If I send you a message that contains: UID: 1 SEQUENCE: 3 RECURRENCE-ID: 20031231T180000Z I am telling you about instance 20030101T120000Z of UID 1. Whether or not you previously knew about EVENT UID 1 or even SEQUENCE versions 0,1, and 2 is completely inconsequential. The rules of iTip as Bruce has referenced many times make this so. In fact, as per the "add an Attendee" subthread, this instance may be the only instance of UID 1 that you ever see. I might be kind enough to tell you about a second instance: UID: 1 SEQUENCE: 3 RECURRENCE-ID: 20041231T180000Z In which case you'd just add this VEVENT to your calander too. Again, not knowing about UID: 1, or SEQUENCE versions 0, 1, or 2 is harmless in a fixed RECURRENCE-ID model. If I should tell you about UID: 1 then you can interact with it and do more than just mess with the two individual instances I told you about, and if you receive info on SEQUENCE versions 0,1, and 2 you will dutifully ignore them. -- Michael -- "Tim Hare" wrote in message news:5.2.1.1.0.20030807223915.009f6cd0@mail.comcast.net... > > OK - after some more of this back-and-forth on the RECURRENCE-ID > discussion, and from some other reading and side e-mail pointing out to me > that all occurrences of a recurrence set are not necessarily instantiated > in the CS (for example infinitely recurring events), I now feel a little > differently about some of this. Someone posted an example where you change > the time for one of the "parts" of a recurrence set. To me that showed > that the RECURRENCE-ID _does_ change, IF its identifier is defined as in > the spec - basically the DTSTART of the instance. It _has_ to change, > under that definition, if the time of the instance changes. This to me > makes it easier for the CUA to determine the RECURRENCE-ID of an event > (merely pick the starting timestamp) when making requests; this also > explains to me that UID is the one and only "key" to my hypothetical CS > "database". I think it _may_ cause some synchronization issues when a > CUA and CS/CUA are looking at the same recurrence set but with different > recurrence IDs [if A thinks the set consists of (x,y,z) and B thinks the > set consists of (x,y,q)] but I _think_ the use of SEQUENCE resolves who > wins in a "debate" situation. > > > Tim Hare > Senior Systems Programmer > Florida Department of Transportation > > > From owner-ietf-calendar@mail.imc.org Fri Aug 8 07:03: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 HAA07669 for ; Fri, 8 Aug 2003 07:03:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78Ar3qt012033 for ; Fri, 8 Aug 2003 03:53:03 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78Ar3Rg012032 for ietf-calendar-bks; Fri, 8 Aug 2003 03:53:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78Ar0qt012026 for ; Fri, 8 Aug 2003 03:53:01 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19l4rK-0002wd-00 for ; Fri, 08 Aug 2003 12:52:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19l4rJ-0002wQ-00 for ; Fri, 08 Aug 2003 12:52:33 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Fri, 8 Aug 2003 01:54:47 -0700 Lines: 64 Message-ID: References: <3F32E092.3030301@Royer.com> X-Complaints-To: usenet@main.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 anyone can send a REQUEST > to an ATTENDEE for ANY time, why do you insist that RECURRECE-ID > need be added? I can't see how not using a RECURRENCE-ID is unambiguous. I mean let's take my now infamous UID: 1 Let's use the 3 recurrences that have come up, Jan-3, Jan-4, and Jan-5 Let's say that nothing has changed about the recurrence set, and these are the original SEQUENCE: 0 instance dates. Satay gets to be our venerable outsider. Let's say we want to invite Satay to the Jan-5 instance. Without the RECURRENCE-ID property as you've suggested, it would contain: UID: 1 SEQUENCE: 0 DTSTART: Jan-5 To which his reply I assume must contain: UID: 1 SEQUENCE: 0 How does this unambiguosly tell me which instance he's responding to. This is especially important if I also want to invite Satay the Jan-4 instance as well: UID: 1 SEQUENCE: 0 DTSTART: Jan-4 What is his CUA to do? Following the rules of iTip: UID: 1 already exists at SEQUENCE: 0 So it falls back to the DTSTAMP field to disambiguate. As a result, without the RECURRENCE-ID Satay can only be invited to one ambiguosly referenced instance of the recurring event. His reply to both will look identical to me save the DTSTAMP field, and not referencing any particular RECURRENCE-ID I will have no way to figure out which instance the two responses goes with. What if anything is missing? If I was to invite Satay to these instances I would send him messages that contain the RECURRENCE-ID I was inviting him to. He would treat them as an invite and send a REPLY that contained the RECURRENCE-ID. In fact this is the only workable method of inviting him to two instances of the same recurring event I can envision. -- Michael -- From owner-ietf-calendar@mail.imc.org Fri Aug 8 07:09: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 HAA07723 for ; Fri, 8 Aug 2003 07:09:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78B1Mqt012606 for ; Fri, 8 Aug 2003 04:01:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78B1MIh012605 for ietf-calendar-bks; Fri, 8 Aug 2003 04:01:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78B1Kqt012599 for ; Fri, 8 Aug 2003 04:01:20 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19l4zN-0003BP-00 for ; Fri, 08 Aug 2003 13:00:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19l4rO-0002wo-00 for ; Fri, 08 Aug 2003 12:52:38 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Fri, 8 Aug 2003 03:51:56 -0700 Lines: 482 Message-ID: References: <3F3039CC.2050101@Royer.com> <3F328D81.6020505@Royer.com> X-Complaints-To: usenet@main.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: "Doug Royer" wrote in message news:3F328D81.6020505@Royer.com... > > So now we go to update it again. If we look at the objects > > themselves. I specified that SEQUENCE: 1 of UID: 1, > > RECURRENCE-ID: ...T180000Z would DTSTART at ...T150000Z. > > Note that no where in this object did I ever say, "oh and > > by the way here's a new RECURRENCE-ID". So now we go > > to move it again. Here's where the disagreement is. > > You do not need to say 'oh and by the way here's a new RECURRENCE-ID' > because iCAL says: > > Purpose: This property is used in conjunction with the "UID" and > "SEQUENCE" property to identify a specific instance of a recurring > "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property > value is the effective value of the "DTSTART" property of the > recurrence instance. > > So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID > for that single instance object SEQUENCE:1 is the effective value > of the "DTSTART" property - ...T150000Z and not ..T180000Z. > > So after that point if you do an update to RECURRENEC-ID ..T180000Z, > there would be no object with that effective DTSTART date and > thus no RECURRENCE-ID to match. Indeed, I grant you that the use of the term "effective" does tend to call for the use of a changing RECURRENCE-ID. But it doesn't, and I'll show you why a little later. So further down in the IMAP definition, we find this text: For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. So here's how I read this: There is a UID which describes a recurrence set. That UID has a SEQUNCE value which identifies the set it describes. This reading is supported by the part that describes how the SEQUNCE changing reflects a set description change which in turn could modify the RECURRENCE-ID of the set instances. So for examples sake, let's again use UID: 1 and say that SEQUENCE: 0 describes every Friday this year. So for UID 1/SEQUENCE 0 the RECURRENCE-ID for each instance is "fixed" at the Fridays of this year. If I move one of those instances (say June, Friday the 13th) to Thursday. Then I update that particular instance's SEQUENCE to 1. This is only an update to the SEQUENCE for that specific instance's calendar component not for the parent UID 1 set descriptor. The UID/SEQUENCE pair has not been updated. The (UID-RECURRENCE-ID)/SEQUENCE pair (or triplet depending on how you want to describe it) has been updated and has no relevance to whethere or not the RECURRENCE-ID is fixed. This view is supported by order of precedence for locating an instance, first the UID, then the RECURRENCE-ID are primary lookup keys, the RECURRENCE-ID can be NULL which means different things in different contexts, and then the SEQUENCE is used as a secondary lookup. In other words, by moving an instance to Thursday I have not modified the description of the recurrence set specified by UID 1/SEQUENCE 0 and therefore the RECURRENCE-ID remains fixed. Consequently, for the pair UID 1/SEQUENCE 0, the RECURRENCE-ID for June, Friday the 13th remains fixed regardless of what I do that particular instance of UID 1 in the context of SEQUNCE 0. In essence, I've simply said that June, Friday the 13th's instance actually occurs on Thursday now. So let's go back to that other quote that seemed to imply a changing RECURRENCE-ID. > The property value is the effective value of the > "DTSTART" property of the recurrence instance. The "effective value" here is referencing the UID/SEQUENCE pair, not the effective value of an instance that's been updated. This must be the case because "for a given UID/SEQUENCE pair the RECURRENCE-ID value for a recurrence instance is fixed". However, if you update the recurrence set description, and consequently update SEQUENCE for that UID, then you must recalculate all the instances in the set and they may have a new DTSTART. To account for the ability for the RECURRENCE-ID to change in this way you must use "the effective value of the DTSTART propoerty of the recurrence instance". The only model under which all the paragraphs make sense is the one where the RECURRENCE-ID is fixed within a given set description of an event. The simplest way to express this in terms programmers can easily adhere to is that for a given UID/SEQUENCE pair (meaning a particular recurring set description) the RECURRENCE-ID value for a recurrence instance is fixed. Once UID 1/SEQUENCE 0 hits UID 1/SEQUENCE 1 (which would mean something significant about the set of instances has changed) all bets are off in regards to RECURRENCE-ID values that previously existed. > In Bruces model you can NEVER add someone to the series > of recurring VEVENT after any change that effects the > effective DTSTART value of any instance as they could never > be able to resolve the RECURRENCE-ID because they never > had SEQUENCE:0. This is just plain false. Given my "every Friday for this year" example above, with the June 13th modification to June 12th, to invite someone to the entire series I would send them a VEVENT REQUEST containing: UID: 1 SEQUENCE: 0 describing every Friday this year with them as an ATTENDEE and simoultaneously also send them a VEVENT REQUEST containing: UID: 1 RECURRENCE-ID: Friday, June 13th SEQUENCE: 1 describing Thrusday, June 12th with them as an ATTENDEE In "Bruce's model" I could even send those two objects out of order and you'd still be able to accurately process it which debunks your claim that they couldn't resolve the RECURRENCE-ID because they never had SEQUENCE: 0. I don't mean to be trolling here, but isn't it in fact the changing RECURRENCE-ID model that has the problem with dealing effectively with lost / missing messages? And lastly to cover the great example you offered: > For a single VEVENT REQUEST with three instance (COUNT=3 > in a RRULE). It has three RECURRENCE-ID's none of which > were ever explicitly created. > > So if the original REQUEST looks like this: > > METHOD:REQUEST > SEQUENCE:0 > DTSTART:20030805T180000Z > RRULE:FREQ=HOURLY;COUNT=3 > LOCATION:A > > Would have 3 RECURRENCE-ID's: > > ...T180000Z 1st instance (effective DTSTART) > ...T190000Z 2nd instance (effective DTSTART) > ...T200000Z 3rd instance (effective DTSTART) So good so far. > So now the ORGANIZER wants to change the 2nd instance to ..T193000Z. > So per iTIP they could send a new REQUEST SEQUENCE:1 : > > METHOD:REQUEST > SEQUENCE:1 > DTSTART:..T193000Z > RECURRNCE-ID:..T190000Z Also so good so far. > So once the CUA accepts the new SEQUENCE:1 object, the object > still has three RECURRENCE-ID's: > > ...T180000Z 1st instance (effective DTSTART) > ...T193000Z 2nd instance (effective DTSTART) > ...T200000Z 3rd instance (effective DTSTART) > > As the RECURRENCE-ID is the effective DTSTART value > of the instance. Oooops just violated: For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. Since you didn't provide a UID in your examples (how strange) let's go ahead and use UID: 1 First you defined UID 1 with three events, then you updated one of those instances. This was fine, but when you listed the new RECURRENCE-ID's you seemed to miss that you haven't redefined the recurrence set of UID 1, just updated the DTSTART of an instance whose effective DTSTART is still defined by UID 1/SEQUENCE 0. UID 1 and UID 1/RECURRENCE-ID ...T190000Z are two totally separate calendar components which each track there own SEQUENCE values. > Now change the 3rd instance of the SEQUENCE:1 object to ...T190000Z > and move its LOCATION to 'B'. > > METHOD:REQUEST > SEQUENCE:2 > DTSTART:..T200000Z > RECURRNCE-ID:..T190000Z > LOCATION:B Woaaahhh you have two problems here. First the 3rd instance is actually RECURRENCE-ID: ...T200000Z which you were trying to DTSTART to ...T190000Z and move to location B so you're example message wrong, but I can work with what you intended. The second problem is that you just jumped two SEQUENCE values when you've only made one change to this object. You haven't touched the 3rd instance prior to this point, and the update above to the second instance did not update UID: 1, it updated UID: 1/RECURRENCE-ID: ...T190000Z so this is actually a SEQUENCE: 1 move for UID: 1/RECURRENCE-ID: ...T200000Z. Remember that: UID: 1 and UID: 1/RECURRENCE-ID: ...T180000Z and UID: 1/RECURRENCE-ID: ...T190000Z and UID: 1/RECURRENCE-ID: ...T200000Z are totally separate objects which persist their own SEQUENCE. > So once the CUA accepts the new SEQUENCE:2 object, the object > still has three RECURRENCE-ID's (new effective DTSTART times): > > ...T180000Z 1st instance (effective DTSTART) > ...T190000Z 2nd instance (effective DTSTART) > (used to be the 3rd instance) > ...T193000Z 3rd instance (effective DTSTART) > (used to be the 2nd instance) This is actually totally screwed up at this point with exception of the first instance. There are four components involved in this event at this point and they are described as follows: UID: 1 - describes three instances starting an hour apart at Location: A UID: 1/RECURRENCE-ID: ...T180000Z - hasn't been touched at Location: A UID: 1/RECURRENCE-ID: ...T190000Z - DTSTART: ...T193000Z at Location: A UID: 1/RECURRENCE-ID: ...T200000Z - DTSTART: ...T190000Z at Location: B This is important to note for you to see the flaw in your later assertion that "in Bruce's model, you're broken". > Now change the SEQUENCE:2 2nd instance to ...T200000Z: This actually needs to read: "Now change the SEQUENCE:1 version of the 2nd instance to ...T200000Z" This will actually be a SEQUENCE: 2 update for the 2nd instance. > METHOD:REQUEST > SEQUENCE:3 > DTSTART:..T190000Z > RECURRNCE-ID:..T200000Z First off you totally screwed the pooch on mixing up the RECURRENCE-ID and DTSTART again. Secondly you're just being sloppy or you're getting models confused because up to now you seem to have been using a changing RECURRENCE-ID model which would make the ID for the 2nd instance ...T193000Z. > Now in Bruce's model, your broken because you just moved > the SEQUENCE:0, LOCATION:A meeting to ...T200000Z to LOCATION:A. > When in fact the move was to move the LOCAION:B meeting. > > Bruce's reply is to throw the object away and start over > because its impossible to resolve. Again, this is a totally bogus assertion. The above message should actually read: METHOD:REQUEST SEQUENCE:2 DTSTART:..T200000Z RECURRNCE-ID:..T190000Z I don't quite understand what you are asserting is broken. If you first create three events at Location: A, you then move the time on the second, and then the time and the location on the third, and then just the time again on the second. You end up with the first two events at location A, one starting at 1800Z, the other at 2000Z, and the thrid event at location B starting at 1900Z. What's broken about that? This would leave us with the following four objects: [Note: The first instance may or may not actually be represented in the calendar store since it was never actually modified from its original description] UID: 1 - describes three instances starting an hour apart at Location: A - SEQUENCE: 0 UID: 1/RECURRENCE-ID: ...T180000Z - hasn't been touched at Location: A - SEQUENCE: 0 UID: 1/RECURRENCE-ID: ...T190000Z - DTSTART: ...T200000Z at Location: A - SEQUENCE: 2 UID: 1/RECURRENCE-ID: ...T200000Z - DTSTART: ...T190000Z at Location: B - SEQUENCE: 1 > > Now I think this means that Doug is trying to say that > > the RECURRENCE-ID is set to the original value of the instance > > being modified which with a changing RECURRENCE-ID could be > > different. But I find it impossible for Doug to support > > this claim because as far as I can see there is no where in > > the text that allows one to set a before and after RECURRENCE-ID. > > So the only way to get a differing RECURRENCE-ID is for CS/CUA > > to proactively change it on its own accord which the message > > never specifies to do. > > You do not change RECURRENCE-ID's directly. You update the object > in ways that alter the effective DTSTART value for an instance. The "effective DTSTART" is per the UID / SEQUENCE set description pair, not the UID/RECURRENCE-ID / SEQUENCE pair. Otherwise you conflict with: For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. > And as its effective DTSTART value is changed, thus its RECRRENCE-ID > changes to match its effective DTSTART value. And: > > (iTIP) > An instance of a recurring event is assigned a unique identification, > "RECURRENCE-ID" property, when that instance is renegotiated. > Negotiation may be necessary when a substantive change to the event > or to-do has be made (such as changing the start time, end time, due > date or location). The "Organizer" can identify a specific recurrence > instance using the "RECURRENCE-ID" property. The property value is > equal to the date/time of the instance. If the "Organizer" wishes to > change the "DTSTART", the original "DTSTART" value is used for > "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values > reflect the change. Note that after the change has occurred, the > "RECURRENCE-ID" has changed to the new "DTSTART" value. > > You do not 'set' the 'before' and 'after' RECURRENCE-ID, you > alter the effective DTSTART directly by updating one or more > instances and the RECURRENCE-ID is defined to match the > new effective DSTART. I hold that the "Note" mentioned above which is a main crux for the changing RECURRENCE-ID understanding is an actual RFC error and was not the intent of the authors. That text appears in one place, however in numerous places throughout the RFC iTip goes to great pains on several occasions to talk about how iTip must be tolerant of missed/lost messages. In the changing RECURRENCE-ID model this idiom is severely violated since it is not tolerant at all to missequenced messages and especially volatile in the presence of lost messages. Further, the "effective DTSTART", is the DTSTART of the instance as described by the recurrence set in the event object and not the current DTSTART for any given instance. Ok, now this next part we all totally agree on!!!! > Another way to change the RECURRENCE-ID's is to alter the times > an existing VEVENT. So if the SEQUENCE:0 object were: > > METHOD:REQUEST > SEQUENCE:0 > DTSTART:20030805T180000Z > RRULE:FREQ=HOURLY;COUNT=3 > LOCATION:A > > Would have 3 RECURRENCE-ID's: > > ...T180000Z 1st instance (effective DTSTART) > ...T190000Z 2nd instance (effective DTSTART) > ...T200000Z 3rd instance (effective DTSTART) > > If the ORGANIZER sent a SEQUENCE:1 : > > METHOD:REQUEST > SEQUENCE:1 > DTSTART:20030805T180000Z (same as the SEQUENCE:0 value) > RRULE:FREQ=HOURLY;COUNT=3;INTERVAL=2 > LOCATION:A > > The SEQUENCE:1 object would 3 RECURRENCE-ID's 2 of which > are different than the SEQUENEC:0 object: > > ...T180000Z 1st instance (effective DTSTART) > ...T200000Z 2nd instance (effective DTSTART) > ...T220000Z 3rd instance (effective DTSTART) > > The ORGANIZER moved two instances and their effective > DTSTART values (RECURRENCE-ID). Absosmurfly! Without question! and with violent agreement, Yes! Updating to SEQUENCE: 1 on the base event object, by for instance doing a recurrence set description update like the above, in every way, shape, and form throws all RECURRENCE-IDs from the SEQUENCE: 0 version into doubt. I am in total agreement, as is Bruce from what I've read, that this kind of change, one in which no RECURRENCE-ID is referenced to limit the scope to a single instance but instead operates on the whole set of instances, totally presents the possibility that the RECURRENCE-ID of the instances will change. In fact, the new RECURRENCE-ID will be the bewly updated "effective DTSTART" value. This new set of RECURRENCE-IDs will remain "fixed" for as long as the event set descriptor maintains its same SEQUENCE value. Should another change update the set descriptor object to SEQUENCE: 2, the entire set of RECURRENCE-ID MUST be recalculated to their new effective DTSTART values. It seems to me that main crux to the differences here is a different understanding in the handling of the SEQUENCE values in relationship to the several calendar components that exist to serve a single recurring event. I'm too tired to look it up now, but the section on what objects must persist under what circumstances should clear up that issue. So at the moment, given lack of text to back me up, I can only contend that the RFCs specify that for each recurring event there are two types of calendar components. One type is the event descriptor itself (UID with no RECURRENCE-ID) and the other type is a recurrence instance within that set (UID and RECURRENCE-ID) and that every one of these objects tracks its own independent SEQUENCE value. -- Michael -- From owner-ietf-calendar@mail.imc.org Fri Aug 8 12:32: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 MAA16919 for ; Fri, 8 Aug 2003 12:32:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GFCqt038320 for ; Fri, 8 Aug 2003 09:15:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78GFBlB038317 for ietf-calendar-bks; Fri, 8 Aug 2003 09:15:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GFAqt038308 for ; Fri, 8 Aug 2003 09:15:11 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32BF48.8000804@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 8 Aug 2003 11:55:22 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/08/2003 12:14:54 PM, Serialize complete at 08/08/2003 12:14:54 PM Content-Type: multipart/alternative; boundary="=_alternative 005743A185256D7C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005743A185256D7C_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 08/07/2003 05:06:16 PM: > > Umm, I dont think you got my meaning. If you create the VEVENT > > recurrence instances at SEQUENCE:0 then by defintion you've assigned > > each instance its RECURRENCE-ID then. You had said that it didnt happen > > until SEQUENCE:1. > > I said no such thing. > > I said: > So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID > for that single instance object SEQUENCE:1 is the effective value > of the "DTSTART" property - ...T150000Z and not ..T180000Z. > > I made no mention of the SEQUENCE:0 RECURRENCE-ID which is > known to the ATTENDEE CUA after (or when) then REPLY to the SEQUENCE:0 > object is made. The implication I got was that there was no RECURRENCE-ID assigned until the SEQUENCE:1 version was booked since you made no mention of all about the RECURRECE-ID for the SEQUENCE:0 versions REQUEST. I didnt intend to misquote you. In any case, the RECURRENCE-ID from the SEQUENCE:0 REQUEST is assigned when the instances are created; thats the original DTSTART value of each instance. As such it exists and is (or can be) used before the SEQUENCE:1 REQUEST arrives. Its perfectly legal for an invitee to send back a REPLY at SEQUENCE:0 for a particular RECURRENCE-ID and not have to wait for SEQUENCE:1. After all its perfectly valid to accept/decline/counter/delegate a particular SEQUENCE:0 instance and as such the RECURRENCE-ID in that REPLY must match. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005743A185256D7C_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 08/07/2003 05:06:16 PM:
> > Umm, I dont think you got my meaning.  If you create the VEVENT
> > recurrence instances at SEQUENCE:0 then by defintion you've assigned
> > each instance its RECURRENCE-ID then.  You had said that it didnt happen
> > until SEQUENCE:1.
>
> I said no such thing.
>
> I said:
>    So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID
>    for that single instance object SEQUENCE:1 is the effective value
>    of the "DTSTART" property - ...T150000Z and not ..T180000Z.
>
> I made no mention of the SEQUENCE:0 RECURRENCE-ID which is
> known to the ATTENDEE CUA after (or when) then REPLY to the SEQUENCE:0
> object is made.
The implication I got was that there was no RECURRENCE-ID assigned until the SEQUENCE:1 version was booked since you made no mention of all about the RECURRECE-ID for the SEQUENCE:0 versions REQUEST.  I didnt intend to misquote you.  

In any case, the RECURRENCE-ID from the SEQUENCE:0 REQUEST is assigned when the instances are created; thats the original DTSTART value of each instance.  As such it exists and is (or can be) used before the SEQUENCE:1 REQUEST arrives.

Its perfectly legal for an invitee to send back a REPLY at SEQUENCE:0 for a particular RECURRENCE-ID and not have to wait for SEQUENCE:1.  After all its perfectly valid to accept/decline/counter/delegate a particular SEQUENCE:0 instance and as such the RECURRENCE-ID in that REPLY must match.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005743A185256D7C_=-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 12:33:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16949 for ; Fri, 8 Aug 2003 12:33:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GJ8qt038430 for ; Fri, 8 Aug 2003 09:19:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78GJ7DI038429 for ietf-calendar-bks; Fri, 8 Aug 2003 09:19:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GJ2qt038416 for ; Fri, 8 Aug 2003 09:19:03 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h78GIgEB016892 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 8 Aug 2003 09:18:47 -0700 Message-ID: <3F33CD59.4070509@Royer.com> Date: Fri, 08 Aug 2003 10:18:33 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090208030400090808060408" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090208030400090808060408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>I anyone can send a REQUEST >>to an ATTENDEE for ANY time, why do you insist that RECURRECE-ID >>need be added? > > > I can't see how not using a RECURRENCE-ID is unambiguous. > > I mean let's take my now infamous UID: 1 > Let's use the 3 recurrences that have come up, > Jan-3, Jan-4, and Jan-5 > > Let's say that nothing has changed about the recurrence > set, and these are the original SEQUENCE: 0 instance dates. > > Satay gets to be our venerable outsider. > > Let's say we want to invite Satay to the Jan-5 instance. > > Without the RECURRENCE-ID property as you've suggested, > it would contain: > UID: 1 > SEQUENCE: 0 > DTSTART: Jan-5 > > To which his reply I assume must contain: > UID: 1 > SEQUENCE: 0 > > How does this unambiguosly tell me which instance he's > responding to. All of them that he was invited to attend. Your thinking of exactly one instance at a time. What if I want someone to attend instances 3,6,14? If you add the RECURRENCE-ID you have to to send 3 REQUESTs and get 3 REPLYs. It is not needed. Just send that ATTENDEE a single REQUEST with the dates/times they are requested to attend. (see how to disambiguate below) I can't believe that any CUA that allows the CU to invite an attendee to one or more specific instances is going to rely on the REPLY's coming back from the ATTENDEE to tell the ORGANIZER when the ATTENDEEs are invited. The ORGANIZER-CUA is going to already know who they invited to what instances. The ORGANIZERs CUA is already going to have to track objects sent that are waiting replies. Match them up which is what you are going to have to do anyway in order to clean up the CUAs pending things to care about queue. Send an iTIP REQUEST and process an iTIP REPLY. No new method needed. No need to confuse a new invitation with a modification to an existing instance. > This is especially important if I also want to invite > Satay the Jan-4 instance as well: > UID: 1 > SEQUENCE: 0 > DTSTART: Jan-4 > > What is his CUA to do? > Following the rules of iTip: > UID: 1 already exists at SEQUENCE: 0 > So it falls back to the DTSTAMP field to disambiguate. > > As a result, without the RECURRENCE-ID Satay can only > be invited to one ambiguosly referenced instance of > the recurring event. With the RECURRENCE-ID you can only specify exactly one instance of a recurring event. Did you say that backwards? > His reply to both will look > identical to me save the DTSTAMP field, and not > referencing any particular RECURRENCE-ID I will have > no way to figure out which instance the two responses > goes with. > > What if anything is missing? iTIP already covers this, send them a new REQUEST/VEVENT with the newest dates they are requested to attend. The newer object overrides the older. No need to invent another method to do the same thing. That's why DTSTAMP is in the object. To disambiguate exactly these kind of cases. Another option is to track the SEQUENCE per recurrence-rule-set per UID. There is NO requirement that all ATTENDEEs see the same objects. Then just bump the SEQUENCE number for each unique ATTENDEE recurrence-rule=set sent - them map them back on REPLYs in the CUA. Another bug is that iTIP already says that if you add RECURRECE-ID you are telling them to MODIFY the instance. Your adding an ambiguity. If they do not have that UID, then they could only make one conclusion, they missed the original because they now have a modification. Now they have to guess, did I miss the original that this is an update to?; or is this a new invitation? If there does need to be a new way to invite someone (And I have not seen any that are not already covered in iTIP), make up a method that can not be confused with an instance modification to a missed object. > If I was to invite Satay to these instances I would > send him messages that contain the RECURRENCE-ID I > was inviting him to. He would treat them as an > invite and send a REPLY that contained the RECURRENCE-ID. This is new method of inviting someone that has not beep proposed but has been declared as a solution to a problem that already had a solution. > In fact this is the only workable method of inviting > him to two instances of the same recurring event I > can envision. Simply send him a REQUEST/VEVENT with the dates that he is requested to attend and process the replies. Ether by issuing a new multi-instance (contains recurrence rules) REQUEST/VEVENT with a new DTSTAMP, or map the SEQUENCE/UID/recurrence-rule-sets and map the replies at the CUA. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090208030400090808060408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwODE2MTgzM1owIwYJKoZIhvcNAQkEMRYEFLM/3cy9 svBobcsnFxOLC1ozQdYEMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBABzolTo8jM6mYt0oOnIK77V7PsELeoj5Wlu6gxbvkMidb+S0EylF 6KzyOgABBoVHi5RpgdhGUj6QRgNVbbURbCisJEFWM4ABm5eBohyY+Uv/eLLYSV0AG/7bHfVQ iQUyVgmJgcpFpHVS/u7S+Rb67kENaD2tuyuSaZst/wYTdz3Y+eBRpzhjBJcAzfW/4R4SCvWY D7U3v2dISWDg4giOCgQ9cQjrjSX9khCQnpgT1n5EoSqbcDhKuivqqspbZntrWbtj7FH8jc5a jfJlFHpnAG8gNICTpznQNAyXGPE77FNBjzq1ApkmEdlxqqdL866W21uY0ayD1qaHL5iFNrMT SuQAAAAAAAA= --------------ms090208030400090808060408-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 12:33: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 MAA16967 for ; Fri, 8 Aug 2003 12:33:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GFFqt038326 for ; Fri, 8 Aug 2003 09:15:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78GFElD038325 for ietf-calendar-bks; Fri, 8 Aug 2003 09:15:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GFAqt038307 for ; Fri, 8 Aug 2003 09:15:11 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32BFE8.8040004@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 8 Aug 2003 12:14:21 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/08/2003 12:14:54 PM, Serialize complete at 08/08/2003 12:14:54 PM Content-Type: multipart/alternative; boundary="=_alternative 005900B685256D7C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005900B685256D7C_= Content-Type: text/plain; charset="US-ASCII" Doug said on 08/07/2003 05:08:56 PM: > > > And you can not create a VEVENT with a RECURRENCE-ID property in it. > > > > You certainly can Doug. If I want to invite you to a particular > > instance of a repeat set I would exactly send that iTIP fragment. > > > > You dont get the instances you are not invited to; you'd have no way to > > know you were not being invited to them! > > And it does not contain a RECURRENCE-ID, else it is not a new invitation, > its a iTIP modify to an existing VEVENT. So, no you can not. > If it contains a RECURRENCE-ID and a DTSTART and METHOD:REQUEST, > then it is a modification to an existing VEVENT, not a new > invitation. Its becoming clear to me that you are not quite clear on the concepts of message sequencing or missequencing or message loss. There is NOTHING in iTIP that says "An invitation has no RECURRENCE-IDs" or "You cannot/MUST NOT use RECURRENCE-IDs in an invitation" or "The REQUEST at some magic SEQUENCE value is an invitation, all others are reschedules.", etc. Its perfectly legal and valid to have a REQUEST for SEQUENCE:0 with a UID and RECURRENCE-ID if you are only inviting someone to a particular instance of the set. A simple example of this is I schedule a repeating meeting with Bob and Pat and they both accept all instances. Pat also sends back a COMMENT:Shouldnt Doug come to Fridays Social? I agree so I select the Friday instance and add you which results in a SEQUENCE:0, RECURRENCE-ID: REQUEST being sent to you. You should apply iTIP Section 2.1.5 Message Sequencing rules and the text from 3.2.2 (below) to treat it as an invitation. No need for me to rev SEQUENCE to 1 just because I add you. Doing so would just invalidate the participation status of Bob and Pat so Id have to reREQUEST them... Because of message sequencing concerns what the Organzier sends as a reschedule may be the only REQUEST received by the invitee and thus they rightly view it as an invitation. We have no defined settings or property combinations that differentiate invite from reschedule from non-reschedule update from anything else. The distinction is inferred by the recipient based on the properties in it. This is described in iTIP with text like: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. from 3.2.2 REQUEST or from 3.2.2.1 Rescheduling an Event: The "REQUEST" method may be used to reschedule an event. A rescheduled event involves a change to the existing event in terms of its time or recurrence intervals and possibly the location or description. If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is greater than the value for the existing event, then the "REQUEST" method describes a rescheduling of the event. Because iTIP messages are not guaranteed to arrive in any particular order (or can even be lost), we created the guidelines in Section 2.1.5 Message Sequencing to be applied to all iTIP methods and thats exactly why each methods data is totally self contained and NEVER relys on any data from previous messages. However, if you build a delta RECURRENCE-ID model then you have just built an implicit reliance on each and every iTIP REQUEST being deliverable and in order at that. This is a poor design because this reliance is not always possible and thus fault prone and hard to recover from. Perhaps I need to put out an example w/iTIP fragments to demonstrate this but in the mean time I would suggest that you go reread iTIP regarding message sequencing and how the recipient is supposed to treat/decode the REQUEST, etc. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005900B685256D7C_= Content-Type: text/html; charset="US-ASCII"
Doug said on 08/07/2003 05:08:56 PM:
> >  > And you can not create a VEVENT with a RECURRENCE-ID property in it.
> >
> > You certainly can Doug.  If I want to invite you to a particular
> > instance of a repeat set I would exactly send that iTIP fragment.  
> >
> > You dont get the instances you are not invited to; you'd have no way to
> > know you were not being invited to them!
>
> And it does not contain a RECURRENCE-ID, else it is not a new invitation,
> its a iTIP modify to an existing VEVENT. So, no you can not.
> If it contains a RECURRENCE-ID and a DTSTART and METHOD:REQUEST,
> then it is a modification to an existing VEVENT, not a new
> invitation.
Its becoming clear to me that you are not quite clear on the concepts of message sequencing or missequencing or message loss.

There is NOTHING in iTIP that says "An invitation has no RECURRENCE-IDs" or "You cannot/MUST NOT use RECURRENCE-IDs in an invitation" or "The REQUEST at some magic SEQUENCE value is an invitation, all others are reschedules.", etc.

Its perfectly legal and valid to have a REQUEST for SEQUENCE:0 with a UID and RECURRENCE-ID if you are only inviting someone to a particular instance of the set.  A simple example of this is I schedule a repeating meeting with Bob and Pat and they both accept all instances.  Pat also sends back a COMMENT:Shouldnt Doug come to Fridays Social?  I agree so I select the Friday instance and add you which results in a SEQUENCE:0, RECURRENCE-ID:<Friday> REQUEST being sent to you.  You should apply iTIP Section 2.1.5 Message Sequencing rules and the text from 3.2.2 (below) to treat it as an invitation.  No need for me to rev SEQUENCE to 1 just because I add you.  Doing so would just invalidate the participation status of Bob and Pat so Id have to reREQUEST them...

Because of message sequencing concerns what the Organzier sends as a reschedule may be the only REQUEST received by the invitee and thus they rightly view it as an invitation.   We have no defined settings or property combinations that differentiate invite from reschedule from non-reschedule update from anything else.  The distinction is inferred by the recipient based on the properties in it.  This is described in iTIP with text like:

   The "UID" and "SEQUENCE" properties are used to distinguish the
  various uses of the "REQUEST" method. If the "UID" property value in
  the "REQUEST" is not found on the recipient's calendar, then the
  "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
  property value is found on the recipient's calendar, then the
  "REQUEST" is for a rescheduling, an update, or a reconfirm of the
  "VEVENT" calendar component.

from 3.2.2 REQUEST or from 3.2.2.1 Rescheduling an Event:

   The "REQUEST" method may be used to reschedule an event. A
  rescheduled event involves a change to the existing event in terms of
  its time or recurrence intervals and possibly the location or
  description. If the recipient CUA of a "REQUEST" method finds that
  the "UID" property value already exists on the calendar, but that the
  "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
  greater than the value for the existing event, then the "REQUEST"
  method describes a rescheduling of the event.

Because iTIP messages are not guaranteed to arrive in any particular order (or can even be lost), we created the guidelines in Section 2.1.5 Message Sequencing to be applied to all iTIP methods and thats exactly why each methods data is totally self contained and NEVER relys on any data from previous messages.  

However, if you build a delta RECURRENCE-ID model then you have just built an implicit reliance on each and every iTIP REQUEST being deliverable and in order at that.  This is a poor design because this reliance is not always possible and thus fault prone and hard to recover from.

Perhaps I need to put out an example w/iTIP fragments to demonstrate this but in the mean time I would suggest that you go reread iTIP regarding message sequencing and how the recipient is supposed to treat/decode the REQUEST, etc.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005900B685256D7C_=-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 12:48: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 MAA17292 for ; Fri, 8 Aug 2003 12:48:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GbRqt039076 for ; Fri, 8 Aug 2003 09:37:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78GbRmQ039075 for ietf-calendar-bks; Fri, 8 Aug 2003 09:37:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GbQqt039070 for ; Fri, 8 Aug 2003 09:37:26 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32C0C6.1040804@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 8 Aug 2003 12:23:31 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/08/2003 12:37:09 PM, Serialize complete at 08/08/2003 12:37:09 PM Content-Type: multipart/alternative; boundary="=_alternative 0059D7B385256D7C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059D7B385256D7C_= Content-Type: text/plain; charset="US-ASCII" Doug noted on 08/07/2003 05:12:38 PM: > > > For REPLY, Single instance update, moving an instance, canceling and > > > instance, but not creating a recurrence set even when the recurrence > > > set has only one instance. > > > > Err, that restriction table snippet came from iTIP Section 3.2.2 REQUEST > > and clearly matches the iTIP note: > > > > . Reschedule an existing event; > > > > Just because we didnt espressly write "Reschedule an existing event [or > > a particular instance or range of instances of a repeating event]" every > > time does not mean it does not work refer to just a particular instance > > only. > > Yes you can also use RANGE if that is what you meant to say. RANGEs are a whole other ball of wax that are not germane to this thread. My point is that you did NOT list RECURRENCE-ID as being valid on a REQUEST as an invitation too which I pointed out it was. Also, what you said about creating a recurrence set of 1 instance is NOT something that iCalendar/iTIP consider repeating. If there are no repeat instances then its non-repeating and has no RECURRNECE-ID. Being invited to a single instance is NOT the same as saying there is only 1 instance in the repeat set. The invitee only knows about the instances they are involved with, the Organzier who owns it knows of them all! (You did say "set even when the recurrence set has only one instance." right??.. so Im not misquoting you). Do not assume that each ATTENDEE knows about each and every instance; that is not required by the RFCs nor it is logical from a workflow point of view. There is no way to distinguish those instances you were actually invited to from those you are just told about so you can ignore or so you can roll out some RECURRENCE-IDs from, As such, REQUESTs only refer to instance(s) involved in invitations, reschedules, etc and do not refer to instances that are not relevant to the Organziers intent. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0059D7B385256D7C_= Content-Type: text/html; charset="US-ASCII"
Doug noted on 08/07/2003 05:12:38 PM:
> >  > For REPLY, Single instance update, moving an instance, canceling and
> >  > instance, but not creating a recurrence set even when the recurrence
> >  > set has only one instance.
> >
> > Err, that restriction table snippet came from iTIP Section 3.2.2 REQUEST
> > and clearly matches the iTIP note:
> >
> >      .  Reschedule an existing event;
> >
> > Just because we didnt espressly write "Reschedule an existing event [or
> > a particular instance or range of instances of a repeating event]" every
> > time does not mean it does not work refer to just a particular instance
> > only.  
>
> Yes you can also use RANGE if that is what you meant to say.
RANGEs are a whole other ball of wax that are not germane to this thread.  My point is that you did NOT list RECURRENCE-ID as being valid on a REQUEST as an invitation too which I pointed out it was.

Also, what you said about creating a recurrence set of 1 instance is NOT something that iCalendar/iTIP consider repeating.  If there are no repeat instances then its non-repeating and has no RECURRNECE-ID.  Being invited to a single instance is NOT the same as saying there is only 1 instance in the repeat set.  The invitee only knows about the instances they are involved with, the Organzier who owns it knows of them all!  (You did say "set even when the recurrence set has only one instance." right??.. so Im not misquoting you).  

Do not assume that each ATTENDEE knows about each and every instance; that is not required by the RFCs nor it is logical from a workflow point of view.  There is no way to distinguish those instances you were actually invited to from those you are just told about so you can ignore or so you can roll out some RECURRENCE-IDs from,  As such, REQUESTs only refer to instance(s) involved in invitations, reschedules, etc and do not refer to instances that are not relevant to the Organziers intent.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0059D7B385256D7C_=-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 13:01: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 NAA17625 for ; Fri, 8 Aug 2003 13:01:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GqVqt040167 for ; Fri, 8 Aug 2003 09:52:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78GqVaO040166 for ietf-calendar-bks; Fri, 8 Aug 2003 09:52:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78GqTqt040160 for ; Fri, 8 Aug 2003 09:52:29 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h78GqMEB017142 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 8 Aug 2003 09:52:29 -0700 Message-ID: <3F33D541.9090601@Royer.com> Date: Fri, 08 Aug 2003 10:52:17 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F3039CC.2050101@Royer.com> <3F328D81.6020505@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020000060101060108070009" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020000060101060108070009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > > > So further down in the IMAP definition, we find this text: > > For a given pair of "UID" and "SEQUENCE" property values, > the "RECURRENCE-ID" value for a recurrence instance is fixed. > > So here's how I read this: > There is a UID which describes a recurrence set. That UID has > a SEQUNCE value which identifies the set it describes. This > reading is supported by the part that describes how the SEQUNCE > changing reflects a set description change which in turn could > modify the RECURRENCE-ID of the set instances. > > So for examples sake, let's again use UID: 1 > and say that SEQUENCE: 0 describes every Friday this year. > > So for UID 1/SEQUENCE 0 the RECURRENCE-ID for each instance > is "fixed" at the Fridays of this year. If I move one of > those instances (say June, Friday the 13th) to Thursday. > Then I update that particular instance's SEQUENCE to 1. > This is only an update to the SEQUENCE for that specific > instance's calendar component not for the parent UID 1 > set descriptor. The UID/SEQUENCE pair has not been updated. > The (UID-RECURRENCE-ID)/SEQUENCE pair (or triplet depending > on how you want to describe it) has been updated and has > no relevance to whethere or not the RECURRENCE-ID is fixed. I am confused reading your above paragraph. Are you saying that the RECURRENCE-ID is tied to the UID/SEQUENCE? Yes that is my point. >>In Bruces model you can NEVER add someone to the series >>of recurring VEVENT after any change that effects the >>effective DTSTART value of any instance as they could never >>be able to resolve the RECURRENCE-ID because they never >>had SEQUENCE:0. > > > This is just plain false. Given my "every Friday for this > year" example above, with the June 13th modification to > June 12th, to invite someone to the entire series I would > send them a > VEVENT REQUEST containing: > UID: 1 > SEQUENCE: 0 > describing every Friday this year > with them as an ATTENDEE > > and simoultaneously also send them a > VEVENT REQUEST containing: > UID: 1 > RECURRENCE-ID: Friday, June 13th > SEQUENCE: 1 > describing Thrusday, June 12th > with them as an ATTENDEE Bruce clamed that you did not have to remember SEQUENCE:10. Your claiming you do. Are you sure you and Bruce are talking the same model? You are claming that the ORGANIZER must figure out and send the ATTENDEE a correct set of all sequences starting at SEQUENCE:0 up to the current sequence, and process a reply for each sequence (because that is how it is done). Why go through all of that? Why not just send ONE REQUEST/VEVENT with the latest state? No RECURRENCE-ID needed no need to force the ATTENDEE CUA to REPLY to X number of REQUESTS only to immediately throw X-1 away and end up with with what could have just been ONE REQUEST/REPLY ? That is not a simplification. Assuming that what you are saying is true, think of a public calendar where hundreds of people may be added and removed to a series of public events. Do you really want to process (SEQUENCE*new-ATTENDEE) objects and REQUEST/REPLYs? When it could just be (1*new-ATTENDEE) REQUEST/REPLY packets? The assertion (by someone) that this is simpler is an attempt to declare that a new way of doing things is iCAL/iTIP. No it is not. Your example covers a case that works, what about the one I described that did not work? > > In "Bruce's model" I could even send those two objects > out of order and you'd still be able to accurately process it > which debunks your claim that they couldn't resolve the > RECURRENCE-ID because they never had SEQUENCE: 0. > > I don't mean to be trolling here, but isn't it in fact > the changing RECURRENCE-ID model that has the problem > with dealing effectively with lost / missing messages? No, because the they map to the UID/SEQUENCE and DTSTAMP. So if you get SEQUENCE:10 and did not get SEQUENCE:9, follow the rules of iTIP and you will now you do not care about SEQUENCE:9 as you have the SEQUENCE:10. If it is a modification to an instance to SEQUENCE:10 (because it has a RECURRENCE-ID), then follow the rules in iTIP - wait abd then to a REFRESH if it does not arrive It works in any order and with missing objects. > > Also so good so far. > > >>So once the CUA accepts the new SEQUENCE:1 object, the object >>still has three RECURRENCE-ID's: >> >>...T180000Z 1st instance (effective DTSTART) >>...T193000Z 2nd instance (effective DTSTART) >>...T200000Z 3rd instance (effective DTSTART) >> >>As the RECURRENCE-ID is the effective DTSTART value >>of the instance. > > > > Oooops just violated: > > For a given pair of "UID" and "SEQUENCE" property values, > the "RECURRENCE-ID" value for a recurrence instance is fixed. Oooops that means per set - and nope, I updated the set. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020000060101060108070009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwODE2NTIxN1owIwYJKoZIhvcNAQkEMRYEFGV5U81a WbcDvTzS33AkB8CxsGGdMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAAD+MyfZyyrk8ar5BptnXz83gRPOog65U4/tv+OAFN09EZjnnu3h QNHeEjRzkstdsatAwedpMOziHau3KITQiX3DbdY5CFwWHgj0jltx7ClWPmWlQeCkXY8o+4fn VCuERGmMCIYxi9lsPIWAsU0PDLL9G15yFTq936aYaLFiGhJy1ALBEQ04dUI9kHvCS6dOelKC 9qrP5vv9hTep0U7LQ36/IRraH1Sz2LaoPSgETL2R70/a2bFTQic2fmXzTJfKxhsb4ZGLgDsF 6LsDUbvyFruqCnhO6ZxclJIhh+GcwHjjv97sN0DtgZkxdqDQ6bQp0beVPjX275I5GXAx99cv m2MAAAAAAAA= --------------ms020000060101060108070009-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 13:23: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 NAA18364 for ; Fri, 8 Aug 2003 13:23:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78HFIqt041069 for ; Fri, 8 Aug 2003 10:15:18 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78HFIXc041068 for ietf-calendar-bks; Fri, 8 Aug 2003 10:15:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78HFHqt041062 for ; Fri, 8 Aug 2003 10:15:17 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F32CF99.9040901@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_07162003NP July 16, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Fri, 8 Aug 2003 13:01:52 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/08/2003 01:14:58 PM, Serialize complete at 08/08/2003 01:14:58 PM Content-Type: multipart/alternative; boundary="=_alternative 005D3A2785256D7C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005D3A2785256D7C_= Content-Type: text/plain; charset="US-ASCII" Sorry Doug your wrong. iTip 3.2.2 REQUEST The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 08/07/2003 06:15 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: RECURRENCE-ID discussion Robert_Ransdell@notesdev.ibm.com wrote: > > Do you disagree that iTIP says that if it has a RECURRENCE-ID and > METHOD:REQUEST that it is a modify and not a new invitation? > > This blatantly FALSE. > > The request method makes no such distinction. > If you receive a request and it is not on your calendar, you must treat > it as an invitation. Nope - iTIP - Modify A Recurring Instance, look for: ...Note the use of "RECURRENCE-ID" property and "SEQUENCE" property in the second request. And i iTIP - Working With Recurrence Instances, at and near: ...If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. Note that after the change has occurred, the "RECURRENCE-ID" has changed to the new "DTSTART" value. If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification. > The presence of a repeat-id makes it an invitation to an instance of a > repeat set. Can you cite any text? Or is that just another take my word for it assertion? Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 005D3A2785256D7C_= Content-Type: text/html; charset="US-ASCII"
Sorry Doug your wrong.

iTip 3.2.2 REQUEST
   The "UID" and "SEQUENCE" properties are used to distinguish the
  various uses of the "REQUEST" method. If the "UID" property value in
  the "REQUEST" is not found on the recipient's calendar, then the
  "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
  property value is found on the recipient's calendar, then the
  "REQUEST" is for a rescheduling, an update, or a reconfirm of the
  "VEVENT" calendar component.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

08/07/2003 06:15 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: RECURRENCE-ID discussion







Robert_Ransdell@notesdev.ibm.com wrote:
>
> Do you disagree that iTIP says that if it has a RECURRENCE-ID and
> METHOD:REQUEST that it is a modify and not a new invitation?
>
> This blatantly FALSE.
>
> The request method makes no such distinction.
> If you receive a request and it is not on your calendar, you must treat
> it as an invitation.

Nope - iTIP - Modify A Recurring Instance, look for:

                ...Note the use of "RECURRENCE-ID" property and "SEQUENCE"
                property in the second request.


And i iTIP - Working With Recurrence Instances, at and near:

   ...If the "Organizer" wishes to
   change the "DTSTART", the original "DTSTART" value is used for
   "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
   reflect the change.  Note that after the change has occurred, the
   "RECURRENCE-ID" has changed to the new "DTSTART" value.

If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification.


> The presence of a repeat-id makes it an invitation to an instance of a
> repeat set.

Can you cite any text? Or is that just another take my word for
it assertion?


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

                We Do Standards - You Need Standards
--=_alternative 005D3A2785256D7C_=-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 15:05: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 PAA21674 for ; Fri, 8 Aug 2003 15:05:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78IsPqt045433 for ; Fri, 8 Aug 2003 11:54:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78IsP4e045432 for ietf-calendar-bks; Fri, 8 Aug 2003 11:54:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78IsNqt045427 for ; Fri, 8 Aug 2003 11:54:24 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h78IrhEB018036 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 8 Aug 2003 11:53:45 -0700 Message-ID: <3F33F1B2.3030702@Royer.com> Date: Fri, 08 Aug 2003 12:53:38 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000307060408060204010205" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000307060408060204010205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug said on 08/07/2003 05:08:56 PM: > > > > And you can not create a VEVENT with a RECURRENCE-ID property in it. > > > > > > You certainly can Doug. If I want to invite you to a particular > > > instance of a repeat set I would exactly send that iTIP fragment. > > > > > > You dont get the instances you are not invited to; you'd have no > way to > > > know you were not being invited to them! > > > > And it does not contain a RECURRENCE-ID, else it is not a new invitation, > > its a iTIP modify to an existing VEVENT. So, no you can not. > > If it contains a RECURRENCE-ID and a DTSTART and METHOD:REQUEST, > > then it is a modification to an existing VEVENT, not a new > > invitation. > > Its becoming clear to me that you are not quite clear on the concepts of > message sequencing or missequencing or message loss. Its becoming clear to me that you did not understand iTIP when you wrote your project and you did not know that these new proposals of yours were already covered in iTIP and we do not need new ways to do things that are already documented. > There is NOTHING in iTIP that says "An invitation has no RECURRENCE-IDs" > or "You cannot/MUST NOT use RECURRENCE-IDs in an invitation" or "The > REQUEST at some magic SEQUENCE value is an invitation, all others are > reschedules.", etc. Exactly - you are proposing a new way to invite ATTENDEEs. And it is not needed. > Its perfectly legal and valid to have a REQUEST for SEQUENCE:0 with a > UID and RECURRENCE-ID. How do you disambiguate that from an update to a missed object? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000307060408060204010205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwODE4NTMzOFowIwYJKoZIhvcNAQkEMRYEFKOonQRJ /tw95S4Y5JIdYfuDQsDxMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBALQV4jNqgfsBJnS2N4xX/gMsB6pGEHtxQFKUPZRXYuY4oxpM26l2 USKn4ELxMEW3l65+8b3zPg37kpWnxTu0gUbt1Jw8G8KEbPmEPSIsOOL63EKGZ9eSC458NaYU 3aOI9G35p3T5m7tKF8s2I9KpgQPFu5bnDWpQSqqKzE4J2E6vnU2olFFchm7mVm+9naJVES6S HVJP34wh80I2PC0eBgQe7KnxkKVjb3crGJ4YEa9IuZ+YjtTvuWbyxiRuqts64Hzf7sjRYvQ1 bQuCgudC/NWuiGRcPfldiLqtNm9JlHThbLXSaWpSN+TtAlvAaT9t8rXzlHHJw3/a2Q5SkFVH tHQAAAAAAAA= --------------ms000307060408060204010205-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 15:06: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 PAA21775 for ; Fri, 8 Aug 2003 15:06:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78It9qt045458 for ; Fri, 8 Aug 2003 11:55:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78It9Es045457 for ietf-calendar-bks; Fri, 8 Aug 2003 11:55:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78It7qt045452 for ; Fri, 8 Aug 2003 11:55:07 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h78It4EB018043 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 8 Aug 2003 11:55:08 -0700 Message-ID: <3F33F203.2040309@Royer.com> Date: Fri, 08 Aug 2003 12:54:59 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030600050908080905090809" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030600050908080905090809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug noted on 08/07/2003 05:12:38 PM: > > > > For REPLY, Single instance update, moving an instance, canceling and > > > > instance, but not creating a recurrence set even when the recurrence > > > > set has only one instance. > > > > > > Err, that restriction table snippet came from iTIP Section 3.2.2 > REQUEST > > > and clearly matches the iTIP note: > > > > > > . Reschedule an existing event; > > > > > > Just because we didnt espressly write "Reschedule an existing event > [or > > > a particular instance or range of instances of a repeating event]" > every > > > time does not mean it does not work refer to just a particular > instance > > > only. > > > > Yes you can also use RANGE if that is what you meant to say. > > RANGEs are a whole other ball of wax that are not germane to this > thread. My point is that you did NOT list RECURRENCE-ID as being valid > on a REQUEST as an invitation too which I pointed out it was. So - HOW DO YOU DISAMBIGUATE IT FROM AN UPDATE TO A MISSED OBJECT AS IT LOOKS EXACTLY THE SAME ? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030600050908080905090809 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwODE4NTQ1OVowIwYJKoZIhvcNAQkEMRYEFMaEM7KM ch+fPGjQy2MzRDajy8wRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBACwD4bozn9XddKGm0x8jGtgAgoiXcTs3ZV4HpcjeQVw7XewjUNYx kxcVkI3gC5SaypU01nd4TGQVm4oWmB0iYKVSeo/UOP//vYgmfNROC+vhcjKMPHzRaQZbvXZi vX9SWBviMfxv5IZOAcTzit1RlGVcmtp3PQ5ssvHlnJlVbpMzVAYJe3kXzo6rJhgZtje5IvMv pfxdbYYntsaKgaKqEIcnK2YPTN8pGSOQYalgqZDFcj0zSevBmQlmKnNr+c7MIyutN+qt6FlZ 7ZBDNaNW9B/hjBf/U1wQusBHPnA9OcS/u/Nb69vYE1lQcmQfe0dM8Krh4lmZKYqAcr25TcA8 FusAAAAAAAA= --------------ms030600050908080905090809-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 15:09: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 PAA22264 for ; Fri, 8 Aug 2003 15:09:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78IvXqt045532 for ; Fri, 8 Aug 2003 11:57:33 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78IvXue045531 for ietf-calendar-bks; Fri, 8 Aug 2003 11:57:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78IvWqt045524 for ; Fri, 8 Aug 2003 11:57:32 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h78IvVEB018070 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 8 Aug 2003 11:57:33 -0700 Message-ID: <3F33F296.8030306@Royer.com> Date: Fri, 08 Aug 2003 12:57:26 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070007030805070408090908" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070007030805070408090908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Sorry Doug your wrong. So rather than discuss the text in iTIP I sent, you want to just declare your beliefs. Thanks for sharing, but it does not make an update to a instance go away. So - how do you disambiguate it from an update to a missed object? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070007030805070408090908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwODE4NTcyNlowIwYJKoZIhvcNAQkEMRYEFAbqVd0n ZFEia2eMZ4O8NojYbv/vMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBALj9wpJO7/kEfNiYgZKPSI8aBQKI7JXZnBZcwlrpSEQtIc3IA65Z NftPJuHf3GRSSdDv8jeS3Ixrhj9HQ/ruVqhU8ZAhYmevO6KzP4A/mOs9YljIu0lXqlooSwuI X9zmLBaHTZJQqerEarTx9clnxLNdl58ZsEivvTZ09pYOIrAz7D00svpZO332Kmw9NAPXz1h1 DQSIccYKqtvsb7V8Vx66GJqMljg+ecGgSoAl7zbCni6np+WWWdP2IL5mzAma2W0kO3Nx5IVB wyBMhuud7BIqv1S5Lo+E1Egvg4xMHVddJTDAoPA87tMm8vGNy29b/3BsNnQ/90w4iiUOkQVG DXYAAAAAAAA= --------------ms070007030805070408090908-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 15:19: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 PAA23087 for ; Fri, 8 Aug 2003 15:19:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78J88qt046022 for ; Fri, 8 Aug 2003 12:08:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78J8822046021 for ietf-calendar-bks; Fri, 8 Aug 2003 12:08:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78J87qt046015 for ; Fri, 8 Aug 2003 12:08:07 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <5.2.1.1.0.20030807223915.009f6cd0@mail.comcast.net> To: Tim Hare Cc: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 8 Aug 2003 14:43:30 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/08/2003 03:07:43 PM, Serialize complete at 08/08/2003 03:07:43 PM Content-Type: multipart/alternative; boundary="=_alternative 0066A86085256D7C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066A86085256D7C_= Content-Type: text/plain; charset="US-ASCII" Tim wrote on 08/07/2003 11:16:48 PM: > Someone posted an example where you change > the time for one of the "parts" of a recurrence set. To me that showed > that the RECURRENCE-ID _does_ change, IF its identifier is defined as in > the spec - basically the DTSTART of the instance. It _has_ to change, > under that definition, if the time of the instance changes. Interesting analysis but lets take a look a couple bits from the RFCs and see if that still holds true. The issues of how a CS manages internal storage is not germane to the data format (iCalendar) or the messaging protocol (iTIP); its strictly an internal issue. Not every C&S product supports the exact same featuresl ike infinite recurrence and thats factored into iTIP (ie: under iTIP 3.6 Status Replies). The concerns should be how well the model can represent C&S functionality and how well workflow performs. First off, iCalendar defines the use of RECURRENCE-ID as: The "RECURRENCE-ID" property allows the reference to an individual instance within the recurrence set. and it later adds: The date/time value is set to the time when the original recurrence instance would occur; So it should be clear that the RECURRENCE-ID value is supposed to be the initial DTSTART value for the instance in question. However even if its not it is necessarily so due to the message sequencing problems that can affect iTIP. If your iTIP REQUESTs get missequenced and your model relys on each previous SEQUENCE values RECURRENCE-ID value to calculate the next one then you cannot recover workflow for just that instance; you can only recover by recreating ALL instances (the infamous 'full REFRESH'). There is no way to guarantee that each and every REQUEST gets there and in the correct order; some may never arrive or they may be delayed out of sequence. So the only thing the user can do is toss out ALL instances and wait for the Organizer to resend 'em all in a new REQUEST. This brings workflow to a grinding halt for that invitee. However, if your RECURRENCE-ID is fixed then you can quickly and easily recover from any missequenced REQUESTs. Since the recipient can uniquely and unambiguously identify the instance in question based on the UID / RECURRENCE-ID pair in a fixed model, they can easily find the correct instance in question and then use SEQUENCE (and DTSTAMP) to resolve missequencing. For example, using a fixed RECURRENCE-ID, I send you a SEQUENCE:0 invitation (MsgA), a SEQUENCE:1 reschedule (MsgB) and then a SEQUENCE:2 reschedule (MsgC) for a particular instance. If they arrive in reverse order (MsgC, MsgB, MsgA) or even missing/missequenced (MsgC, MsgA, no MsgB) then no problems exist and recovery is trivial. Lets see why. MsgC arrives. You check for the UID / RECURRENCE-ID value and do not find it. So by 3.2.2 REQUEST you treat it like an invitation to the instance and put it on your calendar. You send back a UID / RECURRENCE-ID / SEQUENCE:2 REPLY that I can easily match to my instances and everyone is happy. Recovery was essentially nothing since nothing was wrong from your view. MsgB arrives. You check for the UID / RECURRENCE-ID value and find it. You next check your SEQUENCE value and find it higher than the one in MsgB so you know that this REQUEST is obsolete and you safely ignore it. No recovery needed. MsgA arrives. You perform the same steps as for MsgB and again no recovery is necessary. Even if MsgB or MsgA never arrived, recovery was essentially not an issue or necessary. If you move the arrival order around you will see that by properly applying iTIP 2.1.5 Message Sequencing rules its easy to recover from any problems. Now, if we used a changing RECURRENCE-ID model and I send the same messages there are lots of problems to be concerned with. Besides the issue of recovery there is also the issue of how to remove 'orphaned' bad entries in the invitees calendar. Lets see this: MsgC arrives. You check the UID / RECURRENCE-ID and do not find it. As such you treat it like a new instance invitation (which it is per iTIP 3.2.2 REQUEST) and add it to your calendar. You send back a UID / RECURRENCE-ID / SEQUENCE:3 REPLY that I can match to my instances and everyone is happy. So far, no problems are noticed but they will soon start. Recovery was essentially nothing since nothing was wrong from your view (or mine). MsgB arrives. You check the UID / RECURRENCE-ID and do not find it. As such you incorrectly treat it like a new instance invitation (per 3.2.2 REQUEST). and add it to your calendar. Now you have RECURRENCE-ID:C and RECURRENCE-ID:B at different SEQUENCE values on your calendar instead of just RECURRENCE-ID:C. You send back a UID / RECURRENCE-ID / SEQUENCE:2 REPLY that I _cannot_ match to any current instance in my calendar. As such I treat it like a mistake OR an attack on my calendar. If I decide to treat it like a mistake I toss the REPLY away and send you a new REQUEST with the latest UID / RECURRENCE-ID:C / SEQUENCE:3 info (per iTIP; MsgD). Lets say that MsgD arrives before MsgA (just to keep the process moving along here). You check the UID / RECURRENCE-ID value and find it. You check the SEQUENCE value and find it matches what you have so you then check DTSTAMP against your existing one. You detect that MsgD's DTSTAMP is newer than yours so the new REQUEST obsoletes the instance RECURRENCE-ID:C you already have so you replace that copy with the exact same data that you had already from MsgC. At this point you would still have RECURRENCE-ID:B and RECURRENCE-ID:C on your calendar when you should only have 1 instance. If MsgA now arrives you'd take the exact same actions that you did for MsgB and you wind up with 3 instances on your calendar instead of just the 1 you should have. By applying the sequencing rules from 2.1.5 and the differentiation guidelines from 3.2.2 as described then you can wind up with many 'orphaned' instances that do not belong. Now the only way to get rid of these orphans is to do a REQUEST with NO RECURRENCE-ID value but a matching UID value; this has the effect of referring to the entire set of instances and thus I would have to remove all existing instances and then replace them with the new instances defined in the UID only REQUEST. However this approach is more than a little heavy handed when dealing with multiple separate instances because you essentially have to hose ALL unrelated instances as well as the orphans and the specific instance in question; just because you missed 1 REQUEST to 1 particular instance. When we revised our model from a delta model to a fixed model this was one of the factors we considered. There was no benefit in having a delta RECURRENCE-ID model because of the thrashing and extraneous iTIP messaging necessary and since each iTIP REQUEST was fully self contained, there was NOTHING we needed from any previous iTIP REQUEST so we had an additional benefit from the change. The protocol became much more fault tolerant and efficient plus we minimized CUA confusion when referencing instances. > This to me > makes it easier for the CUA to determine the RECURRENCE-ID of an event > (merely pick the starting timestamp) when making requests; Is it easier if you are referring to an instance whose date/time has changed but you NEVER got the rescheduling REQUEST and thus may not longer existing in my calendar? Just how would I match your delayed REPLY to an instance that no longer exists in my calendar? The only way would be to keep a list of "previously known RECURRENCE-ID" values for each instance that you were invited to but even that can be defeated in 5 simple steps (see previous postings for 'em if you missed 'em). If you were only invited to a single instance I could assume thats the one in question but then again not really viable or as reliable. > this also > explains to me that UID is the one and only "key" to my hypothetical CS > "database". The UID is only the primary key if the entry is non-repeating. Otherwise the primary key is clearly defined to be UID / RECURRENCE-ID. I dont think thats in dispute here (or are you disputing it?). If RECURRENCE-ID is not part of your primary key then you cannot perform workflow on the instances indepently of each other unless you rewrite iTIP. > I think it _may_ cause some synchronization issues when a > CUA and CS/CUA are looking at the same recurrence set but with different > recurrence IDs There are sequencing issues like the ones described above. Thats why a fixed RECURRENCE-ID model is what we went for. Recovery is trivail and fast and there is NEVER any ambiguity as to which instance the RECURRENCE-ID is referring to. > Now - whose model did I just say was OK and whose did I say was broken? You said that Dougs delta RECURRENCE-ID model was ok and that the iCalendar "fixed" RECURRENCE-ID model was broken. However, now that Ive shown you some of the problems inherent in dealing with message sequencing do you still think the same? > I've been getting lost on that count. Have we been discussing the protocol, > or potential implementations? It started as a discussion of whats in the published RFCs but Doug recently said its under the guise of discussing changes to iCalendar so Im not sure... Ill keep treating it like an interpreation of the existing RFCs since we have no demonstrated need to literally invert the data model and destroy interoperability with existing implementations. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0066A86085256D7C_= Content-Type: text/html; charset="US-ASCII"
Tim wrote on 08/07/2003 11:16:48 PM:
>                              Someone posted an example where you change
> the time for one of the "parts" of a recurrence set.  To me that showed
> that the RECURRENCE-ID _does_ change, IF its identifier is defined as in
> the spec - basically the DTSTART of the instance.  It _has_ to change,
> under that definition, if the time of the instance changes.

Interesting analysis but lets take a look a couple bits from the RFCs and see if that still holds true.  The issues of how a CS manages internal storage is not germane to the data format (iCalendar) or the messaging protocol (iTIP); its strictly an internal issue.  Not every C&S product supports the exact same featuresl ike infinite recurrence and thats factored into iTIP (ie: under iTIP 3.6 Status Replies).  The concerns should be how well the model can represent C&S functionality and how well workflow performs.

First off, iCalendar defines the use of RECURRENCE-ID as:

                                                  The "RECURRENCE-ID"
  property allows the reference to an individual instance within the
  recurrence set.

and it later adds:

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

So it should be clear that the RECURRENCE-ID value is supposed to be the initial DTSTART value for the instance in question.  However even if its not it is necessarily so due to the message sequencing problems that can affect iTIP.  

If your iTIP REQUESTs get missequenced and your model relys on each previous SEQUENCE values RECURRENCE-ID value to calculate the next one then you cannot recover workflow for just that instance; you can only recover by recreating ALL instances (the infamous 'full REFRESH').  There is no way to guarantee that each and every REQUEST gets there and in the correct order; some may never arrive or they may be delayed out of sequence.

So the only thing the user can do is toss out ALL instances and wait for the Organizer to resend 'em all in a new REQUEST.  This brings workflow to a grinding halt for that invitee.

However, if your RECURRENCE-ID is fixed then you can quickly and easily recover from any missequenced REQUESTs.  Since the recipient can uniquely and unambiguously identify the instance in question based on the UID / RECURRENCE-ID pair in a fixed model, they can easily find the correct instance in question and then use SEQUENCE (and DTSTAMP) to resolve missequencing.

For example, using a fixed RECURRENCE-ID, I send you a SEQUENCE:0 invitation (MsgA), a SEQUENCE:1 reschedule (MsgB) and then a SEQUENCE:2 reschedule (MsgC) for a particular instance.  If they arrive in reverse order (MsgC, MsgB, MsgA) or even missing/missequenced (MsgC, MsgA, no MsgB) then no problems exist and recovery is trivial.  Lets see why.

MsgC arrives.  You check for the UID / RECURRENCE-ID value and do not find it.  So by 3.2.2 REQUEST you treat it like an invitation to the instance and put it on your calendar.  You send back a UID / RECURRENCE-ID / SEQUENCE:2 REPLY that I can easily match to my instances and everyone is happy.  Recovery was essentially nothing since nothing was wrong from your view.

MsgB arrives.  You check for the UID / RECURRENCE-ID  value and find it.  You next check your SEQUENCE value and find it higher than the one in MsgB so you know that this REQUEST is obsolete and you safely ignore it.  No recovery needed.

MsgA arrives.  You perform the same steps as for MsgB and again no recovery is necessary.

Even if MsgB or MsgA never arrived, recovery was essentially not an issue or necessary.

If you move the arrival order around you will see that by properly applying iTIP 2.1.5 Message Sequencing rules its easy to recover from any problems.

Now, if we used a changing RECURRENCE-ID model and I send the same messages there are lots of problems to be concerned with.  Besides the issue of recovery there is also the issue of how to remove 'orphaned' bad entries in the invitees calendar.  Lets see this:

MsgC arrives.  You check the UID / RECURRENCE-ID and do not find it.  As such you treat it like a new instance invitation (which it is per iTIP 3.2.2 REQUEST) and add it to your calendar.  You send back a UID / RECURRENCE-ID / SEQUENCE:3 REPLY that I can match to my instances and everyone is happy.  So far, no problems are noticed but they will soon start.  Recovery was essentially nothing since nothing was wrong from your view (or mine).

MsgB arrives.  You check the UID / RECURRENCE-ID and do not find it.  As such you incorrectly treat it like a new instance invitation (per 3.2.2 REQUEST). and add it to your calendar.  Now you have RECURRENCE-ID:C and RECURRENCE-ID:B at different SEQUENCE values on your calendar instead of just RECURRENCE-ID:C.  You send back a UID / RECURRENCE-ID / SEQUENCE:2 REPLY that I _cannot_ match to any current instance in my calendar.  As such I treat it like a mistake OR an attack on my calendar.  

If I decide to treat it like a mistake I toss the REPLY away and send you a new REQUEST with the latest UID / RECURRENCE-ID:C / SEQUENCE:3 info (per iTIP; MsgD).  Lets say that MsgD arrives before MsgA (just to keep the process moving along here).  You check the UID / RECURRENCE-ID value and find it.  You check the SEQUENCE value and find it matches what you have so you then check DTSTAMP against your existing one.  You detect that MsgD's DTSTAMP is newer than yours so the new REQUEST obsoletes the instance RECURRENCE-ID:C you already have so you replace that copy with the exact same data that you had already from MsgC.

At this point you would still have RECURRENCE-ID:B and RECURRENCE-ID:C on your calendar when you should only have 1 instance.  If MsgA now arrives you'd take the exact same actions that you did for MsgB and you wind up with 3 instances on your calendar instead of just the 1 you should have.

By applying the sequencing rules from 2.1.5 and the differentiation guidelines from 3.2.2 as described then you can wind up with many 'orphaned' instances that do not belong.  Now the only way to get rid of these orphans is to do a REQUEST with NO RECURRENCE-ID value but a matching UID value; this has the effect of referring to the entire set of instances and thus I would have to remove all existing instances and then replace them with the new instances defined in the UID only REQUEST.  

However this approach is more than a little heavy handed when dealing with multiple separate instances because you essentially have to hose ALL unrelated instances as well as the orphans and the specific instance in question; just because you missed 1 REQUEST to 1 particular instance.

When we revised our model from a delta model to a fixed model this was one of the factors we considered.  There was no benefit in having a delta RECURRENCE-ID model because of the thrashing and extraneous iTIP messaging necessary and since each iTIP REQUEST was fully self contained, there was NOTHING we needed from any previous iTIP REQUEST so we had an additional benefit from the change.  The protocol became much more fault tolerant and efficient plus we minimized CUA confusion when referencing instances.

>                                                              This to me
> makes it easier for the CUA to determine the RECURRENCE-ID of an event
> (merely pick the starting timestamp) when making requests;

Is it easier if you are referring to an instance whose date/time has changed but you NEVER got the rescheduling REQUEST and thus may not longer existing in my calendar? Just how would I match your delayed REPLY to an instance that no longer exists in my calendar?  The only way would be to keep a list of "previously known RECURRENCE-ID" values for each instance that you were invited to but even that can be defeated in 5 simple steps (see previous postings for 'em if you missed 'em).

If you were only invited to a single instance I could assume thats the one in question but then again not really viable or as reliable.

>                                                            this also
> explains to me that UID is the one and only "key" to my hypothetical CS
> "database".

The UID is only the primary key if the entry is non-repeating.  Otherwise the primary key is clearly defined to be UID / RECURRENCE-ID.  I dont think thats in dispute here (or are you disputing it?).  If RECURRENCE-ID is not part of your primary key then you cannot perform workflow on the instances indepently of each other unless you rewrite iTIP.

>             I think it _may_ cause some synchronization issues when a
> CUA  and CS/CUA are looking at the same recurrence set but with different
> recurrence IDs  

There are sequencing issues like the ones described above.  Thats why a fixed RECURRENCE-ID model is what we went for.  Recovery is trivail and fast and there is NEVER any ambiguity as to which instance the RECURRENCE-ID is referring to.  
> Now - whose model did I just say was OK and whose did I say was broken?

You said that Dougs delta RECURRENCE-ID model was ok and that the iCalendar "fixed" RECURRENCE-ID model was broken.

However, now that Ive shown you some of the problems inherent in dealing with message sequencing do you still think the same?

> I've been getting lost on that count. Have we been discussing the protocol,
> or potential implementations?
It started as a discussion of whats in the published RFCs but Doug recently said its under the guise of discussing changes to iCalendar so Im not sure...  Ill keep treating it like an interpreation of the existing RFCs since we have no demonstrated need to literally invert the data model and destroy interoperability with existing implementations.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0066A86085256D7C_=-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 15:51: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 PAA23805 for ; Fri, 8 Aug 2003 15:51:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78JbYqt047598 for ; Fri, 8 Aug 2003 12:37:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78JbYIi047596 for ietf-calendar-bks; Fri, 8 Aug 2003 12:37:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78JbWqt047588 for ; Fri, 8 Aug 2003 12:37:32 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h78JbVEB018376 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 8 Aug 2003 12:37:33 -0700 Message-ID: <3F33FBF6.2060201@Royer.com> Date: Fri, 08 Aug 2003 13:37:26 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060905080309050309040407" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060905080309050309040407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Tim wrote on 08/07/2003 11:16:48 PM: > > Someone posted an example where you change > > the time for one of the "parts" of a recurrence set. To me that showed > > that the RECURRENCE-ID _does_ change, IF its identifier is defined as in > > the spec - basically the DTSTART of the instance. It _has_ to change, > > under that definition, if the time of the instance changes. > > Interesting analysis but lets take a look a couple bits from the RFCs > and see if that still holds true. The issues of how a CS manages > internal storage is not germane to the data format (iCalendar) or the > messaging protocol (iTIP); its strictly an internal issue. Not every > C&S product supports the exact same featuresl ike infinite recurrence > and thats factored into iTIP (ie: under iTIP 3.6 Status Replies). The > concerns should be how well the model can represent C&S functionality > and how well workflow performs. I do not follow how or why you think his point has anything to do with storage format. Are you saying because your storage format does not allow for it to change that you want other vendors to change? > First off, iCalendar defines the use of RECURRENCE-ID as: > > The "RECURRENCE-ID" > property allows the reference to an individual instance within the > recurrence set. > > and it later adds: > > The date/time value is set to the time when the original recurrence > instance would occur; > > So it should be clear that the RECURRENCE-ID value is supposed to be the > initial DTSTART value for the instance in question. However even if its > not it is necessarily so due to the message sequencing problems that can > affect iTIP. > > If your iTIP REQUESTs get missequenced and your model relys on each > previous SEQUENCE values RECURRENCE-ID value to calculate the next one > then you cannot recover workflow for just that instance; Not true and if you read iTIP from page one to last you will see that there is an entire section devoted to that problem - with a solution. > ... you can only > recover by recreating ALL instances (the infamous 'full REFRESH'). Your new proposal holds a worse problem. Not only do you have to invent new ways to invite attendees, you have to somehow remember what SEQUENCE:0 object would have sent them and do (current-SEQUENCE * VEVENT) object to update them - MUCH more data than a REFRESH (which is documented), then they have to REPLY to all of that. How is that better than a REFRESH? How is sending much more data as SEQUENCE gets large better than sending one REFRESH/REQUEST set? > There is no way to guarantee that each and every REQUEST gets there and > in the correct order; some may never arrive or they may be delayed out > of sequence. Which is true of all models. A red herring as iTIP has an entire section devoted to that solution. > So the only thing the user can do is toss out ALL instances and wait for > the Organizer to resend 'em all in a new REQUEST. This brings workflow > to a grinding halt for that invitee. As opposed to sending SEQUENCE*EVENTS if they are ever to get an update? > However, if your RECURRENCE-ID is fixed then you can quickly and easily > recover from any missequenced REQUESTs. Since the recipient can > uniquely and unambiguously identify the instance in question based on > the UID / RECURRENCE-ID pair in a fixed model, they can easily find the > correct instance in question and then use SEQUENCE (and DTSTAMP) to > resolve missequencing. Fixed to a SEQUENCE they might not have? Your again ignoring all busted examples sent to this list for your proposed model. > For example, using a fixed RECURRENCE-ID, I send you a SEQUENCE:0 > invitation (MsgA), a SEQUENCE:1 reschedule (MsgB) and then a SEQUENCE:2 > reschedule (MsgC) for a particular instance. If they arrive in reverse > order (MsgC, MsgB, MsgA) or even missing/missequenced (MsgC, MsgA, no > MsgB) then no problems exist and recovery is trivial. Lets see why. Better yet - why not just point to iTIP and say - yes it is documented in iTIP? > Now, if we used a changing RECURRENCE-ID model and I send the same > messages there are lots of problems to be concerned with. Besides the > issue of recovery there is also the issue of how to remove 'orphaned' > bad entries in the invitees calendar. Lets see this: So please clarify - you are indeed proposing a model that is not compliant it iTIP? iTIP already has solved this problem. Trying to get the world to do it your way because you do not like the way iTIP does it is fine - but please do not pretend that iITIP is busted, its not. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060905080309050309040407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwODE5MzcyNlowIwYJKoZIhvcNAQkEMRYEFGdDnDCP 2y9SVsZ1279xce+mpAbHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJfDdHu/aSRj1/7DhzEP+iA4VbxypXZozgl4J0+oJmSZlzVCsRla x0klEzqHQAIkqK9jN32xzGIZmCAZSc56IqxiskiANrnMJXvVX/wD/CCzxQOtvB4ERT0/mgFF WEeCm5HvgBASn/81RFF4AGxwB7pDOcTJlI4cQxSLbzobEPow4N5dlvzM8upTSH8lhVXtjEKi /TzG81W3FWUyAkvKfn46tLawguQQNzxyeefJ0lGtS2v4QSzwUftCNTVElcII6mJRyS78fr+Y h4aQuNeppSLpJd+Dh9WR7+MuDP31/E47oqokcJjj+I2tMP5JthMg4GI9EM1lyqhPMtQnafbm lVsAAAAAAAA= --------------ms060905080309050309040407-- From owner-ietf-calendar@mail.imc.org Fri Aug 8 19:43:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01113 for ; Fri, 8 Aug 2003 19:43:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78NThqt061113 for ; Fri, 8 Aug 2003 16:29:44 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78NThkA061112 for ietf-calendar-bks; Fri, 8 Aug 2003 16:29:43 -0700 (PDT) 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.9/8.12.8) with ESMTP id h78NTgqt061107 for ; Fri, 8 Aug 2003 16:29:42 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h78NTdnW009897; Fri, 8 Aug 2003 16:29:39 -0700 (PDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h78NTdhD023141; Fri, 8 Aug 2003 16:29:39 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJB00NJMQLE3L@ha13sca-mail1.sfbay.sun.com>; Fri, 08 Aug 2003 16:29:38 -0700 (PDT) Date: Sat, 09 Aug 2003 04:59:40 +0530 From: Satya Vempati Subject: RE: RECURRENCE-ID discussion To: Michael Fair , "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT An excellent summary and detailed analysis. I just wish that the RFC was written better: Instead of: For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. if it said: For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" values for all recurrence instances are fixed. we would not be arguing about it today. The current text does sound like it is talking about one instance. Along with Bruce, the growing sense is that the fixed recurrence model is simpler and indeed does work. Actually --again as Bruce has already pointed out-- the discussion of whether "Recurrence-Id" changes goes back to July, 1999. Dan Hickman brought up the (now infamous) iTIP section that states that RECURRENCE-ID should change to the new DTSTART and asked: --------------- The paragraph below is shown at the very end of section 3.7.1 in the rfc2446 (iTIP). The last two sentences seem to conflict in meaning. The first says that "the original DTSTART value is used for RECURRENCE-ID" but the second says that "RECURRENCE-ID has changed to the new DTSTART". I thought we decided to leave the RECURRENCE-ID the same. If the last sentence is true, then it seems we would have to exclude the original date in an "EXDATE" property and then include the new date in an "RDATE" property. Is this right? To which Frank Dawson replied: ---------------- Dan: Good to hear from you. Hope your iCalendar activities are going great! The RECURRENCE-ID (along with the UID and SEQUENCE properties) are used to reference (a particular version of) an individual occurrence for a repeating event or to-do. As such, it will change after the DTSTART for the occurrence changes. >The paragraph below is shown at the very end of section 3.7.1 in the rfc2446 >(iTIP). The last two sentences seem to conflict in meaning. The first says >that "the original DTSTART value is used for RECURRENCE-ID" but the second >says that "RECURRENCE-ID has changed to the new DTSTART". For example, if you scheduled a Monday, Wednesday and Friday meeting and you want to reschedule the Wednesday meeting meeting to Thursday, then the RECURRENCE-ID in the reschedule would specify the date/time of the Wednesday meeting as specified in the original REQUEST. Now, after rescheduling to Thursday, if you want to reference that rescheduled occurrence you specify a RECURRENCE-ID that would have the date/time of the Thursday meeting. >I thought we decided to leave the RECURRENCE-ID the same. If the last >sentence is true, then it seems we would have to exclude the original date >in an "EXDATE" property and then include the new date in an "RDATE" >property. Is this right? Not sure I agree with the last part. You can currently specify a "EXDATE" property in the original REQUEST that has the date/time value of a particular occurrence. You could also specify a duplicate date/time value in a RDATE that is the same as an occurrence specified in a RRULE or other RDATE. However, the set of occurrences will only have one element with a given date/time interval. You can also reschedule by specifying the revised DTSTART/DTEND for the occurrence. However, if you use EXDATE/RDATE wouldn't that appear to be "ADDing" an occurrence? We use the ADD method to do this. It seems to be problematic if you try to use the EXDATE/RDATE to specify the date/time for the rescheduled meeting. It would seem that we should be using the DTSTART/DTEND properties for that. -- Frank To summarize, the iTIP issue was discussed with the original authors but it was deliberately left alone. It is not a miss. But it looks more and more like an error. -----Original Message----- From: Michael Fair [mailto:michael@daclubhouse.net] Sent: Friday, August 08, 2003 4:22 PM To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion "Doug Royer" wrote in message news:3F328D81.6020505@Royer.com... > > So now we go to update it again. If we look at the objects > > themselves. I specified that SEQUENCE: 1 of UID: 1, > > RECURRENCE-ID: ...T180000Z would DTSTART at ...T150000Z. > > Note that no where in this object did I ever say, "oh and > > by the way here's a new RECURRENCE-ID". So now we go > > to move it again. Here's where the disagreement is. > > You do not need to say 'oh and by the way here's a new RECURRENCE-ID' > because iCAL says: > > Purpose: This property is used in conjunction with the "UID" and > "SEQUENCE" property to identify a specific instance of a recurring > "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property > value is the effective value of the "DTSTART" property of the > recurrence instance. > > So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID > for that single instance object SEQUENCE:1 is the effective value > of the "DTSTART" property - ...T150000Z and not ..T180000Z. > > So after that point if you do an update to RECURRENEC-ID ..T180000Z, > there would be no object with that effective DTSTART date and > thus no RECURRENCE-ID to match. Indeed, I grant you that the use of the term "effective" does tend to call for the use of a changing RECURRENCE-ID. But it doesn't, and I'll show you why a little later. So further down in the IMAP definition, we find this text: For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. So here's how I read this: There is a UID which describes a recurrence set. That UID has a SEQUNCE value which identifies the set it describes. This reading is supported by the part that describes how the SEQUNCE changing reflects a set description change which in turn could modify the RECURRENCE-ID of the set instances. So for examples sake, let's again use UID: 1 and say that SEQUENCE: 0 describes every Friday this year. So for UID 1/SEQUENCE 0 the RECURRENCE-ID for each instance is "fixed" at the Fridays of this year. If I move one of those instances (say June, Friday the 13th) to Thursday. Then I update that particular instance's SEQUENCE to 1. This is only an update to the SEQUENCE for that specific instance's calendar component not for the parent UID 1 set descriptor. The UID/SEQUENCE pair has not been updated. The (UID-RECURRENCE-ID)/SEQUENCE pair (or triplet depending on how you want to describe it) has been updated and has no relevance to whethere or not the RECURRENCE-ID is fixed. This view is supported by order of precedence for locating an instance, first the UID, then the RECURRENCE-ID are primary lookup keys, the RECURRENCE-ID can be NULL which means different things in different contexts, and then the SEQUENCE is used as a secondary lookup. In other words, by moving an instance to Thursday I have not modified the description of the recurrence set specified by UID 1/SEQUENCE 0 and therefore the RECURRENCE-ID remains fixed. Consequently, for the pair UID 1/SEQUENCE 0, the RECURRENCE-ID for June, Friday the 13th remains fixed regardless of what I do that particular instance of UID 1 in the context of SEQUNCE 0. In essence, I've simply said that June, Friday the 13th's instance actually occurs on Thursday now. So let's go back to that other quote that seemed to imply a changing RECURRENCE-ID. > The property value is the effective value of the > "DTSTART" property of the recurrence instance. The "effective value" here is referencing the UID/SEQUENCE pair, not the effective value of an instance that's been updated. This must be the case because "for a given UID/SEQUENCE pair the RECURRENCE-ID value for a recurrence instance is fixed". However, if you update the recurrence set description, and consequently update SEQUENCE for that UID, then you must recalculate all the instances in the set and they may have a new DTSTART. To account for the ability for the RECURRENCE-ID to change in this way you must use "the effective value of the DTSTART propoerty of the recurrence instance". The only model under which all the paragraphs make sense is the one where the RECURRENCE-ID is fixed within a given set description of an event. The simplest way to express this in terms programmers can easily adhere to is that for a given UID/SEQUENCE pair (meaning a particular recurring set description) the RECURRENCE-ID value for a recurrence instance is fixed. Once UID 1/SEQUENCE 0 hits UID 1/SEQUENCE 1 (which would mean something significant about the set of instances has changed) all bets are off in regards to RECURRENCE-ID values that previously existed. > In Bruces model you can NEVER add someone to the series > of recurring VEVENT after any change that effects the > effective DTSTART value of any instance as they could never > be able to resolve the RECURRENCE-ID because they never > had SEQUENCE:0. This is just plain false. Given my "every Friday for this year" example above, with the June 13th modification to June 12th, to invite someone to the entire series I would send them a VEVENT REQUEST containing: UID: 1 SEQUENCE: 0 describing every Friday this year with them as an ATTENDEE and simoultaneously also send them a VEVENT REQUEST containing: UID: 1 RECURRENCE-ID: Friday, June 13th SEQUENCE: 1 describing Thrusday, June 12th with them as an ATTENDEE In "Bruce's model" I could even send those two objects out of order and you'd still be able to accurately process it which debunks your claim that they couldn't resolve the RECURRENCE-ID because they never had SEQUENCE: 0. I don't mean to be trolling here, but isn't it in fact the changing RECURRENCE-ID model that has the problem with dealing effectively with lost / missing messages? And lastly to cover the great example you offered: > For a single VEVENT REQUEST with three instance (COUNT=3 > in a RRULE). It has three RECURRENCE-ID's none of which > were ever explicitly created. > > So if the original REQUEST looks like this: > > METHOD:REQUEST > SEQUENCE:0 > DTSTART:20030805T180000Z > RRULE:FREQ=HOURLY;COUNT=3 > LOCATION:A > > Would have 3 RECURRENCE-ID's: > > ...T180000Z 1st instance (effective DTSTART) > ...T190000Z 2nd instance (effective DTSTART) > ...T200000Z 3rd instance (effective DTSTART) So good so far. > So now the ORGANIZER wants to change the 2nd instance to ..T193000Z. > So per iTIP they could send a new REQUEST SEQUENCE:1 : > > METHOD:REQUEST > SEQUENCE:1 > DTSTART:..T193000Z > RECURRNCE-ID:..T190000Z Also so good so far. > So once the CUA accepts the new SEQUENCE:1 object, the object > still has three RECURRENCE-ID's: > > ...T180000Z 1st instance (effective DTSTART) > ...T193000Z 2nd instance (effective DTSTART) > ...T200000Z 3rd instance (effective DTSTART) > > As the RECURRENCE-ID is the effective DTSTART value > of the instance. Oooops just violated: For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. Since you didn't provide a UID in your examples (how strange) let's go ahead and use UID: 1 First you defined UID 1 with three events, then you updated one of those instances. This was fine, but when you listed the new RECURRENCE-ID's you seemed to miss that you haven't redefined the recurrence set of UID 1, just updated the DTSTART of an instance whose effective DTSTART is still defined by UID 1/SEQUENCE 0. UID 1 and UID 1/RECURRENCE-ID ...T190000Z are two totally separate calendar components which each track there own SEQUENCE values. > Now change the 3rd instance of the SEQUENCE:1 object to ...T190000Z > and move its LOCATION to 'B'. > > METHOD:REQUEST > SEQUENCE:2 > DTSTART:..T200000Z > RECURRNCE-ID:..T190000Z > LOCATION:B Woaaahhh you have two problems here. First the 3rd instance is actually RECURRENCE-ID: ...T200000Z which you were trying to DTSTART to ...T190000Z and move to location B so you're example message wrong, but I can work with what you intended. The second problem is that you just jumped two SEQUENCE values when you've only made one change to this object. You haven't touched the 3rd instance prior to this point, and the update above to the second instance did not update UID: 1, it updated UID: 1/RECURRENCE-ID: ...T190000Z so this is actually a SEQUENCE: 1 move for UID: 1/RECURRENCE-ID: ...T200000Z. Remember that: UID: 1 and UID: 1/RECURRENCE-ID: ...T180000Z and UID: 1/RECURRENCE-ID: ...T190000Z and UID: 1/RECURRENCE-ID: ...T200000Z are totally separate objects which persist their own SEQUENCE. > So once the CUA accepts the new SEQUENCE:2 object, the object > still has three RECURRENCE-ID's (new effective DTSTART times): > > ...T180000Z 1st instance (effective DTSTART) > ...T190000Z 2nd instance (effective DTSTART) > (used to be the 3rd instance) > ...T193000Z 3rd instance (effective DTSTART) > (used to be the 2nd instance) This is actually totally screwed up at this point with exception of the first instance. There are four components involved in this event at this point and they are described as follows: UID: 1 - describes three instances starting an hour apart at Location: A UID: 1/RECURRENCE-ID: ...T180000Z - hasn't been touched at Location: A UID: 1/RECURRENCE-ID: ...T190000Z - DTSTART: ...T193000Z at Location: A UID: 1/RECURRENCE-ID: ...T200000Z - DTSTART: ...T190000Z at Location: B This is important to note for you to see the flaw in your later assertion that "in Bruce's model, you're broken". > Now change the SEQUENCE:2 2nd instance to ...T200000Z: This actually needs to read: "Now change the SEQUENCE:1 version of the 2nd instance to ...T200000Z" This will actually be a SEQUENCE: 2 update for the 2nd instance. > METHOD:REQUEST > SEQUENCE:3 > DTSTART:..T190000Z > RECURRNCE-ID:..T200000Z First off you totally screwed the pooch on mixing up the RECURRENCE-ID and DTSTART again. Secondly you're just being sloppy or you're getting models confused because up to now you seem to have been using a changing RECURRENCE-ID model which would make the ID for the 2nd instance ...T193000Z. > Now in Bruce's model, your broken because you just moved > the SEQUENCE:0, LOCATION:A meeting to ...T200000Z to LOCATION:A. > When in fact the move was to move the LOCAION:B meeting. > > Bruce's reply is to throw the object away and start over > because its impossible to resolve. Again, this is a totally bogus assertion. The above message should actually read: METHOD:REQUEST SEQUENCE:2 DTSTART:..T200000Z RECURRNCE-ID:..T190000Z I don't quite understand what you are asserting is broken. If you first create three events at Location: A, you then move the time on the second, and then the time and the location on the third, and then just the time again on the second. You end up with the first two events at location A, one starting at 1800Z, the other at 2000Z, and the thrid event at location B starting at 1900Z. What's broken about that? This would leave us with the following four objects: [Note: The first instance may or may not actually be represented in the calendar store since it was never actually modified from its original description] UID: 1 - describes three instances starting an hour apart at Location: A - SEQUENCE: 0 UID: 1/RECURRENCE-ID: ...T180000Z - hasn't been touched at Location: A - SEQUENCE: 0 UID: 1/RECURRENCE-ID: ...T190000Z - DTSTART: ...T200000Z at Location: A - SEQUENCE: 2 UID: 1/RECURRENCE-ID: ...T200000Z - DTSTART: ...T190000Z at Location: B - SEQUENCE: 1 > > Now I think this means that Doug is trying to say that > > the RECURRENCE-ID is set to the original value of the instance > > being modified which with a changing RECURRENCE-ID could be > > different. But I find it impossible for Doug to support > > this claim because as far as I can see there is no where in > > the text that allows one to set a before and after RECURRENCE-ID. > > So the only way to get a differing RECURRENCE-ID is for CS/CUA > > to proactively change it on its own accord which the message > > never specifies to do. > > You do not change RECURRENCE-ID's directly. You update the object > in ways that alter the effective DTSTART value for an instance. The "effective DTSTART" is per the UID / SEQUENCE set description pair, not the UID/RECURRENCE-ID / SEQUENCE pair. Otherwise you conflict with: For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. > And as its effective DTSTART value is changed, thus its RECRRENCE-ID > changes to match its effective DTSTART value. And: > > (iTIP) > An instance of a recurring event is assigned a unique identification, > "RECURRENCE-ID" property, when that instance is renegotiated. > Negotiation may be necessary when a substantive change to the event > or to-do has be made (such as changing the start time, end time, due > date or location). The "Organizer" can identify a specific recurrence > instance using the "RECURRENCE-ID" property. The property value is > equal to the date/time of the instance. If the "Organizer" wishes to > change the "DTSTART", the original "DTSTART" value is used for > "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values > reflect the change. Note that after the change has occurred, the > "RECURRENCE-ID" has changed to the new "DTSTART" value. > > You do not 'set' the 'before' and 'after' RECURRENCE-ID, you > alter the effective DTSTART directly by updating one or more > instances and the RECURRENCE-ID is defined to match the > new effective DSTART. I hold that the "Note" mentioned above which is a main crux for the changing RECURRENCE-ID understanding is an actual RFC error and was not the intent of the authors. That text appears in one place, however in numerous places throughout the RFC iTip goes to great pains on several occasions to talk about how iTip must be tolerant of missed/lost messages. In the changing RECURRENCE-ID model this idiom is severely violated since it is not tolerant at all to missequenced messages and especially volatile in the presence of lost messages. Further, the "effective DTSTART", is the DTSTART of the instance as described by the recurrence set in the event object and not the current DTSTART for any given instance. Ok, now this next part we all totally agree on!!!! > Another way to change the RECURRENCE-ID's is to alter the times > an existing VEVENT. So if the SEQUENCE:0 object were: > > METHOD:REQUEST > SEQUENCE:0 > DTSTART:20030805T180000Z > RRULE:FREQ=HOURLY;COUNT=3 > LOCATION:A > > Would have 3 RECURRENCE-ID's: > > ...T180000Z 1st instance (effective DTSTART) > ...T190000Z 2nd instance (effective DTSTART) > ...T200000Z 3rd instance (effective DTSTART) > > If the ORGANIZER sent a SEQUENCE:1 : > > METHOD:REQUEST > SEQUENCE:1 > DTSTART:20030805T180000Z (same as the SEQUENCE:0 value) > RRULE:FREQ=HOURLY;COUNT=3;INTERVAL=2 > LOCATION:A > > The SEQUENCE:1 object would 3 RECURRENCE-ID's 2 of which > are different than the SEQUENEC:0 object: > > ...T180000Z 1st instance (effective DTSTART) > ...T200000Z 2nd instance (effective DTSTART) > ...T220000Z 3rd instance (effective DTSTART) > > The ORGANIZER moved two instances and their effective > DTSTART values (RECURRENCE-ID). Absosmurfly! Without question! and with violent agreement, Yes! Updating to SEQUENCE: 1 on the base event object, by for instance doing a recurrence set description update like the above, in every way, shape, and form throws all RECURRENCE-IDs from the SEQUENCE: 0 version into doubt. I am in total agreement, as is Bruce from what I've read, that this kind of change, one in which no RECURRENCE-ID is referenced to limit the scope to a single instance but instead operates on the whole set of instances, totally presents the possibility that the RECURRENCE-ID of the instances will change. In fact, the new RECURRENCE-ID will be the bewly updated "effective DTSTART" value. This new set of RECURRENCE-IDs will remain "fixed" for as long as the event set descriptor maintains its same SEQUENCE value. Should another change update the set descriptor object to SEQUENCE: 2, the entire set of RECURRENCE-ID MUST be recalculated to their new effective DTSTART values. It seems to me that main crux to the differences here is a different understanding in the handling of the SEQUENCE values in relationship to the several calendar components that exist to serve a single recurring event. I'm too tired to look it up now, but the section on what objects must persist under what circumstances should clear up that issue. So at the moment, given lack of text to back me up, I can only contend that the RFCs specify that for each recurring event there are two types of calendar components. One type is the event descriptor itself (UID with no RECURRENCE-ID) and the other type is a recurrence instance within that set (UID and RECURRENCE-ID) and that every one of these objects tracks its own independent SEQUENCE value. -- Michael -- From owner-ietf-calendar@mail.imc.org Sat Aug 9 04:09: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 EAA22706 for ; Sat, 9 Aug 2003 04:09:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h797tjqt091177 for ; Sat, 9 Aug 2003 00:55:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h797tj5u091176 for ietf-calendar-bks; Sat, 9 Aug 2003 00:55:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h797thqt091170 for ; Sat, 9 Aug 2003 00:55:43 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lOan-00014s-00 for ; Sat, 09 Aug 2003 09:56:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lOam-00014i-00 for ; Sat, 09 Aug 2003 09:56:48 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Sat, 9 Aug 2003 00:55:17 -0700 Lines: 483 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> X-Complaints-To: usenet@main.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: > > Let's say we want to invite Satya to the Jan-5 instance. > > > > Without the RECURRENCE-ID property as you've suggested, > > it would contain: > > UID: 1 > > SEQUENCE: 0 > > DTSTART: Jan-5 > > > > To which his reply I assume must contain: > > UID: 1 > > SEQUENCE: 0 > > > > How does this unambiguosly tell me which instance Satya > > is responding to. > > All of them that he was invited to attend. This is totally ambiguous I invited him to two instances. Let's say he accepted Jan-4 and declined Jan-5. How does Satya specify a message that says that? In the model I presented, Satya receives two components that each contain a RECURRENCE-ID and none that contain a UID only. I receive a separate REPLY to each. Each REPLY contains a RECURRENCE-ID which exactly identifies what the attendence status for each instance will be. Because they happen to be for the same UID they can both be put in the same iCal object. In the model you just presented Satya receives 1 message which contains each instance he's invitied too... Which maens... that you are making a special new version of the event, which is also a recurring event, but contains only those two instances? Where in the RFCs does it ever say that MUST, SHOULD, or even MAY ever occur?! UIDs are defined to uniquely and globally identify a component. These new UIDs you are sending are only unique in the context of the recipient's CUA, and are clearly ambiguous in your local calendar store. > Your thinking > of exactly one instance at a time. What if I want someone > to attend instances 3,6,14? If you add the RECURRENCE-ID > you have to to send 3 REQUESTs and get 3 REPLYs. Right, you're inviting them to three instances of the event each of which have an indepentent attendence status. Satya will have to send multiple replies if there are mixed accept/decline/counter responses anyways. > It is > not needed. Just send that ATTENDEE a single REQUEST with > the dates/times they are requested to attend. (see how > to disambiguate below) > I can't believe that any CUA that allows the CU to invite > an attendee to one or more specific instances is going > to rely on the REPLY's coming back from the ATTENDEE to > tell the ORGANIZER when the ATTENDEEs are invited. It doesn't. It sets the fact that it invited the user at the time it sent the REQUEST in its local copy of the instance by setting the ATTENDEE partstat for Satya to "NEEDS-ACTION". It places this ANTENDEE field on the unique calendar component of the UID/RECURRENCE-ID it already has in the local store. It does however rely on the REPLY's coming back from the ATTENDEE to tell the ORGANIZER whether or not the ATTENDEE has ACCEPT/DECLINE/COUNTER obviously. > The ORGANIZER-CUA > is going to already know who they invited to what instances. Right. As I said it adds them as an ANTENDEE to the calendar component that represents those instances (the one with the RECURRENCE-ID). It has one copy of that instance component that it shares with all attendees involved. > The ORGANIZERs CUA is already going to have to track objects > sent that are waiting replies. Match them up which is what > you are going to have to do anyway in order to clean up > the CUAs pending things to care about queue. Wrong. I can't see anything in the RFCs that says you have to track objects sent. The CUA just has to do two things. Keep the most recent state of objects it has seen come through its queue, and process messages as it comes through the queue. It does not have to track which messages are in transit or match up anything to what's in its queue. It has one master calendar store that it keeps all objects in, and it has one or more methods through which it sends/receives messages. A message comes in, that message references a unique object in the store, that message gets processed and then discarded. Any message that it sends out, it optimistically assumes it reached its destination. This is especially true given several of the iTip references to missed messages, but this one from 2.1.3 Component Revisions seems especially telling. In some circumstances the "Organizer" may not have received responses to the final revision sent out. In this situation, the "Organizer" may wish to send an update "REQUEST", and set "RSVP=TRUE" for all "Attendees", so that current responses can be collected. The "Organizer" knows which people it believes haven't responded (either because they never saw the response or it was never sent) because the ATTENDEE partstat field is set to "NEEDS-ACTION". > Send an iTIP REQUEST and process an iTIP REPLY. No new > method needed. No need to confuse a new invitation > with a modification to an existing instance. There's nothing confusing about it as iTip spefically states exactly how to do intrepret the message to figure out if its an invitation or an update. In fact it's really simple. If you have the UID in your store it's an update, and if you don't, it's an invite. AKA if you've ever seen that UID/RECURRENCE-ID before this message is an update (SEQUENCE/DTSTAMP permitting), otherwise it's a new invite. This is simply Sending an iTIP REQUEST and processing an iTIP REPLY and it confuses nothing. < Example stuff leading up to this part snipped> > > As a result, without the RECURRENCE-ID Satya can only > > be invited to one ambiguosly referenced instance of > > the recurring event. > > With the RECURRENCE-ID you can only specify exactly > one instance of a recurring event. Did you say that > backwards? No, I need to specify exactly one instance, and I need to specify one twice. I also misrepresented your model. I was not aware that you were spawning off a new version of the UID to act as a "Satya's version" of the same UID. I thought you were sending a single non-recurring event with the same UID and SEQUENCE but different DTSTART. Under this assumption the UID ambiguously referenced the same two instances because the RECURRENCE-ID was not present. However, doing what you suggest is ta direct violation of iTIP. This model demands a fragementation of the store to track one special version of UID: 1 just for Satya along with at least one other version of the UID for the other ATTENDEES who got the original description with the three instances. This means that to identify a particular REPLY you have to look at UID / SEQUENCE and ATTENDEE to figure out which object in the store you are looking at which is clearly not what the RFCs say. For instance what if Satya wanted to COUNTER the invite? Satya would send a message that used UID: 1 and no RECURRENCE-ID which would ambiguously reference both the UID: 1 that the original people received with three instances, and the version of UID: 1 that Satya received with just two. Further, to back up exactly why doing this fragmentation is a violation of the RFCs, we have: Property Name: UID Purpose: This property defines the persistent, globally unique identifier for the calendar component. Your UIDs are not globally UNIQUE - you have different versions of the same UID for different ATTENDEES in your local store. Further the UIDs on the ATTENDEES calendar are also not globally unique, they are only locally unique. It also does not say "This property used in conjunction with ATTENDEE defines ..." as you are suggesting to use. Then we also have: Property Name: RECURRENCE-ID Purpose: This property is used in conjunction with the "UID" and "SEQUENCE" property to identify a specific instance of a recurring "VEVENT", "VTODO" or "VJOURNAL" calendar component. It does not say UID, SEQUENCE, and ATTENDEE to figure out which instance. It says UID and SEQUENCE only. In your model the SEQUENCE numbers for the various versions get out of sync any time there's a rechedule that does affect every possible ATTENDEE to any instance of the reccuring set. For instance, if we add a Jan-6 instance to UID: 1. Since Satya isn't invited to that instance there's no need to rev Satya's version of the UID. But there is for any of the other ATTENDEE's, so UID: 1 is now at SEQUENCE: 0 for Satya, and SEQUENCE: 1 for the others. If Satya should send a REPLY at this point trying to updating the attendance status for UID: 1/RECCURENCE-ID: Jan-4, as per iTIP processing rules Satya's message would be dropped since Satya is reposnding at a SEQUENCE: 0 component version. So to prevent this either you have to rev the version of Satya's component to, which sends Satya a reschedule but nothing has actaully changed, or you have to also use the ATTENDEE property in conjunction with SEQUENCE and UID property to find out if the message is valid. And we also have: Property Name: ATTENDEE Purpose: The property defines an "Attendee" within a calendar component. No where there does it say "and is also used to disambiguate REPLYs to different versions of a UID created especially for that ATTENDEE". I'm sure I could go on, but I'll stop there for now. > Another option is to track the SEQUENCE per recurrence-rule-set > per UID. There is NO requirement that all ATTENDEEs see the > same objects. Then just bump the SEQUENCE number for each > unique ATTENDEE recurrence-rule=set sent - them map them back > on REPLYs in the CUA. The binding of a SEQUENCE on a UID to the recurrence rule set is exactly what iTIP and iCal call for, but it is a global binding, identical for all CU, not tracked on a per ATTENDEE basis. Further, it is absolutely a requirement that all ATTENDEES see the same objects as an implicit extension that the UID used to create that component be globally unique. I'm sure there are other implicit reasons which by extension demand global uniqueness.... The "Party Crasher" comes to mind since the REPLY does not contain any ATTENDEE for which you have a record of which version you actually sent them, nor is that information necessarily in the REPLY - it might be - but it's not required to be. > Another bug is that iTIP already says that if you add RECURRECE-ID > you are telling them to MODIFY the instance. Your adding > an ambiguity. If they do not have that UID, then they > could only make one conclusion, they missed the original because > they now have a modification. Now they have to guess, did I miss > the original that this is an update to?; or is this a new invitation? No iTIP doesn't say this that is your misintrepretation of something in the prose. I request you find any supporting evidence for this argument or cease with this assertion. (I'd actually demand it, but there's little point in demanding anything online.) iTIP is very clear on "If they do not have that UID" it explicitly and undeniably states that's it's a REQUEST "for a new VEVENT calendar component". Eating my own requests, here are the relevant texts to back up my argument, on both that a new UID with a SEQUNCE > 0 is for a new request AND that any such request can and MUST include a RECURRENCE-ID if referencing a recurring instance. From the iTIP sources: 3.2.2 REQUEST ... If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. No where in there does it ever say anything at all about how to use SEQUENCE, nor does it say anyhing at all about RECURRENCE-ID. It just says "If the UID property value is not found ... a new VEVENT ... " (There is a single reference to SEQUENCE which just says that it is used as part of determining what a particular REQUEST message is, but SEQUENCE's use only occurs in later sections.) So if I send a REQUEST with a UID/RECURRENCE-ID and the CUA has not seen that UID before it's an invite. However now we could get a bit ambiguous because if I send a similar invite to a different instance the CUA will have seen the UID as per the first invite to the first instance. This MIGHT lead someone to believe that this behavior would work the first time but not the next. As the next would then specify some kind of update. But the text specifically talks about "a new VEVENT calendar component". VEVENT calendar components have very strict rules for figuring out exactly which component on the calendar the message is addressing, and those rules clearly state: 2.1.5 Message Sequencing 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. So therefore, to invite someone to "an instance of a recurring component" (which happens to be a separate component in its own right) you use its primary key. Its primary key is the UID/RECURRENCE-ID pair. And therefore, the reference to "UID" in section 3.2.2, by extension of being a reference to the primary key for the calendar component being addressed (which may happen to be a recurrence instance), maes it is pretty clear that the text for section 3.2.2 and the others just like it should have either read "the primary key property" or something along the lines of "the UID (and if present RECURRENCE-ID) property". Now in case that still wasn't enough to convince you. We skip down to the sections that talk about updating an event which is what you seem to think we would be doing: 3.2.2.2 Updating or Reconfirmation of an Event ... If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar and that the "SEQUENCE" property value in the "REQUEST" is the same as the value for the existing event, then the "REQUEST" method describes an update of the event details, but no rescheduling of the event. Again it talks about if "the UID property value already exists" and further that "the SEQUENCE property value is the same" then it's an update. So in this case it very clearly states that CUA MUST already have the exact same UID _and_ SEQUENCE from the message on its calendar in order for the REQUEST message to be treated as an update. In the case that is has never seen that component before, regardless of whatever the SEQUENCE value happens to be in the message, it cannot consider it an update. This leaves the only other possible operation the REQUEST message could be: 3.2.2.1 Rescheduling an Event ... If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is greater than the value for the existing event, then the "REQUEST" method describes a rescheduling of the event. So in this case the CUA MUST have _some version_ of the UID already on its calendar in order for the REQUEST message to be treated like a reschedule. Since it has never seen this component before it is impossible for it to be on its calendar and therefore it is impossible for the CUA to treat this REQUEST as a reschedule. Neither 3.2.2.1 nor 3.2.2.2 tell the CUA what to do if the supplied UID is not on its calendar. And if it's never seen the component before, then it is impossible for the component to be on the calendar and therefore it is impossible to treat a REQUEST message for a component they've never seen before as any kind of an update, reconfirmation, or reschedule by virtue of these two sections. Since no other sections in iTIP talk about how a REQUEST message can be treated as an update, reconfirmation, or reschedule, it is absolutely impossible for one to claim that a REQUEST message, which contains a UID (and by proof above, inclusive of possible RECURRENCE-ID) that the CUA has never seen before can ever be considered an update, reconfirmation, or reschedule. Cease possibly confusing people by claiming that it is a modification or back it up with several corroberating sections as I have done. Further, since sections 3.2.2.1 and 3.2.2.2 do not say what to do if the UID (and, by extension of being a possible primary key component, the RECURRENCE-ID) is absent from the calendar, you have to look somewhere else. Only section 3.2.2 talks about this and it very explicitly states that if the CUA has never seen the UID (which by virtue of being a referrence to a unique calendar component should actually have been either "primary key" or made a reference to the possible RECURRENCE-ID that might required to specify the component) then it is absolutely and without question a REQUEST for a new VEVENT calendar component. No where in the prose either implicitly or explicitly does it ever say that a new VEVENT is only created when the SEQUENCE is 0. Further, it says _absolutely nothing_ about what to do about the SEQUENCE property if it's never seen the component. If it's never seen the component specified in the message, iTIP says one and only thing, it's a REQUEST for a new VEVENT component. If the SEQUENCE should happen to be larger than 0, the VEVENT component just gets created at the large SEQUENCE value and sections 3.2.2, 3.2.2.1 and 3.2.2.2 consistently, cleanly, elegantly, and harmoniously define what to do in every valid message received. > > If I was to invite Satay to these instances I would > > send him messages that contain the RECURRENCE-ID I > > was inviting him to. He would treat them as an > > invite and send a REPLY that contained the RECURRENCE-ID. > > This is new method of inviting someone that has not beep proposed > but has been declared as a solution to a problem that already > had a solution. Not really, this is the existing method defined as I have very explicitly described above. Your method of tracking different versions of UID is just a plain violation of the RFC. I'm not going to say it won't work as it just might given that you fragment your calendar to keep track of separate versions of the same UID for separate individuals which allows you to keep a consistent converstation which each person which will create the illusion of a single object respective of each of the ATTENDEES. But if they ever share the same UID between them without going through you first a whole lotta trouble could occur. > > In fact this is the only workable method of inviting > > him to two instances of the same recurring event I > > can envision. > > Simply send him a REQUEST/VEVENT with the dates that > he is requested to attend and process the replies. > Ether by issuing a new multi-instance (contains recurrence > rules) REQUEST/VEVENT with a new DTSTAMP, or map the > SEQUENCE/UID/recurrence-rule-sets and map the replies > at the CUA. As I said earlier this fragments my calendar to create multiple versions of the same UID and adds ATTENDEE as a new primary key to a VEVENT component which is a clear a deliberate violation of both iTIP and iCal. I will _simply_ do no such thing and purport that it is an implementation of iTIP. It would merely be a proprietary implementation that happened to work with iTIP a lot of the time. -- Michael -- From owner-ietf-calendar@mail.imc.org Sat Aug 9 05:43: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 FAA24029 for ; Sat, 9 Aug 2003 05:43:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h799Xmqt005271 for ; Sat, 9 Aug 2003 02:33:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h799XmhW005270 for ietf-calendar-bks; Sat, 9 Aug 2003 02:33:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h799Xkqt005262 for ; Sat, 9 Aug 2003 02:33:47 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lQ7x-0002Nz-00 for ; Sat, 09 Aug 2003 11:35:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lQ7w-0002Nq-00 for ; Sat, 09 Aug 2003 11:35:08 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Sat, 9 Aug 2003 02:33:41 -0700 Lines: 79 Message-ID: References: <3F32CF99.9040901@Royer.com> X-Complaints-To: usenet@main.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:3F32CF99.9040901@Royer.com... > > > Robert_Ransdell@notesdev.ibm.com wrote: > > > > Do you disagree that iTIP says that if it has a RECURRENCE-ID and > > METHOD:REQUEST that it is a modify and not a new invitation? > > > > This blatantly FALSE. > > > > The request method makes no such distinction. > > If you receive a request and it is not on your calendar, you must treat > > it as an invitation. > > Nope - iTIP - Modify A Recurring Instance, look for: > > ...Note the use of "RECURRENCE-ID" property and "SEQUENCE" > property in the second request. What does this have to do with making a new REQUEST? Of course this example uses a RECURRENCE-ID and it is an update because the recipient already has their calendar. A new REQUEST _by definition_ is one for which the CUA has never seen the UID before. This example is totally out of a context. A REQUEST is sent to do lots of things. Some of which are to request a new VEVENT, update an existing event, reconfirm an existing event, reschedule an existing event, and as a response to a REFRESH. How the local CUA treats the REQUEST is clearly laid out in Section 3.2.2 of iTIP where it explicitly states that if it has never seen the UID before it's a request for a new VEVENT calendar component. I can't find anything in the text that says: If it has a RECURRENCE-ID and METHOD REQUEST then it is an update, but in every single example case the recipient CUA already has a copy of the UID. It is not a new appearance. Even the example that triggers the REFRESH request only does so because it has received a message for which the UID/SEQUENCE it already has versus the one in the message is a 2+ difference so it figured it missed some updates and wants the latest updated copy. Again, not a new instance of a UID which it has never seen before. > And i iTIP - Working With Recurrence Instances, at and near: > > ...If the "Organizer" wishes to > change the "DTSTART", the original "DTSTART" value is used for > "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values > reflect the change. Note that after the change has occurred, the > "RECURRENCE-ID" has changed to the new "DTSTART" value. > > If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification. This is simply saying that if you want to modify a VEVENT you include the RECURRENCE-ID to identify it. Your local calendar has seen the UID before, and all preexisting ATTENDEES have also seen the UID before so therefore it's a RESCHEDULE because the UID already exists and the SEQUENCE is larger than what all of them have seen. This is clearly defined in section 3.2.2.2. If the recipient CUA has never seen the UID before it is treated as a new request as defined in 3.2.2 -- Michael -- From owner-ietf-calendar@mail.imc.org Sat Aug 9 07:08:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25674 for ; Sat, 9 Aug 2003 07:08:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79Awxqt012419 for ; Sat, 9 Aug 2003 03:58:59 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h79AwxBk012418 for ietf-calendar-bks; Sat, 9 Aug 2003 03:58:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79Awuqt012413 for ; Sat, 9 Aug 2003 03:58:57 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lRSN-0003KH-00 for ; Sat, 09 Aug 2003 13:00:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lRSK-0003K8-00 for ; Sat, 09 Aug 2003 13:00:16 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Sat, 9 Aug 2003 03:58:47 -0700 Lines: 289 Message-ID: References: <3F3039CC.2050101@Royer.com> <3F328D81.6020505@Royer.com> <3F33D541.9090601@Royer.com> X-Complaints-To: usenet@main.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:3F33D541.9090601@Royer.com... > > > Michael Fair wrote: > > > > > > So further down in the IMAP definition, we find this text: > > > > For a given pair of "UID" and "SEQUENCE" property values, > > the "RECURRENCE-ID" value for a recurrence instance is fixed. > > > > So here's how I read this: > > There is a UID which describes a recurrence set. That UID has > > a SEQUNCE value which identifies the set it describes. This > > reading is supported by the part that describes how the SEQUNCE > > changing reflects a set description change which in turn could > > modify the RECURRENCE-ID of the set instances. > > > > So for examples sake, let's again use UID: 1 > > and say that SEQUENCE: 0 describes every Friday this year. > > > > So for UID 1/SEQUENCE 0 the RECURRENCE-ID for each instance > > is "fixed" at the Fridays of this year. If I move one of > > those instances (say June, Friday the 13th) to Thursday. > > Then I update that particular instance's SEQUENCE to 1. > > This is only an update to the SEQUENCE for that specific > > instance's calendar component not for the parent UID 1 > > set descriptor. The UID/SEQUENCE pair has not been updated. > > The (UID-RECURRENCE-ID)/SEQUENCE pair (or triplet depending > > on how you want to describe it) has been updated and has > > no relevance to whethere or not the RECURRENCE-ID is fixed. > > I am confused reading your above paragraph. Are you saying > that the RECURRENCE-ID is tied to the UID/SEQUENCE? Yes > that is my point. I am saying that there are two component types. UID - describes a recurring set UID/RECURRENCE-ID - describes an individual instance of the above UID. I am further saying that there is a seperate and distinct SEQUENCE on each type that are completely unrelated to each other. So UID: 1/SEQUENCE: 0 is a totally different component than UID: 1/RECURRENCE-ID: today/SEQUENCE: 5 and that the RECURRENCE-ID is "fixed" in respect to the UID: 1/SEQUENCE: 0 pair. > >>In Bruces model you can NEVER add someone to the series > >>of recurring VEVENT after any change that effects the > >>effective DTSTART value of any instance as they could never > >>be able to resolve the RECURRENCE-ID because they never > >>had SEQUENCE:0. > > > > > > This is just plain false. Given my "every Friday for this > > year" example above, with the June 13th modification to > > June 12th, to invite someone to the entire series I would > > send them a > > VEVENT REQUEST containing: > > UID: 1 > > SEQUENCE: 0 > > describing every Friday this year > > with them as an ATTENDEE > > > > and simoultaneously also send them a > > VEVENT REQUEST containing: > > UID: 1 > > RECURRENCE-ID: Friday, June 13th > > SEQUENCE: 1 > > describing Thrusday, June 12th > > with them as an ATTENDEE > > Bruce clamed that you did not have to remember SEQUENCE:10. > Your claiming you do. Are you sure you and Bruce are > talking the same model? That whole SEQUENCE: 10 thing was about inviting an ATTENDEE to the SEQUENCE: 10 of a particular recurrence instance. You asked how to invite someone to the entire series after some per instance rescheduling had been done. So that's what I showed you. If you like I can move the June 13th instance around 9 more times and invite a new ATTENDEE to the entire series. At that point the SEQUENCE for the June 13th instance will be 10, but the UID: 1 SEQUENCE will still be at 0. Inviting a new someone to an entire series after some rescheduling has been done is the equivalent to a REFRESH request by that ATTENEDEE so of course it has to include all per instance data. This is the same in either model. What I am coming to realize is that in your world, redefining the recurrence set, and rescheduling an instance are one and the same action. You can't say "The Friday the 13th instance occurs on Thrusday the 12th". You can only say, the set has been redefined, Friday the 13th is now excluded and Thursday the 12th is a new addition. Here's the same request back at you. We've shown you ours, now you show me yours. Create an event for every Friday of this year say 180000Z, reschedule June, 13th's instance to the 12th, and then invite a new ATTENDEE and show us the iTIP messages. > You are claming that the ORGANIZER must figure out and > send the ATTENDEE a correct set of all sequences starting > at SEQUENCE:0 up to the current sequence, and process a reply > for each sequence (because that is how it is done). No I'm not. You're stuck in thinking that all references to UID: 1 are the same component. They aren't. UID: 1 / SEQUENCE: 0 describes a recurrence set. It is one calendar component. UID: 1 / RECURREINCE-ID: Friday June 13th is a separate component. It has it's own SEQUENCE value that is incremented independently of the UID: 1 component. As I said (after shifting the event around 9 times) I could have just as easily sent this to that new attendee: VEVENT REQUEST containing: UID: 1 SEQUENCE: 0 describing every Friday this year with them as an ATTENDEE and simoultaneously also send them a VEVENT REQUEST containing: UID: 1 RECURRENCE-ID: Friday, June 13th SEQUENCE: 10 describing Saturday, June 14th with them as an ATTENDEE Once it has processed these _two_, not _eleven_, messages the recipient's CUA will be totally up to date with all the latest information including the per instance information with reschedules. Because it uses a fixed recurrence id for each instance in UID: 1/SEQUENCE: 0 it can unambiguously know that the instance that would have occureed on Friday the 13th now occurs on Saturday the 14th and never needs to concern itself with any SEQUENCE version of UID: 1/RECURRENCE-ID: June 13th prior to 10. > Why go > through all of that? Why not just send ONE REQUEST/VEVENT > with the latest state? No RECURRENCE-ID needed no need > to force the ATTENDEE CUA to REPLY to X number of REQUESTS > only to immediately throw X-1 away and end up with with > what could have just been ONE REQUEST/REPLY ? That is not > a simplification. Because it would also be impossible for me to convey any per instance changes (like venue changes or comments) in just one VEVENT object. Also if I adopted a model where I just sent them one VEVENT with the latest state it would totally invalidate all the "partstat" values for that VEVENT every time a change that caused a SEQUENCE increment to any instance ever happened. With the existing model updating the SEQUENCE for any particular instance only invalidates the "partstat" value for that single instance and for no other instances because none of those other instances have had a significant change to them. > Assuming that what you are saying is true, think of > a public calendar where hundreds of people may be > added and removed to a series of public events. Do you > really want to process (SEQUENCE*new-ATTENDEE) objects and > REQUEST/REPLYs? When it could just be (1*new-ATTENDEE) > REQUEST/REPLY packets? Actually it would never be SEQUENCE*new-ATTENDEE. The absolute worst case scenario in the fixed RECURRENCE-ID world is (1+NUM_INSTANCES)*new-ATTENDEE. And that would only happen if every single instance had per instance data above and beyond what was defined in the base component. For instance partstat values that were different from the base component response, descriptions and comments, ATTENDEES that aren't involved in the base component are all examples of properties that would force a specific description in the iTIP message. Essentially, the cost of inviting a new ATTENDEE is the same cost as a REFRESH which in a fixed RECURRENCE-ID model is at worst 1+NUM_INSTANCES VEVENTs big and at best 1 VEVENT big. > The assertion (by someone) that this is simpler is an attempt > to declare that a new way of doing things is iCAL/iTIP. No it > is not. > > Your example covers a case that works, what about the one I described > that did not work? I have a searched this thread up and down and the only example of you claiming that something didn't work was the example you deleted from this post where I message by message pointed at A) Your sloppy construction of the message, B) How you would construct the proper messages given a fixed RECURRENCE model, C) the state of the calendar after each said message, and D) why "Bruce's model" did not fall down as you asserted it did. Unless there is another example I can't find aside from: Create three instances, move the time of the second, move the time of the third to the original time of the second and change its venue, and then move the time of of the second to the original time of the third. Which I very clearly proved was not a problem for a fixed RECURRENCE-ID model (as had Bruce before me), please post the example/challenge again because I don't see one. If you don't think I proved how the fixed RECURRENCE-ID model succeeds given that example then look at my message of 8/8 3:51am and look for the part about "and lastly to cover that great example you offered" (the one you deleted from this post) and show me how a fixed recurrence model "breaks". All of the messages are there, the state descriptions are there, it very clearly and plainly shows what state every component is in at each phase of the game, and it even compensates for your errors to do what you meant. > > In "Bruce's model" I could even send those two objects > > out of order and you'd still be able to accurately process it > > which debunks your claim that they couldn't resolve the > > RECURRENCE-ID because they never had SEQUENCE: 0. > > > > I don't mean to be trolling here, but isn't it in fact > > the changing RECURRENCE-ID model that has the problem > > with dealing effectively with lost / missing messages? > > No, because the they map to the UID/SEQUENCE and DTSTAMP. > So if you get SEQUENCE:10 and did not get SEQUENCE:9, follow > the rules of iTIP and you will now you do not care about > SEQUENCE:9 as you have the SEQUENCE:10. If it is a modification > to an instance to SEQUENCE:10 (because it has a RECURRENCE-ID), > then follow the rules in iTIP - wait abd then to a REFRESH if > it does not arrive > > It works in any order and with missing objects. Ok this works becuase you consider the rescheduling of any instance a rescheduling of the entire set. Thus you update the master UID to reflect a set that includes the newly rescheduled instance and if you were using an RRULE to define the set you'd have to also include an EXDATE property and a new RDATE property to exclude and reinclude (respectively) the item that you just moved. So how do you get around the fact that you've now forced all the ATTENDEES to every occurence to REPLY with their partstat for every instance again (assuming they had mixed responses)... Further how do you add just one ATTENDEE to a single instance without fragmenting your calendar and tracking a separate UID version for just that person. -- Michael -- From owner-ietf-calendar@mail.imc.org Sat Aug 9 11:51: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 LAA01025 for ; Sat, 9 Aug 2003 11:51:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79Fd4qt033219 for ; Sat, 9 Aug 2003 08:39:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h79Fd4Pd033217 for ietf-calendar-bks; Sat, 9 Aug 2003 08:39:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79Fd3qt033198 for ; Sat, 9 Aug 2003 08:39:03 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h79Fd1EB026278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 9 Aug 2003 08:39:03 -0700 Message-ID: <3F35158F.40303@Royer.com> Date: Sat, 09 Aug 2003 09:38:55 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050707000200040705040600" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050707000200040705040600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>>Let's say we want to invite Satya to the Jan-5 instance. >>> >>>Without the RECURRENCE-ID property as you've suggested, >>>it would contain: >>>UID: 1 >>>SEQUENCE: 0 >>>DTSTART: Jan-5 >>> >>>To which his reply I assume must contain: >>>UID: 1 >>>SEQUENCE: 0 >>> >>>How does this unambiguosly tell me which instance Satya >>>is responding to. >> >>All of them that he was invited to attend. > > > This is totally ambiguous I invited him to two instances. > Let's say he accepted Jan-4 and declined Jan-5. > How does Satya specify a message that says that? > > In the model I presented, Satya receives two components that > each contain a RECURRENCE-ID and none that contain a UID > only. I receive a separate REPLY to each. Each REPLY > contains a RECURRENCE-ID which exactly identifies what > the attendence status for each instance will be. > Because they happen to be for the same UID they can both > be put in the same iCal object. Your ignoring the fact that is what you really sent in your proposal was a modification to an existing iTIP object. See iTIP "4.4.2 Modify A Recurring Instance" You did not send out a new invitation, you sent out a modification. Your not removing any ambiguity, your adding one. You could have copy/paste right from that section and it was mostly your example. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050707000200040705040600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwOTE1Mzg1NlowIwYJKoZIhvcNAQkEMRYEFB5QxQIX CFPlzS/pd0cqVoFy7G9LMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAB1wje2XRRH2iRKsWI7q/6wMdnidLGfaPDc/dty5b+IBWfjADM3+ O3c5vWhEWtiGH1xIzqAM5m5aFdnkysFfdX2p03q58FJQnmx5lv/zLuEb1QqQroIjzFIOaJRa 4KQJsnwS1AgF1ONkSB82jXy2+obpg8G2swXJIrHYfTHe37rnlmW7AN383h1CmmTn5EQeF2+q u2pSAUQnXWw3mizSv6NicmC8W7LF/hD+QyFQKOJ3NGH1qjbdbmjdYha4kPKyL7ZfEBTMZh1x l5WOIjwuyY4YbZmB1QhIz8gYWTuDzQKAWsHjz5OqKbpJkKTws5xlrzfnbaEtxsbWIQ9esKLu 2EoAAAAAAAA= --------------ms050707000200040705040600-- From owner-ietf-calendar@mail.imc.org Sat Aug 9 12:10: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 MAA01221 for ; Sat, 9 Aug 2003 12:10:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79G32qt036519 for ; Sat, 9 Aug 2003 09:03:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h79G32JI036518 for ietf-calendar-bks; Sat, 9 Aug 2003 09:03:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79G30qt036509 for ; Sat, 9 Aug 2003 09:03:00 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h79G2xEB026489 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 9 Aug 2003 09:03:00 -0700 Message-ID: <3F351B2D.1080404@Royer.com> Date: Sat, 09 Aug 2003 10:02:53 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F3039CC.2050101@Royer.com> <3F328D81.6020505@Royer.com> <3F33D541.9090601@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040501060708050502040508" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040501060708050502040508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>> >>>So for UID 1/SEQUENCE 0 the RECURRENCE-ID for each instance >>>is "fixed" at the Fridays of this year. If I move one of >>>those instances (say June, Friday the 13th) to Thursday. >>>Then I update that particular instance's SEQUENCE to 1. >>>This is only an update to the SEQUENCE for that specific >>>instance's calendar component not for the parent UID 1 >>>set descriptor. The UID/SEQUENCE pair has not been updated. >>>The (UID-RECURRENCE-ID)/SEQUENCE pair (or triplet depending >>>on how you want to describe it) has been updated and has >>>no relevance to whethere or not the RECURRENCE-ID is fixed. >> >>I am confused reading your above paragraph. Are you saying >>that the RECURRENCE-ID is tied to the UID/SEQUENCE? Yes >>that is my point. > > > I am saying that there are two component types. > UID - describes a recurring set > UID/RECURRENCE-ID - describes an individual instance of > the above UID. > > I am further saying that there is a seperate and distinct > SEQUENCE on each type that are completely unrelated to > each other. > > So UID: 1/SEQUENCE: 0 is a totally different component > than UID: 1/RECURRENCE-ID: today/SEQUENCE: 5 > and that the RECURRENCE-ID is "fixed" in respect to the > UID: 1/SEQUENCE: 0 pair. Well the UID:1/SEQUENCE:0 paris is fixed. And the UID:1/SEQUENCE:1 pairs are fixed. Is that what you mean? >> >>Bruce clamed that you did not have to remember SEQUENCE:10. >>Your claiming you do. Are you sure you and Bruce are >>talking the same model? > Here's the same request back at you. We've shown you ours, > now you show me yours. > > Create an event for every Friday of this year say 180000Z, > reschedule June, 13th's instance to the 12th, and then > invite a new ATTENDEE and show us the iTIP messages. Original send to ATTENDEE:one UID:1 SEQUENCE:0 DTSTAMP:...time-1... DTSTART:Friday...180000Z RRULE:every...friday... ATTENDEE:one Updates per iTIP can be done in one of two ways: (1) Update entire object and send to ATTENDEE:one UID:1 SEQUENCE:1 DTSTAMP:...time-2... DTSTART:Thursday...180000Z RRULE:every...friday... EXDATE:...june-13... RDATE:...june-12... ATTENDEE:one OR (2) Update an instance and send to ATTENDEE:one (4.4.2 Modify A Recurring Instance) UID:1 SEQUENCE:1 DTSTAMP:...time-2... DTSTART:...june-12... RECURRENCE-ID:...june-13... ATTENDEE:A Adding a new ATTENDEE - sent to ATTENDEE:two and ATTENDEE:one (And you do not have to send it to ATTENDEE:one again unless you want ATTENDEE:one to know that ATTENDEE:two was added). UID:1 SEQUENCE:1 DTSTAMP:...time-3... DTSTART:Thursday...180000Z RRULE:every...friday... EXDATE:...june-13... RDATE:...june-12... ATTENDEE:two ATTENDEE:one > > As I said (after shifting the event around 9 times) I could > have just as easily sent this to that new attendee: > > VEVENT REQUEST containing: > UID: 1 > SEQUENCE: 0 > describing every Friday this year > with them as an ATTENDEE > > and simoultaneously also send them a > VEVENT REQUEST containing: > UID: 1 > RECURRENCE-ID: Friday, June 13th > SEQUENCE: 10 > describing Saturday, June 14th > with them as an ATTENDEE That is a RESCHEDULE - not an ATTENDEE add. > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040501060708050502040508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwOTE2MDI1M1owIwYJKoZIhvcNAQkEMRYEFG13pM/H DovXN1p/RDxzGz2AJ+XeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAKpt9eWomHY2tuuefbhmOA9Xxi8g76uY1j5E1gXh0xWzZgL+T1yZ IY7WkMws7z3M11KeULi2MFABpPu/yFratw8/EQ/WMOOrT9li0l3nVUy1PNPrnSyUkm1KsIJk 065JKvl61cYXh728QhV5FlCqhjrMiQurOWuV2wKRR21uFK7/ffGk6nR8hsG+W7lNqVIWd+pK cgIKKa+cYWIUzblzgWye+NQse83OymVDYoP0PWvEQWzpfCqebLuoW3XS0jzfNSDEFVR+9QBb QGw5uz/ozAiInzyriJR7ZY6s9M4m5DsbelrhAYnW6orDuwKLxLruRJMywi5PYtOyG6KnWWB2 /1AAAAAAAAA= --------------ms040501060708050502040508-- From owner-ietf-calendar@mail.imc.org Sat Aug 9 12:15: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 MAA01316 for ; Sat, 9 Aug 2003 12:15:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79G8wqt037284 for ; Sat, 9 Aug 2003 09:08:58 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h79G8wI4037283 for ietf-calendar-bks; Sat, 9 Aug 2003 09:08:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79G8uqt037277 for ; Sat, 9 Aug 2003 09:08:56 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h79G8tEB026530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 9 Aug 2003 09:08:57 -0700 Message-ID: <3F351C92.707@Royer.com> Date: Sat, 09 Aug 2003 10:08:50 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F3039CC.2050101@Royer.com> <3F328D81.6020505@Royer.com> <3F33D541.9090601@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000608000307000208060503" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000608000307000208060503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > > > No I'm not. You're stuck in thinking that all references > to UID: 1 are the same component. They aren't. When you say 'component' do you mean booked object? Or do you mean 'over the wire component'? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000608000307000208060503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwOTE2MDg1MFowIwYJKoZIhvcNAQkEMRYEFPZd7QR3 9w+wJ1C+EVvu+Lzo5e+oMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEEODjGfekbGmuml0U7WM7TOXkVblJCpb5mqwZal3k/sLL5gOsoD AaQEwk9G4/6FitY7ReQUBk0t6RFtg9FYxID9/fEyxGUM+bt7GyNBz1z8eVoY/E3WNWOR5Mge dHvN2SGyu5j5fdvZhQ41bQSao17ShBXpfWOYnE1rERVxzENj6yOtQrIRs2L39JfSa4Zd4MyH ypiR1VvnFY62u1D4Fzo/q1mQgHzJwvsOwB08Cfmlddf89jEadct5byvNyez/4/2sGo9Rd9NQ mOcHS5wiojmkRxGbO9fwH31MqVxQKg2vxsAmx1+gmdEtjSBph3fRDsNE2jDSyHXyqiPkyXVS dRUAAAAAAAA= --------------ms000608000307000208060503-- From owner-ietf-calendar@mail.imc.org Sat Aug 9 12:37: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 LAA01026 for ; Sat, 9 Aug 2003 11:51:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79Ffjqt033549 for ; Sat, 9 Aug 2003 08:41:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h79FfjNQ033548 for ietf-calendar-bks; Sat, 9 Aug 2003 08:41:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79Ffiqt033541 for ; Sat, 9 Aug 2003 08:41:44 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h79FfgEB026320 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 9 Aug 2003 08:41:44 -0700 Message-ID: <3F351630.5020705@Royer.com> Date: Sat, 09 Aug 2003 09:41:36 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32CF99.9040901@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020305090403000200000005" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020305090403000200000005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F32CF99.9040901@Royer.com... > >> >>Robert_Ransdell@notesdev.ibm.com wrote: >> >>>Do you disagree that iTIP says that if it has a RECURRENCE-ID and >>>METHOD:REQUEST that it is a modify and not a new invitation? >>> >>>This blatantly FALSE. >>> >>>The request method makes no such distinction. >>>If you receive a request and it is not on your calendar, you must treat >>>it as an invitation. >> >>Nope - iTIP - Modify A Recurring Instance, look for: >> >>...Note the use of "RECURRENCE-ID" property and "SEQUENCE" >>property in the second request. > > > What does this have to do with making a new REQUEST? It has to do with the fact that your email was EXACTLY how to modify an existing instance. Not how to add an ATTENDEE. Your example would be indistinguishable from a modification to an existing instance. An iTIP compliant CUA would have no choice but to assume it missed the original. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020305090403000200000005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwOTE1NDEzNlowIwYJKoZIhvcNAQkEMRYEFAxyVFN4 1jp6bU+EYH/FVQlRDYDBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAL/LnLHSqCJv3z7oLUxZcqEhTFZcJZDLIdEw8iKW5iKYipKmYD0R 9ONPYuJDqRM+cNyv13q/2sf0kaP//5ouI0aDosz9M08ZwmDOrtMY7ABNOpc6pHrPd64yOIxj xcyItveTACFXB5piu97LrJrT+hxAFsg+fmn2LlbzVRmi/H5ijdPDMFx9ZW7wKPhGMF8cWrID ATHULyVXQI+ASnV8tcUzkCMAMC9Bi1rJIZWauRmpvYu4+AyLO4mhtHPcFNnBdGrij0pf18Pn 4309VGtP0n7qUCgymb2G59f/bFIf0RmgaHVoPFJx7CpgAZwSK9k8EJ0eajVU3t6Iq7xpmZw8 6bQAAAAAAAA= --------------ms020305090403000200000005-- From owner-ietf-calendar@mail.imc.org Sat Aug 9 12:45: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 MAA01738 for ; Sat, 9 Aug 2003 12:45:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79GYCqt039821 for ; Sat, 9 Aug 2003 09:34:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h79GYC80039820 for ietf-calendar-bks; Sat, 9 Aug 2003 09:34:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79GYAqt039815 for ; Sat, 9 Aug 2003 09:34:10 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h79GY9EB026715 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 9 Aug 2003 09:34:10 -0700 Message-ID: <3F35227C.7090407@Royer.com> Date: Sat, 09 Aug 2003 10:34:04 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F3039CC.2050101@Royer.com> <3F328D81.6020505@Royer.com> <3F33D541.9090601@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010809060700080508050001" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010809060700080508050001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > Once it has processed these _two_, not _eleven_, > messages the recipient's CUA will be totally up > to date with all the latest information including > the per instance information with reschedules. > Because it uses a fixed recurrence id for each > instance in UID: 1/SEQUENCE: 0 it can unambiguously > know that the instance that would have occureed on > Friday the 13th now occurs on Saturday the 14th > and never needs to concern itself with any SEQUENCE > version of UID: 1/RECURRENCE-ID: June 13th prior to 10. Nothing you sent shows how a new ATTENDEE would know how to use instances that overlapped from the original SEQUENCE:0 instances. The only thing you are showing is that as long as in the history of the event no two instances happen to have had the same time, then it works. >>Why go >>through all of that? Why not just send ONE REQUEST/VEVENT >>with the latest state? No RECURRENCE-ID needed no need >>to force the ATTENDEE CUA to REPLY to X number of REQUESTS >>only to immediately throw X-1 away and end up with with >>what could have just been ONE REQUEST/REPLY ? That is not >>a simplification. > > > Because it would also be impossible for me to convey any > per instance changes (like venue changes or comments) > in just one VEVENT object. For that use the "4.4.2 Modify A Recurring Instance" procedure and add COMMENT. > Also if I adopted a model where I just sent them one > VEVENT with the latest state it would totally invalidate > all the "partstat" values for that VEVENT every time a > change that caused a SEQUENCE increment to any instance > ever happened. With the existing model updating the > SEQUENCE for any particular instance only invalidates > the "partstat" value for that single instance and for > no other instances because none of those other instances > have had a significant change to them. First adding an ATTENDEE does NOT require the SEQUENCE be updated. For that update the DTSTAMP and resend. No PARTSTATs are effected. Second, adding an ATTENDEE does NOT require that all ATTENDEEs be updated with the latest DTSTAMP versions. I can add attendees, and as long as I do not update the properties defined in iCAL/iTIP that mandate the SEQUENCE number be updated, then I do not have to tell ALL ATTENDEES. There may be times when an implementation needs or wants to inform ALL ATTENDEEs of each ATTENDEE (or other) addition/deletion, but that in itself does not require that the SEQUENCE be incremented so no PARTSTAT is effected. Third, if you are rescheduling an event, then YES you effect the PARTSTAT of ATTENDEES going to those instances. Fourth, if ATTENDEE 'A' is NOT attending instance 'I', then you do NOT have to send 'A' an instance update. The SEQUENCE number of the booked object would be incremented because you altered the booked object. And the effected ATTENDEEs would be sent the update or new object with the new SEQUENCE. But if it does not effect ATTENDEE 'A' then you can just keep the ATTENDEE 'A' PARTSTAT value the same because they have no decision to make as it did not effect them. >>Assuming that what you are saying is true, think of >>a public calendar where hundreds of people may be >>added and removed to a series of public events. Do you >>really want to process (SEQUENCE*new-ATTENDEE) objects and >>REQUEST/REPLYs? When it could just be (1*new-ATTENDEE) >>REQUEST/REPLY packets? > > > Actually it would never be SEQUENCE*new-ATTENDEE. > > The absolute worst case scenario in the fixed RECURRENCE-ID > world is (1+NUM_INSTANCES)*new-ATTENDEE. If you bump the SEQUENCE, then you are going to tell ALL attendees in that model - correct? Then is is (*ATTENDE [new and old]) not just new-ATTENDEE - correct? > > Essentially, the cost of inviting a new ATTENDEE is the > same cost as a REFRESH which in a fixed RECURRENCE-ID > model is at worst 1+NUM_INSTANCES VEVENTs big and at > best 1 VEVENT big. A refresh is only when you get out if sync. Like getting an update when you do not have the update/sequenec-1 object. > >>The assertion (by someone) that this is simpler is an attempt >>to declare that a new way of doing things is iCAL/iTIP. No it >>is not. >> >>Your example covers a case that works, what about the one I described >>that did not work? > > > I have a searched this thread up and down and the only example > of you claiming that something didn't work was the example you > deleted from this post where I message by message pointed at > A) Your sloppy construction of the message, B) How you would > construct the proper messages given a fixed RECURRENCE model, > C) the state of the calendar after each said message, and > D) why "Bruce's model" did not fall down as you asserted it did. I can not follow your sloppy paragraph, could you cite a date time or link? > Unless there is another example I can't find aside from: > > Create three instances, move the time of the second, > move the time of the third to the original time of the > second and change its venue, and then move the time > of of the second to the original time of the third. > > Which I very clearly proved was not a problem for a > fixed RECURRENCE-ID model (as had Bruce before me), > please post the example/challenge again because I > don't see one. You did not prove it, you changed the example to one in which did not apply to the problem. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010809060700080508050001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgwOTE2MzQwNFowIwYJKoZIhvcNAQkEMRYEFI/JI3I2 RLeznpdjB56LEH6D+p0vMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBALdx9g8F6T6v7+NRqad37uI6gRXeECfZh8AQpMXu01Wnsf/tu7bb uBBpofs3KOflW4IRZoO8fFfaeiR9/8bL69DEoIHKcs41l1BLVoGtT6RWAsy/BfGtmKHmv5ML DcMiuBhB5PGLdp76H8GFwAtedQLn2MhemWvaS42Ow+HH7OenVXJno17W0+DmS9Ab+WEEaxRw BjDzLN8re9w7RfF6d9t1b/L4Axx2R1ge2tw+7LCBVEYJO8bvzmiJ+40jFo0DeGlPae+GZ57N x6CUmMTrceDLauLb+Ezm10KD4cIFncQwqJKPUaZGSPRol2LjTfRui1eJivixS5F5NuRtBPiq 9bsAAAAAAAA= --------------ms010809060700080508050001-- From owner-ietf-calendar@mail.imc.org Sun Aug 10 03:20: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 DAA00523 for ; Sun, 10 Aug 2003 03:20:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7A78Oqt088459 for ; Sun, 10 Aug 2003 00:08:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7A78NxM088458 for ietf-calendar-bks; Sun, 10 Aug 2003 00:08:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7A78Jqt088437 for ; Sun, 10 Aug 2003 00:08:21 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lkKi-0000HT-00 for ; Sun, 10 Aug 2003 09:09:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19lkKg-0000HK-00 for ; Sun, 10 Aug 2003 09:09:38 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lkJM-0000is-00 for ; Sun, 10 Aug 2003 09:08:16 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Sun, 10 Aug 2003 00:08:05 -0700 Lines: 70 Message-ID: References: <3F3039CC.2050101@Royer.com> <3F328D81.6020505@Royer.com> <3F33D541.9090601@Royer.com> <3F351C92.707@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:3F351C92.707@Royer.com... > > > Michael Fair wrote: > > > > > > > No I'm not. You're stuck in thinking that all references > > to UID: 1 are the same component. They aren't. > > When you say 'component' do you mean booked object? > Or do you mean 'over the wire component'? I'll respond to the other posts as well, but this is the most relevant difference it seems. Each instance, plus the parent UID, are each their own 'booked object', an actual component of the calendar. So when I create: UID: 1/SEQUENCE: 0 describing every Friday this year that is one physical object that the CUA can manipulate -- and then every instance of UID: 1 has a RECURRENCE-ID set to something generated by the set described by UID: 1 are separate physical objects. So assuming that there are 52 Fridays in the year, there would be 53 separate and unique objects on the calendar to support the recurring event. To further provide a concrete example of this, each time a particular range of the calendar gets viewed by the CU, the CUA generates the subset of instances that would occur in the range viewed. So if the CU was looking at the month of June, for UID: 1 the CUA would generate the RECURRENCE-IDs of June 6th, June 13th, June 20th, and June 27th. It would then lookup in its store each of those event instance components and display them. Meaning it would display the following objects: UID: 1/RECURRENCE-ID: June 6th UID: 1/RECURRENCE-ID: June 13th UID: 1/RECURRENCE-ID: June 20th UID: 1/RECURRENCE-ID: June 27th However, since we updated UID: 1/RECURRENCE-ID: June 13th to actually DTSTART on the 12th, that object would draw itself on Thursday 12th and not on Friday 13th as originally described by the RRULE of UID: 1. Assuming we made no other substantive changes, UID: 1 would be at SEQUENCE: 0, as would all UID: 1/RECURRENCE-ID: ***** with the exception of UID: 1/RECURRENCE-ID: June 13th which would be at SEQUENCE: 1. UID: 1/RECURRENCE-ID: June 13th would be at SEQUENCE: 1 because it had a substantive change that jeopardized the validity of the partstat status that was attached to the SEQUENCE: 0 version of the instance. In other words, that instance was reshceduled and so therefore the partstat of all ATTENDEES must be renegotiated. -- Michael -- From owner-ietf-calendar@mail.imc.org Sun Aug 10 03:39: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 DAA00731 for ; Sun, 10 Aug 2003 03:39:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7A7WQqt091937 for ; Sun, 10 Aug 2003 00:32:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7A7WQAc091936 for ietf-calendar-bks; Sun, 10 Aug 2003 00:32:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7A7WOqt091930 for ; Sun, 10 Aug 2003 00:32:25 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lki1-0000Rg-00 for ; Sun, 10 Aug 2003 09:33:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19lki0-0000RY-00 for ; Sun, 10 Aug 2003 09:33:44 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lkgh-0000yG-00 for ; Sun, 10 Aug 2003 09:32:23 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Sun, 10 Aug 2003 00:32:11 -0700 Lines: 106 Message-ID: References: <3F32CF99.9040901@Royer.com> <3F351630.5020705@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:3F351630.5020705@Royer.com... > > > Michael Fair wrote: > > "Doug Royer" wrote in message > > news:3F32CF99.9040901@Royer.com... > > > >> > >>Robert_Ransdell@notesdev.ibm.com wrote: > >> > >>>Do you disagree that iTIP says that if it has a RECURRENCE-ID and > >>>METHOD:REQUEST that it is a modify and not a new invitation? > >>> > >>>This blatantly FALSE. > >>> > >>>The request method makes no such distinction. > >>>If you receive a request and it is not on your calendar, you must treat > >>>it as an invitation. > >> > >>Nope - iTIP - Modify A Recurring Instance, look for: > >> > >>...Note the use of "RECURRENCE-ID" property and "SEQUENCE" > >>property in the second request. > > > > > > What does this have to do with making a new REQUEST? > > It has to do with the fact that your email was EXACTLY > how to modify an existing instance. Not how to add > an ATTENDEE. My email was "inviting" an ATTENDEE to a single instance by sending them a REQUEST with the latest SEQUENCE of the instance with them listed as an ATTENDEE. Besides, that was irrelevant at that point, the quote being responded to from you was not in the context of my examples which you were claiming to be flawed by virtue of having a RECURRENCE-ID in them. You were asserting that if a message EVER contains a RECURRENCE-ID and is a METHOD: REQUEST - then it must be a modify. That is blatantly false (to quote Robert). To his response you pointed to some examples, to which I responded that the examples you pointed to are meaningless. The examples you pointed to are considered updates because the recipient already has an existing version to be updated. If the recipient has never seen that UID before, then the METHOD: REQUEST I send, with the VEVENT object that also contains a RECURRENCE-ID would be treated like an invite to that particular instance because it has never seen that VEVENT before. It could never be treated as an update to an event that it doesn't have, couldn't have, and hasn't ever had because that's what iTIP specifies. Again, you were claiming that all iTIP messages that are METHOD: REUQEST and contain RECURRENCE-ID must be an update of some kind. Again, that claim is blatantly false and it's easy to prove via sections 3.2.2.1 and 3.2.2.2 since those are the only sections that describe how to determine what a METHOD: REQUEST is in regards to any kind of updates. Since neither of those sections tell the CUA what to do if it has never seen that UID before, those sections do not apply when the CUA has never seen that UID before. Further, there is another section, 3.2.2 which exactly tells the CUA what to do if it has never seen that UID before. It tells the CUA to treat the message as a REQUEST for a new VEVENT calendar component. Which if the recipient was also listed as an ATTENDEE (which they were) amounts to an invitation to that VEVENT calendar component (aka that recurring event instance). > Your example would be indistinguishable from a modification > to an existing instance. An iTIP compliant CUA would have no > choice but to assume it missed the original. It could only consider it an update to an existing instance if it had ever seen that UID, or UID/RECURRENCE-ID before. And if it had seen that VEVENT before, then it _would_ be a modification to an existing instance, but also wouldn't be newly inviting them, lest somehow they were told about it, but weren't actually invited (like they were a delegate) but that's getting to far away from the intent of our discussion which is just about inviting a new ATTENDEE to a recurring instance of an event for which they are only invited to that one instance and have never seen any version of it before. Therefore, by virtue of having never seen the UID before, the CUA must treat it as a REQUEST for a new VEVENT calendar component. And yes, assuming that SEQUENCE was not 0, any iTIP compliant CUA would have to assume that it missed the original, but it couldn't care less. It has just received an invite to the most recent version what does it care about the original, now invalid, version? -- Michael -- From owner-ietf-calendar@mail.imc.org Sun Aug 10 04: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 EAA01566 for ; Sun, 10 Aug 2003 04:51:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7A8gRqt099846 for ; Sun, 10 Aug 2003 01:42:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7A8gR87099845 for ietf-calendar-bks; Sun, 10 Aug 2003 01:42:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7A8gOqt099817 for ; Sun, 10 Aug 2003 01:42:25 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19llni-0000ya-00 for ; Sun, 10 Aug 2003 10:43:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19llnh-0000yS-00 for ; Sun, 10 Aug 2003 10:43:41 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19llmO-0006Tg-00 for ; Sun, 10 Aug 2003 10:42:20 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Sun, 10 Aug 2003 01:42:07 -0700 Lines: 79 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@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: > Your ignoring the fact that is what you really sent in your > proposal was a modification to an existing iTIP object. > See iTIP "4.4.2 Modify A Recurring Instance" > > You did not send out a new invitation, you sent out > a modification. Your not removing any ambiguity, your > adding one. As we have repeatedly said, we are not ignoring that. Why did you cut out the part of my post that explained this? Why didn't you respond to sections 3.2.2, 3.2.2.1, and 3.2.2.2 where it describes in very clear detail what's an update and what's not? Let's take this again from the top in a simple agree disagree method: [For simplicitly sake we shall assume that only persons who are ATTENDEES will receive copies of events. Further, we assume that any changes, regardless of how minor trigger a message to all listed ATTENDEES of the event on which the change occured.] 1) You can create a VEVENT to describe a recurring event. Agree/Disagree? 2) Whomever we invited to that recurring event receives a copy, and whoever we didn't invite doesn't get a copy. [as per the assumptions] Agree/Disagree? 3) If we modify a particular instance of an event than the SEQUENCE number to reference that event is now 1. [This is true in either of our models.] Agree/Disagree? 4) Adding a new ATTENDEE to that particular instance is a minor change which would trigger a message to all listed ATTENDEES which now includes or new invitee. [As per the assumptions] Agree/Disagree? 5) The new invitee receives a "REQUEST" message for a VEVENT object. Agree/Disagree? 6) The invitee's CUA (being iTIP compliant) must use section 3.2.2 of iTIP to determine what type of REQUEST message this is since that is the section that talks about how to determine what type of REQUEST a message is for VEVENT objects. Agree/Disagree? 7) The REQUEST message the new invitee received, lists a VEVENT object with a UID that is not on its calendar since the CU has never been invited to this or any other version of this event before (regardless of whether or not SEQUENCE is 0 or there is a RECURRENCE-ID present). [As per the assumptions.] Agree/Disagree? 8) Only section 3.2.2 itself, and none of its subsections talk about what a CUA should do if it receives a REQUEST message for an object which has a UID which it does not find on its calendar. And further, both subsections 3.2.2.1 and 3.2.2.2, which are explicitly about updates, contain the clause: If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar Agree/Disagree? I'll wait for your response before drawing any conclusions. -- Michael -- From owner-ietf-calendar@mail.imc.org Sun Aug 10 07:57: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 HAA04443 for ; Sun, 10 Aug 2003 07:57:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ABmRqt018543 for ; Sun, 10 Aug 2003 04:48:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ABmRqf018542 for ietf-calendar-bks; Sun, 10 Aug 2003 04:48:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ABmQqt018536 for ; Sun, 10 Aug 2003 04:48:26 -0700 (PDT) (envelope-from cco@asitturnsout.org) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 218798D7B5 for ; Sun, 10 Aug 2003 04:48:25 -0700 (PDT) From: "Chris Olds" To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion Date: Sun, 10 Aug 2003 04:48:25 -0700 Message-Id: <20030810102255.M61191@asitturnsout.org> In-Reply-To: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> X-Mailer: Open WebMail 2.10 20030617 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This side discussion of whether a new UID with a RECURRENCE-ID is an update or a new request is obscuring the essential problem: Using RECURRENCE-ID values fixed at SEQ:0 requires that CUAs track an additional piece of data for each recurrence of an event that is not required in the so-called 'delta' model (which I think of as a 'current-value' model, because that's all a CUA needs to track in order to get things right). Furthermore, the restriction on the number of RECURRENCE-IDs in a single message means that many more messages must be sent (and recieved!) if the responding CUA is to discover the SEQ:0 :: current-value mapping. If my CUA sees a SEQ value more than 1 more than any previous value it has for that UID, I would hope it would send a REFRESH request to the organizing CUA - there could have been arbitrary changes that I might want to know about, unless the new object has no RECURRENCE-ID (in which case, it represents the entire current state of the EVENT at that SEQ value, and is the same as what I would expect to recieve as a reply to my REFRESH request). So, which model requires more complicated bookkeeping? RECURRENCE-ID fixed at the initial value for the instance. Which requires more messages to keep the attndee's CUA in sync with the organizer? Fixed. If an attendee CUA is to keep its SEQ:0 :: current-value mapping up to date, it must process one VEVENT object per instance that has a current time different from the DTSTART it was initially scheduled with. These updates are problematic, since there is no way to request that the organizer's CUA send such a set of objects that does not risk missing new exceptions; furthermore, since different instances can be scheduled to the same date & time in the fixed model, an attendee CUA may not be able to ask for a refresh of an instance at a particular date and time (as soon as there are more active RECURRENCE-IDs than distinct instance DTSTART values, any RECURRENCE-ID could refer to any DTSTART, so while it may be unlikely that a CUA won't get the data it wants, there is no way to be certain). The fixed RECURRENCE-ID model sure seems to me like both the model that generates the most traffic and one most sensitive to missed messages - the worst of both worlds! All of this complicated bookkeeping and ambiguity can be avoided if the CUA only has to keep track of the current valid DTSTART values for the event. Any object with a SEQ value equal to or only 1 more than the greatest value seen can be processed without any more messages passing. If no RECURRENCE-ID is specified, the object is complete, and can be processed how much greater the SEQ value is; the SEQ is more than 1 more than previously seen and a RECURRENCE-ID is specified, then reqest a REFRESH from the organizer and process the result. Since this is a likely action for this case in either model, it certainly does not imply extra message traffic, or a more fragile pattern. In an email previous to the one I'm responding to, Michael seems to be proposing a third model, which I would call 'SEQ-per-instance'; since there seems to be no way to determine what SEQ to use to send a complete object that had some events updated (esp. updated different numbers of times), I don't think it is workable within the context of RFC 2445 objects, and haven't discussed it. As for the ambiguity of a CUA seeing a VEVENT with a previously-unseen UID and a RECURRENCE-ID, I think that a conservative CUA would probably process it as a new request, but send a REQUEST to the organizer for the full event, so as to be sure it wasn't missing important information. This means that I agree with all of the questions Michael asked (except #4: 'does adding an attendee trigger messages to all Attendees?', where my answer is "Don't care. This seems like a matter between an Organizer and her CUA"), but overall, I think that Doug is right and a CUA that gets such an object should assume it missed a REQUEST VEVENT and ask for a REFRESH of the entire object. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Sun Aug 10 12:55: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 MAA11051 for ; Sun, 10 Aug 2003 12:55:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AGgeqt042444 for ; Sun, 10 Aug 2003 09:42:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7AGgdYe042442 for ietf-calendar-bks; Sun, 10 Aug 2003 09:42:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AGgbqt042433 for ; Sun, 10 Aug 2003 09:42:37 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7AGgBEB024775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 10 Aug 2003 09:42:14 -0700 Message-ID: <3F3675DE.9080707@Royer.com> Date: Sun, 10 Aug 2003 10:42:06 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F3039CC.2050101@Royer.com> <3F328D81.6020505@Royer.com> <3F33D541.9090601@Royer.com> <3F351C92.707@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070703080105060108010409" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070703080105060108010409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F351C92.707@Royer.com... > >> >>Michael Fair wrote: >> >> >>> >>>No I'm not. You're stuck in thinking that all references >>>to UID: 1 are the same component. They aren't. >> >>When you say 'component' do you mean booked object? >>Or do you mean 'over the wire component'? > > > I'll respond to the other posts as well, but this is the > most relevant difference it seems. ... Thank you for clarifying, however that is not the iCalendar model that has been discussed on this WG list over the last few years. And your example that I am cutting out again still does not address the problem. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070703080105060108010409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMDE2NDIwNlowIwYJKoZIhvcNAQkEMRYEFPzFgWMJ kBtrFkC/Zyg7p0vqpvkPMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADC2mXFW8gOMvWHI8ADqMaJi+awJcqg7JhQWealBLV0BrCEWVRR7 cnRkl2QfyF+JToHSseWvT25k11XN53WgifMnctXrQYNiEuO6BPw7QswSGvDiAs2NySDmhUOe aED6Uq1FtOgFLpVaSQ02Kjn1RKfL1dkMApgxSitDG8wB7/Vzbuw6WXrW1TLvtoQimRvknH1X cojW5H/TuXp9XRdjz1AsqlcwO+XzvNTcnkzyD4dn+gyz1Vtp+coWK7ktu289YBTuy8M+trGA fLbXUViV0TrMbBquGynaxkXnJUAzVlOL/qkloyQWlCmH4JiJ2FGNO09sk67Eyjh8/V16WN2Z 3CQAAAAAAAA= --------------ms070703080105060108010409-- From owner-ietf-calendar@mail.imc.org Sun Aug 10 12:58: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 MAA11142 for ; Sun, 10 Aug 2003 12:58:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AGgeqt042445 for ; Sun, 10 Aug 2003 09:42:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7AGgedj042443 for ietf-calendar-bks; Sun, 10 Aug 2003 09:42:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AGgbqt042432 for ; Sun, 10 Aug 2003 09:42:37 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7AGgZEB024777 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 10 Aug 2003 09:42:37 -0700 Message-ID: <3F3675F6.7010407@Royer.com> Date: Sun, 10 Aug 2003 10:42:30 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020705050201080004020105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020705050201080004020105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>Your ignoring the fact that is what you really sent in your >>proposal was a modification to an existing iTIP object. >>See iTIP "4.4.2 Modify A Recurring Instance" >> >>You did not send out a new invitation, you sent out >>a modification. Your not removing any ambiguity, your >>adding one. > > > As we have repeatedly said, we are not ignoring that. > Why did you cut out the part of my post that explained > this? Again - because you altered the example to ignore the problem. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020705050201080004020105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMDE2NDIzMFowIwYJKoZIhvcNAQkEMRYEFEdz5RgI hpFH26lyzLmq65YHriLmMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJlDP4Q8dK3nVip0tlQDqG+S7f7/UnJbW0QOxMuZpLPI5CrlJj6q 85hqRSlDb/9vaoJqFJU2AXFRT7jDByOGhnGhG3ry8WBfu5I5AC0zQ7sKAtQEE8ZjGEdr0czW jPyv2ppyizwwMv5UqKhsEb+20iE+gNSLEaCM9cYTZlw66j3LooV552H1SrZGrnPsa4J0EuO6 MGKXAnpXFn7qgi9gYJqws7lzgkwL2U5DseqN2B612AZLUCV8yIzH3yL9jX3UIHMj9Iew16UU hEzVCeZ5zInkk/gWTJ2zIGf1f04Y/tnKlAjavMAtedjCYTMC3nKFOiD3gM5cIAMFLJhGR62C QxcAAAAAAAA= --------------ms020705050201080004020105-- From owner-ietf-calendar@mail.imc.org Sun Aug 10 14:00: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 OAA11904 for ; Sun, 10 Aug 2003 14:00:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AHpRqt045038 for ; Sun, 10 Aug 2003 10:51:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7AHpRvg045037 for ietf-calendar-bks; Sun, 10 Aug 2003 10:51:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AHpPqt045028 for ; Sun, 10 Aug 2003 10:51:25 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7AHjGEB025163 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 10 Aug 2003 10:45:17 -0700 Message-ID: <3F3684A6.9020007@Royer.com> Date: Sun, 10 Aug 2003 11:45:10 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080705010301040501000501" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080705010301040501000501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > > 1) You can create a VEVENT to describe a recurring event. > Agree/Disagree? > > 2) Whomever we invited to that recurring event receives > a copy, and whoever we didn't invite doesn't get a copy. > [as per the assumptions] > Agree/Disagree? > > 3) If we modify a particular instance of an event than > the SEQUENCE number to reference that event is now 1. > [This is true in either of our models.] > Agree/Disagree? Assume you have only created one VEVENT. There is one VEVENT. That VEVENT can change over time. Each distributed version of that one VEVENT is identified by a CUA by its: UID/SEQUENCE/DTSTAMP If that VEVENT has a recurrence rule, then each instance of that one VEVENT is identified by a CUA by its: UID/SEQUENCE/DTSTAMP/RECURRENCE-ID > 4) Adding a new ATTENDEE to that particular instance is > a minor change which would trigger a message to all > listed ATTENDEES which now includes or new invitee. > [As per the assumptions] > Agree/Disagree? Disagree. It is optional. Not all ATTENDEEs need see the entire ATTENDEE list. Think of a public event like a concert. Each ATTENDEE would not need to know who else is attending. It is optional. Its not a protocol issue, its an application issue. Some applications will need to send it to everyone. Some will not. > 5) The new invitee receives a "REQUEST" message for a > VEVENT object. > Agree/Disagree? Agree. > 6) The invitee's CUA (being iTIP compliant) must use > section 3.2.2 of iTIP to determine what type of > REQUEST message this is since that is the section > that talks about how to determine what type of > REQUEST a message is for VEVENT objects. > Agree/Disagree? Agree. > 7) The REQUEST message the new invitee received, lists > a VEVENT object with a UID that is not on its calendar > since the CU has never been invited to this or any > other version of this event before (regardless of whether > or not SEQUENCE is 0 or there is a RECURRENCE-ID present). > [As per the assumptions.] > Agree/Disagree? As long as you do not make it look like a modification to an existing VEVENT - agree. > 8) Only section 3.2.2 itself, and none of its subsections > talk about what a CUA should do if it receives a REQUEST > message for an object which has a UID which it does not > find on its calendar. And further, both subsections > 3.2.2.1 and 3.2.2.2, which are explicitly about updates, > contain the clause: > > If the recipient CUA of a "REQUEST" method finds that > the "UID" property value already exists on the calendar > > Agree/Disagree? Which is why you just send them a EVENT/REQUEST/UID with the SEQUENCE number equal to the booked item SEQUENCE number. Bruces 'new add attendee' method that looks like a modification to an existing VEVENT is an unneeded and ambiguous addition to the protocol. Just send them the vEVENT in a REQUEST. Send them the current booked UID/SEQUENCE and timestamp it with DTSTAMP to say this version of this one VEVENT. Option 1: You may elect to send that same object (with the SAME SEQUENCE number as the other ATTENDEES have) with an updated DTSTAMP to ALL attendees. The "Organizer" of an event may also send unsolicited "REQUEST" methods. The unsolicited "REQUEST" methods may be used to update the details of the event without rescheduling it, to update the "partstat" parameter of "Attendees", or to reconfirm the event. Option 2: Only send the new ATTENDEE the new object. If you do not want that flurry of REPLYs, don't send them to ATTENDEEs that do not need to know about other ATTENDEEs. If you want the other ATTENDEEs to know about all ATTENDEEs then you are going to get a flurry of REPLYs for huge events. iCal/iTIP were designed to work with unreliable (from the protocols point of view) transports like e-mail where the ORGANIZER can not know if the recipient got the message until the REPLY arrives. That *is* the protocol. If someone feels there is a need to invite an attendee some new way, then propose it. And make it unambiguous to the existing protocol. So far no one has demonstrated or explained why they feel they need that or why the current method does not work. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080705010301040501000501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMDE3NDUxMFowIwYJKoZIhvcNAQkEMRYEFGwUrdVt AnZK/z+3JzaTylB7dd07MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAImOx3n388TL2RW0B/XvSop77jcorxqG/dn90AGFGl3QJpOK7X63 r06lTHyXAkXaxj4gqtjFBGiu7/Y0RJeVGiagtYm+6/kyHdYBOE2gjfzA9W8gyGulsNhufjU1 oKf7XINi87Zes5ZJtAQbawXi+onHji+6a9VKrlYgPkKyGDn1uyTEzxv5gsGAryi68rI6C1+K Vq1/Yct+NcKsptxuMbzzkE10NFmjZrhbgnVHvJrdW6dg+M6TpMDYFmbThyr7dDg1gEgUpsdf sgrcg6+MYmMrjzGw/FHlneohr88Pm5QOxZNPkQ0OsPHXkPVIMw504wz3Rb5n9SRJsu8COV1K 6ccAAAAAAAA= --------------ms080705010301040501000501-- From owner-ietf-calendar@mail.imc.org Sun Aug 10 15:51: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 PAA14790 for ; Sun, 10 Aug 2003 15:51:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AJg5qt049626 for ; Sun, 10 Aug 2003 12:42:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7AJg5N3049625 for ietf-calendar-bks; Sun, 10 Aug 2003 12:42:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AJg0qt049617 for ; Sun, 10 Aug 2003 12:42:03 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lw66-00052J-00 for ; Sun, 10 Aug 2003 21:43:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19lw65-00052B-00 for ; Sun, 10 Aug 2003 21:43:21 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19lw4n-0007Wk-00 for ; Sun, 10 Aug 2003 21:42:01 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Sun, 10 Aug 2003 12:41:39 -0700 Lines: 70 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@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: > > 7) The REQUEST message the new invitee received, lists > > a VEVENT object with a UID that is not on its calendar > > since the CU has never been invited to this or any > > other version of this event before (regardless of whether > > or not SEQUENCE is 0 or there is a RECURRENCE-ID present). > > [As per the assumptions.] > > Agree/Disagree? > > As long as you do not make it look like a modification > to an existing VEVENT - agree. Just because it might look like a modification to you doesn't mean that it is one? Sections 3.2.2.1 and 3.2.2.2 define the only times a message can be a modification and the only times a message can ever be a modification is when the CUA has the existing UID on its calendar. You are putting the cart before the horse. i.e. You are putting the example before the definition. Section 4.4.2 is an EXAMPLE of how to modify a recurring instance. It is not the definition of how to detect whether or not a message is a modification of a recurring instance. The definition of how to detect if a message is a modification comes from section 3.2.2 we can't move on until we've resolved this point as its critical to the proper interpretation of the REQUEST message. You assert that just because something looks like the object in 4.4.2 it is a modification. This is not true. Anything that happens to actually be a modification will look like 4.4.2. But if it happens to be something else it might look like 4.4.2 too. A reconfirmation, a response to a REFRESH, and a new invite will all look like 4.4.2. Just because a message happens to look like it could be a modification because it shares similar values to 4.4.2 doesn't mean that it is. There are only two things that can tell you if a request message is a modification of some sort. One is section 3.2.2.1 and the other is section 3.2.2.2 and neither of them are applicable if the CUA has does not find the UID in question on its calendar. Let me put this yet another way. All of section 4 is examples. As such they are theoretically not needed because the prose above actually dictates what those examples will say. Right? The examples are useful for creating some clarity around what the text says sometimes, but it is not in any way shape or form any kind of actual definition. The examples are just instances of the above sections. In this case, example 4.4.2 happens to be an instance of section 3.2.2.1. Section 3.2.2.1 is only valid "If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar". If you send a REQUEST method to a CU and the CUA does not have the corresponding UID on its calendar neither section 3.2.2.1 nor 3.2.2.2 can be applied and therefore the message cannot be a modification, reconfirmation, or reschedule regardlesss of how much it looks like 4.4.2. -- Michael -- From owner-ietf-calendar@mail.imc.org Sun Aug 10 16:35: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 QAA15632 for ; Sun, 10 Aug 2003 16:35:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AKQrqt053019 for ; Sun, 10 Aug 2003 13:26:53 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7AKQrTN053018 for ietf-calendar-bks; Sun, 10 Aug 2003 13:26:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AKQpqt053011 for ; Sun, 10 Aug 2003 13:26:52 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7AKQpEB026211 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 10 Aug 2003 13:26:52 -0700 Message-ID: <3F36AA86.8000606@Royer.com> Date: Sun, 10 Aug 2003 14:26:46 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060204070404090201000909" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060204070404090201000909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>>7) The REQUEST message the new invitee received, lists >>> a VEVENT object with a UID that is not on its calendar >>> since the CU has never been invited to this or any >>> other version of this event before (regardless of whether >>> or not SEQUENCE is 0 or there is a RECURRENCE-ID present). >>> [As per the assumptions.] >>>Agree/Disagree? >> >>As long as you do not make it look like a modification >>to an existing VEVENT - agree. > > > Just because it might look like a modification to you doesn't > mean that it is one? Sections 3.2.2.1 and 3.2.2.2 define the > only times a message can be a modification and the only times > a message can ever be a modification is when the CUA has the > existing UID on its calendar. > > You are putting the cart before the horse. > i.e. You are putting the example before the definition. > > Section 4.4.2 is an EXAMPLE of how to modify a recurring > instance. It is not the definition of how to detect whether So, is this a modifcation and you missed the original? Or a new object? BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1com RECURRENCE-ID:19970701T210000Z SEQUENCE:1 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970703T210000Z DTEND:19970703T220000Z LOCATION:Conference Call DTSTAMP:19970626T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060204070404090201000909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMDIwMjY0NlowIwYJKoZIhvcNAQkEMRYEFHMfwzp+ 3v5nP1nC9FGlSAKB9z1+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAC6i6Kc2VDg/PLVnstM2WfHDqtmvIwclCiCJ18TwEB3VxStg/XMi ODLAp90LsubuCujs7kDh6y/Ppy0TE77mzbDJktEvALoxZYpoqOu9hUc2bir+cWOEMN8PGZf6 5Xvhd0sicU412jsg7xQYk3WKf58LmNGkBBT+udFWmyekvglMOGT0zZxLHwmPUvLiBoUBeCPa faDc63I5qY8H9kxsR4T8irlVG1a+BEivPKYFnG4coTi5gODswbgUcf89R/nMbgfT9HHnI0Z1 vBjInrnqFZ8dblc6jZY0ROmBKxP2TXfJumvZJzq4B8O6+ydTkWRGQLsj1lsd5U1PK9IU6CZK IqYAAAAAAAA= --------------ms060204070404090201000909-- From owner-ietf-calendar@mail.imc.org Sun Aug 10 16:36: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 QAA15649 for ; Sun, 10 Aug 2003 16:36:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AKQUqt052989 for ; Sun, 10 Aug 2003 13:26:30 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7AKQUcq052987 for ietf-calendar-bks; Sun, 10 Aug 2003 13:26:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7AKQTqt052982 for ; Sun, 10 Aug 2003 13:26:29 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7AKQSEB026208 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 10 Aug 2003 13:26:29 -0700 Message-ID: <3F36AA6E.5020007@Royer.com> Date: Sun, 10 Aug 2003 14:26:22 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090104050603090809080503" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090104050603090809080503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>>7) The REQUEST message the new invitee received, lists >>> a VEVENT object with a UID that is not on its calendar >>> since the CU has never been invited to this or any >>> other version of this event before (regardless of whether >>> or not SEQUENCE is 0 or there is a RECURRENCE-ID present). >>> [As per the assumptions.] >>>Agree/Disagree? >> >>As long as you do not make it look like a modification >>to an existing VEVENT - agree. > > > Just because it might look like a modification to you doesn't > mean that it is one? Sections 3.2.2.1 and 3.2.2.2 define the > only times a message can be a modification and the only times > a message can ever be a modification is when the CUA has the > existing UID on its calendar. > > You are putting the cart before the horse. > i.e. You are putting the example before the definition. > > Section 4.4.2 is an EXAMPLE of how to modify a recurring > instance. It is not the definition of how to detect whether So, is this a modifcation? Or a new object? BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1com RECURRENCE-ID:19970701T210000Z SEQUENCE:1 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970703T210000Z DTEND:19970703T220000Z LOCATION:Conference Call DTSTAMP:19970626T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090104050603090809080503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMDIwMjYyMlowIwYJKoZIhvcNAQkEMRYEFAOTe0ur smLb3/donHLeLJW8ZhkGMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAK9nV/GiRxR4pBtj4FrF7YxJI1w/349KxIp7or7phvZEeNS3B01l ZQ9SOzMQea7ygLAfDPmFrcqOc1JSgwAFoFr7e0yxrM0vEBWlCwOhnlsYGoHTc/J2U3xP+2Fg zuxlXCQ1TMxkH/tlB5Rtj3jLaZIy1C5+IrqLI3ZsLRYHxTM0zjsmQBzKG/3qGdwiznqyrmo0 MRZBM8EruMIZv1ROhIQxJB80Ssaym3umJ3i+fK87V4Rm92M/VsM4nzTvdZanPDeES8FnQMw1 JAG14IhDsSyOMQmMZoiOfPIBMzrLrpNOiYOnTt2r6wWkuUBzmGCb/dSsMkgOTh2nll8RBhXw hdEAAAAAAAA= --------------ms090104050603090809080503-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 04:48: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 EAA10408 for ; Mon, 11 Aug 2003 04:48:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7B8Rnqt009442 for ; Mon, 11 Aug 2003 01:27:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7B8RnkG009441 for ietf-calendar-bks; Mon, 11 Aug 2003 01:27:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7B8Rjqt009434 for ; Mon, 11 Aug 2003 01:27:46 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19m835-0002yw-00 for ; Mon, 11 Aug 2003 10:29:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19m834-0002yo-00 for ; Mon, 11 Aug 2003 10:29:02 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19m81n-0004my-00 for ; Mon, 11 Aug 2003 10:27:43 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 01:27:07 -0700 Lines: 325 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@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: > So, is this a modifcation and you missed the original? > Or a new object? > > BEGIN:VCALENDAR > METHOD:REQUEST > PRODID:-//RDU Software//NONSGML HandCal//EN > VERSION:2.0 > BEGIN:VEVENT > UID:guid-1@host1com > RECURRENCE-ID:19970701T210000Z > SEQUENCE:1 > ORGANIZER:Mailto:A@example.com > ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com > ATTENDEE:Mailto:B@example.com > ATTENDEE:Mailto:C@example.com > ATTENDEE:Mailto:D@example.com > DESCRIPTION:IETF-C&S Conference Call > CLASS:PUBLIC > SUMMARY:IETF Calendaring Working Group Meeting > DTSTART:19970703T210000Z > DTEND:19970703T220000Z > LOCATION:Conference Call > DTSTAMP:19970626T093000Z > STATUS:CONFIRMED > END:VEVENT > END:VCALENDAR It could be any number of things depending on whether or not I have an an object on my calendar with: UID:guid-1@host1com You have to go through the Nessage Sequencing rules of 2.1.5 and the REQUEST VEVENT rules of 3.2.2 to find out. So I'll just do that and see where we end up: 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. So applying that, this message is referencing object: UID:guid-1@host1com RECURRENCE-ID:19970701T210000Z The object being referenced is an instance of a recurring event. 2. The secondary key for referencing a component is the "SEQUENCE" property value. For components where the "UID" is the same, the component with the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values. This object references the SEQUENCE:1 version of this component. 3. ... [ Point 3 applies to "REPLY" messages and is therefore skipped ] 4. ... [ Point 4 won't apply in this particular instance since we won't have the problem of matching SEQUENCE numbers in this case. but it is somewhat relevant to the overall converstaion. ] -------------------------------- Ok so given that, we now exactly what object this is talking about and where it fits in the overall order of messages. UID:guid-1@host1com RECURRENCE-ID:19970701T210000Z SEQUENCE:1 -------------------------------- So now we go to section 3.2.2 about VEVENT REQUESTS: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. The CUA then references its Calendar looking for UID referenced and it doesn't find it. Therefore this request is for a new VEVENT calendar component. Specifically it's a new request for component: UID:guid-1@host1com RECURRENCE-ID:19970701T210000Z SEQUENCE:1 The answer to your question stops there. It's a new object. The fact there's a SEQUENCE jump of more than one (null to 1) only clues the CUA in to the _possibility_ that it _might_ have missed something. After its processed the new request, including any REPLYs it might send in response, it SHOULD move on to dealing with the possibly missed message but it is not required to. ---- So what should the CUA do about this inconsistency. I'll make a stab at what a highly intellingent CUA might do pulling from the RFC to figure out what the CUA's options are and then make some intelligent(?) suggestions. First, all sections that I have found which give the CUA clues about how to handle the fact that something has been missed are marked MAY or SHOULD. So anything I come up with are not demands just suggestions. In the sections below I pull from all over iTIP. I'll try to keep it to just the relevant bits. Conclusion: There is nothing that explicitly handles our case but I believe there is enough implications to say that the CUA must put the object it received onto the calendar exactly as is, and it should send a REFRESH to the ORGANIZER for the UID without the RECURRENCE-ID. Support: As you will see, in our example case, where the CU has only been invited to one instance of the recurring event, it will never actually receive a response to the master event for which it sent a REFRESH request. If it receives any response at all, it will merely be a duplicate of what it already had. The CUA will be left with only that one instance. This is good actually, because that's what was intended. But it doesn't change the fact that the CUA should still send the REFRESH request. All that being said.... where to begin.... How about why it should place the object exactly as is, as one instance of a recurring event for which it has no set description yet, on the calendar. I pull that from three sections really: First we have: 2.1.5 Message Sequencing Hence, CUAs must persist the following component properties: "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". This implies that every component has a RECURRENCE-ID. In the cases where it is absent, that RECURRENCE-ID is null. But this does make it very explicit that the authors clearly intended the CUA to do bookkeeping that included the tracking of a recurrence-id on the components. This mandate makes it possible to even consider doing such a thing. and the second section: 3.7.1 Working With Recurrence Instances ... the protocol is designed so that each recurring instance may be both referenced and versioned. ... This makes it pretty clear that the authors intended a calendar component with a RECURRENCE-ID has its own independent SEQUENCE value and that tracks an independent version for just that instance. This makes it even clearer that the instances have a SEQUENCE all their own and have independent versioning. And lastly, the third section: 5.2.1 Cancellation of an Unknown Calendar Component. When a "CANCEL" method is received before the original "REQUEST" method the calendar will be unable to correlate the "UID" property of the cancellation with an existing calendar component. It is suggested that messages that can not be correlated that also contain non-zero sequence numbers be held and not discarded. Implementations MAY age them out if no other messages arrive with the same "UID" property value and a lower sequence number. This talks about not being able to correlate objects on the calendar with the object in the message. This of course is about cancellations which we aren't doing, but it does suggest something interesting to us: It is suggested that messages that can not be correlated that also contain non-zero sequence numbers be held and not discarded. This suggestion implies that a CUA should expect to do something useful with the message. So the implication I draw from here is that CUA in effect should assume that this is an update to an instance of an event for which it has not yet received the parent description object and the message should have an action take equivalent to the message being "held and not discarded". This however means there are two options. Hold it and don't put it on the calendar. Or put it on the calendar and discard the message. The problem with not putting it on the calendar is that the CUA may never receive the base event because the CU was not invited to it or the transport mechanism may have just lost it. Further, if the CUA puts it on the calendar, then the message can just be discarded which lowers its burden. But one thing is clear about this example, the authors want the CUA to take optimistic action in regards to the messages it receives. As a result of all those texts being present makes it pretty clear to me that an instance of a recurring event is intended to be treated as a first class citizen component equal in treatment to any other singleton event. Special provisions have been made that allow a CUA to avoid actually taking up bits on the disk for each instance unless that instance is renegotiated. This makes sense. Why take up disk space for an event if you don't have to. If there is no per instance data/differences to track for the event, then the parent object is totally sufficient to describe that instance and thus there is no missing info. However, in this case, the CUA doesn't have the parent object so there is no existing instance to update. This component is still a first class event and the CUA should take optimistic action on the message. Therefore it should be placed on the calendar, and its version set to SEQUENCE:1. It should be treated like a singleton whose primary key is: UID:guid-1@host1com RECURRENCE-ID:19970701T210000Z ------ But, the fact that we did not receive a SEQUENCE:0 of this indicates that the CUA possibly missed something. If this was just an ordinary singleton we wouldn't care. We'd assume that we had the latest version and just move on. And respective of the singleton instance that this object is, that's exactly what we do. We won't be sending a REFRESH request for the instance (i.e. UID/RECURRENCE-ID pair). But being that this is an instance of a recurring event and that we have no prior SEQUENCE for that event we should do something. We can draw some inferences for what do from: 4.7.2 Bad RECURRENCE-ID Component instances are identified by the combination of "UID", "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request to an "Attendee", there are three cases in which an instance cannot be found. They are: 1. The component with the referenced "UID" and "RECURRENCE-ID" has been found but the "SEQUENCE" number in the calendar store does not match that of the ITIP message. In case (1) ... If the "SEQUENCE" number of the "Attendee's" instance is smaller, then the "Organizer" is sending out a newer version of the component and the "Attendee's" version needs to be updated. Since one or more updates have been missed, the "Attendee" SHOULD send a "REFRESH" ... In reality there are at least four cases, and ours is the one missing. This example section only addresses cases where the UID has been found which in our case it isn't. But case (1) is similar if we optimisticly assume that the CUA should have received the parent object and further assume that the instance actaully exists (a fairly safe assumption), then case (1) says we should send a "REFRESH" to the "ORGANIZER" to get the latest copy of the event. This request will be a request for the parent event and not the instance, and as such will not contain a RECURRENCE-ID. But consideration must be taken as to what will actually happen when the ORGANIZER receives that REFRESH request. Section 6.1.7 says: 6.1.7 Unauthorized REFRESH Requests It is possible for an "Organizer" to receive a "REFRESH" request from someone who is not an "Attendee" of an event or to-do. Only "Attendee's" of an event or to-do are authorized to receive replies to "REFRESH" requests. Replying to such requests to anyone who is not an "Attendee" may be a security problem. Since the sender is an ATTENDEE of the instance component only, it is only authorized to receive replies for that singleton component. As a consequence, the ORGANIZER's CUA should not send the requested response. It should go through the recurrence set and send a reply for all instances that the ATTENDEE has been invited to, but this will be one iTIP message with multiple VEVENT components that each have a RECURRENCE-ID. Not one component with a UID that matches the original component that the ATTENDEE was not invited to and no RECURRENCE-ID. -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Aug 11 06:01: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 GAA11803 for ; Mon, 11 Aug 2003 06:01:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7B9qlqt022865 for ; Mon, 11 Aug 2003 02:52:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7B9qlN3022864 for ietf-calendar-bks; Mon, 11 Aug 2003 02:52:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7B9qkqt022859 for ; Mon, 11 Aug 2003 02:52:46 -0700 (PDT) (envelope-from cco@asitturnsout.org) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 8BCFA8D7B5 for ; Mon, 11 Aug 2003 02:52:45 -0700 (PDT) From: "Chris Olds" To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 02:52:45 -0700 Message-Id: <20030811092404.M97253@asitturnsout.org> In-Reply-To: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> X-Mailer: Open WebMail 2.10 20030617 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 11 Aug 2003 01:27:07 -0700, Michael Fair wrote > > So, is this a modifcation and you missed the original? > > Or a new object? > > > > BEGIN:VCALENDAR > > METHOD:REQUEST > > PRODID:-//RDU Software//NONSGML HandCal//EN > > VERSION:2.0 > > BEGIN:VEVENT > > UID:guid-1@host1com > > RECURRENCE-ID:19970701T210000Z > > SEQUENCE:1 > > ORGANIZER:Mailto:A@example.com > > ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com > > ATTENDEE:Mailto:B@example.com > > ATTENDEE:Mailto:C@example.com > > ATTENDEE:Mailto:D@example.com > > DESCRIPTION:IETF-C&S Conference Call > > CLASS:PUBLIC > > SUMMARY:IETF Calendaring Working Group Meeting > > DTSTART:19970703T210000Z > > DTEND:19970703T220000Z > > LOCATION:Conference Call > > DTSTAMP:19970626T093000Z > > STATUS:CONFIRMED > > END:VEVENT > > END:VCALENDAR > > It could be any number of things depending on whether or > not I have an an object on my calendar with: > UID:guid-1@host1com and then goes on to show, with good support, that a CUA receiving this should a) place it in the calendar (or do whatever it does for REQUEST VEVENT objects w/o a RECURRENCE-ID and b) send a REFRESH request to the Organizer. However, at the very end, there is an unsupported statement: > Since the sender is an ATTENDEE of the instance component > only, it is only authorized to receive replies for that > singleton component. As a consequence, the ORGANIZER's > CUA should not send the requested response. This is not supported by the RFC paragraph quoted. 6.1.7 talks about a REFRESH request from someone not an attendee to the event. If an event consists of multiple instances, the fact that an attendee is invited to only one of them does not exclude her from the set of attendees! An Organizing CUA that is capable of sending a single instance of an event to an attendee without generating a new UID (which it could easily do), is surely capable of forming a response that only includes those instances to which that attendee is invited. > It should > go through the recurrence set and send a reply for all > instances that the ATTENDEE has been invited to, but > this will be one iTIP message with multiple VEVENT > components that each have a RECURRENCE-ID. Not one > component with a UID that matches the original component > that the ATTENDEE was not invited to and no RECURRENCE-ID. Why not? This should be simple enough to do, since the Organizing CUA has all of the pertinent data, including the identity of the requesting CUA. Nothing in the RFCs I've read suggest that this is what MUST happen, nor even that it SHOULD. This seems like a lot of trouble to go to, and while it may be necessary to send such a set of VEVENT objects if one subscribes to the 'RECURRENCE-ID fixed at SEQ:0' dogma, it is not necessary in the 'current-value' interpretation, and both would require that a VEVENT object be sent w/o a RECURRENCE-ID at some point, or the cycle will continue indefinitely (since each REQUEST VEVENT with a RECURRENCE-ID to an attendee will, as Michael has shown, result in a REFRESH being sent back to the Organizer w/o a RECURRENCE-ID, if the Organizer responds by sending back N VEVENT objects with RECURRENCE-IDs, it will recieve between 1 and N additional REFRESH requests, and so on, and so on... this seems Very Bad Indeed...). Again, 'RECURRENCE-ID fixed at SEQ:0' causes more messages; by Michael's interpretation, it might even cause an exponential growth in messages, with no end at hand! 'current-value' semantics for RECURRENCE-ID are simple, consistent, error-reistant, and require less bookkeeping and fewer messages. The fact that reading the RFCs and using common definitions for 'original' and 'change' supports this view is just gravy, IMHO. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Mon Aug 11 11:33: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 LAA20367 for ; Mon, 11 Aug 2003 11:33:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFKJqt048603 for ; Mon, 11 Aug 2003 08:20:19 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BFKJ27048602 for ietf-calendar-bks; Mon, 11 Aug 2003 08:20:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFKIqt048579 for ; Mon, 11 Aug 2003 08:20:18 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32C1F7.10209@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 11:15:33 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 11:19:49 AM, Serialize complete at 08/11/2003 11:19:49 AM Content-Type: multipart/alternative; boundary="=_alternative 005393F985256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005393F985256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 08/07/2003 05:17:43 PM: > And the ORIGINAL SEQUENCE:0 FULL object can not contain a RECURRENCE-ID. Says who? Its nowhere in any text or table in iTIP. Its perfectly valid to send: BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1com RECURRENCE-ID:19970701T210000Z SEQUENCE:0 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call SUMMARY:IETF Calendaring Working Group Meeting DTSTART:20030814T210000Z DTEND:20030814T220000Z LOCATION:Conference Call to resolve RECURRENCE-ID DTSTAMP:20030811T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR NOWHERE in iCalendar or iTIP do we ever say this is NOT allowed. Sorry but you are creating new semantics for REQUEST that simply do not exist in iTIP. iTIP 3.2.2 REQUEST says that REQUEST is used for multiple actions: . Invite "Attendees" to an event; . Reschedule an existing event; . Response to a REFRESH request; . Update the details of an existing event, without rescheduling it; . Update the status of "Attendees" of an existing event, without rescheduling it; . Reconfirm an existing event, without rescheduling it; . Forward a "VEVENT" to another uninvited CU. . For an existing "VEVENT" calendar component, delegate the role of "Attendee" to another CU; . For an existing "VEVENT" calendar component, changing the role of "Organizer" to another CU. and it later says how to differentiate between these different cases with the text: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. and: 3.2.2.1 Rescheduling an Event The "REQUEST" method may be used to reschedule an event. A rescheduled event involves a change to the existing event in terms of its time or recurrence intervals and possibly the location or description. If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is greater than the value for the existing event, then the "REQUEST" method describes a rescheduling of the event. 3.2.2.2 Updating or Reconfirmation of an Event The "REQUEST" method may be used to update or reconfirm an event. An update to an existing event does not involve changes to the time or recurrence intervals, and might not involve a change to the location or description for the event. If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar and that the "SEQUENCE" property value in the "REQUEST" is the same as the value for the existing event, then the "REQUEST" method describes an update of the event details, but no rescheduling of the event. So, if the UID / RECURRENCE-ID are not found for a repeating instance then "then the "REQUEST" is for a new "VEVENT" calendar component." (aka an invitation). If the UID / RECURRENCE-ID are found for the repeating instance and the SEQUENCE value is "greater" (not just 1+) "then the "REQUEST" method describes a rescheduling of the event." (aka a reschedule in case the section header wasnt clue enough). If the UID / RECURRENCE-ID are found for the repeating instance and the SEQUENCE value is the same (factoring in DTSTAMP too) "then the "REQUEST" method describes an update of the event details, but no rescheduling of the event." (aka an update in case the section header wasnt clue enough here too). The CUA does NOT construct semantics based on just the properties in the message; it bases it on them and those it has (or does not have) locally! Any other behaviour is contrary to iTIP and a misapplication of it. > And if it does contain a RECURRENCE-ID, then it is a object modify > as defined by iTIP and not an new invitation. You seem to be ignoring the application of Section 2.1.5 Message Sequencing rules when you read the Section 3 messages. Because the workflow process needs to be able to deal with different kinds of messages that may arrive in different order than they were sent, we created Section 2.1.5 as a common place for explaining how to sequence them all. This also had the benefit of not making us having to expressly say "If you find the "UID" (or the "UID" / "RECURRENCE-ID" pair in the case of a repeating instance) ..." in every place in the Section 3 texts. It made for a smaller draft and made editing easier. I say this because you keep saying that there is no RECURRENCE-ID on an invitation and Im guessing that you think this because the text from 3.2.2 does not expressly say "RECURRENCE-ID" in it somewhere. However neither do the 3.2.2.1 or 3.2.2.2 texts so perhaps you think that you cannot have RECURRENCE-IDs on reschedules or updates too then??... > Do you disagree that iTIP says that if it has a RECURRENCE-ID and > METHOD:REQUEST that it is a modify and not a new invitation? Yes. If you understand the function of Section 2.1.5 and correctly apply it to all the Section 3 texts you should see that iTIP NEVER says that a METHOD:REQUEST without a RECURRENCE-ID is an invitation, otherwise its a reschedule. iTIP NEVER draws that distinction. If one correctly reads the text in 3.2.2 (and 3.2.2.1 and 3.2.2.2) then you should see that the recipients interpretation of the message is dependent on what they _already_ know about the instance in question and not just the senders intent! So, if you never got the SEQUENCE:0 thru SEQUENCE:5 REQUESTS (they got lost in a disk crash enroute or your Admin was messing with you or some coworker was getting even or...) and you do receive the SEQUENCE:6 REQUEST then you should treat it like an invitation even though from the Organizers point of view it was the 6th reschedule of the instance (to which you may have only recently been added or were an 'original' ATTENDEE). It does not matter to you really in that you can correctly join the workflow for that instance by simply sending back a REPLY with the UID / RECURRENCE-ID / SEQUENCE values you just got. If you recieve one or some of the previous SEQUENCE valued REQUESTS later then you simply can treat them as obsoleted REQUESTs for an instance you already have more current info and ignore them. That of course assumes a fixed RECURRENCE-ID model so that you can do the correct obsolete determination. Otherwise you have to go thru all the extra gyrations and thrashing I described in my analysis for Tim last week. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005393F985256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 08/07/2003 05:17:43 PM:
> And the ORIGINAL SEQUENCE:0 FULL object can not contain a RECURRENCE-ID.
Says who?  Its nowhere in any text or table in iTIP.  Its perfectly valid to send:

   BEGIN:VCALENDAR
  METHOD:REQUEST
  PRODID:-//RDU Software//NONSGML HandCal//EN
  VERSION:2.0
  BEGIN:VEVENT
  UID:guid-1@host1com
  RECURRENCE-ID:19970701T210000Z
  SEQUENCE:0
  ORGANIZER:Mailto:A@example.com
  ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
  ATTENDEE:Mailto:B@example.com
  ATTENDEE:Mailto:C@example.com
  ATTENDEE:Mailto:D@example.com
  DESCRIPTION:IETF-C&S Conference Call
  SUMMARY:IETF Calendaring Working Group Meeting
  DTSTART:20030814T210000Z
  DTEND:20030814T220000Z
  LOCATION:Conference Call to resolve RECURRENCE-ID
  DTSTAMP:20030811T093000Z
  STATUS:CONFIRMED
  END:VEVENT
  END:VCALENDAR

NOWHERE in iCalendar or iTIP do we ever say this is NOT allowed.  Sorry but you are creating new semantics for REQUEST that simply do not exist in iTIP.  iTIP 3.2.2 REQUEST says that REQUEST is used for multiple actions:

     .  Invite "Attendees" to an event;
    .  Reschedule an existing event;
    .  Response to a REFRESH request;
    .  Update the details of an existing event, without rescheduling it;
    .  Update the status of "Attendees" of an existing event, without
       rescheduling it;
    .  Reconfirm an existing event, without rescheduling it;
    .  Forward a "VEVENT" to another uninvited CU.
    .  For an existing "VEVENT" calendar component, delegate the role of
       "Attendee" to another CU;
    .  For an existing "VEVENT" calendar component, changing the role of
       "Organizer" to another CU.

and it later says how to differentiate between these different cases with the text:

   The "UID" and "SEQUENCE" properties are used to distinguish the
  various uses of the "REQUEST" method. If the "UID" property value in
  the "REQUEST" is not found on the recipient's calendar, then the
  "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
  property value is found on the recipient's calendar, then the
  "REQUEST" is for a rescheduling, an update, or a reconfirm of the
  "VEVENT" calendar component.

and:

3.2.2.1 Rescheduling an Event

  The "REQUEST" method may be used to reschedule an event. A
  rescheduled event involves a change to the existing event in terms of
  its time or recurrence intervals and possibly the location or
  description. If the recipient CUA of a "REQUEST" method finds that
  the "UID" property value already exists on the calendar, but that the
  "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
  greater than the value for the existing event, then the "REQUEST"
  method describes a rescheduling of the event.

3.2.2.2 Updating or Reconfirmation of an Event

  The "REQUEST" method may be used to update or reconfirm an event. An
  update to an existing event does not involve changes to the time or
  recurrence intervals, and might not involve a change to the location
  or description for the event. If the recipient CUA of a "REQUEST"
  method finds that the "UID" property value already exists on the
  calendar and that the "SEQUENCE" property value in the "REQUEST" is
  the same as the value for the existing event, then the "REQUEST"
  method describes an update of the event details, but no rescheduling
  of the event.

So, if the UID / RECURRENCE-ID are not found for a repeating instance then "then the "REQUEST" is for a new "VEVENT" calendar component." (aka an invitation).  

If the UID / RECURRENCE-ID are found for the repeating instance and the SEQUENCE value is "greater" (not just 1+) "then the "REQUEST" method describes a rescheduling of the event." (aka a reschedule in case the section header wasnt clue enough).  

If the UID / RECURRENCE-ID are found for the repeating instance and the SEQUENCE value is the same (factoring in DTSTAMP too) "then the "REQUEST" method describes an update of the event details, but no rescheduling of the event." (aka an update in case the section header wasnt clue enough here too).

The CUA does NOT construct semantics based on just the properties in the message; it bases it on them and those it has (or does not have) locally!  Any other behaviour is contrary to iTIP and a misapplication of it.

> And if it does contain a RECURRENCE-ID, then it is a object modify
> as defined  by iTIP and not an new invitation.
You seem to be ignoring the application of Section 2.1.5 Message Sequencing rules when you read the Section 3 messages.  Because the workflow process needs to be able to deal with different kinds of messages that may arrive in different order than they were sent, we created Section 2.1.5 as a common place for explaining how to sequence them all.  This also had the benefit of not making us having to expressly say "If you find the "UID" (or the "UID" / "RECURRENCE-ID" pair in the case of a repeating instance) ..." in every place in the Section 3 texts.  It made for a smaller draft and made editing easier.  

I say this because you keep saying that there is no RECURRENCE-ID on an invitation and Im guessing that you think this because the text from 3.2.2 does not expressly say "RECURRENCE-ID" in it somewhere.  However neither do the 3.2.2.1 or 3.2.2.2 texts so perhaps you think that you cannot have RECURRENCE-IDs on reschedules or updates too then??...

> Do you disagree that iTIP says that if it has a RECURRENCE-ID and
> METHOD:REQUEST that it is a modify and not a new invitation?
Yes. If you understand the function of Section 2.1.5 and correctly apply it to all the Section 3 texts you should see that iTIP NEVER says that a METHOD:REQUEST without a RECURRENCE-ID is an invitation, otherwise its a reschedule.  iTIP NEVER draws that distinction.

If one correctly reads the text in 3.2.2 (and 3.2.2.1 and 3.2.2.2) then you should see that the recipients interpretation of the message is dependent on what they _already_ know about the instance in question and not just the senders intent!  

So, if you never got the SEQUENCE:0 thru SEQUENCE:5 REQUESTS (they got lost in a disk crash enroute or your Admin was messing with you or some coworker was getting even or...) and you do receive the SEQUENCE:6 REQUEST then you should treat it like an invitation even though from the Organizers point of view it was the 6th reschedule of the instance (to which you may have only recently been added or were an 'original' ATTENDEE).  

It does not matter to you really in that you can correctly join the workflow for that instance by simply sending back a REPLY with the UID / RECURRENCE-ID / SEQUENCE values you just got.  If you recieve one or some of the previous SEQUENCE valued REQUESTS later then you simply can treat them as obsoleted REQUESTs for an instance you already have more current info and ignore them.  That of course assumes a fixed RECURRENCE-ID model so that you can do the correct obsolete determination.  

Otherwise you have to go thru all the extra gyrations and thrashing I described in my analysis for Tim last week.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005393F985256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 11:37: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 LAA20437 for ; Mon, 11 Aug 2003 11:37:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFTnqt049951 for ; Mon, 11 Aug 2003 08:29:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BFTn7t049950 for ietf-calendar-bks; Mon, 11 Aug 2003 08:29:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFTmqu049923 for ; Mon, 11 Aug 2003 08:29:49 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32C569.6070907@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 11:24:29 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 11:29:19 AM, Serialize complete at 08/11/2003 11:29:19 AM Content-Type: multipart/alternative; boundary="=_alternative 0054655485256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054655485256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 08/07/2003 05:32:25 PM: > Except you were replying to my email - not yours. Evade and distract all you like, the points and analysis still stand and nothing you've NOT said about 'em should confirm them. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0054655485256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 08/07/2003 05:32:25 PM:
> Except you were replying to my email - not yours.
Evade and distract all you like, the points and analysis still stand and nothing you've NOT said about 'em should confirm them.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0054655485256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 11:38: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 LAA20467 for ; Mon, 11 Aug 2003 11:38:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFTnqt049944 for ; Mon, 11 Aug 2003 08:29:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BFTn8F049942 for ietf-calendar-bks; Mon, 11 Aug 2003 08:29:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFTmqt049923 for ; Mon, 11 Aug 2003 08:29:48 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32C5C1.7020100@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 11:22:48 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 11:29:18 AM, Serialize complete at 08/11/2003 11:29:18 AM Content-Type: multipart/alternative; boundary="=_alternative 00543DCE85256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00543DCE85256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 08/07/2003 05:33:53 PM: > > > Show me anywhere where in any RFC it says you can ignore: > > > > > > (iCAL) > > > ...When the definition of the recurrence > > > set for a calendar component changes, and hence the "SEQUENCE" > > > property value changes, the "RECURRENCE-ID" for a given recurrence > > > instance might also change. ... > > > > Whats to ignore? > > Your ignoring the fact it changes. Im not the one ignoring: 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. and Im not the one who treats a reschedule of a recurrence _instance_ as a change to the "recurrence _set_". Ive also pointed out that we dealt with the 1 line in iTIP back in 1999 (if not before then given the way Dan phrased his posting). If one takes a serious look at the workflow process and how a changing RECURRENCE-ID model is very fault intolerant compared to the fixed model it should be clear that the intent is to use fixed RECURRENCE-IDs. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00543DCE85256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 08/07/2003 05:33:53 PM:
> >  > Show me anywhere where in any RFC it says you can ignore:
> >  >
> >  >    (iCAL)
> >  >     ...When the definition of the recurrence
> >  >     set for a calendar component changes, and hence the "SEQUENCE"
> >  >     property value changes, the "RECURRENCE-ID" for a given recurrence
> >  >     instance might also change. ...
> >
> > Whats to ignore?
>
> Your ignoring the fact it changes.
Im not the one ignoring:

   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.

and Im not the one who treats a reschedule of a recurrence _instance_ as a change to the "recurrence _set_".

Ive also pointed out that we dealt with the 1 line in iTIP back in 1999 (if not before then given the way Dan phrased his posting).  

If one takes a serious look at the workflow process and how a changing RECURRENCE-ID model is very fault intolerant compared to the fixed model it should be clear that the intent is to use fixed RECURRENCE-IDs.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00543DCE85256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 12:12: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 MAA21363 for ; Mon, 11 Aug 2003 12:12:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BG1lqt054556 for ; Mon, 11 Aug 2003 09:01:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BG1l4w054555 for ietf-calendar-bks; Mon, 11 Aug 2003 09:01:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BG1kqt054549 for ; Mon, 11 Aug 2003 09:01:46 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BG1iEB001612 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 09:01:46 -0700 Message-ID: <3F37BDE2.1010409@Royer.com> Date: Mon, 11 Aug 2003 10:01:38 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090803020608060207010607" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090803020608060207010607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit So, what't the answer? Was the orgignal missed or not? Michael Fair wrote: > > It could be any number of things depending on whether or > not I have an an object on my calendar with: > UID:guid-1@host1com > > > -- Michael -- > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090803020608060207010607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTE2MDEzOFowIwYJKoZIhvcNAQkEMRYEFKpqEUAL NSedC5tScRTnAH717i8BMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAAq2w0GuqurgFMd5PAdgFWs20MOTPVnXe8ux8DCmrNYW08S+VaOC EcI3KLHY5xplfwTNfckUeK4p7qBl3BCC+eihWFSH1e4D56ATU90RDQs/Pwwtiq9bXSigKmlK MCjgm/VmLU4252G2VtXa5DIOf9/g/8NXDVxt3776Bv8kloH3x5gTyONvijFyaDhi88O2Y6TE nhzuk0igodshWC/WsES6fQ6W0viZ641B5OOq5Cijo5rZ1cBdML4c+N/Z4u+EnjWTeaT6ETwY fKpiNjTvrXjbcQ3C5wE2SVD++VzHi70JmrUZFG0Jv4cUBqxUQpXF9uJIZGC8S/gpL7jTnOVY X0AAAAAAAAA= --------------ms090803020608060207010607-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 12:20: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 MAA21688 for ; Mon, 11 Aug 2003 12:20:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGBkqt055971 for ; Mon, 11 Aug 2003 09:11:46 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGBk6X055970 for ietf-calendar-bks; Mon, 11 Aug 2003 09:11:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGBjqt055950 for ; Mon, 11 Aug 2003 09:11:45 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32CD34.5030102@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 12:01:53 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 12:11:13 PM, Serialize complete at 08/11/2003 12:11:13 PM Content-Type: multipart/alternative; boundary="=_alternative 0057D1E885256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057D1E885256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 08/07/2003 06:05:40 PM: > And what about the example I sent to this list that shows how > your model broken in that area? You put no iTIP fragment into your postings that I saw. You merely put in text that said: In Bruces model you can NEVER add someone to the series of recurring VEVENT after any change that effects the effective DTSTART value of any instance as they could never be able to resolve the RECURRENCE-ID because they never had SEQUENCE:0. Thats just an unsubstantiated claim that Ive demonstrated to be false and misleading with both iTIP fragments and iTIP citations. > You know the one that showed > that new attendess in your model can not process instance > changes unless they just happen to be the same as the SEQUENCE:0 instances? I dont know what example you are referring to since there was none in your 08/07/2003 01:33:53 PM reply. In any case, I see that there is a greater problem with your misunderstanding of iTIP and the REQUEST method. I covered much of it already in an earlier reply to a different posting but essentially you are trying to imply Organziers semantics on the recipients side when you cannot. iTIP says that the recipient determines the semantics of the REQUEST based on the information it has about that UID / RECURRENCE-ID / SEQUENCE / DTSTAMP. If you understand the role of Section 2.1.5 and how it applys to all Section 3 iTIP methods this should be relatively easy to see. To be clear to those that may not see that other message, iTIP says that if the UID / RECURRENCE-ID are not found in the recipients store then the REQUEST is an invitation (Section 3.2.2). If the values are found then SEQUENCE (and DTSTAMP too) are used to differentiate between a reschedule (SEQUENCE values do not match, Section 3.2.2.1) and an update (SEQUENCE values match, Section 3.2.2.2) with DTSTAMP being used to determine obsolesce. The senders semantics are not always those determined by the recipient; it depends on what they already know about the event / instance in question! > Except all of your examples were how to modify an existing VEVENT > and you called it inviting a new attendee. Where did you pull that from?!? I simply sent: UID: 1 SEQUENCE: 10 RECURRENCE-ID: 20030805T180000Z DTSTART: 20030816T150000Z to someone who does not have it yet since I just added them. By iTIP Section 3.2.2 REQUEST: If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. so they treat it for exactly what it is, an invitation. Just how could it be an update or a reschedule if they dont have it yet?? > There is no problem > to solve, just send them a VEVENT with NO RECURRENCE-ID as all > of the examples in iCAL and iTIP show and every thing works. Sending just: UID: 1 SEQUENCE: 10 DTSTART: 20030816T150000Z is WRONG since they are being added to a particular instance and NOT the entire set (or to a non-repeating entry). Perhaps you missed: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. in the REQUEST restriction table. Since the invitation is for an instance then it MUST be there. If there is no RECURRENCE-ID then the invitee would send back a REPLY w/o one and this is defined in 3.2.3 REPLY as: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it must NOT be present. so the Organizer would think they are referring to all instances in the set when in fact they are referring to just one. In addtion, in order to add them to another instance using Dougs model you will have to send a new REQUEST that has NO RECURRENCE-ID on it but has RDATE info so that the recipient will toast their view of that UID and recreate it. That means that the invitee has to either renegotate that 1st instance all over again or at a minimum remove and recreate the exact same instance. This waste of bandwidth and cycles is necessary because in Dougs model the RECURRENCE-IDs change on each reschedule and the invitees have NO way to differentiate between a missed reschedule OR an invitation to a new instance they never knew about before. So far Ive shown this twice by example yet some would prefer to ignore it for whatever reasons they have. (This REQUEST with RDATEs is Dougs "full REFRESH" for those still reading) No matter the distractions or claims to the contrary, it was easyly shown how fault _intolerant_ and error prone a changing RECURRENCE-ID model is. If you missed it when I posted it on Friday Ill be glad to repost it along w/the exact same comparison for the fixed RECURRENCE-ID model so you can see for yourself. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0057D1E885256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 08/07/2003 06:05:40 PM:
> And what about the example I sent to this list that shows how
> your model broken in that area?

You put no iTIP fragment into your postings that I saw.  You merely put in text that said:

In Bruces model you can NEVER add someone to the series
of recurring VEVENT after any change that effects the
effective  DTSTART value of any instance as they could never
be able to resolve the RECURRENCE-ID because they never
had SEQUENCE:0.

Thats just an unsubstantiated claim that Ive demonstrated to be false and misleading with both iTIP fragments and iTIP citations.

>                                  You know the one that showed
> that new attendess in your model can not process instance
> changes unless they just happen to be the same as the SEQUENCE:0 instances?
I dont know what example you are referring to since there was none in your 08/07/2003 01:33:53 PM reply.  

In any case, I see that there is a greater problem with your misunderstanding of iTIP and the REQUEST method.  I covered much of it already in an earlier reply to a different posting but essentially you are trying to imply Organziers semantics on the recipients side when you cannot.

iTIP says that the recipient determines the semantics of the REQUEST based on the information it has about that UID / RECURRENCE-ID / SEQUENCE / DTSTAMP.  If you understand the role of Section 2.1.5 and how it applys to all Section 3 iTIP methods this should be relatively easy to see.

To be clear to those that may not see that other message, iTIP says that if the UID / RECURRENCE-ID are not found in the recipients store then the REQUEST is an invitation (Section 3.2.2).  If the values are found then SEQUENCE (and DTSTAMP too) are used to differentiate between a reschedule (SEQUENCE values do not match, Section 3.2.2.1) and an update (SEQUENCE values match, Section 3.2.2.2) with DTSTAMP being used to determine obsolesce.  The senders semantics are not always those determined by the recipient; it depends on what they already know about the event / instance in question!

> Except all of your examples were how to modify an existing VEVENT
> and you called it inviting a new attendee.

Where did you pull that from?!?  I simply sent:

UID: 1
SEQUENCE: 10
RECURRENCE-ID: 20030805T180000Z
DTSTART: 20030816T150000Z

to someone who does not have it yet since I just added them.  By iTIP Section 3.2.2 REQUEST:

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

so they treat it for exactly what it is, an invitation.  Just how could it be an update or a reschedule if they dont have it yet??  

>                                                There is no problem
> to solve, just send them a VEVENT with NO RECURRENCE-ID as all
> of the examples in iCAL and iTIP show and every thing works.

Sending just:

UID: 1
SEQUENCE: 10
DTSTART: 20030816T150000Z

is WRONG since they are being added to a particular instance and NOT the entire set (or to a non-repeating entry).  Perhaps you missed:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise it
                           MUST NOT be present.

in the REQUEST restriction table. Since the invitation is for an instance then it MUST be there.  If there is no RECURRENCE-ID then the invitee would send back a REPLY w/o one and this is defined in 3.2.3 REPLY as:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise
                           it must NOT be present.

so the Organizer would think they are referring to all instances in the set when in fact they are referring to just one.  

In addtion, in order to add them to another instance using Dougs model you will have to send a new REQUEST that has NO RECURRENCE-ID on it but has RDATE info so that the recipient will toast their view of that UID and recreate it.   That means that the invitee has to either renegotate that 1st instance all over again  or at a minimum remove and recreate the exact same instance.  

This waste of bandwidth and cycles is necessary because in Dougs model the RECURRENCE-IDs change on each reschedule and the invitees have NO way to differentiate between a missed reschedule OR an invitation to a new instance they never knew about before.  So far Ive shown this twice by example yet some would prefer to ignore it for whatever reasons they have.  (This REQUEST with RDATEs is Dougs "full REFRESH" for those still reading)

No matter the distractions or claims to the contrary, it was easyly shown how fault _intolerant_ and error prone a changing RECURRENCE-ID model is.  If you missed it when I posted it on Friday Ill be glad to repost it along w/the exact same comparison for the fixed RECURRENCE-ID model so you can see for yourself.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0057D1E885256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 12: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 MAA21825 for ; Mon, 11 Aug 2003 12:22:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGEfqt056622 for ; Mon, 11 Aug 2003 09:14:41 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGEfE1056620 for ietf-calendar-bks; Mon, 11 Aug 2003 09:14:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGEeqt056613 for ; Mon, 11 Aug 2003 09:14:40 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BGEcEB001692 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 09:14:40 -0700 Message-ID: <3F37C0E9.6010307@Royer.com> Date: Mon, 11 Aug 2003 10:14:33 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020400080406020209010100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020400080406020209010100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 08/07/2003 05:17:43 PM: > > And the ORIGINAL SEQUENCE:0 FULL object can not contain a RECURRENCE-ID. > > Says who? Its nowhere in any text or table in iTIP. Its perfectly > valid to send: Because it is then indistinguishable from an instance modification. The ATTENDEE being unable to tell the differanec will have to do a REFRESH. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020400080406020209010100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTE2MTQzM1owIwYJKoZIhvcNAQkEMRYEFPw64vcl dVtoUHKc4g4YfT5J4PhrMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEcP53atSwfy916g6AUJkpeZ7w+QHRqZ29Bn8NzeRAyJIekCpRXs 5hoBm56eiikPxgfFYUkbb78rkYVtsgtpQRHSidPiVd8B0wDXXFmcs6bbZiWdkQ8A92xDXcOy 146CnYzEFY3YonGwBgmAmQqHUBnjTbTAX/LRCDXDEvSnGUd7QSIXQa5jgnsm+k/btEW4eG/P odWkOBkevOeQxqFBsmuiNKT26r0NHwOtM1Hhe/BUwRPVL9IIBGnas6lPXVKRT/hRjQihbK20 4Sl/PcpyKwMTfLtFPUBGLtVa5pAo7rv6Cc5FvGTAO5lYjPDsyfrBO9cj6Y4zVAQzLT6/JlNq 5BIAAAAAAAA= --------------ms020400080406020209010100-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 12:22:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21826 for ; Mon, 11 Aug 2003 12:22:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGD8qt056259 for ; Mon, 11 Aug 2003 09:13:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGD8Un056258 for ietf-calendar-bks; Mon, 11 Aug 2003 09:13:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGD6qt056242 for ; Mon, 11 Aug 2003 09:13:07 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BGD4EB001685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 09:13:07 -0700 Message-ID: <3F37C08B.9010909@Royer.com> Date: Mon, 11 Aug 2003 10:12:59 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> In-Reply-To: <20030811092404.M97253@asitturnsout.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090409050001040202090207" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090409050001040202090207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chris Olds wrote: > On Mon, 11 Aug 2003 01:27:07 -0700, Michael Fair wrote > >>>So, is this a modifcation and you missed the original? >>>Or a new object? >>> ... >> >>It could be any number of things depending on whether or >>not I have an an object on my calendar with: >>UID:guid-1@host1com > > > and then goes on to show, with good support, that a CUA receiving this should > a) place it in the calendar (or do whatever it does for REQUEST VEVENT objects > w/o a RECURRENCE-ID and > b) send a REFRESH request to the Organizer. Correct - you unconditionally have to do a REFRESH if some use it as a way to add an attendee, because if it looks like it might be a modification and it is used for both purposes. You will never know. So if we allow this to be used for both purposes then each receiving ATTENDEE will have to do a REFRESH and it will generate 5 packets per ATTENDEE: (1)The original (ORGANIZER -> ATTENDEEs) (2)Its REPLY (ATTENDEEs -> ORGANIZER) (3)A REFRESH (ATTENDEEs -> ORGANZIER) (4)A full-object REQUEST (ORGANIZER -> ATTENDEEs) (5)REPLY. (ATTENDEEs -> ORGANZIER) So lets not use it for that purpose. If the ORGANZER sends a full-REQUEST to effected (or all) ATTENDEEs: (1) The origanal (ORGANZIER -> ATTTENDEEs) (2) Its REPLY (ATTENDEEs -> ORGANZER) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090409050001040202090207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTE2MTI1OVowIwYJKoZIhvcNAQkEMRYEFB95c+no Z33UZdEUF68JMw8j/3X5MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBACJwfim9kBdG7C0GAWNvb0Of3yOumlX0saKkr6P81RGRMsfXxZSE YCc1GtpV1zKAagRCWs7L6Au7lj5bmCc+kTABY7PKTiUD/enJX6KgpsOCEeqnk4qySQAAS9bZ Ligb+/gsa/aKSZR7AVA4KQ+pg7j3InFqP/Za2GtzgOodj8hWIe10ImSqt8vG06hqrmoxWol6 7uNKgigwcscm3JVWr8gNjlAZbyO/DHFurrMV725o6rLckKxD7r90O04WdlxETDhMiqktpWOx 2MPmmmw37paMHWgRnfWjuWJF/v6whu7UXY9n4L6V5iK1Y0Kz1b3DwEKGGi36HdyvcAlJChz4 mL0AAAAAAAA= --------------ms090409050001040202090207-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 12:23: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 MAA21877 for ; Mon, 11 Aug 2003 12:23:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGFjqt056719 for ; Mon, 11 Aug 2003 09:15:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGFjr7056718 for ietf-calendar-bks; Mon, 11 Aug 2003 09:15:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGFhqt056712 for ; Mon, 11 Aug 2003 09:15:43 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BGFeEB001708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 09:15:44 -0700 Message-ID: <3F37C127.2020500@Royer.com> Date: Mon, 11 Aug 2003 10:15:35 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090107000403020704060601" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090107000403020704060601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 08/07/2003 05:32:25 PM: > > Except you were replying to my email - not yours. > > Evade and distract all you like, the points and analysis still stand and > nothing you've NOT said about 'em should confirm them. That you replied to my email? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090107000403020704060601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTE2MTUzNVowIwYJKoZIhvcNAQkEMRYEFJly4U+o Wb3bGWBkKjnYHsN6JeJaMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIOV/AnkGbnokeQ8QXRE0taynYAwvSOzhI8zWgIqRw+OVHQxWAMV VXHLm8sPx0ELWuoq2R+tFWk9kYA/UCPciOt2I/b0KNcSFScrnNM7daYmQyH21fR/jOZYCgCW Wenoz6nAT9z/id027x4l9RyW/Sgo1yfVc63iXYHHziK+9JX/FVmGNiQKwO+IBkAf9yNBReaW pPwI+8HqSqI2SW4pWtT/MJx4OwTB0TYNwlLOXOAGQ3hc7hFuxU6xq55ucKFDp0lYSI2rsCvv 5mQ18vJAuau52HQhzS5PPeiXpzGFHLpBY+A6Xs2MDMmv5q5bZ5944ESbo4sZ0Bq6pzsMzo70 BrwAAAAAAAA= --------------ms090107000403020704060601-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 12:45: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 MAA22525 for ; Mon, 11 Aug 2003 12:45:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGZ1qt057858 for ; Mon, 11 Aug 2003 09:35:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGZ19m057855 for ietf-calendar-bks; Mon, 11 Aug 2003 09:35:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGZ0qt057836 for ; Mon, 11 Aug 2003 09:35:01 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32CF99.9040901@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 12:23:35 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 12:34:28 PM, Serialize complete at 08/11/2003 12:34:28 PM Content-Type: multipart/alternative; boundary="=_alternative 0059CE8485256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059CE8485256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 08/07/2003 06:15:53 PM: > > The request method makes no such distinction. > > If you receive a request and it is not on your calendar, you must treat > > it as an invitation. > > Nope - iTIP - Modify A Recurring Instance, look for: Lets not get distracted from the details shall we: 1: Your example is a misuse of an iTIP example (Section 4.4.2 Modify A Recurring Instance) which clearly is for "a recurring meeting" NOT for a single instance of that repeating set. 2: You are relying on an example thats not the same scenario we have been discussing (the invitation to a single instance of a repeating set) 3: iTIP Section 3.2.2 REQUEST clearly defines how the recipient is to determine invitation from reschedule from update. If you properly use Sections 2.1.5 and 3.2.2 (or any Section 3 message) you will know how to distinguish between all the cases. > And i iTIP - Working With Recurrence Instances, at and near: > > ...If the "Organizer" wishes to > change the "DTSTART", the original "DTSTART" value is used for > "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values > reflect the change. Note that after the change has occurred, the > "RECURRENCE-ID" has changed to the new "DTSTART" value. You recycle old references that the WG covered at least 4 years ago. The 1st line you cite agrees w/iCalendar in its reference to 'original' (no matter your defition), the last line is the only conflict w/the rest of iCalendar or the iTIP. 1 line vs all the rest of the agreeing text is hardly a forceful case to redefine the model that iCalendar defines. > If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification. DIFFERENT CASE! Stop trying to mix the examples so you can twist the discussion. We have been discussing the workflow of a single instance of a repeating set; not changing the recurrence set by expanding it. If you want to go and change the repeating set by ADDing an instance then iCalendar is clear when it says that the RECURRENCE-ID "might also change". However that is NOT the example we have been discussing. > Can you cite any text? Or is that just another take my word for > it assertion? Its in the REQUEST restriction table: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. There is also the text from 2.1.5 that some folks seem to neglect: 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. Because of potential sequencing problems enroute the Organziers "reschedule" may be treated by the invitee as an "invitation" since it gets there first. It is trivial to show that an instance of a repeating set may never go beyond SEQUENCE:0 (all invitees agree to the date/time w/o COUNTERing or the Organizer never reschedules it because of any number of reasons) and as such adding someone to that instance alone clearly means they will get an invitation at SEQUENCE:0. Under Dougs model its not clear that I would not have to rev SEQUENCE when I add a new invitee given his postings so far. As such, it sounds as if I would have to rev SEQUENCE to a higher value every time a I add someone just because I have to craft some specialized REQUEST to them. Ugh! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0059CE8485256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 08/07/2003 06:15:53 PM:
> > The request method makes no such distinction.
> > If you receive a request and it is not on your calendar, you must treat
> > it as an invitation.
>
> Nope - iTIP - Modify A Recurring Instance, look for:
Lets not get distracted from the details shall we:

1: Your example is a misuse of an iTIP example (Section 4.4.2 Modify A Recurring Instance) which clearly is for "a recurring meeting" NOT for a single instance of that repeating set.

2: You are relying on an example thats not the same scenario we have been discussing (the invitation to a single instance of a repeating set)

3: iTIP Section 3.2.2 REQUEST clearly defines how the recipient is to determine invitation from reschedule from update.  If you properly use Sections 2.1.5 and 3.2.2 (or any Section 3 message) you will know how to distinguish between all the cases.

> And i iTIP - Working With Recurrence Instances, at and near:
>
>     ...If the "Organizer" wishes to
>     change the "DTSTART", the original "DTSTART" value is used for
>     "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
>     reflect the change.  Note that after the change has occurred, the
>     "RECURRENCE-ID" has changed to the new "DTSTART" value.
You recycle old references that the WG covered at least 4 years ago.  The 1st line you cite agrees w/iCalendar in its reference to 'original' (no matter your defition), the last line is the only conflict w/the rest of iCalendar or the iTIP.  1 line vs all the rest of the agreeing text is hardly a forceful case to redefine the model that iCalendar defines.

> If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification.
DIFFERENT CASE!  Stop trying to mix the examples so you can twist the discussion.  We have been discussing the workflow of a single instance of a repeating set; not changing the recurrence set by expanding it.  

If you want to go and change the repeating set by ADDing an instance then iCalendar is clear when it says that the RECURRENCE-ID "might also change".  However that is NOT the example we have been discussing.

> Can you cite any text? Or is that just another take my word for
> it assertion?
Its in the REQUEST restriction table:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise it
                           MUST NOT be present.
There is also the text from 2.1.5 that some folks seem to neglect:

   1.  The primary key for referencing a particular iCalendar component
      is the "UID" property value. To reference an instance of a
      recurring component, the primary key is composed of the "UID" and
      the "RECURRENCE-ID" properties.

Because of potential sequencing problems enroute the Organziers "reschedule" may be treated by the invitee as an "invitation" since it gets there first.  

It is trivial to show that an instance of a repeating set may never go beyond SEQUENCE:0 (all invitees agree to the date/time w/o COUNTERing or the Organizer never reschedules it because of any number of reasons) and as such adding someone to that instance alone clearly means they will get an invitation at SEQUENCE:0.  Under Dougs model its not clear that I would not have to rev SEQUENCE when I add a new invitee given his postings so far.  As such, it sounds as if I would have to rev SEQUENCE to a higher value every time a I add someone just because I have to craft some specialized REQUEST to them.  Ugh!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0059CE8485256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 12:45: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 MAA22544 for ; Mon, 11 Aug 2003 12:45:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGZ2qt057869 for ; Mon, 11 Aug 2003 09:35:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGZ1nf057863 for ietf-calendar-bks; Mon, 11 Aug 2003 09:35:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGZ0qu057836 for ; Mon, 11 Aug 2003 09:35:01 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32DF90.1000706@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 12:33:05 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 12:34:28 PM, Serialize complete at 08/11/2003 12:34:28 PM Content-Type: multipart/alternative; boundary="=_alternative 005AAD2185256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005AAD2185256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug asked on 08/07/2003 07:24:00 PM: > How about responding to the email that showed why your model > is broken? You have not shown anything; you have merely written a few lines claiming the model is broken. I have posted detailed examples and analyses of how workflow performs using both your changing RECURRENCE-ID model and the iCalendar fixed RECURRENCE-ID model. I have provided iTIP fragments all along that support the model and are supported by the RFC texts. I have shown that in 5 simple steps its easy for the Organizer to fail to match the REPLY to the proper instance. I have shown that error recovery for missequenced or lost iTIP messages is trival for the fixed RECURRENCE-ID case. All it takes is 1 simple REPLY and workflow is restored. I have shown that for a changing RECURRENCE-ID model, because you cannot uniquely identify the correct instance in question because its id changes, its easy to trash about trying to recover from 1 single missequenced or lost message. Recovery at the instance level is NOT possible as Doug has tacitly agreed, the only way to recover is to nuke all instances and recreate them all from scratch. This of course assumes you can correctly sequence that REQUEST w/the rest and its not missequenced too! At this point Im coming to the conclusion that Doug is either unfamiliar with iTIP Section 2.1.5 or is unsure how to correctly apply it to all the iTIP methods. Thats the only explaination I can come up with for how hes is misinterpreting iTIP (invitation vs reschedules) and iCalendar but if someone else can see it please chime in. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005AAD2185256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug asked on 08/07/2003 07:24:00 PM:
> How about responding to the email that showed why your model
> is broken?
You have not shown anything; you have merely written a few lines claiming the model is broken.

I have posted detailed examples and analyses of how workflow performs using both your changing RECURRENCE-ID model and the iCalendar fixed RECURRENCE-ID model.  

I have provided iTIP fragments all along that support the model and are supported by the RFC texts.

I have shown that in 5 simple steps its easy for the Organizer to fail to match the REPLY to the proper instance.

I have shown that error recovery for missequenced or lost iTIP messages is trival for the fixed RECURRENCE-ID case.  All it takes is 1 simple REPLY and workflow is restored.

I have shown that for a changing RECURRENCE-ID model, because you cannot uniquely identify the correct instance in question because its id changes, its easy to trash about trying to recover from 1 single missequenced or lost message.  Recovery at the instance level is NOT possible as Doug has tacitly agreed, the only way to recover is to nuke all instances and recreate them all from scratch.  This of course assumes you can correctly sequence that REQUEST w/the rest and its not missequenced too!

At this point Im coming to the conclusion that Doug is either unfamiliar with iTIP Section 2.1.5 or is unsure how to correctly apply it to all the iTIP methods.  Thats the only explaination I can come up with for how hes is misinterpreting iTIP (invitation vs reschedules) and iCalendar but if someone else can see it please chime in.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005AAD2185256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 13:08: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 NAA23259 for ; Mon, 11 Aug 2003 13:08:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGwhqt059109 for ; Mon, 11 Aug 2003 09:58:43 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGwhfj059108 for ietf-calendar-bks; Mon, 11 Aug 2003 09:58:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGweqt059096 for ; Mon, 11 Aug 2003 09:58:41 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mG1S-000748-00 for ; Mon, 11 Aug 2003 18:59:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mG1R-000740-00 for ; Mon, 11 Aug 2003 18:59:53 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mG0B-0002Us-00 for ; Mon, 11 Aug 2003 18:58:35 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 09:57:43 -0700 Lines: 37 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <3F37BDE2.1010409@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: No the original was not missed. The ATTENDEE is not invited to the original so the ATTENDEE was never sent it and therefore did not miss it. -- Michael -- "Doug Royer" wrote in message news:3F37BDE2.1010409@Royer.com... > > So, what't the answer? Was the orgignal missed or not? > > Michael Fair wrote: > > > > > It could be any number of things depending on whether or > > not I have an an object on my calendar with: > > UID:guid-1@host1com > > > > > > -- Michael -- > > > > > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Mon Aug 11 13:12:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23924 for ; Mon, 11 Aug 2003 13:12:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BH3Hqt059309 for ; Mon, 11 Aug 2003 10:03:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BH3Hch059308 for ietf-calendar-bks; Mon, 11 Aug 2003 10:03:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BH3Hqt059300 for ; Mon, 11 Aug 2003 10:03:17 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32E092.3030301@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 12:51:52 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 01:03:18 PM, Serialize complete at 08/11/2003 01:03:18 PM Content-Type: multipart/alternative; boundary="=_alternative 005C653B85256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C653B85256D7F_= Content-Type: text/plain; charset="US-ASCII" Dogu claimed on 08/07/2003 07:28:18 PM: > > Wrong. You clearly do not understand iTIP Section 3.2.2 REQUEST and the > > relevant subsections. Section 3.2.2 tells you how to distinguish > > betweeen a new invitation and an update/reschedule. That text that does > > is: > > > > The "UID" and "SEQUENCE" properties are used to distinguish the > > various uses of the "REQUEST" method. If the "UID" property value in > > the "REQUEST" is not found on the recipient's calendar, then the > > "REQUEST" is for a new "VEVENT" calendar component. If the "UID" > > property value is found on the recipient's calendar, then the > > "REQUEST" is for a rescheduling, an update, or a reconfirm of the > > "VEVENT" calendar component. > > And your still ignoring the part of iTIP that says to modify > an event add the RECURRENCE-ID. Please show me any iTIP text or restriction table that says RECURRENCE-ID is only for a modify! In the mean time I suggest you mull over the text above and how Section 2.1.5 factors in with it. > So if you add a RECURRENCE-ID and then it looks *exactly* like > an iTIP modification there is NO way to tell if you missed something. > That model will not work. Not in your implimentation but it works fine as a general model. Ive shown exactly how it works just fine on Friday but you seemed to have missed that posting. > Is there ANY text in iCAL or iTIP that says there are two > ways to invite someone, one that works all of the time including > for single instance (without a RECURRECE-ID) that the one > you keep asserting is your way? Sure, there are 2 bits of iTIP that come to mind. Section 2.1.5 Message Sequencting: 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. and Section 3.2.2 REQUESTs restriction table: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. The 0 is for non-repeating components, the 1 is for "referring to an instance of a recurring calendar component" which I think an invitation to a specific instance qualifies for. The Section 2.1.5 text says that if the iTIP method is for an instance of a recurrence set then the RECURRENCE-ID is used along w/the UID. If its NOT there then you are not referring to an instance (or range of instances), you are referring to the entire set w/that UID. > I anyone can send a REQUEST > to an ATTENDEE for ANY time, why do you insist that RECURRECE-ID > need be added? Because the REQUEST is for a particular instance, thats why. If I were referring to the set then Id just use UID, otherwise I MUST use RECURRENCE-ID to identify the instance the REQUEST is referring to. Are you suggesting that a REQUEST with no RECURRENCE-ID is actually referring to an instance of a repeating set by the omission of the property? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005C653B85256D7F_= Content-Type: text/html; charset="US-ASCII"
Dogu claimed on 08/07/2003 07:28:18 PM:
> > Wrong.  You clearly do not understand iTIP Section 3.2.2 REQUEST and the
> > relevant subsections.  Section 3.2.2 tells you how to distinguish
> > betweeen a new invitation and an update/reschedule.  That text that does
> > is:
> >
> >    The "UID" and "SEQUENCE" properties are used to distinguish the
> >   various uses of the "REQUEST" method. If the "UID" property value in
> >   the "REQUEST" is not found on the recipient's calendar, then the
> >   "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
> >   property value is found on the recipient's calendar, then the
> >   "REQUEST" is for a rescheduling, an update, or a reconfirm of the
> >   "VEVENT" calendar component.
>
> And your still ignoring the part of iTIP that says to modify
> an event add the RECURRENCE-ID.
Please show me any iTIP text or restriction table that says RECURRENCE-ID is only for a modify!  In the mean time I suggest you mull over the text above and how Section 2.1.5 factors in with it.

> So if you add a RECURRENCE-ID and then it looks *exactly* like
> an iTIP modification there is NO way to tell if you missed something.
> That model will not work.
Not in your implimentation but it works fine as a general model.  Ive shown exactly how it works just fine on Friday but you seemed to have missed that posting.

> Is there ANY text in iCAL or iTIP that says there are two
> ways to invite someone, one that works all of the time including
> for single instance (without a RECURRECE-ID) that the one
> you keep asserting is your way?

Sure, there are 2 bits of iTIP that come to mind.  Section 2.1.5 Message Sequencting:

   1.  The primary key for referencing a particular iCalendar component
      is the "UID" property value. To reference an instance of a
      recurring component, the primary key is composed of the "UID" and
      the "RECURRENCE-ID" properties.

and Section 3.2.2 REQUESTs restriction table:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise it
                           MUST NOT be present.

The 0 is for non-repeating components, the 1 is for "referring to an instance of a recurring calendar component" which I think an invitation to a specific instance qualifies for.

The Section 2.1.5 text says that if the iTIP method is for an instance of a recurrence set then the RECURRENCE-ID is used along w/the UID.  If its NOT there then you are not referring to an instance (or range of instances), you are referring to the entire set w/that UID.

>                                        I anyone can send a REQUEST
> to an ATTENDEE for ANY time, why do you insist that RECURRECE-ID
> need be added?
Because the REQUEST is for a particular instance, thats why.  If I were referring to the set then Id just use UID, otherwise I MUST use RECURRENCE-ID to identify the instance the REQUEST is referring to.   Are you suggesting that a REQUEST with no RECURRENCE-ID is actually referring to an instance of a repeating set by the omission of the property?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005C653B85256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 13:29: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 NAA24920 for ; Mon, 11 Aug 2003 13:29:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BHJ7qt060572 for ; Mon, 11 Aug 2003 10:19:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BHJ7YC060571 for ietf-calendar-bks; Mon, 11 Aug 2003 10:19:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BHJ6qt060566 for ; Mon, 11 Aug 2003 10:19:06 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BHJ4EB002266 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 10:19:06 -0700 Message-ID: <3F37D003.4040803@Royer.com> Date: Mon, 11 Aug 2003 11:18:59 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <3F37BDE2.1010409@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020104060609050007040309" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020104060609050007040309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > No the original was not missed. Yes - it was. Your CUA is now out of sync. > The ATTENDEE is not invited to the original so the > ATTENDEE was never sent it and therefore did not > miss it. Perhaps I mis e-mailed the original to this list, I guess that is why you miss-guessed and thought it was a new ATTENDEE. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020104060609050007040309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTE3MTg1OVowIwYJKoZIhvcNAQkEMRYEFApUZF7y 9xCQlzDm18kKlN/nXaeyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAB+Vm9OcOzU1P45WgzusZNG5vApDtvu2MMJnQRaajM0ZGzY8JRWu +EX5aH3tGej+x9BI75D0uUI4JkeRBVNwsbvwGDnd4g8fLaVspjkYFW2SFYGVR4KBbSFuDfeK GPPwY2Z4WOjq0BiFCY9t9vmkj9JBXesMp90pk8yhFFSyvH2YoZbSoNgjMrJ3g33Mir7zG40I IR06ngrMRIRzB+Q9vbIQFwr8KwVKyc3q0OrN7O6z0gN8SCbWtOlG0vi+sOyjUscYPldlJuRe WD4GbgNu5EPKbSMSifLK8CyljwjBXENc4AUTVpUHW6nF1vinvdIWREm0nKzflqNDyoF/ioal iZ4AAAAAAAA= --------------ms020104060609050007040309-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 14:22: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 OAA27183 for ; Mon, 11 Aug 2003 14:22:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BICZqt063921 for ; Mon, 11 Aug 2003 11:12:35 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BICZnV063920 for ietf-calendar-bks; Mon, 11 Aug 2003 11:12:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BICYqt063910 for ; Mon, 11 Aug 2003 11:12:34 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F32E165.5090904@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 14:02:23 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 02:12:32 PM, Serialize complete at 08/11/2003 02:12:32 PM Content-Type: multipart/alternative; boundary="=_alternative 0062D9DD85256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0062D9DD85256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 08/07/2003 07:31:49 PM: > > > > It does not matter that you never saw the SEQUENCE 0 thru 9 versions, > > > > the SEQUENCE:10 version obsoletes them anyway. If I had invited > > you at > > > > SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can > > > > correctly apply the iTIP message sequencing rules to detect that the > > > > message is obsolete and thus you ignore it (and the missequenced 9 > > too). > > > > > > So if SEQUNCE:10 is the following REQUEST VEVENT and is the FIRST > > > one to which I am invited: > > > > > > SEQUENCE:10 > > > RDATE: Jan-1 > > > RDATE: Jan-2 > > > RDATE: Jan-3 > > > > My example was for a particular instance at SEQUENCE:10 and your > > response was for the entire set I assume. This is mixing apples and > > kiwis. We've been discussing how instances are affected so lets try to > > stay focused shall we. > > No, I am showing why your model does not work. Please respond > to the text submitted. Gladly and I hope you will respond to the analyses Ive done on why the changing RECURRENCE-ID model is the wrong one. Ill go first... You have not shown any such failure; merely claimed it and posted 1 incomplete iTIP fragment (above). Neither have you disputed my analysis of the weaknesses in the changing RECURRENCE-ID model as they relate to message sequencing but more on that later. Lets take a look at your purported failure example shall we. First off its makes some assumptions that could be invalid: 1: ALL instances share the same SEQUENCE value. Each instance can be negotiated separately so they are not always likely to have the same SEQUENCE values but they could. 2: Using that fragment every instance would share the same data (except the derived DTSTART/DTEND values). In the real world I do not often find this to be the case for ALL repeating calendar entries; in fact I find it to be quite contrary to the norm where Organizers update the DESCRIPTION or ATTACHments or vary ATTENDEE lists, etc based on the needs/requirements of each instance. 3: This implicly assumes that this REQUEST will get to the invitee and not be lost or missequenced. If your later REQUESTs assume that this one arrived and was properly processed then you are gonna be in a world of hirt as you misread iTIP. iTIP messages are NOT guaranteed to be delivered in the same order they were sent; this should be obvious to most email users who get replys to postings they have yet to see. In fact, iTIP message delivery is NOT guaranteed at all and thats why each iTIP message is self contained; they have NO dependencies on any previous iTIP message contents. The exception to this seems to be Dougs model where the RECURRENCE-ID changes on each reschedule. 4: iTIP REQUEST allows for the Organzier to send multiple body parts for the same UID in the same iTIP message: For the "REQUEST" method, multiple "VEVENT" components in a single iCalendar object are only permitted when for components with the same "UID" property. That is, a series of recurring events may have instance-specific information. In this case, multiple "VEVENT" components are needed to express the entire series. and this is necessary when you want to sent data about multiple instances all at once as in a new invitation to a repeating set. There are 2 ways that a new invitee can be added to a _set_ of instances and Ive already given those iTIP fragments in response to Arnaud over a month ago. Go check the archives for my posting. It should be noted that Doug never responded to the request how it would work in his model and still has not after 6+ weeks. I can only guess why not. However this is a digression from the case of adding a single invitee to a single instance of the repeating set but I have indulged the digression in an attempt to show how the claim of failure is patently false and incorrect. If you understand iTIP Section 2.1.5 and how it applys to all Section 3 text you should see that adding a new invitee to an existing instance is trivial: simply send a REQUEST with the UID / RECURRENCE-ID / SEQUENCE that the instance currently has. The invitee should apply iTIP 3.2.2 text to detect that the UID / RECURRENCE-ID are not in the calendar and thus the REQUEST is an invitation. For invitations to multiple instances, the iTIP REQUEST contains the data for those instances (using the behaviour cited under #4 above) > Why will you not respont to the problem > that I submitted? Why? I have responed (this is the 2nd time) and so far Ive seen nothing that supports your assertion of a bad model or that something breaks. I now expect that you will respond to my analysis of the workflow model and how fault _intolerant_ and error prone it is when a changing RECURRENCE-ID is used. > You can > not update that VEVENT can you Bruce? Where do you pull these assertions from Doug?! You must not be reading my side by side analysis of each model and how message sequencing works (the iCalendar model) or fails (your model). However in case some missed it Ill repost part of it here to show exactly whose model is broken. First off, a fixed RECURRENCE-ID model: An update to an existing entry is defined in iTIP 3.2.2.2 Updating or Reconfirmation of an Event and a reschedule is defined in iTIP 3.2.2.1 Rescheduling an Event. Both are quite similar so Ill just discuss the reschedule case and leave it to the reader to apply the same understanding to the update case. 3.2.2.2 says: If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is greater than the value for the existing event, then the "REQUEST" method describes a rescheduling of the event. So to determine that this is a reschedule from a new invitation (iTIP 3.2.2 REQUEST) the UID and RECURRENCE-ID values must exist in the invitees calendar. The text says that SEQUENCE is "greater than the value for the existing event" without any distinction of being 1 or 2 or 5 or 1000 greater. This should imply that the RECURRENCE-ID value does not change but Ill continue. If the invitee is able to find the instance by UID / RECURRENCE-ID and then properly detect that their SEQUENCE value is, say, 3 lower than the SEQUENCE on the REQUEST they can tell 3 things: 1: This is indeed a rescschedule of the given UID / RECURRENCE-ID 2 The version they have is obsolete compared to the one in the REQUEST (this comes from iTIP Section 2.1.5 bullet 2 AND the text above!) 3: They can safely act on the REQUEST and apply it to the correct instance in their calendar. The invitee can now craft the proper REPLY and send it back to the Organzier and update their copy of the event with the newer info. No problems. Now, suppose that the reschedule for the same UID / RECURRENCE-ID came in but with a lower SEQUENCE value (one of the missing 2). If the CUA correctly implements Sections 2.1.5 and 3.2.2 they would see that they have the UID / RECURRENCE-ID values (so its NOT an invitation) but that the SEQUENCE is "lower" than the value they currently have so the REQUEST is obsolete and is safely ignored. No failures here. Nothing to worry about! Now for the changing RECURRENCE-ID model: The CUA looks at the UID / RECURRENCE-ID and does not find it in the calendar. As such it should follow iTIP 2.1.5 Message Sequencing and 3.2.2 REQUEST: If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. (since its a repeating instance) and _incorrectly_ treat the REQUEST as a new invitation to the instanced referred to by UID / RECURRENCE-ID at the given SEQUENCE. It now adds a new instance of UID to the users calendar and they have 2 instances of the UID at different date/times rather than 1. The invitee now crafts up a REPLY with the given UID / RECURRENCE-ID / SEQUENCE and send it back to the Organzier. The problems that we have at this point are: 1: There are now 2 versions of what is really the same instance on the users calendar. The user does not know something was wrong NOR do they have a way to simply remove the stale duplicates. 2: The REPLY to the Organzier has a RECURRENCE-ID matches one the Organizer has so they think the invitee is coming to 1 instance. Now, suppose that the reschedule for the same instance (same UID / another different RECURRENCE-ID) came in but with a lower SEQUENCE value (one of the missing 2). If the CUA correctly implements Sections 2.1.5 and 3.2.2 they would see that they do not have the UID / RECURRENCE-ID values and again incorrectly treat it as an invitation. They would repeat the same process of adding a 3rd duplicate instance and sending a REPLY back to the Organizer. Assuming the Organizer gets the REPLY for the older UID / RECURRENCE-ID / SEQUENCE they have NO way to 100% accurately match it to the correct instance in question. The CUA could try to guess but any attempt is easily defeated in 5 steps (see previous 2 descriptions of this if interested). As such the Organizer does not know for sure which instance in question the REPLY was for so they would send out a new REQUEST with the latest UID / RECURRENCE-ID / SEQUENCE (per iTIP). However its not clear what data would be in it since its not always possible to tell exactly which instance is in question. The only solution to this dilema is to destroy and recreate ALL instances by sending a REQUEST with a UID and a higher SEQUENCE value but no RECURRENCE-ID (but with RDATEs instead). This is much like Dougs example at the top with the same assumptions and related bagage. The answer is therefore that the Organizer must send an iTIP REQUEST that will cause the invitee to toast all instances it thinks it knows about and recreate them all; even those UNRELATED to the instance in question. And even this is not a totally viable solution as it does fails to fix the problem if the 'nuke' REQUEST never gets delivered. Since iTIP messages may get lost in transit for any number of causes, its not safe to rely on the assumption that the 'nuke ' REQUEST will actually get to the user (this is why REQUESTs are full snapshots, yes!?). If it gets lost then the orphaned duplicates will still exist on the invitees calendar. Any future REQUESTs will get treated as new invitations instead of reschedules and although the REPLYs look like the invitee knows the current state of things in fact they have a totally poluted calendar with duplicate instances that the Organzier has know way to knowing about or way to get rid of. Yep, this sounds like the model I want to have for my calendar system! Even if you have an unusual definition for the word 'original', take an analytical look at iTIP messging, message sequencing and its impact on C&S workflow. How can anyone who takes an analytical look at the workflow and how it fails with missequenced or lost messages when the RECURRENCE-ID changes actually think that model works when compared to the very fault tolerant fixed RECURRENCE-ID model?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0062D9DD85256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 08/07/2003 07:31:49 PM:
> >  > > It does not matter that you never saw the SEQUENCE 0 thru 9 versions,
> >  > > the SEQUENCE:10 version obsoletes them anyway.  If I had invited
> > you at
> >  > > SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can
> >  > > correctly apply the iTIP message sequencing rules to detect that the
> >  > > message is obsolete and thus you ignore it (and the missequenced 9
> > too).
> >  >
> >  > So if SEQUNCE:10 is the following REQUEST VEVENT and is the FIRST
> >  > one to which I am invited:
> >  >
> >  >    SEQUENCE:10
> >  >    RDATE: Jan-1
> >  >    RDATE: Jan-2
> >  >    RDATE: Jan-3
> >
> > My example was for a particular instance at SEQUENCE:10 and your
> > response was for the entire set I assume.  This is mixing apples and
> > kiwis.  We've been discussing how instances are affected so lets try to
> > stay focused shall we.
>
> No, I am showing why your model does not work. Please respond
> to the text submitted.

Gladly and I hope you will respond to the analyses Ive done on why the changing RECURRENCE-ID model is the wrong one.  Ill go first...

You have not shown any such failure; merely claimed it and posted 1 incomplete iTIP fragment (above).  

Neither have you disputed my analysis of the weaknesses in the changing RECURRENCE-ID model as they relate to message sequencing but more on that later.  

Lets take a look at your purported failure example shall we.  First off its makes some assumptions that could be invalid:

1: ALL instances share the same SEQUENCE value.  Each instance can be negotiated separately so they are not always likely to have the same SEQUENCE values but they could.

2: Using that fragment every instance would share the same data (except the derived DTSTART/DTEND values).  In the real world I do not often find this to be the case for ALL repeating calendar entries; in fact I find it to be quite contrary to the norm where Organizers update the DESCRIPTION or ATTACHments or vary ATTENDEE lists, etc based on the needs/requirements of each instance.

3: This implicly assumes that this REQUEST will get to the invitee and not be lost or missequenced.  If your later REQUESTs assume that this one arrived and was properly processed then you are gonna be in a world of hirt as you misread iTIP.  iTIP messages are NOT guaranteed to be delivered in the same order they were sent; this should be obvious to most email users who get replys to postings they have yet to see.  In fact, iTIP message delivery is NOT guaranteed at all and thats why each iTIP message is self contained; they have NO dependencies on any previous iTIP message contents.  The exception to this seems to be Dougs model where the RECURRENCE-ID changes on each reschedule.

4: iTIP REQUEST allows for the Organzier to send multiple body parts for the same UID in the same iTIP message:

   For the "REQUEST" method, multiple "VEVENT" components in a single
  iCalendar object are only permitted when for components with the same
  "UID" property.  That is, a series of recurring events may have
  instance-specific information.  In this case, multiple "VEVENT"
  components are needed to express the entire series.

and this is necessary when you want to sent data about multiple instances all at once as in a new invitation to a repeating set.  

There are 2 ways that a new invitee can be added to a _set_ of instances and Ive already given those iTIP fragments in response to Arnaud over a month ago.  Go check the archives for my posting.  It should be noted that Doug never responded to the request how  it would work in his model and still has not after 6+ weeks.  I can only guess why not.  However this is a digression from the case of adding a single invitee to a single instance of the repeating set but I have indulged the digression in an attempt to show how the claim of failure is patently false and incorrect.

If you understand iTIP Section 2.1.5 and how it applys to all Section 3 text you should see that adding a new invitee to an existing instance is trivial:  simply send a REQUEST with the UID / RECURRENCE-ID / SEQUENCE that the instance currently has.  The invitee should apply iTIP 3.2.2 text to detect that the UID / RECURRENCE-ID are not in the calendar and thus the REQUEST is an invitation.  For invitations to multiple instances, the iTIP REQUEST contains the data for those instances (using the behaviour cited under #4 above)

> Why will you not respont to the problem
> that I submitted? Why?

I have responed (this is the 2nd time) and so far Ive seen nothing that supports your assertion of a bad model or that something breaks.

I now expect that you will respond to my analysis of the workflow model and how fault _intolerant_ and error prone it is when a changing RECURRENCE-ID is used.

>                                                   You can
> not update that VEVENT can you Bruce?
Where do you pull these assertions from Doug?!  You  must not be reading my side by side analysis of each model and how message sequencing works (the iCalendar model) or fails (your model).

However in case some missed it Ill repost part of it here to show exactly whose model is broken.

First off, a fixed RECURRENCE-ID model:

An update to an existing entry is defined in iTIP 3.2.2.2 Updating or Reconfirmation of an Event and a reschedule is defined in iTIP 3.2.2.1 Rescheduling an Event.  Both are quite similar so Ill just discuss the reschedule case and leave it to the reader to apply the same understanding to the update case.  3.2.2.2 says:

                  If the recipient CUA of a "REQUEST" method finds that
  the "UID" property value already exists on the calendar, but that the
  "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
  greater than the value for the existing event, then the "REQUEST"
  method describes a rescheduling of the event.

So to determine that this is a reschedule from a new invitation (iTIP 3.2.2 REQUEST) the UID and RECURRENCE-ID values must exist in the invitees calendar.  The text says that SEQUENCE is "greater than the value for the existing event" without any distinction of being 1 or 2 or 5 or 1000 greater.  This should imply that the RECURRENCE-ID value does not change but Ill continue.  If the invitee is able to find the instance by UID / RECURRENCE-ID and then properly detect that their SEQUENCE value is, say, 3 lower than the SEQUENCE on the REQUEST they can tell 3 things:

1: This is indeed a rescschedule of the given UID / RECURRENCE-ID
2 The version they have is obsolete compared to the one in the REQUEST (this comes from iTIP Section 2.1.5 bullet 2 AND the text above!)
3: They can safely act on the REQUEST and apply it to the correct instance in their calendar.

The invitee can now craft the proper REPLY and send it back to the Organzier and update their copy of the event with the newer info.  No problems.

Now, suppose that the reschedule for the same UID / RECURRENCE-ID came in but with a lower SEQUENCE value (one of the missing 2).  If the CUA correctly implements Sections 2.1.5 and 3.2.2 they would see that they have the UID / RECURRENCE-ID values (so its NOT an invitation) but that the SEQUENCE is "lower" than the value they currently have so the REQUEST is obsolete and is safely ignored.  No failures here.  Nothing to worry about!

Now for the changing RECURRENCE-ID model:

The CUA looks at the UID / RECURRENCE-ID and does not find it in the calendar.  As such it should follow iTIP 2.1.5 Message Sequencing and  3.2.2 REQUEST:

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

(since its a repeating instance) and _incorrectly_ treat the REQUEST as a new invitation to the instanced referred to by UID / RECURRENCE-ID at the given SEQUENCE.  It now adds a new instance of UID to the users calendar and they have 2 instances of the UID at different date/times rather than 1.  

The invitee now crafts up a REPLY with the given UID / RECURRENCE-ID / SEQUENCE and send it back to the Organzier.  The problems that we have at this point are:

1: There are now 2 versions of what is really the same instance on the users calendar.  The user does not know something was wrong NOR do they have a way to simply remove the stale duplicates.
2: The REPLY to the Organzier has a RECURRENCE-ID matches one the Organizer has so they think the invitee is coming to 1 instance.

Now, suppose that the reschedule for the same instance (same UID / another different RECURRENCE-ID) came in but with a lower SEQUENCE value (one of the missing 2).  If the CUA correctly implements Sections 2.1.5 and 3.2.2 they would see that they do not have the UID / RECURRENCE-ID values and again incorrectly treat it as an invitation.  They would repeat the same process of adding a 3rd duplicate instance and sending a REPLY back to the Organizer.

Assuming the Organizer gets the REPLY for the older UID / RECURRENCE-ID / SEQUENCE they have NO way to 100% accurately match it to the correct instance in question.  The CUA could try to guess but any attempt is easily defeated in 5 steps (see previous 2 descriptions of this if interested).  As such the Organizer does not know for sure which instance in question the REPLY was for so they would send out a new REQUEST with the latest UID / RECURRENCE-ID / SEQUENCE (per iTIP).   However its not clear what data would be in it since its not always possible to tell exactly which instance is in question.

The only solution to this dilema is to destroy and recreate ALL instances by sending a REQUEST with a UID and a higher SEQUENCE value but no RECURRENCE-ID (but with RDATEs instead).  This is much like Dougs example at the top with the same assumptions and related bagage.  The answer is therefore that the Organizer must send an iTIP REQUEST that will cause the invitee to toast all instances it thinks it knows about and recreate them all; even those UNRELATED to the instance in question.  And even this is not a totally viable solution as it does fails to fix the problem if the 'nuke' REQUEST never gets delivered.

Since iTIP messages may get lost in transit for any number of causes, its not safe to rely on the assumption that the 'nuke ' REQUEST will actually get to the user (this is why REQUESTs are full snapshots, yes!?).  If it gets lost then the orphaned duplicates will still exist on the invitees calendar.  Any future REQUESTs will get treated as new invitations instead of reschedules and although the REPLYs look like the invitee knows the current state of things in fact they have a totally poluted calendar with duplicate instances that the Organzier has know way to knowing about or way to get rid of.  Yep, this sounds like the model I want to have for my calendar system!

Even if you have an unusual definition for the word 'original', take an analytical look at iTIP messging, message sequencing and its impact on C&S workflow.

How can anyone who takes an analytical look at the workflow and how it fails with missequenced or lost messages when the RECURRENCE-ID changes actually think that model works when compared to the very fault tolerant fixed RECURRENCE-ID model??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0062D9DD85256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 14:44: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 OAA27779 for ; Mon, 11 Aug 2003 14:44:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BIa6qt065078 for ; Mon, 11 Aug 2003 11:36:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BIa6id065077 for ietf-calendar-bks; Mon, 11 Aug 2003 11:36:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BIa5qt065069 for ; Mon, 11 Aug 2003 11:36:06 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: "Michael Fair" Cc: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 14:12:23 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 02:36:03 PM, Serialize complete at 08/11/2003 02:36:03 PM Content-Type: multipart/alternative; boundary="=_alternative 0063C45885256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063C45885256D7F_= Content-Type: text/plain; charset="US-ASCII" Michael replied on 08/08/2003 06:51:56 AM: > Indeed, I grant you that the use of the term "effective" does > tend to call for the use of a changing RECURRENCE-ID. 'effective' is likely due to the fact that the DTSTART date/time values for the instance cannot be blindly copied from the 1st instance to all others. This is due to things like timezone shifts where the starting time is, say, 9:00 AM EST half the year and and 10:00 AM EDT the other half. Another example is the effect of unrolling the RRULE which may have BYxxx components that effect the final DTSTART value of the instance. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 0063C45885256D7F_= Content-Type: text/html; charset="US-ASCII"
Michael replied on 08/08/2003 06:51:56 AM:
> Indeed, I grant you that the use of the term "effective" does
> tend to call for the use of a changing RECURRENCE-ID.

'effective' is likely due to the fact that the DTSTART date/time values for the instance cannot be blindly copied from the 1st instance to all others.  

This is due to things like timezone shifts where the starting time is, say, 9:00 AM EST half the year and and 10:00 AM EDT the other half.  Another example is the effect of unrolling the RRULE which may have BYxxx components that effect the final DTSTART value of the instance.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 0063C45885256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 14:57: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 OAA28198 for ; Mon, 11 Aug 2003 14:57:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BInRqt065677 for ; Mon, 11 Aug 2003 11:49:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BInRW0065676 for ietf-calendar-bks; Mon, 11 Aug 2003 11:49:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BInPqt065671 for ; Mon, 11 Aug 2003 11:49:25 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BInOEB002934 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 11:49:26 -0700 Message-ID: <3F37E52E.5080003@Royer.com> Date: Mon, 11 Aug 2003 12:49:18 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030404000501020307060203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030404000501020307060203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > Lets take a look at your purported failure example shall we. First off > its makes some assumptions that could be invalid: > > 1: ALL instances share the same SEQUENCE value. Each instance can be > negotiated separately so they are not always likely to have the same > SEQUENCE values but they could. I think we agree - the instance can change. > 2: Using that fragment every instance would share the same data (except > the derived DTSTART/DTEND values). In the real world I do not often > find this to be the case for ALL repeating calendar entries; in fact I > find it to be quite contrary to the norm where Organizers update the > DESCRIPTION or ATTACHments or vary ATTENDEE lists, etc based on the > needs/requirements of each instance. Frequency of occurrence is not relevant. I think we agree that the exceptions are what break most models. > 3: This implicly assumes that this REQUEST will get to the invitee and > not be lost or missequenced. Are you saying that is your opinion? Or that you think that is my opinion? Which is opposed to the iTIP 'Abstract': The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects. Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects. > If your later REQUESTs assume that this > one arrived and was properly processed then you are gonna be in a world > of hirt as you misread iTIP. iTIP messages are NOT guaranteed to be > delivered in the same order they were sent; this should be obvious to > most email users who get replys to postings they have yet to see. In > fact, iTIP message delivery is NOT guaranteed at all and thats why each > iTIP message is self contained; they have NO dependencies on any > previous iTIP message contents. The exception to this seems to be Dougs > model where the RECURRENCE-ID changes on each reschedule. Stating a truism is not relevant to the point. It is also true that I am sending email. How many times do I need to say that? I have nor have I seen anyone on this list claim that the above truism you state is false. > 4: iTIP REQUEST allows for the Organzier to send multiple body parts for > the same UID in the same iTIP message: > > For the "REQUEST" method, multiple "VEVENT" components in a single > iCalendar object are only permitted when for components with the same > "UID" property. That is, a series of recurring events may have > instance-specific information. In this case, multiple "VEVENT" > components are needed to express the entire series. Yes, and we both fought for that - another turism. > and this is necessary when you want to sent data about multiple > instances all at once as in a new invitation to a repeating set. > > There are 2 ways that a new invitee can be added to a _set_ of instances > and Ive already given those iTIP fragments in response to Arnaud over a > month ago. Go check the archives for my posting. It should be noted > that Doug never responded to the request how it would work in his model > and still has not after 6+ weeks. I can only guess why not. I did respond - check your email or the imc archives. > However > this is a digression from the case of adding a single invitee to a > single instance of the repeating set but I have indulged the digression > in an attempt to show how the claim of failure is patently false and > incorrect. Your intentional ignoreing my questions does not make it proved. > > If you understand iTIP Section 2.1.5 and how it applys to all Section 3 > text you should see that adding a new invitee to an existing instance is > trivial: simply send a REQUEST with the UID / RECURRENCE-ID / SEQUENCE > that the instance currently has. The invitee should apply iTIP 3.2.2 > text to detect that the UID / RECURRENCE-ID are not in the calendar and > thus the REQUEST is an invitation. For invitations to multiple > instances, the iTIP REQUEST contains the data for those instances (using > the behaviour cited under #4 above) And what about my repeated questions that show when that does not work? I am deleteing the rest of your reply becuase so far you still keep giving your opinion, do not address the facts, or just quote text that does not address the questions that you reportataly above declared to address... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030404000501020307060203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTE4NDkxOFowIwYJKoZIhvcNAQkEMRYEFFBiblMu k04axJ3izdOHa2tu7NSwMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJkdXkbemMLZygNTzZoLWWRnRr/CiIUd6oUOiVuMk0TPNQkV1hI6 SgbL1avl1Xvdjk0PZB2CegUoXh9lJgmQizRAnfUQeDouZC+rlzMYiuNYOQNSbPYFAbLGsrg/ 5YjYwLjTWfvVu08sjLNhZDBd4LspcErVjpmhX+JBEF+nhU1B3ro4wfNIxAEGvV14GcplzzmA RzDfqnZc4bl+eUbDVbLQFDRyUxidE63Zne3h+3+aJyT7VMhkGCQ12EWjRv2roH8Sg7d7dEyl X6/7CbLORh2xge3sKY7I7Y64MS5oAZcouoEJ1jws7PJropyHUY2nA2EyNX2pyOvO2UqGfwth QW0AAAAAAAA= --------------ms030404000501020307060203-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 15:00: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 PAA28341 for ; Mon, 11 Aug 2003 15:00:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BIqeqt065828 for ; Mon, 11 Aug 2003 11:52:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BIqehi065827 for ietf-calendar-bks; Mon, 11 Aug 2003 11:52:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BIqcqt065819 for ; Mon, 11 Aug 2003 11:52:39 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BIqbEB002962 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 11:52:39 -0700 Message-ID: <3F37E5F0.2040808@Royer.com> Date: Mon, 11 Aug 2003 12:52:32 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000802030109060102010507" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000802030109060102010507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Michael replied on 08/08/2003 06:51:56 AM: > > Indeed, I grant you that the use of the term "effective" does > > tend to call for the use of a changing RECURRENCE-ID. > > 'effective' is likely due to the fact that the DTSTART date/time values > for the instance cannot be blindly copied from the 1st instance to all > others. > > This is due to things like timezone shifts where the starting time is, > say, 9:00 AM EST half the year and and 10:00 AM EDT the other half. > Another example is the effect of unrolling the RRULE which may have > BYxxx components that effect the final DTSTART value of the instance. Yet in sections that have noting to do with timezones, such as RECURRECE-ID and RANGE it also talks about the effective start date of an instance. Sounds like selective reading to me. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000802030109060102010507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTE4NTIzMlowIwYJKoZIhvcNAQkEMRYEFHzFAC4T 74kokyLbnCvSxALHYFVsMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBACjBozDhDU8uM4s9MMMsXfLhHVvrsrtnxtT4k9q4dWtZb6XyZ3ef df5IRkO1UkKoT4ZYrDkAFSsrFlOABBeEuRkh+fZDCIpE+3p1pDS/miQE7yrMidkpv5yDaFyP 2Ijvf8OUUYDDnjNhmDZN4q4yGzYwWB8FWIO8j2vgLWQQHU1nnPFRJDHswoqIT677mRbRwP3n sjlv4WE9LQD8D/EhlFe8AVlbnZW479D+afZucmxSCIvUXfV9QgDUZwxQ2v36U+momLk9pV5q uFuKUsMDwzvU05dQabKvPxPvthvljzgn3jle8YULf3fKuWsyEcZxjxTDgssRu1th3LGTYM2v XJ4AAAAAAAA= --------------ms000802030109060102010507-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 15:15: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 PAA29620 for ; Mon, 11 Aug 2003 15:15:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJ6Yqt066996 for ; Mon, 11 Aug 2003 12:06:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BJ6YUa066995 for ietf-calendar-bks; Mon, 11 Aug 2003 12:06:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJ6Yqt066987 for ; Mon, 11 Aug 2003 12:06:34 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F33CD59.4070509@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 14:42:12 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 03:06:30 PM, Serialize complete at 08/11/2003 03:06:30 PM Content-Type: multipart/alternative; boundary="=_alternative 00667F4C85256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00667F4C85256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug said on 08/08/2003 12:18:33 PM: > > How does this unambiguosly tell me which instance he's > > responding to. > > All of them that he was invited to attend. So your answer is that he cannot do this?? Michael asked how does Satay differentiate the instance he is REPLYing to and you say that he responds to "all of them that he was invited to". This is another drawback to the changing RECURRENCE-ID model over the fixed model. With a fixed model Satay can easily and unambiguously identify the specific instance in question. Another thing that Im not sure if Michale noted was that in order for Satay to be added to the 4-Jan case the REQUEST MUST be crafted such that Satay will destroy his current version of the UID and recreate it with just the information in the REQUEST. All this even if his 5-Jan participation has not changed. (Plus this assumes that the 4-Jan and 5-Jan instances share the same data). > Your thinking > of exactly one instance at a time. Thats because the REQUEST was regarding the 4-Jan instance, not all or a subset of them. > What if I want someone > to attend instances 3,6,14? If you add the RECURRENCE-ID > you have to to send 3 REQUESTs and get 3 REPLYs. Wrong. Go recheck iTIP Section 3.2.2 REQUEST: For the "REQUEST" method, multiple "VEVENT" components in a single iCalendar object are only permitted when for components with the same "UID" property. That is, a series of recurring events may have instance-specific information. In this case, multiple "VEVENT" components are needed to express the entire series. so a single REQUEST is all thats necessary; it can contain the definitions of the individual instances as they currently are. Since the REPLY is either for an instance, contiguous subset of instances (RANGEs) or the entire set you will need to send back the proper number of respones. However it can be done in 1 iCalendar stream of data and does not need to be in 3 separate actual, say, emails. In addtion the data in the REPLY is considerably less that whats in the REQUEST (just the ATTENDEE, DTSTAMP, ORGANIZER, RECURRENCE-ID, UID and SEQUENCE properites) its not as great a demand or impact as you imply. > It is > not needed. Just send that ATTENDEE a single REQUEST with > the dates/times they are requested to attend. (see how > to disambiguate below) This does not always work as you claim, see my other postings on this matter and on the implicit assumptions you make. > I can't believe that any CUA that allows the CU to invite > an attendee to one or more specific instances is going > to rely on the REPLY's coming back from the ATTENDEE to > tell the ORGANIZER when the ATTENDEEs are invited. Its NOT just a matter of saying what instances they were invited to, its a matter of matching their responses to the correct instance defintions. > The ORGANIZER-CUA > is going to already know who they invited to what instances. > The ORGANIZERs CUA is already going to have to track objects > sent that are waiting replies. You dont wait for REPLYs, they can be sent at any time by the invitees for any reason they choose. The Organizer tracks their participation status based on the REPLYs they send as it matches it to the correct instance in questions. Ive repeatedly shown that it only takes 5 steps to make this matching 100% guesswork and you have yet to disprove this. > Match them up which is what > you are going to have to do anyway in order to clean up > the CUAs pending things to care about queue. You have totally omitted factoring in message missequencing or message loss in transit. > Send an iTIP REQUEST and process an iTIP REPLY. No new > method needed. No need to confuse a new invitation > with a modification to an existing instance. Your interpreation has NO way to distinguish a new invitation from a missequenced reschedule. You may be thinking of some pure CAP implemenation that processes the users pending queue but this is iTIP we are talking about now and NOT some CAP implementation you did. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00667F4C85256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug said on 08/08/2003 12:18:33 PM:
> > How does this unambiguosly tell me which instance he's
> > responding to.
>
> All of them that he was invited to attend.

So your answer is that he cannot do this??  Michael asked how does Satay differentiate the instance he is REPLYing to and you say that he responds to "all of them that he was invited to".  

This is another drawback to the changing RECURRENCE-ID model over the fixed model.  With a fixed model Satay can easily and unambiguously identify the specific instance in question.

Another thing that Im not sure if Michale noted was that in order for Satay to be added to the 4-Jan case the REQUEST MUST be crafted such that Satay will destroy his current version of the UID and recreate it with just the information in the REQUEST.  All this even if his 5-Jan participation has not changed.  (Plus this assumes that the 4-Jan and 5-Jan instances share the same data).

> Your thinking
> of exactly one instance at a time.

Thats because the REQUEST was regarding the 4-Jan instance, not all or a subset of them.

>                                     What if I want someone
> to attend instances 3,6,14? If you add the RECURRENCE-ID
> you have to to send 3 REQUESTs and get 3 REPLYs.

Wrong.  Go recheck iTIP Section 3.2.2 REQUEST:

  For the "REQUEST" method, multiple "VEVENT" components in a single
  iCalendar object are only permitted when for components with the same
  "UID" property.  That is, a series of recurring events may have
  instance-specific information.  In this case, multiple "VEVENT"
  components are needed to express the entire series.
so a single REQUEST is all thats necessary; it can contain the definitions of the individual instances as they currently are.  Since the REPLY is either for an instance, contiguous subset of instances (RANGEs)  or the entire set you will need to send back the proper number of respones. However it can be done in 1 iCalendar stream of data and does not need to be in 3 separate actual, say, emails.  In addtion the data in the REPLY is considerably less that whats in the REQUEST (just the ATTENDEE, DTSTAMP, ORGANIZER, RECURRENCE-ID, UID and SEQUENCE properites) its not as great a demand or impact as you imply.
>                                                   It is
> not needed. Just send that ATTENDEE a single REQUEST with
> the dates/times they are requested to attend. (see how
> to disambiguate below)
This does not always work as you claim, see my other postings on this matter and on the implicit assumptions you make.

> I can't believe that any CUA that allows the CU to invite
> an attendee to one or more specific instances is going
> to rely on the REPLY's coming back from the ATTENDEE to
> tell the ORGANIZER when the ATTENDEEs are invited.

Its NOT just a matter of saying what instances they were invited to, its a matter of matching their responses to the correct instance defintions.  


>                                The ORGANIZER-CUA
> is going to already know who they invited to what instances.
> The ORGANIZERs CUA is already going to have to track objects
> sent that are waiting replies.

You dont wait for REPLYs, they can be sent at any time by the invitees for any reason they choose.  The Organizer tracks their participation status based on the REPLYs they send as it matches it to the correct instance in questions.  Ive repeatedly shown that it only takes 5 steps to make this matching 100% guesswork and you have yet to disprove this.

>                                 Match them up which is what
> you are going to have to do anyway in order to clean up
> the CUAs pending things to care about queue.
You have totally omitted factoring in message missequencing or message loss in transit.

> Send an iTIP REQUEST and process an iTIP REPLY. No new
> method needed. No need to confuse a new invitation
> with a modification to an existing instance.
Your interpreation has NO way to distinguish a new invitation from a missequenced reschedule.  You may be thinking of some pure CAP implemenation that processes the users pending queue but this is iTIP we are talking about now and NOT some CAP implementation you did.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00667F4C85256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 15:44: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 PAA01150 for ; Mon, 11 Aug 2003 15:44:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJZ4qt068383 for ; Mon, 11 Aug 2003 12:35:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BJZ4jw068382 for ietf-calendar-bks; Mon, 11 Aug 2003 12:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJZ2qt068375 for ; Mon, 11 Aug 2003 12:35:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BJZ1EB003225 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 12:35:03 -0700 Message-ID: <3F37EFE0.9050503@Royer.com> Date: Mon, 11 Aug 2003 13:34:56 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP -12 and LAST CALL (hopefully) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010101090203020009060300" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010101090203020009060300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit With the addition to the typo's that people have filed using bugzilla and the ones on this list it looks as if CAP is almost ready to release. The only non-typo issue seems to be the BEEP profile. Bruce has declared twice that it has not been discusses and proposed no solution. So that responce is a dead end. If anyone (including Bruce) has a proposal or objection to the BEEP profile below - please speak up. There has been a discussion on the 1:1 and 1:many replies and the first time I sent the BEEP proposal below (apx JUL-7) there have been no responces. I do not really have any choice but to assume it is acceptable. I'll fix the typos submitted, add the BEEP profile below. This weekend (if I have time) I'll submit -12 and hopefully it will be the last WG call. There have been posts asking for issues, so obviously those asking for the issues do not have any at this time. Proposed Beep profile: As there have been no replies to my comments to the BEEP profile and after re-reading the WG archives, I will put the following into -12 (still not too late to comment on my proposal). Beep replies will be one to one (1:1 MSG/RPY) if possible and one to many (1:many MSG/ANS) when the TARGET changes. Profile Identification: specify a URI [10] that authoritatively identifies this profile. http://iana.org/beep/cap/1.0 Message Exchanged during Channel Creation: specify the datatypes that may be exchanged during channel creation. CUAs SHOULD supply the BEEP "localize" attributes in the BEEP "greeting" messages. CSs SHOULD supply the BEEP "localize" attributes in the BEEP "greeting" messages. CUAs SHOULD supply the BEEP "serverName" attribute at channel creation time to the CS so that if the CS is performing virtual hosting the CS can determine the intended virtual host. CSs that do not support virtual hosting may ignore the BEEP "serverName" attribute. Messages starting one-to-one exchanges: specify the datatypes that may be present when an exchange starts. The initial message each direction MUST BE single "text/calendar" object containing a CAP "CAPABILITY" CMD and must not be part of a MIME multipart message. After the initial message then a BEEP "MSG" may contain one or more MIME objects at least one of which MUST be "text/calendar" and at least one "text/calendar" MIME object MUST contain a CAP "CMD" property. The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "MSG" so long as all of the "text/calendar" CAP objects have the same "TARGET" property value. Messages in positive replies: specify the datatypes that may be present in a positive reply. After the initial message then a BEEP "RPY" may contain one or more MIME objects at least one of which MUST be "text/calendar" and at least one "text/calendar" MIME object MUST contain a CAP "CMD" property. All "text/calendar" MIME objects in a single BEEP "RPY" messages MUST have the same "TARGET" property value. The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "RPY" so long as all of the "text/calendar" CAP objects have the same "TARGET" property value. Messages in negative replies: specify the datatypes that may be present in a negative reply. Any valid "text/calendar" MIME object that contains CAP "REQUEST-STATUS" property and a CAP "CMD" property with a property value of "REPLY". And where the CS has determined the requested operation to be a fatal error. And when the CS has performed NO operation that effected the contents of any part of the CS or any calendar controlled by the CS. Messages in one-to-many exchanges: specify the datatypes that may be present in a one-to-many exchange. After the initial message then a BEEP "MSG" may contain one or more MIME objects at least one of which MUST be "text/calendar" and at least one "text/calendar" MIME object MUST contain a CAP "CMD" property. The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "MSG" so long as all of the "text/calendar" CAP objects have the same "TARGET" property value. The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "ANS" so long as all of the "text/calendar" CAP objects in EACH BEEP "ANS" message have the same "TARGET" property value. Each unique "TARGET" property value per BEEP "ANS" message. Message Syntax: specify the syntax of the datatypes exchanged by the profile. They are CAP "text/calendar" MIME objects as specified in this memo. Message Semantics: specify the semantics of the datatypes exchanged by the profile. As defined in this memo. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010101090203020009060300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTE5MzQ1NlowIwYJKoZIhvcNAQkEMRYEFMX/XdSY 78hUwqaPipNkmM6QBiNfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAK55Hh4kNoI5yIGH1oi2LUDAB0gUTo+gbo6Qji8jrik5YomQLaX2 IXJJ1oFDXo5jyLiiDK64z/9ppZ7pp/jYdhuRfPV2qvCA7RfwcA5xPwbMfWxHKbTyfBPnBeZ0 w1CO8zgH2MgOJgOb4NiPGWho1lh9Bz21z323/G0LKf2lA5Aoe10ONbhdvMXCvIAqshZ3AIm+ dW8/Z9EvYohCkupeOnBwS/uSRO/Jl8j5rWS2Q0RSZ1A51Glu4bxM73Cs2KkQl1NOuoNrrm9z HxzdOOOlZPjpokpt3DNAbHzDe3g3GN21B9SLUW64N8/nphWJC+dDEHkebpU7BqTb2S+lN7lD UjwAAAAAAAA= --------------ms010101090203020009060300-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 15:45: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 PAA01210 for ; Mon, 11 Aug 2003 15:45:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJbLqt068479 for ; Mon, 11 Aug 2003 12:37:21 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BJbLcS068478 for ietf-calendar-bks; Mon, 11 Aug 2003 12:37:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJbKqt068473 for ; Mon, 11 Aug 2003 12:37:20 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BJbJEB003252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 12:37:21 -0700 Message-ID: <3F37F06A.8040906@Royer.com> Date: Mon, 11 Aug 2003 13:37:14 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000601010707020101090904" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000601010707020101090904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug said on 08/08/2003 12:18:33 PM: > > > How does this unambiguosly tell me which instance he's > > > responding to. > > > > All of them that he was invited to attend. > > So your answer is that he cannot do this?? No. I said the he would REPLY to all of them he was invited to attend. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000601010707020101090904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTE5MzcxNFowIwYJKoZIhvcNAQkEMRYEFL20AuFT niU65ibua7w7YzdLYSHoMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAA1FtCEBpWaiovHGfQu5HOs3ftP0ZQb6s4x0t2a1l3BkcEO2JedO CZKIB5yFAuZYvzSJwNO/fmFF3XF/YcI5pFeRsMs5A9jDJCenlhifedfBvlQSyx4u1Sav8QVR q3bzEGwpuydEp69NMu/xnnpyzRY+9SsIk+P+Kj3RwkCR9wyy1yMeefP8eUmsA9gSTOWtmoLY Mr5SMN3ulDKvKczlSBSs/rq2j3h21JOpd2n1zlrY3X9xXOVgW8CYZeAKtmBzVWNQ64atmFyp cgZUYp4mUxe6U7r+DAs/CcUA3nYHMFha2UnBgfsW7j9cJSoOqbeO0RMa5fF0sagGCoJ81Zzq zE4AAAAAAAA= --------------ms000601010707020101090904-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 15:51: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 PAA02007 for ; Mon, 11 Aug 2003 15:51:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJgxqt068734 for ; Mon, 11 Aug 2003 12:42:59 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BJgwZS068733 for ietf-calendar-bks; Mon, 11 Aug 2003 12:42:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJgwqt068724 for ; Mon, 11 Aug 2003 12:42:58 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F33D541.9090601@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 15:30:40 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 03:42:52 PM, Serialize complete at 08/11/2003 03:42:52 PM Content-Type: multipart/alternative; boundary="=_alternative 006AEEEB85256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006AEEEB85256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug trumpted on 08/08/2003 12:52:17 PM: > I am confused reading your above paragraph. Are you saying > that the RECURRENCE-ID is tied to the UID/SEQUENCE? Yes > that is my point. You are basing your design on an example (Section 4.7.2 Bad RECURRENCE-ID, bullet 2) and NOT on the normalative prose of iTIP that are relevant like Section 2.1.5 Message Sequencing and many parts (or subparts) of Section 3. This is folly, coding to an example and not the prose its intended to demonstrate but it would not be the first time someone did that. In case you want something to ignore, Ill provide you with the key sequencing bits: To maximize interoperability and to handle messages that arrive in an unexpected order, use the following rules: 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. 2. The secondary key for referencing a component is the "SEQUENCE" property value. For components where the "UID" is the same, the component with the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values. Even bullet 1 of Dougs prescious Section 4.7.2 clearly descibes a case where UID / RECURRENCE-ID are fixed and used to find the instance in question before checking SEQUENCE (otherwise how could you find the UID / RECURRENCE-ID but have a SEQUENCE that is greater or lesser??). Of course thats contrary to Dougs UID / SEQUENCE / RECURRNECE-ID model so he'd just like you to forget it. Lets take some common sense approach to this discussion and see if that helps. If you want to unambiguously refer to an instance of something you need to assign it an identifier that you can use consistantly and that will always allow you to find the instance in question or be sure you and the other party are referring to the same item/instance. Otherwise you risk having 2 separate converstations and never noticing a problem. One way that we do this now is to assign serial numbers to things like your PC or a VIN to your car. If I want to have any correspondence with someone about the item I can always use that serial number for doing things like tracking it inventory and tracking current ownership. I do not say "Where is your Dell laptop?" when I talk w/someone who may have > 1 laptop if Im interested in a particular laptop. I must say "Where is your Dell laptop, serial #123456?" That way I know that both the other person and I are referring to the same laptop and not different ones. Otherwise I may think the person still has laptop #123456 but in fact it no loner exists. For people (here in the US), your name can change but your Social Security Number (SSN) does not. So a person can change their name but the government still has a way to uniquely refer to them no matter the change. If the government had to rely on a value that could change at any time then they would have NO way to accurately know which "Doug Royer" or "Bruce Kahn" was which. Thats why SSNs are fixed (ok, they are reused on your death after 20 years but thats not relevant). Your cell phone has a unique identifier it uses to access the phone networks so that the carriers can confirm your phones identity and apply the charges to the proper account. If the identifier it used on each call was different then the charges could not be accurately apply to your account. Gee, maybe I could like Dougs model for some things... iTIP is designed to be fault tolerant because not all bindings of it are going to be able ensure 100% message delivery and ordering and handling (NOT EVEN CAP can guarantee that!). The ONLY way to correctly identify the instance the sender was referring to on the receiving side is if the identifier (RECURRENCE-ID) is fixed. If the design required that all previous messages be recived and in the order sent then it would not be very fault tolerant at all and very error prone. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006AEEEB85256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug trumpted on 08/08/2003 12:52:17 PM:
> I am confused reading your above paragraph. Are you saying
> that the RECURRENCE-ID is tied to the UID/SEQUENCE? Yes
> that is my point.
You are basing your design on an example (Section 4.7.2 Bad RECURRENCE-ID, bullet 2) and NOT on the normalative prose of iTIP that are relevant like Section 2.1.5 Message Sequencing and many parts (or subparts) of Section 3.  This is folly, coding to an example and not the prose its intended to demonstrate but it would not be the first time someone did that.

In case you want something to ignore, Ill provide you with the key sequencing bits:

   To maximize interoperability and to handle messages that arrive in an
  unexpected order, use the following rules:

  1.  The primary key for referencing a particular iCalendar component
      is the "UID" property value. To reference an instance of a
      recurring component, the primary key is composed of the "UID" and
      the "RECURRENCE-ID" properties.

  2.  The secondary key for referencing a component is the "SEQUENCE"
      property value.  For components where the "UID" is the same, the
      component with the highest numeric value for the "SEQUENCE"
      property obsoletes all other revisions of the component with
      lower values.

Even bullet 1 of Dougs prescious Section 4.7.2 clearly descibes a case where UID / RECURRENCE-ID are fixed and used to find the instance in question before checking SEQUENCE (otherwise how could you find the UID / RECURRENCE-ID but have a SEQUENCE that is greater or lesser??).  Of course thats contrary to Dougs UID / SEQUENCE / RECURRNECE-ID model so he'd just like you to forget it.

Lets take some common sense approach to this discussion and see if that helps.  If you want to unambiguously refer to an instance of something you need to assign it an identifier that you can use consistantly and that will always allow you to find the instance in question or be sure you and the other party are referring to the same item/instance.   Otherwise you risk having 2 separate converstations and never noticing a problem.

One way that we do this now is to assign serial numbers to things like your PC or a VIN to your car.  If I want to have any correspondence with someone about the item I can always use that serial number for doing things like tracking it inventory and tracking current ownership.  I do not say "Where is your Dell laptop?" when I talk w/someone who may have > 1 laptop if Im interested in a particular laptop.  I must say "Where is your Dell laptop, serial #123456?"  That way I know that both the other person and I are referring to the same laptop and not different ones.  Otherwise I may think the person still has laptop #123456 but in fact it no loner exists.

For people (here in the US), your name can change but your Social Security Number (SSN) does not.  So a person can change their name but the government still has a way to uniquely refer to them no matter the change.  If the government had to rely on a value that could change at any time then they would have NO way to accurately know which "Doug Royer" or "Bruce Kahn" was which.  Thats why SSNs are fixed (ok, they are reused on your death after 20 years but thats not relevant).

Your cell phone has a unique identifier it uses to access the phone networks so that the carriers can confirm your phones identity and apply the charges to the proper account.  If the identifier it used on each call was different then the charges could not be accurately apply to your account.  Gee, maybe I could like Dougs model for some things...

iTIP is designed to be fault tolerant because not all bindings of it are going to be able ensure 100% message delivery and ordering and handling (NOT EVEN CAP can guarantee that!).  The ONLY way to correctly identify the instance the sender was referring to on the receiving side is if the identifier (RECURRENCE-ID) is fixed.   If the design required that all previous messages be recived and in the order sent then it would not be very fault tolerant at all and very error prone.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006AEEEB85256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 15:55: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 PAA02578 for ; Mon, 11 Aug 2003 15:55:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJl4qt068915 for ; Mon, 11 Aug 2003 12:47:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BJl4P2068914 for ietf-calendar-bks; Mon, 11 Aug 2003 12:47:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJl1qt068902 for ; Mon, 11 Aug 2003 12:47:02 -0700 (PDT) (envelope-from pregen@egenconsulting.com) Subject: Re: CAP -12 and LAST CALL (hopefully) To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Mon, 11 Aug 2003 15:47:01 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 08/11/2003 03:47:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug: 1. The chairs make the Last Call statement - not the editors. 2. I think there are a lot more issues on the list that are not addressed in what you have put in CAP 12. 3. Saying that no one responding to a comment by Bruce stops the issue is the chairs call, not the editors. 4. I am not comfortable that CAP is ready for last call - I think a lot of issues were raised that are still outstandingl I know that sounds a bit harsh - but, I've seen a lot of activity but not a lot of clear decisions. If the list agrees that Doug's draft is ok as is, then I'll say last call But I don't think it's ready. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer To: "ietf-calendar@imc.org" Sent by: cc: owner-ietf-calendar@m Subject: CAP -12 and LAST CALL (hopefully) ail.imc.org 08/11/2003 03:34 PM Please respond to "ietf-calendar@imc.or g" With the addition to the typo's that people have filed using bugzilla and the ones on this list it looks as if CAP is almost ready to release. The only non-typo issue seems to be the BEEP profile. Bruce has declared twice that it has not been discusses and proposed no solution. So that responce is a dead end. If anyone (including Bruce) has a proposal or objection to the BEEP profile below - please speak up. There has been a discussion on the 1:1 and 1:many replies and the first time I sent the BEEP proposal below (apx JUL-7) there have been no responces. I do not really have any choice but to assume it is acceptable. I'll fix the typos submitted, add the BEEP profile below. This weekend (if I have time) I'll submit -12 and hopefully it will be the last WG call. There have been posts asking for issues, so obviously those asking for the issues do not have any at this time. Proposed Beep profile: As there have been no replies to my comments to the BEEP profile and after re-reading the WG archives, I will put the following into -12 (still not too late to comment on my proposal). Beep replies will be one to one (1:1 MSG/RPY) if possible and one to many (1:many MSG/ANS) when the TARGET changes. Profile Identification: specify a URI [10] that authoritatively identifies this profile. http://iana.org/beep/cap/1.0 Message Exchanged during Channel Creation: specify the datatypes that may be exchanged during channel creation. CUAs SHOULD supply the BEEP "localize" attributes in the BEEP "greeting" messages. CSs SHOULD supply the BEEP "localize" attributes in the BEEP "greeting" messages. CUAs SHOULD supply the BEEP "serverName" attribute at channel creation time to the CS so that if the CS is performing virtual hosting the CS can determine the intended virtual host. CSs that do not support virtual hosting may ignore the BEEP "serverName" attribute. Messages starting one-to-one exchanges: specify the datatypes that may be present when an exchange starts. The initial message each direction MUST BE single "text/calendar" object containing a CAP "CAPABILITY" CMD and must not be part of a MIME multipart message. After the initial message then a BEEP "MSG" may contain one or more MIME objects at least one of which MUST be "text/calendar" and at least one "text/calendar" MIME object MUST contain a CAP "CMD" property. The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "MSG" so long as all of the "text/calendar" CAP objects have the same "TARGET" property value. Messages in positive replies: specify the datatypes that may be present in a positive reply. After the initial message then a BEEP "RPY" may contain one or more MIME objects at least one of which MUST be "text/calendar" and at least one "text/calendar" MIME object MUST contain a CAP "CMD" property. All "text/calendar" MIME objects in a single BEEP "RPY" messages MUST have the same "TARGET" property value. The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "RPY" so long as all of the "text/calendar" CAP objects have the same "TARGET" property value. Messages in negative replies: specify the datatypes that may be present in a negative reply. Any valid "text/calendar" MIME object that contains CAP "REQUEST-STATUS" property and a CAP "CMD" property with a property value of "REPLY". And where the CS has determined the requested operation to be a fatal error. And when the CS has performed NO operation that effected the contents of any part of the CS or any calendar controlled by the CS. Messages in one-to-many exchanges: specify the datatypes that may be present in a one-to-many exchange. After the initial message then a BEEP "MSG" may contain one or more MIME objects at least one of which MUST be "text/calendar" and at least one "text/calendar" MIME object MUST contain a CAP "CMD" property. The BEEP "MSG" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "MSG" so long as all of the "text/calendar" CAP objects have the same "TARGET" property value. The BEEP "RPY" messages can only contain MIME "multipart" MIME objects if the other endpoint has received a CAP "CAPABILITY" indicating the other endpoint supports multipart MIME objects. This does not prevent the endpoint from sending multiple "text/calendar" MIME objects in a single BEEP "ANS" so long as all of the "text/calendar" CAP objects in EACH BEEP "ANS" message have the same "TARGET" property value. Each unique "TARGET" property value per BEEP "ANS" message. Message Syntax: specify the syntax of the datatypes exchanged by the profile. They are CAP "text/calendar" MIME objects as specified in this memo. Message Semantics: specify the semantics of the datatypes exchanged by the profile. As defined in this memo. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Mon Aug 11 15:59: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 PAA03178 for ; Mon, 11 Aug 2003 15:59:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJq8qt069179 for ; Mon, 11 Aug 2003 12:52:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BJq8lU069178 for ietf-calendar-bks; Mon, 11 Aug 2003 12:52:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BJq7qt069162 for ; Mon, 11 Aug 2003 12:52:07 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F33F203.2040309@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 15:45:55 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 03:52:01 PM, Serialize complete at 08/11/2003 03:52:01 PM Content-Type: multipart/alternative; boundary="=_alternative 006C547285256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C547285256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug wondered on 08/08/2003 02:54:59 PM: > So - HOW DO YOU DISAMBIGUATE IT FROM AN UPDATE TO A MISSED OBJECT > AS IT LOOKS EXACTLY THE SAME ? iTIP tells you exactly how. Lets start with Section 2.1.5 Message Sequencing since this is a sequencing problem: To maximize interoperability and to handle messages that arrive in an unexpected order, use the following rules: 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. 2. The secondary key for referencing a component is the "SEQUENCE" property value. For components where the "UID" is the same, the component with the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values. This helps you detect ordering problems if you apply it correctly for all Section 3 methods. Section 3.2.2 REQUEST has: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. As such if you NEVER EVER saw any previous UID / RECURRENCE-ID REQUESTs you treat it for what it is, an invitation. SO WHAT if its actually the reschedule REQUEST that you got out of order; its new to you so its an invitation. You as a recipient have NO way to know if this is the 1st or 10th or 1006th REQUEST that the Organzier sent to you; to you its new so its an invitation. If the other REQUESTs come out of order too (ie: in reverse order) then so what?!! They are obsolete compared to the version you treated as an invitation so they do not matter any more! Toss em away and get on with your life. Of course you cant do that if your primary keys value changes though can you?... Section 3.2.2.1 Rescheduling an Event covers how to distingush a reschedule from the invitation and Section 3.2.2.2 Updating or Reconfirmation of an Event covers how to distinguish non-rescheduling updates from the other possible meanings of the REQUEST. You seem to think that the ordering of iTIP messages implys some kind of semantic interpreation on the receiving end. This is NOT true. The senders exactly meaning for the REQUEST is NOT conveyed in the iTIP message, at least where REQUEST is concerned. iTIP says that the meaning is derived based on the values of UID / [RECURRENCE-ID when repeating instances are involved] / SEQUENCE "are used to distinguish the various uses of the "REQUEST" method.". If you simply take the prose of UID / SEQUENCE alone then you are totally ignoring iTIP Section 2.1.5 when constructing your keys for searching and indentification. Ive said it before and Ill say it again, the reason that each and every instance of "UID" does not say "UID" (or "UID" and "RECURRENCE-ID" when referencing an instance of a repeating set)" was that we use that term in many places and putting in such quialifications into every Section 3 text would have resulted in lots of bloat compared to putting it into the guidelines under 2.1.5 that apply to all messages (since all messages need to be sequence conscious). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... Warning: Dates in Calendar are closer than they appear. --=_alternative 006C547285256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug wondered on 08/08/2003 02:54:59 PM:
> So - HOW DO YOU DISAMBIGUATE IT FROM AN UPDATE TO A MISSED OBJECT
>       AS IT LOOKS EXACTLY THE SAME ?
iTIP tells you exactly how.  Lets start with Section 2.1.5 Message Sequencing since this is a sequencing problem:

   To maximize interoperability and to handle messages that arrive in an
  unexpected order, use the following rules:

  1.  The primary key for referencing a particular iCalendar component
      is the "UID" property value. To reference an instance of a
      recurring component, the primary key is composed of the "UID" and
      the "RECURRENCE-ID" properties.

  2.  The secondary key for referencing a component is the "SEQUENCE"
      property value.  For components where the "UID" is the same, the
      component with the highest numeric value for the "SEQUENCE"
      property obsoletes all other revisions of the component with
      lower values.

This helps you detect ordering problems if you apply it correctly for all Section 3 methods.  Section 3.2.2 REQUEST has:

   The "UID" and "SEQUENCE" properties are used to distinguish the
  various uses of the "REQUEST" method. If the "UID" property value in
  the "REQUEST" is not found on the recipient's calendar, then the
  "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
  property value is found on the recipient's calendar, then the
  "REQUEST" is for a rescheduling, an update, or a reconfirm of the
  "VEVENT" calendar component.

As such if you NEVER EVER saw any previous UID / RECURRENCE-ID REQUESTs you treat it for what it is, an invitation.  SO WHAT if its actually the reschedule REQUEST that you got out of order; its new to you so its an invitation.  You as a recipient have NO way to know if this is the 1st or 10th or 1006th REQUEST that the Organzier sent to you; to you its new so its an invitation.  If the other REQUESTs come out of order too (ie: in reverse order) then so what?!!  They are obsolete compared to the version you treated as an invitation so they do not matter any  more!  Toss em away and get on with your life.  Of course you cant do that if your primary keys value changes though can you?...

Section 3.2.2.1 Rescheduling an Event covers how to distingush a reschedule from the invitation and Section 3.2.2.2 Updating or Reconfirmation of an Event covers how to distinguish non-rescheduling updates from the other possible meanings of the REQUEST.

You seem to think that the ordering of iTIP messages implys some kind of semantic interpreation on the receiving end.  This is NOT true.  The senders exactly meaning for the REQUEST is NOT conveyed in the iTIP message, at least where REQUEST is concerned.  iTIP says that the meaning is derived based on the values of UID / [RECURRENCE-ID when repeating instances are involved] / SEQUENCE "are used to distinguish the various uses of the "REQUEST" method.".  If you simply take the prose of UID / SEQUENCE alone then you are totally ignoring iTIP Section 2.1.5 when constructing your keys for searching and indentification.  

Ive said it before and Ill say it again, the reason that each and every instance of "UID" does not say "UID" (or "UID" and "RECURRENCE-ID" when referencing an instance of a repeating set)" was that we use that term in many places and putting in such quialifications into every Section 3 text would have resulted in lots of bloat compared to putting it into the guidelines under 2.1.5 that apply to all messages (since all messages need to be sequence conscious).  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Warning: Dates in Calendar are closer than they appear.

--=_alternative 006C547285256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 16:39: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 QAA05427 for ; Mon, 11 Aug 2003 16:39:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BKSNqt072860 for ; Mon, 11 Aug 2003 13:28:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BKSN79072859 for ietf-calendar-bks; Mon, 11 Aug 2003 13:28:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BKSMqt072852 for ; Mon, 11 Aug 2003 13:28:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BKSEEB003708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 13:28:19 -0700 Message-ID: <3F37FC58.30406@Royer.com> Date: Mon, 11 Aug 2003 14:28:08 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050409090003010101040308" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050409090003010101040308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wondered on 08/08/2003 02:54:59 PM: > > So - HOW DO YOU DISAMBIGUATE IT FROM AN UPDATE TO A MISSED OBJECT > > AS IT LOOKS EXACTLY THE SAME ? > > iTIP tells you exactly how. Lets start with Section 2.1.5 Message > Sequencing since this is a sequencing problem: The section you quoted does NOT show how to tell if you missed the first object. Without the new method you propose for adding an attendee, it is possible to use the text you site to differentiate. With your proposal then ANY object with a RECURRENCE-ID could be considered an update to a missed object, or a new object. What is the justification for creating a new way to add an ATTENDEE? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050409090003010101040308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIwMjgwOFowIwYJKoZIhvcNAQkEMRYEFHu6YbiD 2qRXH5gtlhBUhEs4+7Y6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAAHLs33qO/Bh4O5Hz4BRSCpxSBIZqjsjZ+mSq1+LPsIMYKjRrUXe N1D6LHLP3AhxknzAzp5F7mzUAm5PlSVx7jrWPHJBM7K2qlQA9uxk6gQsjLPTNpImELKDxbuj 0hj8Mfs0oWruWKCBZ2fGaFIDnXVQ1OS5rp26YIYuwA39sGXANpbc3bIcly3TVz5ETOgCIzBI qe1jsDGnCs9DA1xgqmqSTfd8nnJ8+hAwqQoJZSXiulZFwZNyHjpX4nm7/sAEVV4o4/lcNoLS /7cZNk1bkDGFsiXPmTlbhoH+u3S7R9RfCTIY86GKgefJNnKWHgnDW0f1ugXw7PgHp33Z6/PW NIYAAAAAAAA= --------------ms050409090003010101040308-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 16:43: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 QAA05511 for ; Mon, 11 Aug 2003 16:43:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BKYsqt073168 for ; Mon, 11 Aug 2003 13:34:54 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BKYsfE073167 for ietf-calendar-bks; Mon, 11 Aug 2003 13:34:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BKYrqt073162 for ; Mon, 11 Aug 2003 13:34:53 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BKYqEB003773 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 13:34:54 -0700 Message-ID: <3F37FDE7.7010000@Royer.com> Date: Mon, 11 Aug 2003 14:34:47 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP -12 and LAST CALL (hopefully) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070206070508000704040700" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070206070508000704040700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > Doug: > 1. The chairs make the Last Call statement - not the editors. Good thing I put 'hopefully' on the subject line :-) > 2. I think there are a lot more issues on the list that are not addressed > in what you have put in CAP 12. Such as? > 3. Saying that no one responding to a comment by Bruce stops the issue is > the chairs call, not the editors. I did not say no one responded to Bruce (and I did and I was the only one that did), I said: Bruce has declared twice that it has not been discusses and proposed no solution. > 4. I am not comfortable that CAP is ready for last call - I think a lot of > issues were raised that are still outstanding. Such as? > I know that sounds a bit harsh - but, I've seen a lot of activity but not a > lot of clear decisions. If the list agrees that Doug's draft is ok as is, > then I'll say last call But I don't think it's ready. There has been a lot of 'iCal-version-next'. And for CAP a lot of questions and answers, and updated text to clarify, but there have not been any 'I think that is broke' or like emails on CAP for a while. The VFREEBUSY text is in -11 and there have been NO counter proposals. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070206070508000704040700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIwMzQ0N1owIwYJKoZIhvcNAQkEMRYEFCxvfdTa SHbZHyvZmLixJV2gzztyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJp/CiiG1KQO19Ct7Lkvx7WwEuRaTU1hMLULlzTffH8+W46YmGUq 6XmiLAZisS5DA3iMEBSFEQjFjd4DCtLCvMA33iIbBOgmly4T4USKMrKgIxbrQp2f1pYe6Zap v5BY9Kgnivu6J1i4ajIMkHkgjeJNRTKvnhG6q52S5ezEpRWA4Dy2bGXdsmrGEzzcz4h1Va0Z zokhbw/1SLSNbAtBipmraoWX2v1t91iTpWw4vkFMN4yoJ3MrkeENvqBJ+Eavv1yZm80gl2qB poPD2NzAGc7Hs6ttSho/T2RGf+o60ETJGLi8Yf8iNQ/hj/paP6B+sdRX9V7YFs76GLr2cEDR r2UAAAAAAAA= --------------ms070206070508000704040700-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 17:08:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06555 for ; Mon, 11 Aug 2003 17:08:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BKwlqt074224 for ; Mon, 11 Aug 2003 13:58:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BKwkfU074223 for ietf-calendar-bks; Mon, 11 Aug 2003 13:58:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BKwkqt074214 for ; Mon, 11 Aug 2003 13:58:46 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F37EFE0.9050503@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP -12 and LAST CALL (hopefully) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 16:54:26 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 04:58:36 PM, Serialize complete at 08/11/2003 04:58:36 PM Content-Type: multipart/alternative; boundary="=_alternative 00729A5E85256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00729A5E85256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 08/11/2003 03:34:56 PM: > With the addition to the typo's that people have filed using bugzilla > and the ones on this list it looks as if CAP is almost ready > to release. I have yet to see the diffs document for the last change that were promised a while ago. Will there be one? If not, will there be one for CAP 10 -> 12? Also will there be some due diligence in addressing the issues already raised in the WG list over the past few months? I would have expected the issues to be logged by the current author(s) as they were raised so we could be sure they were addressed. Making them get reraised to be addressed before Last Call seems like an attempt to sweep them under the rug if someone does not speak up _again_... Examples of recenty issues: The issue of searching scoping was raised and once the issue was clear to everyone there was no discussion on resolving it. The issue of busytime lookups and maintenance was rasied and I proposed a change but I dont know if it got into CAP 11 or the pending 12. I had noted that only the CREATE command had the ability in the ABNF to actually use a VQUERY but I dont know if it was addressed in CAP 11 or the pending 12. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00729A5E85256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 08/11/2003 03:34:56 PM:
> With the addition to the typo's that people have filed using bugzilla
> and the ones on this list it looks as if CAP is almost ready
> to release.
I have yet to see the diffs document for the last change that were promised a while ago.  Will there be one?  If not, will there be one for CAP 10 -> 12?

Also will there be some due diligence in addressing the issues already raised in the WG list over the past few months?  I would have expected the issues to be logged by the current author(s) as they were raised so we could be sure they were addressed.  Making them get reraised to be addressed before Last Call seems like an attempt to sweep them under the rug if someone does not speak up _again_...

Examples of recenty issues:

The issue of searching scoping was raised and once the issue was clear to everyone there was no discussion on resolving it.

The issue of busytime lookups and maintenance was rasied and I proposed a change but I dont know if it got into CAP 11 or the pending 12.

I had noted that only the CREATE command had the ability in the ABNF to actually use a VQUERY but I dont know if it was addressed in CAP 11 or the pending 12.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00729A5E85256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 17:25: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 RAA07037 for ; Mon, 11 Aug 2003 17:25:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLG5qt075222 for ; Mon, 11 Aug 2003 14:16:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BLG5MJ075221 for ietf-calendar-bks; Mon, 11 Aug 2003 14:16:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLG1qt075215 for ; Mon, 11 Aug 2003 14:16:02 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mK2a-0000id-00 for ; Mon, 11 Aug 2003 23:17:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mK2a-0000iV-00 for ; Mon, 11 Aug 2003 23:17:20 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mK1J-0001Wg-00 for ; Mon, 11 Aug 2003 23:16:01 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 14:15:00 -0700 Lines: 380 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> 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: For an analysis of why the fixed-id does not create an infinite loop see the end of the post. > However, at the very end, there is an unsupported statement: > > > Since the sender is an ATTENDEE of the instance component > > only, it is only authorized to receive replies for that > > singleton component. As a consequence, the ORGANIZER's > > CUA should not send the requested response. > > This is not supported by the RFC paragraph quoted. 6.1.7 talks about a > REFRESH request from someone not an attendee to the event. > If an event consists of multiple instances, the fact that an > attendee is invited to only one of them does not exclude her > from the set of attendees! An Organizing CUA that is capable > of sending a single instance of an event to an attendee > without generating a new UID (which it could easily do), is > surely capable of forming a response that only includes those > instances to which that attendee is invited. First, UID is one event, UID/RECURRENCE-ID is a different event. In the UID only properties of the event the CU is not list as an ATTENDEE and can never be listed as an ATTENDEE lest they be invited to all instances of the recurring event. So therefore 6.1.7 stands as used. The ORGANIZER receives a REFRESH request for UID only. The CU isn't an ATTENDEE of that event. The only way this might be possible if you fragment the event to make two versions of the same UID, one for the ATTENDEE and another for every one else. Which leads me to second, this violates the mandate that a UID be globally unique. You now have two objects of different forms with the same UID and no other iTIP compliant disambiguating values. As just an example of one case where this is a sever issue, let's say that the ATTENDEE sent a COUNTER response. In your model they will have received an object with a UID and no RECURRENCE-ID. At best it will be a recurring event with only one RDATE, at worst it will just be a singleton. Using the best case scenario the CUA might send a COUNTER to just the individual instance in which case you lucked out. Also using the best case scenario the CUA might detect that the CU wants to reschedule every instance of the event (since there is only one instance described in the event) and send a COUNTER to the UID only component with a new RDATE. Using the worst case scenario, the CUA will send a COUNTER message to the UID only event trying to turn it into a singleton at a new time. In anything but the best case scenario with some luck, they will be sending a COUNTER message that attempts to redefine the original recurring event. No where in the RFCs does it ever instruct an ORGANIZER's CUA to track independent versions of the same event for different ATTENDEES. And in fact it actually says in both iCal and iTIP that you can't do that. They say this both explicitly and implicitly every time they talk about global uniqueness, updating a master copy (not copies) over which only the ORGANIZER has rights to, and that they expect CUs will pass these objects around to each other for purposes of delegation and FYI (as indicated by the reference to a "Party Crasher" which the ORGANIZER never invited). As two other examples of where your model breaks apart we have 3.2.2.3 Delegating to another CU and 3.2.2.6 Forwarding to an uninvited CU. Let's use two different people, A and B, who are invited to separate instances of a recurring event. In your model, they each will have received an object with no RECURRENCE-ID which describes a single different date and time. If B decides they can't make it, and wants to delegate to A, or they decide they think A should be invited as well, A's CUA will be totally confused about the message. The message from B describes an event which it has on its calendar, but has a different primary key. It will have to apply the message SEQUENCING rules and if the SEQUENCE number doesn't catch the DTSTAMP value will certainly place the incoming message as either an old message or one that looks like an update that didn't come from the ORGANIZER. Assuming that A's CUA was ultra brilliant and managed to figure out what was going on it now has the responsibility of sending a REPLY to the ORGANIZER. How will the ORGANIZER unambiguously know what's going on? In the case of delegation, because B has to send a REPLY to the organizer as well as A, it will be possible for the ORGANIZER's CUA to figure out that it should be expecting something from A that has an event which is actually B's event merged with A's event (where in the RFC's does _ever_ talk about merging events), _if_ it magically on its own accord receiving no instruction from the RFCs also treats the ATTENDEE as part of the primary key for an event. In the case of B just extending the invite to A, A's reply when put through the message sequencing rules is just going to look very strange. First, just following the iTIP rules there should only be one version of the same object at any given time, your model extends the primary key to include the ATTENDEE, but even then how is the ORGANIZER's CUA supposed to figure out what just happened. It's totally ambiguous as to what the content of the REPLY is actually going to be... A had an original version of the UID object, B invited A to a different version of the same object which rather than throwing it out as a missequenced message or an update from someone other than the organizer it decided to treat as an invite to a separate instance of a recurring event (why and how it did this I have no clue, I'm just trying to make your model fit the reality of what needs to happen here). At this point A must formluate a reply to the ORGANIZER, but I can't for the life of me figure out what it should be. "A" might have two singleton events with differing versions which it now merges (despite all the confusion this causes), to construct a single recurring event with two instances. I guess it sets the SEQUENCE and DTSTAMP fields to the values from the "most recent" singleton and just prays that's the right answer.... "A" might have two recurring event descriptions which each describe a different single instance which it again must merge (despite all the glaring violations this causes especially of 6.1.7). Again, I guess the SEQUENCE and DTSTAMP should just be set to the values of the "most recent" object. This model gets so convulated when the messages get passed around because it is in total violation of the assumption of the authors. That there would be _one_, globally unique, uniquely identifiable object that could be distributed across the Internet without confusion. The only thing they then had to do was figure out how to version the objects so that CUAs could figure out if what they were looking at was an older or more recent version of the event which brought about SEQUENCE and DTSTAMP. They then associated different semantics to each. Updating SEQUENCE means something that would violate the partstat field of the ATTENDEES and DTSTAMP was any for any other non-triggering update. So assuming you're still reading at this point, I'll go on. > > It should > > go through the recurrence set and send a reply for all > > instances that the ATTENDEE has been invited to, but > > this will be one iTIP message with multiple VEVENT > > components that each have a RECURRENCE-ID. Not one > > component with a UID that matches the original component > > that the ATTENDEE was not invited to and no RECURRENCE-ID. > > Why not? Because to do it any other way would either violate the global uniqueness of the UID or imply the CU was invited to event instances that it wasn't. > Nothing > in the RFCs I've read suggest that this is what MUST happen, > nor even that it SHOULD. You're right. There is nothing in the RFCs that talks directly about this. There is no example of inviting an ATTENDEE to a single instance. There is only the document that should be internally consistent enough to indicate how this should be done. Sadly, it unfortunately isn't, as we both have enough evidence from the text to defend two very different standpoints. We have to resort to figuring what the chain of messages in each model will be to figure out which one holds more water within the text as a whole. I also never implied that it MUST do this. In fact, I very explicitly said that it had every right just to drop the message on the floor. The original recurring event is a globally unique entity in its own right as must be each instance of it. Otherwise CUs passing around messages to each other (which they are explicitly granted the right to do) will confuse both each other's and the ORGANIZER's CUA. I simply said that the most useful interpretation of that REQUEST is to send a response that included all instances of the event that the CU was invited to and therefore that's what the ORGANIZER's CUA should do. > This seems like a lot of trouble to go to, and while it may be > necessary to send such a set of VEVENT objects if one subscribes > to the 'RECURRENCE-ID fixed at SEQ:0' dogma, it is not necessary > in the 'current-value' interpretation, and both would require > that a VEVENT object be sent w/o a RECURRENCE-ID at some point, This last part isn't actually true. The fixed-id model never requires a UID without a RECURRENCE-ID object to be consistent. I will finish out what the CUA does with the response it gets from the intelligent ORGANIZER which contained a copy of every instance it was invited to with all objects containing a RECURREINCE-ID and no object without one. The recipient CUA would follow the rules as outlined in 2.1.5 Message Sequencing, and 3.2.2 REQUEST for each object. As such it would go through each instance one by one, and assuming that it had not missed any other messages it would find that it found every object referenced and all the SEQUENCE numbers for each object matched. At this point it stops. It processed the entire message and had no problems identifying any of the objects being referenced. If it had missed any messages, then at least one of the SEQUENCE numbers would be wrong, and section 4.7.2 Bad RECURRENCE-ID would apply which for the dumb recurring event CUA would cause one last REFRESH cycle (which I agree is wasteful). For the smarter CUA it could use the fact that it has already sent a REFRESH once, it has received a message that conatins objects of which it found every one and would assume that it was not invited to the base UID onnly event and not do the REFRESH cycle again. This creates the following semantics: The CUA will send a REFRESH to the ORGANIZER only when it receives a message for an object with a UID that it cannot find or the SEQUENCE for any particular instance jumps more than 1 point. This means that it will only send a REFRESH the first time it is invited to its first instance of that recurring event, or when one of the instances jumps more than one SEQUENCE number. This will at worst cause one and only one REFRESH/REQUEST cycle, lest more missed messages are introduced into the queue. > 'current-value' semantics for RECURRENCE-ID are simple, consistent, > error-reistant, and require less bookkeeping and fewer messages. > The fact that reading the RFCs and using common definitions for > 'original' and 'change' supports this view is just gravy, IMHO. Ok, let's try and follow that "error resistant" train. First, from above I've shown you why it is a total violation of the intent of global uniqueness, and the real world problems with versioning a UID per ATTENDEE. Now let's talk about the presence of missed messages. First, let's just say we're talking about very normal activity where we invite everyone to every meeting. Let's call SEQ:0 "every Monday for this year". Every responds in the affirmative that they will attend. The ORGANIZER, just being nice, sends an update to inform everyone of the new ATTENDEE status changes. Now let's say we add a comment to the first instance. For arguments sake we'll say it says '1st instance'. This forces the CUA to track some per instance info for this event which it must persist. This sends an update to the attendees with RID:1st Monday and SEQUENCE:0 that sets the comment. No big deal. So now we move the 1st instance to Tuesday due to some major failure the message gets delayed and no one receives it and the ORGANIZER isn't aware so doesn't resend it. In the 'current-value' model the official SEQUENCE on the ORGANIZER's calendar is now 1 and the official RID is now "1st Tuesday". There is an inconsistency on the CUs calendar as they have SEQUENCE:0 and RID:1st Monday. So now we move the same instance again to Wednesday. This RID:1st Tuesday and SEQUENCE:2 There is no failure and everybody gets this message. Everybody now receives a message for RID:1st Tuesday which none of them have, to now be 1st Wednesday. Given sections 2.1.5 and 3.2.2 the CUA must put this on the calendar as a new invitation. This means they now have two meetings scheduled. The original Monday version at SEQUENCE:0 and the new Wednesday version at SEQUENCE:2. There is nothing in the RFC that says they have to do anything further at this point. Dumb CUAs will just let it sit there. Smarter CUAs will notice the inconsistency and ask for a REFRESH. This is what the CUA should do, but it doesn't have to. Let's say that before the REFRESH answer arrives, the delayed message shows up. Since in this model there is only one SEQUENCE value that all instances share, and it's lower than the most recent value we've seen for that UID. We throw the update out. It's old and no longer valid. If however the 'current-value' model concedes that each instance tracks its own SEQUENCE as section 3.7.1 dictates, then it process the message as an update to the 1st Monday instance. This still creates the wrong situation where there are two events in the first week, one now on either Monday or Tuesday depending on whether or not you processed the message and one on Wednesday. So now the response to the REFRESH shows up. The only valid response it could be in this model is one where it has rescheduled the set to be every Monday this year, except the 1st Monday, and an RDATE of 1st Wednesday with the SEQUENCE set to "2". This makes the CUA touch every instance of the recurring event for which it has per instance data and update the persisted SEQUENCE value to 2. Finally it has this now bogus event on its calendar at Monday or Tuesday depending on how you processed it and so it must delete it since it's not listed in the master UID object. In the presence of missed or delayed messages the 'current-value' model must live with invalid calendars until a full copy of the most recent information arrives. In the fixed-id model missed messages only result in dealing with older, but at one time valid data. Redoing this same example with the fixed-id model we get the following: 1) Schedule every Monday, accept it, add the comment. (no big deal) 2) Miss the Tuesday move Again CUs end up with same calendar as above. 3) Receive the Wednesday move. Since the fixed RID is still set to '1st Monday' The CUA correctly moves the Monday instance to Wednesday and updates its SEQUENCE to 2. At this point dumb CUAs who don't do anything have and keep a consistent calendar with all info they have seen to date and nothing is inconsistent with the actual view the ORGANIZER has. Smart CUAs will detect the 0 to 2 jump and ask for a REFRESH. The old "move to Tuesday" message will show up and the CUA will accurately identify it as a reference to the fixed-id '1st Monday' but with SEQUENCE:1 which is less than the 2 it currently has for that component and discard it. The response to the refresh will show up and the data it has on its calendar will exactly match what's in the message, it will do nothing and stop there. This is only a mild example of what can get screwed up using a 'current-value' model. -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Aug 11 17:33: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 RAA07300 for ; Mon, 11 Aug 2003 17:33:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLQmqt076591 for ; Mon, 11 Aug 2003 14:26:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BLQm4V076590 for ietf-calendar-bks; Mon, 11 Aug 2003 14:26:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLQlqt076584 for ; Mon, 11 Aug 2003 14:26:47 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F33F1B2.3030702@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 17:06:07 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 05:26:36 PM, Serialize complete at 08/11/2003 05:26:36 PM Content-Type: multipart/alternative; boundary="=_alternative 0073AC1685256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073AC1685256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug asked on 08/08/2003 02:53:38 PM: > Its becoming clear to me that you did not understand iTIP when you > wrote your project and you did not know that these new proposals > of yours were already covered in iTIP and we do not need new ways > to do things that are already documented. I have not proposed anything new. I have merely done an analytical analysis of the way a changing RECURRENCE-ID model would function (or misfunction) and how a fixed RECURRENCE-ID model woudl function under the rules currently in iTIP. You seem to ignore the concepts that dont fit your ideas and try to twist the rest to fit. Anyone can go and compare my analysis of BOTH models against the RFCs and confirm the results. So far you have not so Ill take that as tacit agreement that its correct. > > Its perfectly legal and valid to have a REQUEST for SEQUENCE:0 with a > > UID and RECURRENCE-ID. > > How do you disambiguate that from an update to a missed object? By the presence of the instance in your calendar. iTIP says it in Section 3.2.2 REQUEST in case you missed it the last 4+ times: If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. In the case of a repeating instance the values used would be UID / RECURRENCE-ID and not UID alone assuming you understand iTIP Section 2.1.5 Message Sequencing when it says: 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. If you find the UID / RECURRENCE-ID then you can decide if its a reschedule or an non-rescheduling update by the text in Sections 3.2.2.1 Rescheduling an Event and 3.2.2.2 Updating or Reconfirmation of an Event respectively. This is what we did in our 3 separate implementations and what Microsoft did in Outlook and Exchange so either the original authors all misinterpreted their own text and the design OR you did... I wonder which is more likely??... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0073AC1685256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug asked on 08/08/2003 02:53:38 PM:
> Its becoming clear to me that you did not understand iTIP when you
> wrote your project and you did not know that these new proposals
> of yours were already covered in iTIP and we do not need new ways
> to do things that are already documented.
I have not proposed anything new.  I have merely done an analytical analysis of the way a changing RECURRENCE-ID model would function (or misfunction) and how a fixed RECURRENCE-ID model woudl function under the rules currently in iTIP.  

You seem to ignore the concepts that dont fit your ideas and try to twist the rest to fit.  Anyone can go and compare my analysis of BOTH models against the RFCs and confirm the results.  So far you have not so Ill take that as tacit agreement that its correct.

> > Its perfectly legal and valid to have a REQUEST for SEQUENCE:0 with a
> > UID and RECURRENCE-ID.
>
> How do you disambiguate that from an update to a missed object?
By the presence of the instance in your calendar.  iTIP says it in Section 3.2.2 REQUEST in case you missed it the last 4+ times:

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

In the case of a repeating instance the values used would be UID / RECURRENCE-ID and not UID alone assuming you understand iTIP Section 2.1.5 Message Sequencing when it says:

   1.  The primary key for referencing a particular iCalendar component
      is the "UID" property value. To reference an instance of a
      recurring component, the primary key is composed of the "UID" and
      the "RECURRENCE-ID" properties.

If you find the UID / RECURRENCE-ID then you can decide if its a reschedule or an non-rescheduling update by the text in Sections 3.2.2.1 Rescheduling an Event and 3.2.2.2 Updating or Reconfirmation of an Event respectively.  

This is what we did in our 3 separate implementations and what Microsoft did in Outlook and Exchange so either the original authors all misinterpreted their own text and the design OR you did...  I wonder which is more likely??...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0073AC1685256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 18:00:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07885 for ; Mon, 11 Aug 2003 18:00:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLoaqt080202 for ; Mon, 11 Aug 2003 14:50:36 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BLoaX5080200 for ietf-calendar-bks; Mon, 11 Aug 2003 14:50:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLoYqt080191 for ; Mon, 11 Aug 2003 14:50:34 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BLoXEB004357 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 14:50:35 -0700 Message-ID: <3F380FA4.8070901@Royer.com> Date: Mon, 11 Aug 2003 15:50:28 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP -12 and LAST CALL (hopefully) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030507090307080803050007" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030507090307080803050007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 08/11/2003 03:34:56 PM: > > With the addition to the typo's that people have filed using bugzilla > > and the ones on this list it looks as if CAP is almost ready > > to release. > > I have yet to see the diffs document for the last change that were > promised a while ago. Will there be one? If not, will there be one for > CAP 10 -> 12? If I do not get to it soon, feel free to use the diff tool of your choice and post them. > Also will there be some due diligence in addressing the issues already > raised in the WG list over the past few months? I would have expected > the issues to be logged by the current author(s) as they were raised so > we could be sure they were addressed. Making them get reraised to be > addressed before Last Call seems like an attempt to sweep them under the > rug if someone does not speak up _again_... Pat has just declared on this list that the CHAIRs declare such a list, NOT the editors. Pat - do you have any open issues? > Examples of recenty issues: > > The issue of searching scoping was raised and once the issue was clear > to everyone there was no discussion on resolving it. It was addressed in CAP-11, the ABNF updates were made and I did comment in the CAP-11 announcement that no proposals were submitted. Bruce- did the updates in -11 solve the problem as you see it? > The issue of busytime lookups and maintenance was rasied and I proposed > a change but I dont know if it got into CAP 11 or the pending 12. There have been lots of VFREEBUSY posts. Your proposal said for future use: ...I suspect that anything that can be CREATEd in your queue needs to be able to get searched for so you can remove 'em, process 'em, etc. Although we dont have iMIP -> CAP designed now, it may be possible in the future (CAP creation is not the only way to get 'em into your queue essentially). I just re-read your reply and it did NOT include a proposal. Your (1) - was the reason I asked the question - when are they not useless? Your (2) - is NOT what CAP does at this time. It does not get iMIP messages. So I'll ask - why do we want to store objects in CAP when NO tool can use them? Why not add it later if need? > I had noted that only the CREATE command had the ability in the ABNF to > actually use a VQUERY but I dont know if it was addressed in CAP 11 or > the pending 12. The XML->RFC tool may be busted. It is in my XML here and it does not make it in to the TXT version, I'll hand edit CAP-12 (not from the XML source) to fix it until I can find the reason. (not sure when it got added as it did not show up in the TXT version). The missing text for SEARCH is (follows the ABNF): "The format of the request is the search command (search-cmd) followed by one or more (query) "VQUERY" components" Followed by the 'Response' section and then examples of 'SEARCH'. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030507090307080803050007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIxNTAyOFowIwYJKoZIhvcNAQkEMRYEFDkN4FiQ o+/tKJ6nx8/h00wtWPK6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBACtBuUxwC2XtaaFxhRTQRy2XI1qFfhIDL9vkbVUKWIF56f5gU6vn UMmcUZxGJQlAIhCknAYdgo5uCwEP76TOif4clGfiAWhEdD90V968SZKADHyoS3tRqQC3AHmS 4CB1sGX5ZPRjE0cFAZr73TTSCgRLiozQ+9czWBapzfOcqgMklQVZd3El09Nej2q0lyHPWKtS TbpWmesm9L48E14E0M4LgAVq2MqSmN+fDKNLiWX8i/KRJn/ehhRrFYSzjT91GFLWjXkhZCNe YpeK1iEDiw7JIckx9YvFAMcawsqX0rIjOT1GPtXcySLUaKrLiJuLEggOXpJkM+kXnltBEf7z AREAAAAAAAA= --------------ms030507090307080803050007-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 18:46: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 SAA09886 for ; Mon, 11 Aug 2003 18:46:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BMZUqt082625 for ; Mon, 11 Aug 2003 15:35:30 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BMZUJE082624 for ietf-calendar-bks; Mon, 11 Aug 2003 15:35:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BMZSqt082619 for ; Mon, 11 Aug 2003 15:35:28 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BMZREB004695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 15:35:29 -0700 Message-ID: <3F381A2A.6080900@Royer.com> Date: Mon, 11 Aug 2003 16:35:22 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060509050704010703090704" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060509050704010703090704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > For an analysis of why the fixed-id does not create an infinite > loop see the end of the post. > > >>However, at the very end, there is an unsupported statement: >> >> >>>Since the sender is an ATTENDEE of the instance component >>>only, it is only authorized to receive replies for that >>>singleton component. As a consequence, the ORGANIZER's >>>CUA should not send the requested response. >> >>This is not supported by the RFC paragraph quoted. 6.1.7 talks about a >>REFRESH request from someone not an attendee to the event. >>If an event consists of multiple instances, the fact that an >>attendee is invited to only one of them does not exclude her >>from the set of attendees! An Organizing CUA that is capable >>of sending a single instance of an event to an attendee >>without generating a new UID (which it could easily do), is >>surely capable of forming a response that only includes those >>instances to which that attendee is invited. > > > First, UID is one event, UID/RECURRENCE-ID is a different event. > > In the UID only properties of the event the CU is not list as an > ATTENDEE and can never be listed as an ATTENDEE lest they be > invited to all instances of the recurring event. So therefore > 6.1.7 stands as used. The ORGANIZER receives a REFRESH > request for UID only. The CU isn't an ATTENDEE of that event. > > The only way this might be possible if you fragment the event > to make two versions of the same UID, one for the ATTENDEE and > another for every one else. Which leads me to second, this > violates the mandate that a UID be globally unique. You now > have two objects of different forms with the same UID and no > other iTIP compliant disambiguating values. Only UID/SEQUENCE/DTSTAMP or UID/SEQUENCE/DTSTAP/RECURRECE-ID is globally unique in content, not UID by itself. And yes each of unique SEQUENCE and DTSTAMP for a UID are going to be different anyway as that is how you differentiate between the different versions of objects representing the same UID. Why would you think that the ATTENDEE property should be an exception to that? > As just an example of one case where this is a sever issue, > let's say that the ATTENDEE sent a COUNTER response. > > In your model they will have received an object with a UID and > no RECURRENCE-ID. At best it will be a recurring event with > only one RDATE, at worst it will just be a singleton. > Using the best case scenario the CUA might send a COUNTER > to just the individual instance in which case you lucked out. > Also using the best case scenario the CUA might detect that > the CU wants to reschedule every instance of the event (since > there is only one instance described in the event) and send > a COUNTER to the UID only component with a new RDATE. Using > the worst case scenario, the CUA will send a COUNTER message > to the UID only event trying to turn it into a singleton at > a new time. The ORGANIZER CUA can tell because the ATTENDEE sends what they want DIFFERENT than what they were sent. If the ATTENDEE does not include (because they did not get) an recurrence rule. No problem. Then they are COUNTERing the one instance. If an ATTENDEE removed any recurrence rule it is sent then the ATTENDEE would be telling the ORGANIZER they wish to remove the additional instances. No conflict. > In anything but the best case scenario with some luck, they > will be sending a COUNTER message that attempts to redefine > the original recurring event. No where in the RFCs does it > ever instruct an ORGANIZER's CUA to track independent versions > of the same event for different ATTENDEES. The ORGANIZER CUA will already have to know what each ATTENDEE was invited to - simply compare what they were invited to attend with what they send, mask out what they were not invited to and any difference is their COUNTER proposal. In my experience there are always going to be exceptions to invitations. Customers cancel meeting and reschedule them all of the time. Reservations are continually changed and canceled. I would hate to think that 100% of all attendees would need to see all of the changes for 100% of all of the other attendees. And as they are not all required to see all of the other attendees, there ARE unique to ATTENDEE packets. Yes - there is going to have to be attendee specific packets sent. And because iTIP says: Hence, CUAs must persist the following component properties: "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" and "DTSTAMP" property values associated with the "Attendee's" response. And as the ORGANIZER CUA *will* know what they were invited to and what they REPLYed to and could be countering. I do not see a problem. > And in fact it > actually says in both iCal and iTIP that you can't do that. > They say this both explicitly and implicitly every time they > talk about global uniqueness, updating a master copy (not > copies) over which only the ORGANIZER has rights to, and > that they expect CUs will pass these objects around to each > other for purposes of delegation and FYI (as indicated by > the reference to a "Party Crasher" which the ORGANIZER > never invited). The over the wire protocol is not the same as the object itself. The object itself is undefined because of the different models for calendaring and scheduling. What works for a car rental agency will not work for a massive company. iCAl/iTIP specify how to transfer the data, they are not the booked object itself. > > As two other examples of where your model breaks apart we > have 3.2.2.3 Delegating to another CU and 3.2.2.6 Forwarding > to an uninvited CU. Let's use two different people, A and B, > who are invited to separate instances of a recurring event. > In your model, they each will have received an object with > no RECURRENCE-ID which describes a single different date > and time. If B decides they can't make it, and wants to > delegate to A, or they decide they think A should be invited > as well, A's CUA will be totally confused about the message. Why? > The message from B describes an event which it has on its > calendar, but has a different primary key. Why? Will the UID/SEQUENCE/DTSTART be changed before forwarding to 'B'? No, so where is the problem? > It will have to > apply the message SEQUENCING rules and if the SEQUENCE number > doesn't catch the DTSTAMP value will certainly place the > incoming message as either an old message or one that looks > like an update that didn't come from the ORGANIZER. Who cares where it came from? It is valid or not. If your are the delegatee, then process it. > Assuming that A's CUA was ultra brilliant and managed to > figure out what was going on it now has the responsibility > of sending a REPLY to the ORGANIZER. How will the ORGANIZER > unambiguously know what's going on? Because of 'SENT-BY', 'DELEGATED-FROM', 'DELEGATED-TO' and perhaps more. The object will be tagged (if compliant) and the ORGANIZER will parse the object sent from B. The ORGANIZER matches them up to what the ORGANZIER sent to 'DELEGATED-TO' as recieved from the original ATTENDEE. And from iTIP: Cut from iTIP, A == ORGANIZER, 'C' = ATTENDEE delegator and 'E' == delegatee, my comments in (). "C" got a REQUEST from "A". "C" sends a REPLY to "A" with the ATTENDEE. "partstat" parameter set to "delegated" and with a new "ATTENDEE" property for "E". "E's" ATTENDEE delegated-from" param is set to "C". (that how ORGANIZER knows) "delegated-from" param is set to "C". "C's" ATTENDEE "delegated-to" param is set to "E". "C" sends REQUEST message to "E" with the original meeting request information. The "partstat" property parameter for "C" is set to "delegated" and the "delegated-to" parameter is set to the address of "E". An "ATTENDEE" property is added for "E" and the "delegated-from" parameter is set to the address of "C". ... > ...cut... (I'll respond to the other points in separate email) > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060509050704010703090704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIyMzUyMlowIwYJKoZIhvcNAQkEMRYEFOIl9fJl 5UIfeekN3JzI7QdvLA1eMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBABXdHrXdKulWbP1LgqRmjclpgkcvs9Z42xX1/qlHsR/DDqAl6fKM z1dhYkyGGaUCf3phXmZoTFvqTNbLcjD7NpZW2JvkUOMTpCa7PfXV5ylxHMwgCqx37feHMvoN GC0LlpF7QIwnmzpE9RIVJ4uAliG+XRUjYR+B+DAFZ+5ugHwcyDSaqG9MeV4Xvq+Q4hP2wlKd zgwCeFCGhg+XKqnnPmLS0Slt7ptpLC3ZNudYBfhmEtZS7/YuvDkhiihZQdg1gK5N4HaFJmpw 2Bd/JLUq6QEQ6/iGvfXpI697+bdHBOBgBWOmQAtlYIRhSolwCxcgtOvDqVlhJ/KXLe9v8fPD GywAAAAAAAA= --------------ms060509050704010703090704-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 18:54: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 SAA10046 for ; Mon, 11 Aug 2003 18:54:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BMkiqt082947 for ; Mon, 11 Aug 2003 15:46:44 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BMkiBP082946 for ietf-calendar-bks; Mon, 11 Aug 2003 15:46:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BMkfqt082941 for ; Mon, 11 Aug 2003 15:46:42 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mLSL-0001Na-00 for ; Tue, 12 Aug 2003 00:48:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mLSK-0001NS-00 for ; Tue, 12 Aug 2003 00:48:00 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mLR4-0003fl-00 for ; Tue, 12 Aug 2003 00:46:42 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 15:45:37 -0700 Lines: 117 Message-ID: References: <3F37FC58.30406@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:3F37FC58.30406@Royer.com... > > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > Doug wondered on 08/08/2003 02:54:59 PM: > > > So - HOW DO YOU DISAMBIGUATE IT FROM AN UPDATE TO A MISSED OBJECT > > > AS IT LOOKS EXACTLY THE SAME ? > > > > iTIP tells you exactly how. Lets start with Section 2.1.5 Message > > Sequencing since this is a sequencing problem: > > The section you quoted does NOT show how to tell if you missed the first > object. Without the new method you propose for adding an attendee, > it is possible to use the text you site to differentiate. With your > proposal then ANY object with a RECURRENCE-ID could be considered > an update to a missed object, or a new object. Actually that's not true. This is only true in the case where the original recurrence description object (the one without the RECURRENCE-ID) has not ever been seen. If I've ever seen that object, then it will tell me what all the possibly valid RECURRENCE-IDs are. For instance, SEQ:0 of the object describes every Friday. If I've received that message then I know that the recurring event instances will all have RECURRENCE-IDs on Friday. So if I ever receive an object that has that UID, but doesn't have a RECURRENCE-ID on Friday I know something went wrong. Assuming no one is just trying to be mean and inserting bad data, it means that my copy of the orginal UID object is out of date, and needs to be refreshed. This post does bring up a good point though. There might be a situation where the model as I've presented it has the same problems that the 'current-value' model constantly suffers from. However, it also might just be my misinterpretation of when and how a RECURRENCE-ID might change. To cause the problem it requires both an invitation to a single instance, and a complete rescheduling of the entire set of instances. However, anyone who has more knowledge of how this is handled and can tell me how I'm misintrepreting what goes on here is encouraged to please chime in. Here's the situation: Assuming a simple every Friday meeting of which no instances have been touched. We're at SEQ:0 and all RID's are Friday. I invite someone to a single instance using: UID:1 RID:Some Friday SEQ:0 They've never seen the parent UID:1 and thereofore have no way to know what is a valid RID and not. They do the Refresh thing and get back just the single instance they've been invited to. I then reschedule the entire series from Friday to Thursday which updates SEQUENCE for the UID and moves all the RIDs to Thursdays. I then try and send the ATTENDEE the update. According to my original methodology I wouldn't be able to send them the "move to Thursdays" update because they weren't invited. I would send them the new updated invite with a Thursday RID with which the CUA wouldn't be able to locate an instance on its calendar. This would be treated as a new invite to a separate instance and not a rescheduling of the first. Noticing the SEQUENCE jump for this instance it should send a refresh. The ORGANIZER will respond with a description of only one VEVENT that references the new Thrusday instance and says nothing about the old Friday instance and the CUA will be stuck having two instances on its calendar. The 'current-value' camp relies on violating the global uniqueness requirement of the event UID to get around this problem. It would have sent a version of the event without a RECURRENCE-ID that described only the instance that the CU was invited to. If the fixed-id camp wanted to, it could violate the global uniqueness requirement too and in exact same way and get the same level of clarity that the 'current-value' model has to resolve the issue. The CUA would get an event that had the parent UID and it would describe the Thursday in question but not the Friday in question and the CUA could drop the Friday occurence. But this violates the global uniqueness property of the UID used and cause all kinds of other madness I outlined above.... I'm leaving it unresolved for now until someone with more wisdom than I can paint a consistent model where this can be done. -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Aug 11 18:54: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 SAA10066 for ; Mon, 11 Aug 2003 18:54:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BMkOqt082933 for ; Mon, 11 Aug 2003 15:46:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BMkOrK082932 for ietf-calendar-bks; Mon, 11 Aug 2003 15:46:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BMkNqt082927 for ; Mon, 11 Aug 2003 15:46:23 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F33FBF6.2060201@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 18:24:43 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 06:46:08 PM, Serialize complete at 08/11/2003 06:46:08 PM Content-Type: multipart/alternative; boundary="=_alternative 007ADE9585256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007ADE9585256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 08/08/2003 03:37:26 PM: > I do not follow how or why you think his point has anything to do with storage > format. Are you saying because your storage format does not allow for > it to change that you want other vendors to change? Tim cited the example of infinite recurrence as a factor in his decision for how he interpreted the RFCs. I was responding to this by pointing out that the internal storage format of any CUA or CS is NOT covered by iCalendar or iTIP. iCalendar is an interoperability format for on the wire and iTIP is the semantics for understanding the data it represents. Are you now saying that all iTIP implementations MUST use a storage format thats basically native iCalendar? That would ruin your cherished SQL backend for CAP wouldn't it? Besides, you seem to want to digress us into non-related stuff than discuss the analysis. Ignoring it wont make it go away or disprove it. > > If your iTIP REQUESTs get missequenced and your model relys on each > > previous SEQUENCE values RECURRENCE-ID value to calculate the next one > > then you cannot recover workflow for just that instance; > > Not true and if you read iTIP from page one to last you will see > that there is an entire section devoted to that problem - with > a solution. You have consistanly claimed that the CUA first matches the RECURRENCE-ID in the RECURRENCE-ID in the REQUESt and then the RECURRENCE-ID value gets changed to the DTSTART value when the instance gets added to my calendar on a reschedule. This clearly means that the RECURRENCE-ID value is reliant on those from previous iTIP REQUESTS. Otherwise you could not match it to the one you incorrectly saved. You are correct in that iTIP has Section 2.1.5 Message Sequencing to deal with missequencing of iTIP messages. However your model does not follow this text. Instead it relys in the some of the example text under Section 4.7.2 Bad RECURRENCE-ID. You have coded something against an example rather than against the prose it was intended to describe and you should have known better. Coding to examples rather than the prose or ABNF is poor practice that no amount of RFC text can resolve. > > ... you can only > > recover by recreating ALL instances (the infamous 'full REFRESH'). > > Your new proposal holds a worse problem. Not only do you have to invent > new ways to invite attendees, you have to somehow remember what SEQUENCE:0 > object would have sent them and do (current-SEQUENCE * VEVENT) object > to update them - MUCH more data than a REFRESH (which is documented), then > they have to REPLY to all of that. How is that better than a REFRESH? I wonder where you pulled this from since it does not apply at all to the model described in iTIP. You should note that there is NO need to do any "full REFRESH" as you so like to say since under the fixed RECURRENCE-ID model in the RFCs: The REQUEST for the given UID / RECURRENCE-ID is either found or its not in the recipients calendar. If its found it identifies the correct instance in question and so a Reschedule / Update check can easily be applied (iTIP Sections 3.2.2.1 or 3.2.2.2 respectively). If its not found then by iTIP 3.2.2 its an invitation to a new instance. I can simply put it on my calendar and send back the REPLY since the invitation contains the current version of all data for that instance. There is NO need to do a REFRESH, its a new invitation that simply gets put on the calendar. When you use a changing RECURRENCE-ID model then the problem of identifying the correct instance in question is raised. As you so deftly noted, its not possible to match to the existing set and since you cannot distinguish between a new invitation and a missequenced reschedule the ONLY solution is to DESTROY THEM ALL AND RECREATE THEM (aka a "full REFRESH"). This is a very drastic thing to do if you the REQUEST was simply missequenced Id say! Imagine, one reschedule for just 1 instance of any repeating instance is lost or delayed and the ONLY solution is to destroy ALL instances in the users calendar and ask for them all again! That works out great don't you think? Oh yeah, adding an invitee to another instance of a repeating entry they already know about requires that you send another 'nuke' REQUEST to recreate the entire subset of instances the user is invited to. Even if the other instance has not changed! Yep, thats an efficient workflow protocol. You MUST do this for Dougs model because thats the ONLY way for the invitee to distinguish between a missed reschedule and a new instance invitation when you use changing RECURRENCE-IDs. If the RECURRENCE-ID were fixed you can quickly, consistanly and unambiguously tell how to deal with the REQUEST. > How is sending much more data as SEQUENCE gets large better than > sending one REFRESH/REQUEST set? This incorrectly follows from your misunderstandng above. There is no need to have to resend all the data for all relevant instances if you can consistanly identify the instance in question despite missed or missequenced iTIP messages. > > There is no way to guarantee that each and every REQUEST gets there and > > in the correct order; some may never arrive or they may be delayed out > > of sequence. > > Which is true of all models. A red herring as iTIP has an entire section > devoted to that solution. Its not a red hering; its germane to the analysis of why we did specifed a fixed RECURRENCE-ID (except in the 1 erroneous line in iTIP). Recovery and handling of the problem is different in each model and its also key in understanding why the fixed RECURRENCE-ID works much better than the changing RECURRENCE-ID. No matter how you try or wish, you cannot say the behaviours are the same in both models or that the delta model functions better. The analysis of each still stand. > > So the only thing the user can do is toss out ALL instances and wait for > > the Organizer to resend 'em all in a new REQUEST. This brings workflow > > to a grinding halt for that invitee. > > As opposed to sending SEQUENCE*EVENTS if they are ever to get an update? Huh!?! Where do you come up with this stuff I wonder. In case its not clear by now Doug, you do NOT need to do any kind of REFRESH because no matter the misordering its quick and simple to recover the workflow for a particular instance (and ignore the obsoleted missequenced REQUESTS if they ever do arrive). Since a fixed RECURRENCE-ID allows me to do the correct instance identification no matter the missequcing or message loss I can correctly find the instance in question, do the correct invitation / reschedule / update determination and apply it and send a REPLY. Any obsolete iTIP messages are ignored and have as such late arrivals are detected as being obsolete (Section 2.1.5 again!) and thus ignored. This correct instance identification is 100% impossible when there is a missequenced or lost message involved. Thus the only possible solution is to do a "full REFRESH" and wait for the Organziers 'nuke' REQUEST. Of course, since that REQUEST too could be lost you are left with the invitees in an indeterminate state and with lots of duplicate orphans that will never get cleaned up. Just think, a later reschedule REQUEST at a higher SEQUENCE could match the UID / RECURRENCE-ID for _some_ particular instance (not necessarily the one the Organizer was thinking of) the invitee already has and viola, they update the wrong instance. The REPLY would have data to match the Organizers so the Organizer has NO way to tell that the invitee mismatched the UID / RECURRENCE-ID and is thinking of the wrong instance. As such they have no reason to send a 'nuke' REFRESH to get the invitee resyncd w/them; they think everyone is resynced when in fact one 'orphan' was simply rescheduled and the others are still there. Yep, that sounds like a real good solution to me... > > However, if your RECURRENCE-ID is fixed then you can quickly and easily > > recover from any missequenced REQUESTs. Since the recipient can > > uniquely and unambiguously identify the instance in question based on > > the UID / RECURRENCE-ID pair in a fixed model, they can easily find the > > correct instance in question and then use SEQUENCE (and DTSTAMP) to > > resolve missequencing. > > Fixed to a SEQUENCE they might not have? Your again ignoring all busted > examples sent to this list for your proposed model. No, NOT fixed to a particular SEQUENCE value. The RECURRENCE-ID value is fixed when the instance is created and persists indefinitely unless the set gets changed (ie: you do an ADD which I have NOT done). For this case iCalendar says that RECURRENCE-ID "might also change" NOT "will change" or "should change", etc. A reschedule on the instance changes the instance, not the "set". If you want to discuss this then perhaps you can show me your dictionary where you got "original" means "current" or "latest" from and then we can rehash iCalendar again. You claim busted examples but nothing backs up your assertion. Im not the one trying to infer invitation vs reschedule vs update based on RECURRENCE-ID. NO TEXT OR RESTRICTION TABLE says thats how you decode the intent of the REQUEST so I dont know where you get this from. If you do not understand how Section 2.1.5 Message Sequencing applys to all iTIP methods under Section 3 then I cant help you there. Perhaps we need Frank or someone else here to transcode it and explaint it a different way. I do however stand by the analysis I did based on the use of the fixed and changing RECURRENCE-ID values. > > For example, using a fixed RECURRENCE-ID, I send you a SEQUENCE:0 > > invitation (MsgA), a SEQUENCE:1 reschedule (MsgB) and then a SEQUENCE:2 > > reschedule (MsgC) for a particular instance. If they arrive in reverse > > order (MsgC, MsgB, MsgA) or even missing/missequenced (MsgC, MsgA, no > > MsgB) then no problems exist and recovery is trivial. Lets see why. > > Better yet - why not just point to iTIP and say - yes it is documented > in iTIP? Because I can demonstrate how flawed the delta RECURRENCE-ID model is when it comes to missequenced or lost messages. I can also demonstrate how flexible and robust the fixed RECURRENCE-ID model is when it comes to these problems. This should help those who eschew a changing RECURRENCE-ID model of its weakness and inflexibility when compared to the fixed RECURRENCE-ID model. I still stand by the analysis I did and am curious if it makes Tim or Chris think twice... > > Now, if we used a changing RECURRENCE-ID model and I send the same > > messages there are lots of problems to be concerned with. Besides the > > issue of recovery there is also the issue of how to remove 'orphaned' > > bad entries in the invitees calendar. Lets see this: > > So please clarify - you are indeed proposing a model that is not > compliant it iTIP? I have proposed NOTHING Doug. I have done an analysis of how each model deals with faults introduced into the workflow process. > iTIP already has solved this problem. Trying > to get the world to do it your way because you do not like the > way iTIP does it is fine - but please do not pretend that iITIP > is busted, its not. You amaze me Doug. You claim to have years and years of experience doing stuff like this and you seem to fail to recognize (or at least acknowledge) flaws inherent in the design interpretation you have of iCalendar and iTIP. You are unwilling or unable to distinguish an analysis of 2 models from a proposal; I have strived to prevent misinterpreations of the RFCs (or to at least prevent others from being mislead) and not propose any RFC changes. You consistanly fail to understand the text in iTIP Sections 2.1.5, 3.2.2, 3.2.2.1 and 3.2.2.2 which tells a CUA how to handle messge sequencing and distinguish between invite/reschedule/update. You have invented some mechanism for differentation DIFFERENT from that in iTIP Sections 3.2.2, 3.2.2.1 and 3.2.2.2 (based some how on either SEQUENCE and/or RECURRENCE-ID in the REQUEST) yet you claim that Im proposing something new. You seem to have latched onto one bulleted case in an example section for your understanding of the iCalendar/iTIP design and you have ignored all the normalative text in iCalendar/iTIP to the contrary. You have also claimed that both models work just fine when infact it can be shown that this is not the case. I have attempted to show that iCalendar defines a fixed RECURRENCE-ID model and that iTIP supports this. I have done both an analysis of text in iCalendar and iTIP regarding RECURRENCE-ID and Ive done a workflow analysis utilizing both a fixed and a changing RECURRENCE-ID model. So far, nothing Ive read indicates that you disagree w/the weakness inherent in the delta RECURRENCE-ID model. It does appear to me that you still do not follow the fixed RECURRENCE-ID model examples all that well since as I noted there is NO need to do the things you claim because with a fixed RECURRENCE-ID you can easily recover from the problems of message loss or missequecing. BTW: You have never answered my question: Does each instance have its own SEQUENCE or not? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007ADE9585256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 08/08/2003 03:37:26 PM:
> I do not follow how or why you think his point has anything to do with storage
> format. Are you saying because your storage format does not allow for
> it to change that you want other vendors to change?
Tim cited the example of infinite recurrence as a factor in his decision for how he interpreted the RFCs.  I was responding to this by pointing out that the internal storage format of any CUA or CS is NOT covered by iCalendar or iTIP.  iCalendar is an interoperability format for on the wire and iTIP is the semantics for understanding the data it represents.  

Are you now saying that all iTIP implementations MUST use a storage format thats basically native iCalendar?  That would ruin your cherished SQL backend for CAP wouldn't it?  Besides, you seem to want to digress us into non-related stuff than discuss the analysis.  Ignoring it wont make it go away or disprove it.

> > If your iTIP REQUESTs get missequenced and your model relys on each
> > previous SEQUENCE values RECURRENCE-ID value to calculate the next one
> > then you cannot recover workflow for just that instance;
>
> Not true and if you read iTIP from page one to last you will see
> that there is an entire section devoted to that problem - with
> a solution.
You have consistanly claimed that the CUA first matches the RECURRENCE-ID in the RECURRENCE-ID in the REQUESt and then the RECURRENCE-ID value gets changed to the DTSTART value when the instance gets added to my calendar on a reschedule.  This clearly means that the RECURRENCE-ID value is reliant on those from previous iTIP REQUESTS.  Otherwise you could not match it to the one you incorrectly saved.

You are correct in that iTIP has Section 2.1.5 Message Sequencing to deal with missequencing of iTIP messages.  However your model does not follow this text.  Instead it relys in the some of the example text under Section 4.7.2 Bad RECURRENCE-ID.  You have coded something against an example rather than against the prose it was intended to describe and you should have known better.  Coding to examples rather than the prose or ABNF is poor practice that no amount of RFC text can resolve.

> > ... you can only
> > recover by recreating ALL instances (the infamous 'full REFRESH').
>
> Your new proposal holds a worse problem. Not only do you have to invent
> new ways to invite attendees, you have to somehow remember what SEQUENCE:0
> object would have sent them and do (current-SEQUENCE * VEVENT) object
> to update them - MUCH more data than a REFRESH (which is documented), then
> they have to REPLY to all of that. How is that better than a REFRESH?
I wonder where you pulled this from since it does not apply at all to the model described in iTIP.  You should note that there is NO need to do any "full REFRESH" as you so like to say since under the fixed RECURRENCE-ID model in the RFCs: The REQUEST for the given UID / RECURRENCE-ID is either found or its not in the recipients calendar.   If its found it identifies the correct instance in question and so a Reschedule / Update check can easily be applied (iTIP Sections 3.2.2.1 or 3.2.2.2 respectively).  If its not found then by iTIP 3.2.2 its an invitation to a new instance.  I can simply put it on my calendar and send back the REPLY since the invitation contains the current version of all data for that instance.  

There is NO need to do a REFRESH, its a new invitation that simply gets put on the calendar.

When you use a changing RECURRENCE-ID model then the problem of identifying the correct instance in question is raised.  As you so deftly noted, its not possible to match to the existing set and since you cannot distinguish between a new invitation and a missequenced reschedule the ONLY solution is to DESTROY THEM ALL AND RECREATE THEM (aka a "full REFRESH").  This is a very drastic thing to do if you the REQUEST was simply missequenced Id say!  

Imagine, one reschedule for just 1 instance of any repeating instance is lost or delayed and the ONLY solution is to destroy ALL instances in the users calendar and ask for them all again!  That works out great don't you think?

Oh yeah, adding an invitee to another instance of a repeating entry they already know about requires that you send another 'nuke' REQUEST to recreate the entire subset of instances the user is invited to.  Even if the other instance has not changed!  Yep, thats an efficient workflow protocol.  

You MUST do this for Dougs model because thats the ONLY way for the invitee to distinguish between a missed reschedule and a new instance invitation when you use changing RECURRENCE-IDs.   If the RECURRENCE-ID were fixed you can quickly, consistanly and unambiguously tell how to deal with the REQUEST.

> How is sending much more data as SEQUENCE gets large better than
> sending one REFRESH/REQUEST set?
This incorrectly follows from your misunderstandng above.  There is no need to have to resend all the data for all relevant instances if you can consistanly identify the instance in question despite missed or missequenced iTIP messages.

> >  There is no way to guarantee that each and every REQUEST gets there and
> > in the correct order; some may never arrive or they may be delayed out
> > of sequence.
>
> Which is true of all models. A red herring as iTIP has an entire section
> devoted to that solution.
Its not a red hering; its germane to the analysis of why we did specifed a fixed RECURRENCE-ID (except in the 1 erroneous line in iTIP).

Recovery and handling of the problem is different in each model and its also key in understanding why the fixed RECURRENCE-ID works much better than the changing RECURRENCE-ID.  No matter how you try or wish, you cannot say the behaviours are the same in both models or that the delta model functions better.  The analysis of each still stand.

> > So the only thing the user can do is toss out ALL instances and wait for
> > the Organizer to resend 'em all in a new REQUEST.  This brings workflow
> > to a grinding halt for that invitee.
>
> As opposed to sending SEQUENCE*EVENTS if they are ever to get an update?
Huh!?!  Where do you come up with this stuff I wonder.

In case its not clear by now Doug, you do NOT need to do any kind of REFRESH because no matter the misordering its quick and simple to recover the workflow for a particular instance (and ignore the obsoleted missequenced REQUESTS if they ever do arrive).  Since a fixed RECURRENCE-ID allows me to do the correct instance identification no matter the missequcing or message loss I can correctly find the instance in question, do the correct invitation / reschedule / update determination and apply it and send a REPLY.  Any obsolete iTIP messages are ignored and have as such late arrivals are detected as being obsolete (Section 2.1.5 again!) and thus ignored.

This correct instance identification is 100% impossible when there is a missequenced or lost message involved.  Thus the only possible solution is to do a "full REFRESH" and wait for the Organziers 'nuke' REQUEST.  Of course, since that REQUEST too could be lost you are left with the invitees in an indeterminate state and with lots of duplicate orphans that will never get cleaned up.  

Just think, a later reschedule REQUEST at a higher SEQUENCE could match the UID / RECURRENCE-ID for _some_ particular instance (not necessarily the one the Organizer was thinking of) the invitee already has and viola, they update the wrong instance.  The REPLY would have data to match the Organizers so the Organizer has NO way to tell that the invitee mismatched the UID / RECURRENCE-ID and is thinking of the wrong instance.  As such they have no reason to send a 'nuke' REFRESH to get the invitee resyncd w/them; they think everyone is resynced when in fact one 'orphan' was simply rescheduled and the others are still there.

Yep, that sounds like a real good solution to me...

> > However, if your RECURRENCE-ID is fixed then you can quickly and easily
> > recover from any missequenced REQUESTs.  Since the recipient can
> > uniquely and unambiguously identify the instance in question based on
> > the UID / RECURRENCE-ID pair in a fixed model, they can easily find the
> > correct instance in question and then use SEQUENCE (and DTSTAMP) to
> > resolve missequencing.
>
> Fixed to a SEQUENCE they might not have? Your again ignoring all busted
> examples sent to this list for your proposed model.
No, NOT fixed to a particular SEQUENCE value.  The RECURRENCE-ID value is fixed when the instance is created and persists indefinitely unless the set gets changed (ie: you do an ADD which I have NOT done).  For this case iCalendar says that RECURRENCE-ID "might also change" NOT "will change" or "should change", etc.  A reschedule on the instance changes the instance, not the "set".   If you want to discuss this then perhaps you can show me your dictionary where you got "original" means "current" or "latest" from and then we can rehash iCalendar again.

You claim busted examples but nothing backs up your assertion.  Im not the one trying to infer invitation vs reschedule vs update based on RECURRENCE-ID.  NO TEXT OR RESTRICTION TABLE says thats how you decode the intent of the REQUEST so I dont know where you get this from.   If you do not understand how Section 2.1.5 Message Sequencing applys to all iTIP methods under Section 3 then I cant help you there.  Perhaps we need Frank or someone else here to transcode it and explaint it a different way.

I do however stand by the analysis I did based on the use of the fixed and changing RECURRENCE-ID values.  

> > For example, using a fixed RECURRENCE-ID, I send you a SEQUENCE:0
> > invitation (MsgA), a SEQUENCE:1 reschedule (MsgB) and then a SEQUENCE:2
> > reschedule (MsgC) for a particular instance.  If they arrive in reverse
> > order (MsgC, MsgB, MsgA) or even missing/missequenced (MsgC, MsgA, no
> > MsgB) then no problems exist and recovery is trivial.  Lets see why.
>
> Better yet - why not just point to iTIP and say - yes it is documented
> in iTIP?
Because I can demonstrate how flawed the delta RECURRENCE-ID model is when it comes to missequenced or lost messages.  I can also demonstrate how flexible and robust the fixed RECURRENCE-ID model is when it comes to these problems.  This should help those who eschew a changing RECURRENCE-ID model of its weakness and inflexibility when compared to the fixed RECURRENCE-ID model.

I still stand by the analysis I did and am curious if it makes Tim or Chris think twice...

> > Now, if we used a changing RECURRENCE-ID model and I send the same
> > messages there are lots of problems to be concerned with.  Besides the
> > issue of recovery there is also the issue of how to remove 'orphaned'
> > bad entries in the invitees calendar.  Lets see this:
>
> So please clarify - you are indeed proposing a model that is not
> compliant it iTIP?

I have proposed NOTHING Doug.  I have done an analysis of how each model deals with faults introduced into the workflow process.

>                     iTIP already has solved this problem. Trying
> to get the world to do it your way because you do not like the
> way iTIP does it is fine - but please do not pretend that iITIP
> is busted, its not.
You amaze me Doug.  You claim to have years and years of experience doing stuff like this and you seem to fail to recognize (or at least acknowledge) flaws inherent in the design interpretation you have of iCalendar and iTIP.  You are unwilling or unable to distinguish an analysis of 2 models from a proposal; I have strived to prevent misinterpreations of the RFCs (or to at least prevent others from being mislead) and not propose any RFC changes.

You consistanly fail to understand the text in iTIP Sections 2.1.5, 3.2.2, 3.2.2.1 and 3.2.2.2 which tells a CUA how to handle messge sequencing and distinguish between invite/reschedule/update.  You have invented some mechanism for differentation DIFFERENT from that in iTIP Sections 3.2.2, 3.2.2.1 and 3.2.2.2 (based some how on either SEQUENCE and/or RECURRENCE-ID in the REQUEST) yet you claim that Im proposing something new.

You seem to have latched onto one bulleted case in an example section for your understanding of the iCalendar/iTIP design and you have ignored all the normalative text in iCalendar/iTIP to the contrary.  You have also claimed that both models work just fine when infact it can be shown that this is not the case.  

I have attempted to show that iCalendar defines a fixed RECURRENCE-ID model and that iTIP supports this.  I have done both an analysis of text in iCalendar and iTIP regarding RECURRENCE-ID and Ive done a workflow analysis utilizing both a fixed and a changing RECURRENCE-ID model.  So far, nothing Ive read indicates that you disagree w/the weakness inherent in the delta RECURRENCE-ID model.

It does appear to me that you still do not follow the fixed RECURRENCE-ID model examples all that well since as I noted there is NO need to do the things you claim because with a fixed RECURRENCE-ID you can easily recover from the problems of message loss or missequecing.  

BTW: You have never answered my question: Does each instance have its own SEQUENCE or not?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007ADE9585256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 19:12: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 TAA10471 for ; Mon, 11 Aug 2003 19:12:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BN44qt083829 for ; Mon, 11 Aug 2003 16:04:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BN44qG083828 for ietf-calendar-bks; Mon, 11 Aug 2003 16:04:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BN43qt083823 for ; Mon, 11 Aug 2003 16:04:03 -0700 (PDT) (envelope-from gsbarnes@u.washington.edu) Received: from mead7.u.washington.edu (mead7.u.washington.edu [140.142.12.147]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7BN40oa015048 for ; Mon, 11 Aug 2003 16:04:05 -0700 Received: from localhost (gsbarnes@localhost) by mead7.u.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7BN40xA012452 for ; Mon, 11 Aug 2003 16:04:00 -0700 Date: Mon, 11 Aug 2003 16:04:00 -0700 (PDT) From: "G. Barnes" To: "ietf-calendar@imc.org" Subject: Re: CAP -12 and LAST CALL (hopefully) In-Reply-To: <3F37EFE0.9050503@Royer.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've just submitted another 'bug report', that is mostly typos. In any event, nothing there is really an 'issue', but there were a few things that deserve a little more publicity than just a bug report: --------------------------------------------------------------- Section 3.3.1 States that 'CREATE' can be implied for iTIP objects. What does that mean? That you can omit a CMD if you include an iTIP object, and the server should infer you want to CREATE it? If so, this should be explained clearly, here and in 10.1 or 10.1.4. Note that this 'implied command' probably contradicts Doug Royer's proposed BEEP profile, which states CMDs are mandatory. 6.1.1.13 The paragraph in this section is extremely difficult to understand. The key point, I gather, is that 'If there are two VALARM components in a given VEVENT, then both components are tested' and if either matches (and the STATE=BOOKED), then the UID, SUMMARY, DESCRIPTION of that VEVENT is returned. As it reads now, the 3rd sentence says *all* UID, SUMMARY, DESCRIPTIONS from all VEVENTs are returned if we get one match, which is surely not right. Assuming this is right, a more plausible rewrite might be: If a query references a component and a component or property contained in the component, any clauses referring to the contained component or property must be evaluated on all of the contained components or properties. If any of the contained components or properties match the query, and the conditions on the containing component are also true, the component matches the query. For example, in the query below, if a BOOKED VEVENT contains multiple VALARMs, and the VALARM.TRIGGER clause is true for any of the VALARMs in the VEVENT, then the UID, SUMMARY, and DESCRIPTION of this VEVENT would be included in the QUERY results. [Someone please check my work here. I may be missing something...] 6.1.2 'A CU's UPN MUST never be an e-mail address that is deliverable to a different person as there is no requirement that a person's UPN MUST BE their e-mail address'. The logic in this sentence is contradictory (if there's no requirement that the UPN be a person's mailing address, then why does that imply they can't have a UPN that is someone else's e-mail address? It would seem to imply the exact opposite). Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Mon Aug 11 19:15: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 TAA10518 for ; Mon, 11 Aug 2003 19:15:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BN56qt083871 for ; Mon, 11 Aug 2003 16:05:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BN56sR083870 for ietf-calendar-bks; Mon, 11 Aug 2003 16:05:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BN55qt083865 for ; Mon, 11 Aug 2003 16:05:05 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BN54EB004903 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 16:05:06 -0700 Message-ID: <3F38211B.3040400@Royer.com> Date: Mon, 11 Aug 2003 17:04:59 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000104050002050409060302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000104050002050409060302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > >>> It should >>>go through the recurrence set and send a reply for all >>>instances that the ATTENDEE has been invited to, but >>>this will be one iTIP message with multiple VEVENT >>>components that each have a RECURRENCE-ID. Not one >>>component with a UID that matches the original component >>>that the ATTENDEE was not invited to and no RECURRENCE-ID. >> >>Why not? > > > Because to do it any other way would either violate the global > uniqueness of the UID or imply the CU was invited to event > instances that it wasn't. IUD's are only unique to the booked object. IUD's are not unique over the wire by themselves. > > >>Nothing >>in the RFCs I've read suggest that this is what MUST happen, >>nor even that it SHOULD. > > > You're right. There is nothing in the RFCs that talks directly > about this. There is no example of inviting an ATTENDEE to a > single instance. There is only the document that should be > internally consistent enough to indicate how this should be > done. Sadly, it unfortunately isn't, as we both have enough > evidence from the text to defend two very different standpoints. > We have to resort to figuring what the chain of messages in > each model will be to figure out which one holds more water > within the text as a whole. So whoever invented a way that breaks single instance modifications? No. I do not think it is going to make it into iCal-verion-next. > This last part isn't actually true. The fixed-id model never > requires a UID without a RECURRENCE-ID object to be consistent. > > I will finish out what the CUA does with the response it gets > from the intelligent ORGANIZER which contained a copy of every > instance it was invited to with all objects containing a > RECURREINCE-ID and no object without one. It't not relevant if it is indistinguishable from a single instance update. And so far NO ONE has supplied any reason or need to make add attendee look like a single instance update. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000104050002050409060302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIzMDQ1OVowIwYJKoZIhvcNAQkEMRYEFAQiMo4y wz3KkQFlmPwItBbfCImFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAHpMWGQ0LvVgfeAoS96mrhYRFEpicatU4anE9Aw98km4y+uVI7jp 8xs5ELfpDvPy6OVSOLLJjUQjaUL9AVayxuTPcQveu4Ofy+Nw9w+YIRj1dzpQOdvcXQ5QvcLk ci0F4PrYvtt50KlaFFUrDw3rkVdsg2N4BD41G05oUTBZ+WAltTYs1ehLO/EoeoX4DtcTXvRg Yny4mPksQBmXbZL+Akuk4HNTYoDDdTzLr/o+m4xHWkf6WjYeaFXe9BjxAe28w8GbMm0006Cb 2sLpaYJf19SDtCbJTmWYNwBjj1KnJ428moHxU3U76ZBk4mehZsP/GNiJ4GX756ftnxWixIZ3 dBcAAAAAAAA= --------------ms000104050002050409060302-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 19:18: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 TAA10559 for ; Mon, 11 Aug 2003 19:18:57 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNARqt084053 for ; Mon, 11 Aug 2003 16:10:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BNARYi084052 for ietf-calendar-bks; Mon, 11 Aug 2003 16:10:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNAQqt084047 for ; Mon, 11 Aug 2003 16:10:26 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BNANEB004957 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 16:10:27 -0700 Message-ID: <3F38225A.3080307@Royer.com> Date: Mon, 11 Aug 2003 17:10:18 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090901080304060803030403" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090901080304060803030403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug asked on 08/08/2003 02:53:38 PM: > > Its becoming clear to me that you did not understand iTIP when you > > wrote your project and you did not know that these new proposals > > of yours were already covered in iTIP and we do not need new ways > > to do things that are already documented. > > I have not proposed anything new. Your propiosing that to add and attendee, you send a instance update. That *IS* new. Here are some snips of how iTIP says to uinvite an ATTENDEE: 3.2.2 REQUEST The "REQUEST" method in a "VEVENT" component provides the following scheduling functions: . Invite "Attendees" to an event; .... ... The "Organizer" originates the "REQUEST". The recipients of the "REQUEST" method are the CUs invited to the event, the "Attendees". "Attendees" use the "REPLY" method to convey attendance status to the "Organizer". ... 3.2.2.6 Forwarding to An Uninvited CU An "Attendee" invited to an event may invite another uninvited CU to the event. The invited "Attendee" accomplishes this by forwarding the original "REQUEST" method to the uninvited CU. The "Organizer" decides whether or not the uninvited CU is added to the attendee .... Which *IS* distinctly different than: 4.4.2 Modify A Recurring Instance In this example the "Organizer" issues a recurring meeting. Later the "Organizer" changes an instance of the event by changing the "DTSTART" property. Note the use of "RECURRENCE-ID" property and "SEQUENCE" property in the second request. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090901080304060803030403 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIzMTAxOFowIwYJKoZIhvcNAQkEMRYEFBTEYmT9 5tq1n0+tOqAZX+pw1alyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIhmMgWGLG9V/ki1TsDgLJ0VWNesGsLJEfb+NcWdFMI8Q4x+RNr1 fFhXwM8bRbLSHqhu4hkNbr0K9SOC9UOBmRTS4kLLVkygYOjM4i+cPVgZZ1ZfiMn5AFDlw3By mIHCXSeSiLyfOFa8Gx2by4U6RPkQuigKEfo+cCJl4dKrtIlze4CkHS1kji4dgGf7FH2YKVjp h+00pEEhtrWEoqzZ8W8lWgWW1aiOHnLBNu3Vr1/OHmnXILkJJxWTNM5KsNSgB2S3BsFOq7P7 vnPjD0hnslvpBr70NJnS1rdrEPo9nvyA6blyVNCfPpUGUJ8EEzTvmoTEQVtJcnSHO+mKh3Vx 3yAAAAAAAAA= --------------ms090901080304060803030403-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 19:25: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 TAA10610 for ; Mon, 11 Aug 2003 19:25:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNGWqt084435 for ; Mon, 11 Aug 2003 16:16:32 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BNGW6v084434 for ietf-calendar-bks; Mon, 11 Aug 2003 16:16:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNGVqt084429 for ; Mon, 11 Aug 2003 16:16:31 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F380FA4.8070901@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP -12 and LAST CALL (hopefully) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Aug 2003 18:57:52 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/11/2003 07:16:33 PM, Serialize complete at 08/11/2003 07:16:33 PM Content-Type: multipart/alternative; boundary="=_alternative 007DE76585256D7F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007DE76585256D7F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 08/11/2003 05:50:28 PM: > If I do not get to it soon, feel free to use the diff tool of your > choice and post them. Not my job; thats something the editor does. > Pat has just declared on this list that the CHAIRs declare such a list, > NOT the editors. Pat - do you have any open issues? Thats NOT what she said. She wrote: >3. Saying that no one responding to a comment by Bruce stops the issue is >the chairs call, not the editors. Its the chairs call if the issue is resolved or not; the list is not theirs to maintain. Thats something for the editor to do. You did it before so you should be familiar w/the process. > > Examples of recenty issues: > > > > The issue of searching scoping was raised and once the issue was clear > > to everyone there was no discussion on resolving it. > > It was addressed in CAP-11, the ABNF updates were made and I did > comment in the CAP-11 announcement that no proposals were submitted. > Bruce- did the updates in -11 solve the problem as you see it? I did not see CAP 11. As I said I have too much to do to reread CAP 11 front to back to find the differences. Thats why I asked for a diff to be posted. No diffs still for 10-11 so I was reposting what I could recall off hand. I dont recall seeing any WG discussion of some issues like the fact that queryc was only in the CREATE command and no other. I would expect that the ABNF for all commands would be changed such that its clear what commands can or cannot take queryc, etc but thats not something we talked about at all. > > The issue of busytime lookups and maintenance was rasied and I proposed > > a change but I dont know if it got into CAP 11 or the pending 12. > > There have been lots of VFREEBUSY posts. Your proposal said > for future use: > > ...I suspect that anything that can be CREATEd in your queue needs to be > able to get searched for so you can remove 'em, process 'em, > etc. Although > we dont have iMIP -> CAP designed now, it may be possible in the future > (CAP creation is not the only way to get 'em into your queue essentially). > > I just re-read your reply and it did NOT include a proposal. > Your (1) - was the reason I asked the question - when are they not useless? > Your (2) - is NOT what CAP does at this time. It does not get iMIP > messages. > > So I'll ask - why do we want to store objects in CAP when NO tool > can use them? Why not add it later if need? I had proposed that we reinstate the text that was removed w/o WG discussion or approval that was in CAP-03 thru -05 that said that the CS maintained the busytime data (and other stuff related to it). I had even provided the snippets from 03 and 05 as reference. Perhaps you missed that posting. I want to be sure of what I think you are saying: Are you claiming as the current CAP author that we will never support iMIP generated VFREEBUSY messages via CAP? Thats what I read you to say with "when are they not useless?" but I could be wrong If its possible to have them ("useless" != "never") then CAP needs to be able to at least clean them out if nothing else. Even if the CS does not autoprocess them and craft back some kind of iMIP VFREEBUSY REPLY, if they can get into your queue then CAP MUST provide some way to find and remove them. I would expect that SEARCH with STATE()!='BOOKED' would mean this so STATE() may be necessary for SEARCHing on VFREEBUSYs if only to remove them from your queue. Ideally the CS would handle processing of the requests (subject to VCARs) and generate the proper iMIP REPLY but thats just an idea I have and not actually in CAP... You misunderstood (2). If I can CREATE a VFEEBUSY REQUEST in your queue by TARGETing it and the response that the CS generates is "Yes, I created your VFREEBUSY REQUEST" (which it logically means) then either A) CREATE needs to be reworked to disallow this (assuming there is some other way to do busytime lookups!!) or B) CREATE and SEARCH of VFREEBUSY components need to be beter codified to their behaviour to distinguish exactly how busytime is searched for in a CAP system. And if you think no CAP client can use a busytime system then you dont understand the use of busytime for dong Scheduling. Accurate busytime greatly improves the workflow process; missing or inaccurate busytime greatly degrades the process. > The XML->RFC tool may be busted. It is in my XML here and it does > not make it in to the TXT version, I'll hand edit CAP-12 (not from the XML > source) to fix it until I can find the reason. (not sure when it > got added as it did not show up in the TXT version). This causes me some big concerns. What else may be missing? What else may be in the XML version that disappears in the TXT version that folks may object to but not know about? As long as the TXT is whats submitted then things may be ok but its sure gonna make me leary of the TXT versions. What about the HTML versions too?? > The missing text for SEARCH is (follows the ABNF): > > "The format of the request is the search command (search-cmd) followed > by one or more (query) "VQUERY" components" > > Followed by the 'Response' section and then examples of 'SEARCH'. This is insufficient since this is not reflected in the ABNF. In previous drafts we've had text to the effect of order of precedence: The memo also includes a formal grammar for the content type based on the Internet ABNF defined in [RFC 2234]. This ABNF is required for the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the memo. but we are missing it in CAP. We need something like this for resolving future disputes or to aid in interpreation. Otherwise its possible to generate ABNF accurate CAP payloads that are nonsensical or conflict w/the prose and we have no way to resolve the dispute. 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 007DE76585256D7F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 08/11/2003 05:50:28 PM:
> If I do not get to it soon, feel free to use the diff tool of your
> choice and post them.
Not my job; thats something the editor does.  

> Pat has just declared on this list that the CHAIRs declare such a list,
> NOT the editors. Pat - do you have any open issues?
Thats NOT what she said.  She wrote:

>3.  Saying that no one responding to a comment by Bruce stops the issue is
>the chairs call, not the editors.

Its the chairs call if the issue is resolved or not; the list is not theirs to maintain.   Thats something for the editor to do.  You did it before so you should be familiar w/the process.

> > Examples of recenty issues:
> >
> > The issue of searching scoping was raised and once the issue was clear
> > to everyone there was no discussion on resolving it.
>
> It was addressed in CAP-11, the ABNF updates were made and I did
> comment in the CAP-11 announcement that no proposals were submitted.
> Bruce- did the updates in -11 solve the problem as you see it?
I did not see CAP 11.  As I said I have too much to do to reread CAP 11 front to back to find the differences.  Thats why I asked for a diff to be posted.  No diffs still for 10-11 so I was reposting what I could recall off hand.  I dont recall seeing any WG discussion of some issues like the fact that queryc was only in the CREATE command and no other.  I would expect that the ABNF for all commands would be changed such that its clear what commands can or cannot take queryc, etc but thats not something we talked about at all.

> > The issue of busytime lookups and maintenance was rasied and I proposed
> > a change but I dont know if it got into CAP 11 or the pending 12.
>
> There have been lots of VFREEBUSY posts. Your proposal said
> for future use:
>
>     ...I suspect that anything that can be CREATEd in your queue needs to be
>     able to get searched for so you can remove 'em, process 'em,
> etc.  Although
>     we dont have iMIP -> CAP designed now, it may be possible in the future
>    (CAP creation is not the only way to get 'em into your queue essentially).
>
> I just re-read your reply and it did NOT include a proposal.
> Your (1) - was the reason I asked the question - when are they not useless?
> Your (2) - is NOT what CAP does at this time. It does not get iMIP
>             messages.
>
> So I'll ask - why do we want to store objects in CAP when NO tool
> can use  them? Why not add it later if need?
I had proposed that we reinstate the text that was removed w/o WG discussion or approval that was in CAP-03 thru -05 that said that the CS maintained the busytime data (and other stuff related to it).  I had even provided the snippets from 03 and 05 as reference.

Perhaps you missed that posting.

I want to be sure of what I think you are saying:  Are you claiming as the current CAP author that we will never support iMIP generated VFREEBUSY messages via CAP?  Thats what I read you to say with "when are they not useless?" but I could be wrong

If its possible to have them ("useless" != "never") then CAP needs to be able to at least clean them out if nothing else.  Even if the CS does not autoprocess them and craft back some kind of iMIP VFREEBUSY REPLY, if they can get into your queue then CAP MUST provide some way to find and remove them.  I would expect that SEARCH with STATE()!='BOOKED' would mean this so STATE() may be necessary for SEARCHing on VFREEBUSYs if only to remove them from your queue.  Ideally the CS would handle processing of the requests (subject to VCARs) and generate the proper iMIP REPLY but thats just an idea I have and not actually in CAP...

You misunderstood (2).  If I can CREATE a VFEEBUSY REQUEST in your queue by TARGETing it and the response that the CS generates is "Yes, I created your VFREEBUSY REQUEST" (which it logically means) then either A) CREATE needs to be reworked to disallow this (assuming there is some other way to do busytime lookups!!) or B) CREATE and SEARCH of VFREEBUSY components need to be beter codified to their behaviour to distinguish exactly how busytime is searched for in a CAP system.

And if you think no CAP client can use a busytime system then you dont understand the use of busytime for dong Scheduling.  Accurate busytime greatly improves the workflow process; missing or inaccurate busytime greatly degrades the process.

> The XML->RFC tool may be busted. It is in my XML here and it does
> not make it in to the TXT version, I'll hand edit CAP-12 (not from the XML
> source) to fix it until I can find the reason. (not sure when it
> got added as it did not show up in the TXT version).
This causes me some big concerns.  What else may be missing?  What else may be in the XML version that disappears in the TXT version that folks may object to but not know about?  As long as the TXT is whats submitted then things may be ok but its sure gonna make me leary of the TXT versions.  What about the HTML versions too??

> The missing text for SEARCH is (follows the ABNF):
>
>     "The format of the request is the search command (search-cmd) followed
>     by one or more (query) "VQUERY" components"
>
> Followed by the 'Response' section and then examples of 'SEARCH'.
This is insufficient since this is not reflected in the ABNF.  In previous drafts we've had text to the effect of order of precedence:

   The memo also includes a formal grammar for the content type based on
  the Internet ABNF defined in [RFC 2234]. This ABNF is required for
  the implementation of parsers and to serve as the definitive
  reference when ambiguities or questions arise in interpreting the
  descriptive prose definition of the memo.
but we are missing it in CAP.  We need something like this for resolving future disputes or to aid in interpreation.  Otherwise its possible to generate ABNF accurate CAP payloads that are nonsensical or conflict w/the prose and we have no way to resolve the dispute.

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 007DE76585256D7F_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 19:37: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 TAA10986 for ; Mon, 11 Aug 2003 19:37:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNUQqt085606 for ; Mon, 11 Aug 2003 16:30:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BNUQ6u085605 for ietf-calendar-bks; Mon, 11 Aug 2003 16:30:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNUPqt085598 for ; Mon, 11 Aug 2003 16:30:25 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BNUPEB005107 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 16:30:27 -0700 Message-ID: <3F38270C.7050106@Royer.com> Date: Mon, 11 Aug 2003 17:30:20 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000606060102060605030207" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000606060102060605030207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 08/08/2003 03:37:26 PM: > > I do not follow how or why you think his point has anything to do > with storage > > format. Are you saying because your storage format does not allow for > > it to change that you want other vendors to change? > > Tim cited the example of infinite recurrence as a factor in his decision > for how he interpreted the RFCs. I was responding to this by pointing > out that the internal storage format of any CUA or CS is NOT covered by > iCalendar or iTIP. iCalendar is an interoperability format for on the > wire and iTIP is the semantics for understanding the data it represents. > > Are you now saying that all iTIP implementations MUST use a storage > format thats basically native iCalendar? No. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000606060102060605030207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIzMzAyMFowIwYJKoZIhvcNAQkEMRYEFK5Uivj9 Pe3ereL+2Fji3pPePIPlMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAC4MC33ZLdhgXke4/MCgsNKWNbGgyuOmzwzKbBYz2RCfKs85N5Vj 6vxAdzDjj5hEnzoWHlThKt2ugTvbXZp9Fv6Penf4n7cCjZZwgp2V+3eaSLKXSHfoRPFBInTZ ztefp8yLFy25+V6Fhhjx23yXw4yCJe8rAh/eMxKxOPsEoSymsIvjcxduFcN8w5I2R5I+inZx VGWoZpcViP9h48NxsqQ3my8kou5dTxtBi8ZrExPsHQ5efcZaikEUkUTOpWoJ9RUCvi6vnRva CyiPSRqXc/mdJ/Wyyj7whK2KaCuQ+2cz3altWKkLdXVEtvP5++u61MMFZovCZCVXXXUP36Fh U5IAAAAAAAA= --------------ms000606060102060605030207-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 19:37: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 TAA11002 for ; Mon, 11 Aug 2003 19:37:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNTAqt085520 for ; Mon, 11 Aug 2003 16:29:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BNTAlo085519 for ietf-calendar-bks; Mon, 11 Aug 2003 16:29:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNT8qt085513 for ; Mon, 11 Aug 2003 16:29:09 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BNT7EB005084 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 16:29:10 -0700 Message-ID: <3F3826BE.2090000@Royer.com> Date: Mon, 11 Aug 2003 17:29:02 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010307040805000703030100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010307040805000703030100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > > You're right. There is nothing in the RFCs that talks directly > about this. There is no example of inviting an ATTENDEE to a > single instance. iTIP 3.2.2 REQUEST The "REQUEST" method in a "VEVENT" component provides the following scheduling functions: . Invite "Attendees" to an event; ... It gives instruction on how to invite an attendee and it is not restricted to single or multiple instances. And the example in "4.2.1 A Group Event Request" is for a SINGLE instance VEVENT. Why do you think what the initial SEQUENCE number is when an ATTENDEE is invited matters? It does not matter. An ATTENDEE could be delegated-to a single meeting at SEQUENCE:30. It makes not difference. The ORGANIZER-CU and/or DELEGATED-FROM-CU does not need to tell every ATTENDEE about every meeting they will not be attending in a series of meetings. That is often good business practice. Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010307040805000703030100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIzMjkwMlowIwYJKoZIhvcNAQkEMRYEFDcK3lRt 7Mm+Zxs6mdlq36m9CXY+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAHVdjGXIOm52lb7FkOQ8nkkXj2ctjcE7CR+65TQ8obe/oj2Jfeb5 P5LMHJKBnyuNnCa16AH5x3GtU3Ekl36cyxk8XFXVtptNHUKGjbDqGGoCEHLWk18PeNVmpkLp wA+FJjzUeZ72W13P63eojwr6iWhRyj9l00QZIkuvTvHaruGglobQcIjVr3anotIgbGncTq4O TmJ0ijBEcCN9MWlj1N68sVGD5evtETrL/t4FBCkjuBaoIQPEokgWcDYMlIqYhemtp/kCJmTR 5jeCkieLjsfwEwUmfXDzds6kwlWbcbxiDVF9CDZlCJXR+mjaYSreDrnZrdxUX4oZD6VPyUQl l2UAAAAAAAA= --------------ms010307040805000703030100-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 19:44:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11097 for ; Mon, 11 Aug 2003 19:44:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNa3qt086032 for ; Mon, 11 Aug 2003 16:36:03 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BNa2sb086031 for ietf-calendar-bks; Mon, 11 Aug 2003 16:36:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNa0qt086023 for ; Mon, 11 Aug 2003 16:36:01 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mME5-0001el-00 for ; Tue, 12 Aug 2003 01:37:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mME4-0001ed-00 for ; Tue, 12 Aug 2003 01:37:20 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mMCo-0004kC-00 for ; Tue, 12 Aug 2003 01:36:02 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 16:34:55 -0700 Lines: 280 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> <3F381A2A.6080900@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: All I can say Doug is show me the code. Please show me the chain of messages that go between the different CUA's and what in iTIP tells each CUA how to process these messages. Here's the task. Given the following event with you as the ORGANIZER: UID:1 SEQUENCE:0 DTSTART:Friday, Jan 3rd, 2003 at 6pm UTC DTEND:Friday, Jan 3rd, 2003 at 7pm UTC RRULE:FREQ=WEEKLY ORAGANIZER;PARTSTAT=ACCEPTED:Doug Invite user A to the 1st instance (RID: 1st Friday). Invite user B to the 2nd instance (RID: 2nd Friday). Now have B forward the invite to A and tell me why (citing iTIP) A's CUA doesn't get confused. What the REPLY that "A" send you to accept looks like. And how (again using iTIP) your CUA knows what is going on. You can use "O", "A", and "B" to reference the given parties. I will make efforts to understand shortcuts like "SEQ" for SEQUENCE, and "RID" for "RECURRENCE-ID" and others as long as its not confusing. In fact, if you're right, you won't use a single RECURRENCE-ID property in the whole sequence of messages. You provided no evidence or messages or even message fragments you simply said to "process the message". I'm telling you that a CUA can't process the message because the messages it is getting are borked respective to the message sequence rules and REQUEST processing rules of iTIP. I'm assuming you're thinking I'm just dense and maybe I am, I'm willing to admit when I've made a mistake, even one as big as the lengthy thread we've got going. So here's your chance to prove it. You show me why using iTIP processing rules you can get away with what you are suggesting. There are still other things to sort out, but I can at least withdraw my argument that this is impossible to do within iTIP using the methods you've described. (Note: At no point in iTIP does it ever say anything about a CUA tracking which ATTENDEES it has sent which messages. It only talks about tracking responses in relationship to a given event. A given event is only identified by its UID/RECURRENCE-ID (in which the RID may be null). The SEQUENCE and DTSTAMP properties or only used to figure out which versions of two identically identified events is most recent. So any argument that relies on knowing which version was sent to an ATTENDEE is violating the RFC and will have no support. Further, you claim that all ATTENDEES do not have to be kept abreast of the current state of things. However they absolutely can be if the implementors chose such a path. So your model must support that. If it does not it is also in violation of the RFC demands.) -- Michael -- "Doug Royer" wrote in message news:3F381A2A.6080900@Royer.com... > > > Michael Fair wrote: > > For an analysis of why the fixed-id does not create an infinite > > loop see the end of the post. > > > > > >>However, at the very end, there is an unsupported statement: > >> > >> > >>>Since the sender is an ATTENDEE of the instance component > >>>only, it is only authorized to receive replies for that > >>>singleton component. As a consequence, the ORGANIZER's > >>>CUA should not send the requested response. > >> > >>This is not supported by the RFC paragraph quoted. 6.1.7 talks about a > >>REFRESH request from someone not an attendee to the event. > >>If an event consists of multiple instances, the fact that an > >>attendee is invited to only one of them does not exclude her > >>from the set of attendees! An Organizing CUA that is capable > >>of sending a single instance of an event to an attendee > >>without generating a new UID (which it could easily do), is > >>surely capable of forming a response that only includes those > >>instances to which that attendee is invited. > > > > > > First, UID is one event, UID/RECURRENCE-ID is a different event. > > > > In the UID only properties of the event the CU is not list as an > > ATTENDEE and can never be listed as an ATTENDEE lest they be > > invited to all instances of the recurring event. So therefore > > 6.1.7 stands as used. The ORGANIZER receives a REFRESH > > request for UID only. The CU isn't an ATTENDEE of that event. > > > > The only way this might be possible if you fragment the event > > to make two versions of the same UID, one for the ATTENDEE and > > another for every one else. Which leads me to second, this > > violates the mandate that a UID be globally unique. You now > > have two objects of different forms with the same UID and no > > other iTIP compliant disambiguating values. > > Only UID/SEQUENCE/DTSTAMP or UID/SEQUENCE/DTSTAP/RECURRECE-ID > is globally unique in content, not UID by itself. And yes each > of unique SEQUENCE and DTSTAMP for a UID are going to be different > anyway as that is how you differentiate between the different versions > of objects representing the same UID. Why would you think that > the ATTENDEE property should be an exception to that? > > > As just an example of one case where this is a sever issue, > > let's say that the ATTENDEE sent a COUNTER response. > > > > In your model they will have received an object with a UID and > > no RECURRENCE-ID. At best it will be a recurring event with > > only one RDATE, at worst it will just be a singleton. > > Using the best case scenario the CUA might send a COUNTER > > to just the individual instance in which case you lucked out. > > Also using the best case scenario the CUA might detect that > > the CU wants to reschedule every instance of the event (since > > there is only one instance described in the event) and send > > a COUNTER to the UID only component with a new RDATE. Using > > the worst case scenario, the CUA will send a COUNTER message > > to the UID only event trying to turn it into a singleton at > > a new time. > > The ORGANIZER CUA can tell because the ATTENDEE sends what > they want DIFFERENT than what they were sent. If the ATTENDEE > does not include (because they did not get) an recurrence rule. > No problem. Then they are COUNTERing the one instance. > > If an ATTENDEE removed any recurrence rule it is sent then > the ATTENDEE would be telling the ORGANIZER they wish > to remove the additional instances. > > No conflict. > > > In anything but the best case scenario with some luck, they > > will be sending a COUNTER message that attempts to redefine > > the original recurring event. No where in the RFCs does it > > ever instruct an ORGANIZER's CUA to track independent versions > > of the same event for different ATTENDEES. > > The ORGANIZER CUA will already have to know what each ATTENDEE was > invited to - simply compare what they were invited to attend > with what they send, mask out what they were not invited to > and any difference is their COUNTER proposal. In my experience > there are always going to be exceptions to invitations. Customers > cancel meeting and reschedule them all of the time. Reservations > are continually changed and canceled. I would hate to think > that 100% of all attendees would need to see all of the changes > for 100% of all of the other attendees. And as they are not > all required to see all of the other attendees, there ARE > unique to ATTENDEE packets. Yes - there is going > to have to be attendee specific packets sent. > > And because iTIP says: > > Hence, CUAs must persist the following component properties: "UID", > "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each > "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" > and "DTSTAMP" property values associated with the "Attendee's" > response. > > And as the ORGANIZER CUA *will* know what they were invited to and > what they REPLYed to and could be countering. > > I do not see a problem. > > > And in fact it > > actually says in both iCal and iTIP that you can't do that. > > > They say this both explicitly and implicitly every time they > > talk about global uniqueness, updating a master copy (not > > copies) over which only the ORGANIZER has rights to, and > > that they expect CUs will pass these objects around to each > > other for purposes of delegation and FYI (as indicated by > > the reference to a "Party Crasher" which the ORGANIZER > > never invited). > > The over the wire protocol is not the same as the object > itself. The object itself is undefined because of the different > models for calendaring and scheduling. What works for a car > rental agency will not work for a massive company. iCAl/iTIP > specify how to transfer the data, they are not the booked > object itself. > > > > > As two other examples of where your model breaks apart we > > have 3.2.2.3 Delegating to another CU and 3.2.2.6 Forwarding > > to an uninvited CU. Let's use two different people, A and B, > > who are invited to separate instances of a recurring event. > > In your model, they each will have received an object with > > no RECURRENCE-ID which describes a single different date > > and time. If B decides they can't make it, and wants to > > delegate to A, or they decide they think A should be invited > > as well, A's CUA will be totally confused about the message. > > Why? > > > The message from B describes an event which it has on its > > calendar, but has a different primary key. > > Why? Will the UID/SEQUENCE/DTSTART be changed before forwarding > to 'B'? No, so where is the problem? > > > It will have to > > apply the message SEQUENCING rules and if the SEQUENCE number > > doesn't catch the DTSTAMP value will certainly place the > > incoming message as either an old message or one that looks > > like an update that didn't come from the ORGANIZER. > > Who cares where it came from? It is valid or not. > If your are the delegatee, then process it. > > > Assuming that A's CUA was ultra brilliant and managed to > > figure out what was going on it now has the responsibility > > of sending a REPLY to the ORGANIZER. How will the ORGANIZER > > unambiguously know what's going on? > > Because of 'SENT-BY', 'DELEGATED-FROM', 'DELEGATED-TO' and > perhaps more. The object will be tagged (if compliant) > and the ORGANIZER will parse the object sent from B. > > The ORGANIZER matches them up to what the ORGANZIER sent > to 'DELEGATED-TO' as recieved from the original ATTENDEE. > > And from iTIP: > > Cut from iTIP, A == ORGANIZER, 'C' = ATTENDEE delegator > and 'E' == delegatee, my comments in (). > > "C" got a REQUEST from "A". > > "C" sends a REPLY to "A" with the ATTENDEE. "partstat" parameter set > to "delegated" and with a new "ATTENDEE" property for "E". > "E's" ATTENDEE delegated-from" param is set to "C". > > (that how ORGANIZER knows) > > "delegated-from" param is set to "C". "C's" ATTENDEE "delegated-to" > param is set to "E". "C" sends REQUEST message to "E" with the original > meeting request information. The "partstat" property parameter for "C" > is set to "delegated" and the "delegated-to" parameter is set to > the address of "E". An "ATTENDEE" property is added for "E" and the > "delegated-from" parameter is set to the address of "C". > ... > > > > ...cut... (I'll respond to the other points in separate email) > > > > > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Mon Aug 11 19:46: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 TAA11157 for ; Mon, 11 Aug 2003 19:46:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNdFqt086299 for ; Mon, 11 Aug 2003 16:39:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BNdFPE086298 for ietf-calendar-bks; Mon, 11 Aug 2003 16:39:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNdDqt086292 for ; Mon, 11 Aug 2003 16:39:13 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7BNdCEB005159 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 16:39:15 -0700 Message-ID: <3F38291B.9020407@Royer.com> Date: Mon, 11 Aug 2003 17:39:07 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F37FC58.30406@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030807060004020709060702" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030807060004020709060702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F37FC58.30406@Royer.com... > >> >>Bruce_Kahn@notesdev.ibm.com wrote: >> >>>Doug wondered on 08/08/2003 02:54:59 PM: >>> > So - HOW DO YOU DISAMBIGUATE IT FROM AN UPDATE TO A MISSED OBJECT >>> > AS IT LOOKS EXACTLY THE SAME ? >>> >>>iTIP tells you exactly how. Lets start with Section 2.1.5 Message >>>Sequencing since this is a sequencing problem: >> >>The section you quoted does NOT show how to tell if you missed the first >>object. Without the new method you propose for adding an attendee, >>it is possible to use the text you site to differentiate. With your >>proposal then ANY object with a RECURRENCE-ID could be considered >>an update to a missed object, or a new object. > > > Actually that's not true. > This is only true in the case where the original recurrence > description object (the one without the RECURRENCE-ID) has > not ever been seen. > > If I've ever seen that object, then it will tell me what > all the possibly valid RECURRENCE-IDs are. Which is NOT the problem. No one is disputing that SEQUENCE:x where X != 0 is an issue. it is when you may have missed the ORIGINAL object (maybe you missed the SEQUENCE:0 object). Prior to this new invention - it was determinable. > This post does bring up a good point though. > > There might be a situation where the model as I've > presented it has the same problems that the > 'current-value' model constantly suffers from. > > However, it also might just be my misinterpretation > of when and how a RECURRENCE-ID might change. > > To cause the problem it requires both an invitation to > a single instance, and a complete rescheduling of the > entire set of instances. To cause the problem it requires that you somehow missed the SEQUENCE:0 object. Yet it looks *exactly* like a modification. How can I tell which it is when the 1st UID:x I see is SEQUENCE:1 ? What if I was first invited to SEQUENCE:Z yet I missed Z, so I only see the modification:Z+1. Now how do It tell if I missed SEQUENCE:Z ? I no longer can - don't do it that way. > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030807060004020709060702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIzMzkwN1owIwYJKoZIhvcNAQkEMRYEFIQIpxi9 CrLXP2uraT9E6c5vW7D0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADtIQsGBdvvtVC3rn/8uBPMSegZuzUjXly5h/NUGeq006ddtqcQV WXy0iokJMw3Q9Sy+pDHtF+Fhwbupse71mN31aJS6DXV9zjAelNwCKqM3sDcOglI+wfPF1TBg TGODPkvzJvn1q81EaPK0AfepGThicDjTfd4Gq5FrmLJQH2ATP8imvVHkfhoGQOWFMH2YkG8s jMotRy121+wdxE1bSUc9ij9I4ac+Dlj7c8II/uxCZM77kLKkZEMpgzl3F8WNvlSrkUfuEtVo +oFqSt06maE9Jgjucl7S9Ef65Jd9IN8fiqMYy2BaHHE5/EWujwqZVKS5rqBd2t+9ZstVzA9x +54AAAAAAAA= --------------ms030807060004020709060702-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 19:56:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11244 for ; Mon, 11 Aug 2003 19:56:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNnBqt087147 for ; Mon, 11 Aug 2003 16:49:11 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BNnBOd087146 for ietf-calendar-bks; Mon, 11 Aug 2003 16:49:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNn7qt087138 for ; Mon, 11 Aug 2003 16:49:09 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mMQk-0001ku-00 for ; Tue, 12 Aug 2003 01:50:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mMHY-0001hI-00 for ; Tue, 12 Aug 2003 01:40:56 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mMGI-0004op-00 for ; Tue, 12 Aug 2003 01:39:38 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 16:38:32 -0700 Lines: 56 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> <3F3826BE.2090000@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: You're out of context. a "single instance" is not a singleton event. It was a short form of "single instance of a recurring event" which I figured would be understood since that's what this entire conversation has been about. I'm sorry if I confused you. -- Michael -- "Doug Royer" wrote in message news:3F3826BE.2090000@Royer.com... > > > Michael Fair wrote: > > > > > You're right. There is nothing in the RFCs that talks directly > > about this. There is no example of inviting an ATTENDEE to a > > single instance. > > iTIP 3.2.2 REQUEST > > The "REQUEST" method in a "VEVENT" component provides the following > scheduling functions: > > . Invite "Attendees" to an event; > ... > > It gives instruction on how to invite an attendee and it is > not restricted to single or multiple instances. > > And the example in "4.2.1 A Group Event Request" is for > a SINGLE instance VEVENT. Why do you think what the initial > SEQUENCE number is when an ATTENDEE is invited matters? > It does not matter. > > An ATTENDEE could be delegated-to a single meeting > at SEQUENCE:30. It makes not difference. > > The ORGANIZER-CU and/or DELEGATED-FROM-CU does not need to tell > every ATTENDEE about every meeting they will not be attending in > a series of meetings. That is often good business practice. > > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Mon Aug 11 20:21: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 UAA11611 for ; Mon, 11 Aug 2003 20:21:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C0DYqt089068 for ; Mon, 11 Aug 2003 17:13:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C0DYcM089066 for ietf-calendar-bks; Mon, 11 Aug 2003 17:13:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C0DWqt089060 for ; Mon, 11 Aug 2003 17:13:33 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mMoP-0001w1-00 for ; Tue, 12 Aug 2003 02:14:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mMoO-0001vt-00 for ; Tue, 12 Aug 2003 02:14:52 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mMn8-0005TW-00 for ; Tue, 12 Aug 2003 02:13:34 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 17:12:26 -0700 Lines: 96 Message-ID: References: <3F38225A.3080307@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: Umm.... Ok... Let's follow this train wreck.... Again, show me code. Update an instance of a recurring event. (For arguments sake move Friday, June 13th to the 12th) Now invite an uninvited CU to the new 12th meeting. Remember, as per 3.2.2.6 which talks about forwarding: When forwarding a "REQUEST" to another CU, the forwarding "Attendee" MUST NOT make changes to the VEVENT property set. by VEVENT property set they mean the entire set of properties on the VEVENT. In other words, the VEVENT must be sent wholesale, exactly as is. There is an implied exception in which the forwarder MAY add the new recipient as an ATTENDEE but isn't encouraged to. After you do this, show me how you didn't change the property set, and why the recipient CUA isn't confused by this. -- Michael -- "Doug Royer" wrote in message news:3F38225A.3080307@Royer.com... > > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > Doug asked on 08/08/2003 02:53:38 PM: > > > Its becoming clear to me that you did not understand iTIP when you > > > wrote your project and you did not know that these new proposals > > > of yours were already covered in iTIP and we do not need new ways > > > to do things that are already documented. > > > > I have not proposed anything new. > > Your propiosing that to add and attendee, you send a instance update. > > That *IS* new. > > Here are some snips of how iTIP says to uinvite an ATTENDEE: > > 3.2.2 REQUEST > > The "REQUEST" method in a "VEVENT" component provides the following > scheduling functions: > > . Invite "Attendees" to an event; > .... > > ... > The "Organizer" originates the "REQUEST". The recipients of the > "REQUEST" method are the CUs invited to the event, the "Attendees". > "Attendees" use the "REPLY" method to convey attendance status to the > "Organizer". > ... > > 3.2.2.6 Forwarding to An Uninvited CU > > An "Attendee" invited to an event may invite another uninvited CU to > the event. The invited "Attendee" accomplishes this by forwarding the > original "REQUEST" method to the uninvited CU. The "Organizer" > decides whether or not the uninvited CU is added to the attendee > .... > > Which *IS* distinctly different than: > > 4.4.2 Modify A Recurring Instance > > In this example the "Organizer" issues a recurring meeting. Later the > "Organizer" changes an instance of the event by changing the > "DTSTART" property. Note the use of "RECURRENCE-ID" property and > "SEQUENCE" property in the second request. > > > > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Mon Aug 11 20:31: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 UAA11816 for ; Mon, 11 Aug 2003 20:31:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C0MEqt090476 for ; Mon, 11 Aug 2003 17:22:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C0MEUl090475 for ietf-calendar-bks; Mon, 11 Aug 2003 17:22:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C0MCqt090469 for ; Mon, 11 Aug 2003 17:22:13 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C0MCEB005422 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 17:22:14 -0700 Message-ID: <3F38332F.6010807@Royer.com> Date: Mon, 11 Aug 2003 18:22:07 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP -12 and LAST CALL (hopefully) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070200030506020302030801" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070200030506020302030801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit G. Barnes wrote: > I've just submitted another 'bug report', that is mostly typos. In any > event, nothing there is really an 'issue', but there were a few things that > deserve a little more publicity than just a bug report: > > --------------------------------------------------------------- > > Section 3.3.1 States that 'CREATE' can be implied for iTIP objects. What > does that mean? That you can omit a CMD if you include an iTIP object, and > the server should infer you want to CREATE it? If so, this should be > explained clearly, here and in 10.1 or 10.1.4. Note that this > 'implied command' probably contradicts Doug Royer's proposed BEEP profile, > which states CMDs are mandatory. Thanks - your right. I'll remove the 'optional' from the text. It was discussed in the past. I'll change it to: CREATE - Create a new object on the CS.(Section 10.1.4) > 6.1.1.13 The paragraph in this section is extremely difficult to > understand. The key point, I gather, is that 'If there are two VALARM > components in a given VEVENT, then both components are tested' and if either > matches (and the STATE=BOOKED), then the UID, SUMMARY, DESCRIPTION of that > VEVENT is returned. As it reads now, the 3rd sentence says *all* UID, > SUMMARY, DESCRIPTIONS from all VEVENTs are returned if we get one match, > which is surely not right. > Assuming this is right, a more plausible rewrite might be: > > If a query references a component and a component or property > contained in the component, any clauses referring to the contained > component or property must be evaluated on all of the contained > components or properties. If any of the contained components or > properties match the query, and the conditions on the containing > component are also true, the component matches the query. > > For example, in the query below, if a BOOKED VEVENT contains multiple > VALARMs, and the VALARM.TRIGGER clause is true for any of the VALARMs > in the VEVENT, then the UID, SUMMARY, and DESCRIPTION of this VEVENT > would be included in the QUERY results. > > [Someone please check my work here. I may be missing something...] What you don't want an obscure wildcard? :-) Yes and it has had a few rewrites. > 6.1.2 'A CU's UPN MUST never be an e-mail address that is deliverable to > a different person as there is no requirement that a person's UPN MUST BE > their e-mail address'. The logic in this sentence is contradictory (if > there's no requirement that the UPN be a person's mailing address, then why > does that imply they can't have a UPN that is someone else's e-mail address? > It would seem to imply the exact opposite). I'll rewrite it into two sentences: A CU's UPN MUST never be an e-mail address that is deliverable to a different person. There is no requirement that a persons UPN be their e-mail address. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070200030506020302030801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAwMjIwN1owIwYJKoZIhvcNAQkEMRYEFO4OMJ/0 yCYqf7xCokX5lWzY3z9XMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEOYo/dtt3PsvkZAwKLy4xQBfU85TJmcEHdh7gPzh8c0fiKUUJMq ndO6CYEGoiiHKTGgmfZ2IpwEZlO9DHFUdlwuHGvXZwAVAOnKzno4Rs/L9zp/7y/FAL3FX4os hWX+TWFtcVIkXKDbXOhZLLrV8Zu2tfECiC9CGiypuXsG5LNdizsRK5wn/kwtou+yLQ5rNDTv NSo7LOCCOnNniX0j0mf0A3ephmgeyLOsQ5qcJVGsW6JmyDXpklWVd8Rv/7/7tPAdIl9ritDy 2JySOrC/BANz89ghwsAJW1aYFc5hGZwZ/2Ngyzw0ua0K2plc5UVySEvGMAQk/jmjc5yQcxu3 OfoAAAAAAAA= --------------ms070200030506020302030801-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 20:42: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 UAA12005 for ; Mon, 11 Aug 2003 20:42:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C0Zjqt092233 for ; Mon, 11 Aug 2003 17:35:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C0ZjKs092232 for ietf-calendar-bks; Mon, 11 Aug 2003 17:35:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C0Zhqt092221 for ; Mon, 11 Aug 2003 17:35:44 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mN9s-0005nu-00 for ; Tue, 12 Aug 2003 02:37:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mN9r-0005nm-00 for ; Tue, 12 Aug 2003 02:37:03 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mN8b-0006Bz-00 for ; Tue, 12 Aug 2003 02:35:45 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 17:34:36 -0700 Lines: 63 Message-ID: References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@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: > To cause the problem it requires that you somehow missed the > SEQUENCE:0 object. Yet it looks *exactly* like a modification. > How can I tell which it is when the 1st UID:x I see is > SEQUENCE:1 ? Ok, in an attempt to finish this train of thought since nothing we have said about this topic in what feels like umpteen posts I will try to say it a different way (again). You don't care what it actually it is, it's an invite to you. You treat it like an invite, your REPLY to it like an invite, and the world is a happy place. > What if I was first invited to SEQUENCE:Z yet > I missed Z, so I only see the modification:Z+1. In a fixed-id model Z+1 _is_ the most recent version of the event so you couldn't care less about whether or not you saw Z. You don't need Z. Z and Now how do It tell if I missed SEQUENCE:Z ? > I no longer can - don't do it that way. If you are saying that "Z" was a recurring description, and that "Z+1" is an instance modification that's a bit different. If the CUA thinks there's something fishy about the SEQUENCE numbers it can send a REFRESH if it likes. In fact, if Z+1 is the very first instance in the entire set of events refrenced by the recurring series, and it only describes an instance of a recurring event, it SHOULD request a REFRESH and use it to single that it might have missed a message. Right after it puts it on the calendar and REPLYs to it as a new invite. This behavior should be exactly the same in both models. Are you saying that in the 'current-value' if Z described a recurring event, and Z+1 described an instance update, and the CUA saw Z+1 (the update) before it saw Z that the CUA should ignore or refrain from processing the message at all until it sees Z? Tsk, Tsk Doug that's not good. But to give you the benefit of the doubt. Doug, in the 'current-value' model what should a CUA do if it received Z+1 (the update to an instance) before it saw Z (which described the recurring event)? -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Aug 11 20:45: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 UAA12067 for ; Mon, 11 Aug 2003 20:45:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C0cKqt092691 for ; Mon, 11 Aug 2003 17:38:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C0cKoH092690 for ietf-calendar-bks; Mon, 11 Aug 2003 17:38:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C0cJqt092681 for ; Mon, 11 Aug 2003 17:38:19 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C0cJEB005510 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 17:38:21 -0700 Message-ID: <3F3836F6.3000208@Royer.com> Date: Mon, 11 Aug 2003 18:38:14 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> <3F3826BE.2090000@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000001020403010502080901" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000001020403010502080901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > You're out of context. > > a "single instance" is not a singleton event. It > was a short form of "single instance of a recurring > event" which I figured would be understood since that's > what this entire conversation has been about. > > I'm sorry if I confused you. No confusion as there is no difference to the ATTENDEE receiving a VEVENT with no recurrence rules who would not and perhaps should not have any idea if the ORGANIZER had invited others to that booked UID. So if they get part or the entire copy of the booked VEVENT makes no difference to them as they could not tell anyway. And that is my point. iTIP already tells you how to invite an ATTENDEE. And the ORGANIZER is already going to have to track ATTENDEE instance attendance. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000001020403010502080901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAwMzgxNFowIwYJKoZIhvcNAQkEMRYEFJejij1i v34D/a15+AM4nQPXmz27MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGaYNwr22rAA9Py4OA7QMStK9HGf3GRUfZfoa6hbNfT0pSd4NZlq 0rBZJMMzjR9XdPJn3GGBdPR9TFeftyBxbdfFYgq+7EYGnz6hyBbi/HEtWoY07F32Zlh3Io2i X/AnJbyQ4QAsSejx/IBFw3+bvhXab70exN8GkMRPHrtEq7tEgtcfTBLM7eXUjltkb2spFLow W41MSVyeGe/nzX8K+z9PEZa3wjvWztKqFIv9uROyUgw6fXb3EW7JxuYbS45IeiSFu/YhmJjI aeGk8Ze2lufRuKl36rF8Yqp0e3+Px3vU8Fvwrqa+5DAS0K2FYXbMMQfFGXjPN6nL9t8xpb0m F7oAAAAAAAA= --------------ms000001020403010502080901-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 21:21:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12807 for ; Mon, 11 Aug 2003 21:21:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1Cwqt098200 for ; Mon, 11 Aug 2003 18:12:58 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C1CvQv098199 for ietf-calendar-bks; Mon, 11 Aug 2003 18:12:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1Csqt098186 for ; Mon, 11 Aug 2003 18:12:55 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mNjp-00063G-00 for ; Tue, 12 Aug 2003 03:14:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mNjo-000638-00 for ; Tue, 12 Aug 2003 03:14:12 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mNiY-0007Eg-00 for ; Tue, 12 Aug 2003 03:12:54 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 18:11:44 -0700 Lines: 40 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> <3F3826BE.2090000@Royer.com> <3F3836F6.3000208@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: > And that is my point. iTIP already tells you how to > invite an ATTENDEE. And the ORGANIZER is already > going to have to track ATTENDEE instance attendance. They track the instance attendence in the components referenced by the UID/RID. Let's assume a world where everyone always got all information. I know it's not how you work, but it is allowed by the RFC and I think it makes things easier because you just know that everyone always gets everything (no intellignece needed). If I do a "REFRESH" on a UID/RID I'm asking for the latest version of that component which, in our transparent world of pretend for the moment, will include the attendence status for each of the attendees of that instance. If I do a "REFRESH" on just a UID that references a recurring event I am asking for the latest version of that component which, in our transparent world of pretend for the moment, will include not only the base attendence list for the master component, but will also include the attendence status for each and every attendee in every instance where something is different. That is why the recurrence instances can be separately "referenced and versioned". However doing this does not mean that the ATTENDEE property in any way, shape, or form is ever even considered when attempting to identify how to process the event, or which component of the calendar the message is referencing. -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Aug 11 21:23: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 VAA12853 for ; Mon, 11 Aug 2003 21:23:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1Ehqt098564 for ; Mon, 11 Aug 2003 18:14:43 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C1EgY3098562 for ietf-calendar-bks; Mon, 11 Aug 2003 18:14:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1Eeqt098554 for ; Mon, 11 Aug 2003 18:14:40 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C1EdEB005785 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 18:14:41 -0700 Message-ID: <3F383F79.6070107@Royer.com> Date: Mon, 11 Aug 2003 19:14:33 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP -12 and LAST CALL (hopefully) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030800010604040808040108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030800010604040808040108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 08/11/2003 05:50:28 PM: > > If I do not get to it soon, feel free to use the diff tool of your > > choice and post them. > > Not my job; thats something the editor does. Bruce - I supplied them in the past and I have NOT seen any other editor do such a thing. No not my 'job'. Feel free to post a diff. When I posted them in the past to my web site you complained because you wanted it on calsch.org (which 'I' do not own and until recently had NO access to change the web pages.) Are you going to complain if I post them to my webite this time? > > Pat has just declared on this list that the CHAIRs declare such a list, > > NOT the editors. Pat - do you have any open issues? > > Thats NOT what she said. She wrote: > > >3. Saying that no one responding to a comment by Bruce stops the issue is > >the chairs call, not the editors. I did NOT say "...that no one responding to a comment by Bruce..." I said "Bruce has declared twice that it has not been discusses and proposed no solution." The reason that I said that was because you have declared twice on this list that it has not been discussed and you did not propose a solution. > Its the chairs call if the issue is resolved or not; the list is not > theirs to maintain. Thats something for the editor to do. You did it > before so you should be familiar w/the process. I did not declare the list resolved. I said: " With the addition to the typo's that people have filed using bugzilla and the ones on this list it looks as if CAP is almost ready to release. The only non-typo issue seems to be the BEEP profile. Bruce has declared twice that it has not been discusses and proposed no solution. So that response is a dead end. If anyone (including Bruce) has a proposal or objection to the BEEP profile below - please speak up." And after 20+ years on IETF mailing lists, it is *RARE* for an editor to post a list. I did in the past does not mean that I have to do it now. If you or others have issues - PLEASE post them. > > It was addressed in CAP-11, the ABNF updates were made and I did > > comment in the CAP-11 announcement that no proposals were submitted. > > Bruce- did the updates in -11 solve the problem as you see it? > > I did not see CAP 11. As I said I have too much to do to reread CAP 11 > front to back to find the differences. Thats why I asked for a diff to > be posted. No diffs still for 10-11 so I was reposting what I could > recall off hand. I dont recall seeing any WG discussion of some issues > like the fact that queryc was only in the CREATE command and no other. > I would expect that the ABNF for all commands would be changed such > that its clear what commands can or cannot take queryc, etc but thats > not something we talked about at all. Declaring that you have not read -11 or even bothered to run a diff yourself tells me that I can not worry and ignore your comments about CAP until you read it for yourself. I do not get paid to do this and I will not spend any more time with you on the subject of CAP if you do not read the proposals. I'll simply take your word for it - you do not know because you do not have the time to look. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030800010604040808040108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAxMTQzNFowIwYJKoZIhvcNAQkEMRYEFKowkxMC MmDH5wA6ZfxitWmTDpCzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADiCyoD74eadZyP2eediAj6S3IIHMCiLmyMz4YK2SCBp+TzNHkwR xbpv//Se1xQEpHi5Gp2KhfLnH4lqkfsl/3Lgt9dGyw6WMq4k7UK7RLzgcqgmJsDZEP2wIKMp 8k++8o1TmBTyp/ynG9rYEZDiD2l6hPax721GR8GeLNtZsdT57k6KGc7ZwXuCm0XXedyLWtYg 4NOQb1FDiEr/inQryp/ayX9KbkgqgSNv0CGZXdEa66kWJ5Ga2xPukxUWR/Nnu+1U1jKyO/BH 0ssfyMvt0dvzPwUrrJApoR+GtY75HH0DzgzJbHyImMdUrlEOu4kb7iu/VK55eU6fkJInuGVp GzYAAAAAAAA= --------------ms030800010604040808040108-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 21:23: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 VAA12882 for ; Mon, 11 Aug 2003 21:23:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1H7qt098888 for ; Mon, 11 Aug 2003 18:17:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C1H7ua098886 for ietf-calendar-bks; Mon, 11 Aug 2003 18:17:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1H5qt098874 for ; Mon, 11 Aug 2003 18:17:06 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C1H5EB005809 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 18:17:07 -0700 Message-ID: <3F38400C.8010206@Royer.com> Date: Mon, 11 Aug 2003 19:17:00 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020202080704050904040101" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020202080704050904040101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>To cause the problem it requires that you somehow missed the >>SEQUENCE:0 object. Yet it looks *exactly* like a modification. >>How can I tell which it is when the 1st UID:x I see is >>SEQUENCE:1 ? > > > Ok, in an attempt to finish this train of thought since > nothing we have said about this topic in what feels like > umpteen posts I will try to say it a different way (again). > > You don't care what it actually it is, it's an invite > to you. You treat it like an invite, your REPLY to it > like an invite, and the world is a happy place. Except your CUA is out of sync with the ORGANIZER if it was an update and you missed the original. > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020202080704050904040101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAxMTcwMFowIwYJKoZIhvcNAQkEMRYEFCsLMYer oU9OCd8VkJDovEtTtxo7MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJzIJJOTGBAk1iDf21sj9z171sTNJybKM3TbZj6j77wOVzNdKRaH LdpinOBx4lPMRPI4dKHCvDfMKC8ahivnMM1wSnTJ7Qk7MQZXU6RUF6PjtmS+iAUmQe6nntnn Gnoi9IBODIyKHJ9n6azIfmOelVwvgpc+ZPD8Bw9t0xswWvplGUXELpvqyWGU4/Dne2JPMcRO cjsc826rEXsMq91dk9v2T81iONFiDtfBXwep4LioAwJ2m58IHTAN92YyacEwTpT/Kbdogo+z WKpEbGyyzueGe3m8Is/4CWlipwRmdjFKK5D1oCuxAEfOnHznQBzGzFGyomimwrNmwUC9sg0F DwMAAAAAAAA= --------------ms020202080704050904040101-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 21:25: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 VAA12938 for ; Mon, 11 Aug 2003 21:25:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1JDqt099169 for ; Mon, 11 Aug 2003 18:19:13 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C1JDrn099168 for ietf-calendar-bks; Mon, 11 Aug 2003 18:19:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1JBqt099160 for ; Mon, 11 Aug 2003 18:19:11 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mNpv-00066W-00 for ; Tue, 12 Aug 2003 03:20:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mNoN-00064u-00 for ; Tue, 12 Aug 2003 03:18:55 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mNn8-0007Js-00 for ; Tue, 12 Aug 2003 03:17:38 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 18:16:27 -0700 Lines: 54 Message-ID: References: <3F38270C.7050106@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: While not in direct reply to this response, at the end of at least two messages, Bruce has asked a specific and direct question of you Doug. Does each instance of a recurring event have its own SEQEUNCE or is there one SEQUENCE value for the entire recurring series which they all share? In case the question isn't clear: If I have a new recurring event and the only I change I make is to update one instance in which I use SEQUENCE:1, and then I go to update a totally different instance, is the SEQUENCE value for the second instance 1 or 2? -- Michael -- "Doug Royer" wrote in message news:3F38270C.7050106@Royer.com... > > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > Doug replied on 08/08/2003 03:37:26 PM: > > > I do not follow how or why you think his point has anything to do > > with storage > > > format. Are you saying because your storage format does not allow for > > > it to change that you want other vendors to change? > > > > Tim cited the example of infinite recurrence as a factor in his decision > > for how he interpreted the RFCs. I was responding to this by pointing > > out that the internal storage format of any CUA or CS is NOT covered by > > iCalendar or iTIP. iCalendar is an interoperability format for on the > > wire and iTIP is the semantics for understanding the data it represents. > > > > Are you now saying that all iTIP implementations MUST use a storage > > format thats basically native iCalendar? > > No. > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Mon Aug 11 21:32: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 VAA13090 for ; Mon, 11 Aug 2003 21:32:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1Oeqt099636 for ; Mon, 11 Aug 2003 18:24:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C1OeoX099634 for ietf-calendar-bks; Mon, 11 Aug 2003 18:24:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1Ocqt099629 for ; Mon, 11 Aug 2003 18:24:38 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C1OcEB005873 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 18:24:40 -0700 Message-ID: <3F3841D1.9000005@Royer.com> Date: Mon, 11 Aug 2003 19:24:33 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080002070408050203070001" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080002070408050203070001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > >>Now how do It tell if I missed SEQUENCE:Z ? >>I no longer can - don't do it that way. > > > If you are saying that "Z" was a recurring description, > and that "Z+1" is an instance modification that's a > bit different. > > If the CUA thinks there's something fishy about the > SEQUENCE numbers it can send a REFRESH if it likes. And how would it know? You just made an update look like a new object. Its out of sync and can't even know that it is out of sync. > In fact, if Z+1 is the very first instance in the > entire set of events refrenced by the recurring series, > and it only describes an instance of a recurring event, > it SHOULD request a REFRESH and use it to single that > it might have missed a message. Right after it puts > it on the calendar and REPLYs to it as a new invite. How would it know that? You sent a modification (or was it a new event?). > This behavior should be exactly the same in both models. > > Are you saying that in the 'current-value' if Z described > a recurring event, and Z+1 described an instance update, > and the CUA saw Z+1 (the update) before it saw Z that the > CUA should ignore or refrain from processing the message > at all until it sees Z? > > Tsk, Tsk Doug that's not good. But it can happen over iMIP. Objects can get out of order. Just check the Received-by lines compared to the 'Date' lines of email on this WG list. They are not all in order by 'Date' or 'Received-by'. They are just mostly ordered by one or the other. > But to give you the benefit of the doubt. > > Doug, in the 'current-value' model what should a CUA > do if it received Z+1 (the update to an instance) before > it saw Z (which described the recurring event)? As you would NOT invite someone with an object that also looked like a modification, it could tell that it was a modification and do a REFRESH. But because you want that exact same object it to also look like an invitation it can no longer tell in anyone's model. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080002070408050203070001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAxMjQzM1owIwYJKoZIhvcNAQkEMRYEFH9CZCiG KMajXqu6m12dPYweSEqwMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBABK6vdjvEGxf0saIPCMxPLFk8bk7Cjmpy8OkzNr3g8mJJF62J6Ok LnMluyIXLTD6WRnYWbEbv1dDzswK375xK0GP/yFWYBTDNC5rzMinmI20bF+XwTVsWVBIScZI fZoCqo6so0ReI5JlEbI5nkkFMyEp4/WdUhec5r5UgoKovBeBQ8ZHTaV0qFJDx/UrfHMEzC/O 9lwO+mD8A3o78dDZNdil0MC6R9JWQbqeIicvo3hTY6b0GmfdSxlJeNg1YBPgIErsplg36zj4 yUXmmx2aznv6O9YAWBR1QEVirhrftG90uvmJGvJBWU5ph8tr+1f6t7s7ciCW9gNVCYZW9E7L HgwAAAAAAAA= --------------ms080002070408050203070001-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 21:33: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 VAA13125 for ; Mon, 11 Aug 2003 21:33:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1Qaqt099747 for ; Mon, 11 Aug 2003 18:26:36 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C1QaMQ099746 for ietf-calendar-bks; Mon, 11 Aug 2003 18:26:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1QYqt099741 for ; Mon, 11 Aug 2003 18:26:35 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C1QZEB005892 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 18:26:36 -0700 Message-ID: <3F384245.5020301@Royer.com> Date: Mon, 11 Aug 2003 19:26:29 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> <3F381A2A.6080900@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070403050800060504090600" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070403050800060504090600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > All I can say Doug is show me the code. > > Please show me the chain of messages that go between > the different CUA's and what in iTIP tells each CUA > how to process these messages. > > Here's the task. Here is the answer: Read iTIP the example is in iTIP. It goes through great pains to explain that process. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070403050800060504090600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAxMjYyOVowIwYJKoZIhvcNAQkEMRYEFCm2dLC5 m75Yk3IvUIF5fFg25cdQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAFq800kOsR4dy4g9A+K2IKA4GGLKpNlwGzPBeF/C9G5haF1mJ0WJ 6JHjS5UBVhCE5S1hk4jCNBg9AhSn/FJ7vE+/He+0F8yEdh+cxNb0vfVIGBs6wlssR0QPnpof fwkK7jdwAE8xOCCk8kCzt/G/KwWuWZ6B+4CeJ9pvEw6ASfQYfdNBAPHAnYW3OpgzpxMg1iO1 4XmI4pFfDE2SjrK2s66lWEw4kv/edGTXLkGs3XVV0r0iLGprgCiLYiqmzxT172wuw7zHn5px X45A7wp2xEKyMK6rsO0109Tj/jaNh5y+HAm36Wm7AxgFgvGUR+aRC62KP5u41bwEkUEtQje/ KZUAAAAAAAA= --------------ms070403050800060504090600-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 22:02:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13783 for ; Mon, 11 Aug 2003 22:02:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1sqqt001318 for ; Mon, 11 Aug 2003 18:54:52 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C1sqYg001317 for ietf-calendar-bks; Mon, 11 Aug 2003 18:54:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C1soqt001311 for ; Mon, 11 Aug 2003 18:54:51 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C1soEB006196 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 18:54:52 -0700 Message-ID: <3F3848E5.3000205@Royer.com> Date: Mon, 11 Aug 2003 19:54:45 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F38270C.7050106@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060500070508020100000100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060500070508020100000100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > While not in direct reply to this response, at the > end of at least two messages, Bruce has asked a > specific and direct question of you Doug. > > Does each instance of a recurring event have its own > SEQEUNCE or is there one SEQUENCE value for the entire > recurring series which they all share? > > In case the question isn't clear: > If I have a new recurring event and the only > I change I make is to update one instance in > which I use SEQUENCE:1, and then I go to > update a totally different instance, is the > SEQUENCE value for the second instance 1 or 2? If you update any date or recurrence rule (and other things), then you have to update the SEQUENCE, but you do not necessarily have to send it to all attendees. So the booked object is at '2'. The rules are in iCal/iTIP, so I am not sure of your question. There is an example in iTIP that covers that case exactly. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060500070508020100000100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAxNTQ0NVowIwYJKoZIhvcNAQkEMRYEFEZaHIEf kgi0jKwCRwiOwQvAUIAfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAH7Mk7Cn/knq+7IWSNGv/tD1oVXUD1ajmaMZO6UwIbuId1ueYnVn HIhtiD7O8+7ViHPmAjGGAvmL/SCcBYpJNLxqppS8YQ7RhdPaAvxcytL6wD6Y8UMgnaMG7UQO 3dGm7XY2vj+jeDnuo4P6nNOdYVfVQ6hIfon7hhW39CPGaJs3YQ1rQ/MRAnk2SOTSb1s7/a1a vU/PFh5S0fGOgzC4Ai4eWda6yiNumxasMOxYiO/36A9bOI1vi9ximovZ7asWTCEuf7vz3mFW X0CYckB2OlspHtF/oiAYiPhm5q5Vqp13aqes0QMVBkm/LxTQUhgc173TCcvlC6UkXLO5Pq5m dYAAAAAAAAA= --------------ms060500070508020100000100-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 22:17: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 WAA13996 for ; Mon, 11 Aug 2003 22:17:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C29Iqt001905 for ; Mon, 11 Aug 2003 19:09:18 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C29In3001904 for ietf-calendar-bks; Mon, 11 Aug 2003 19:09:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C29Gqt001899 for ; Mon, 11 Aug 2003 19:09:16 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C26HEB006308 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 19:06:24 -0700 Message-ID: <3F384B93.9020209@Royer.com> Date: Mon, 11 Aug 2003 20:06:11 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> <3F3826BE.2090000@Royer.com> <3F3836F6.3000208@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050004090704050108070603" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050004090704050108070603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>And that is my point. iTIP already tells you how to >>invite an ATTENDEE. And the ORGANIZER is already >>going to have to track ATTENDEE instance attendance. > > > They track the instance attendence in the components > referenced by the UID/RID. iTIP: Hence, CUAs must persist the following component properties: "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" and "DTSTAMP" property values associated with the "Attendee's" response. And as it says **Attendee's response** it is talking about the ORGANIZER CUA. > Let's assume a world where everyone always got all > information. I know it's not how you work, but it > is allowed by the RFC and I think it makes things > easier because you just know that everyone always > gets everything (no intellignece needed). > > If I do a "REFRESH" on a UID/RID I'm asking for > the latest version of that component which, in our > transparent world of pretend for the moment, will > include the attendence status for each of the > attendees of that instance. No, it will include the attendee status of at least yourself and MAY include other attendees. It could be a massive security problem at public events. Lets see if the president is attending, at which game. We covered this before. Do you disagree? > If I do a "REFRESH" on just a UID that references > a recurring event I am asking for the latest version > of that component which, in our transparent world of > pretend for the moment, will include not only the > base attendence list for the master component, but > will also include the attendence status for each > and every attendee in every instance where something > is different. No. As explained above. If it did, then it still does not mean that the object sent to that attendee contains instances where that attendee does not need to know about and for the reasons explained above. There is no reason that an attendee need to know who is attending or when other meeting are taking place. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050004090704050108070603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAyMDYxMVowIwYJKoZIhvcNAQkEMRYEFIISBzE8 s0vAVvx+QDKYZKOd252kMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBABRT+BCb0X89nmV1rvGa7l1FUOLcmXqyOPJtTcyxKtbVAlxCWkeF ySgiVGLlQR3PDE+oiM42aKtkTBsahU0FquD7yZa/VCWpTQ9Skdnv3wjCd/iFDMxX+I3z37ss RTIa1xj1x0H6odDSyHG0iAL+zFNzjP5Leyjxmi7Uo50kRMjH/6f5irUP46KtD3Wa7XXE9Qw7 NR43LtTd61Mn4pc9Q9pJqwbRICxUdAWwnrHkOTUQZPDB2KJDzv/l3lpp3l80V1ftAHg2mRgt lWysooPUqRCZDrQ4ykKvwwC3OvSvSZPhLgC2VVUHaJ3aZHU/TI0pA1YhsSS7dBPh4e8bzNEH biAAAAAAAAA= --------------ms050004090704050108070603-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 22:37: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 WAA14366 for ; Mon, 11 Aug 2003 22:37:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C2T9qt002660 for ; Mon, 11 Aug 2003 19:29:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C2T9mu002659 for ietf-calendar-bks; Mon, 11 Aug 2003 19:29:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C2T5qt002653 for ; Mon, 11 Aug 2003 19:29:06 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mOvZ-0006c0-00 for ; Tue, 12 Aug 2003 04:30:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mOvX-0006bg-00 for ; Tue, 12 Aug 2003 04:30:23 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mOuH-0000V7-00 for ; Tue, 12 Aug 2003 04:29:05 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 19:27:53 -0700 Lines: 191 Message-ID: References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@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 don't know what this hangup on modification versus new object is about? It's been explained several times and since you continue to persist, it will continue to be repeated until you say something that is actually consistent and responsive to what's been written. An instance of an event is an object in its own right. An update to an instance of an event is targeted specificly at that separate independent object. If I send a REQUEST and it contains UID:1/RID:1 then it is a reference to the object UID:1/RID:1. UID:1 part is only the first half of the primary key. It doesn't, in anyway shape or form, have any bearing on the totally separate object UID:1. The CUA doesn't need the object UID:1. The CUA might hope to someday see UID:1 but it can be perfectly functional without it. It has seen UID:1/RID:1. It has processed UID:1/RID:1. UID:1/RID:1 is a uniquely identifiable singleton. The CUA treats UID:1/RID:1 as a singleton. It sends a REPLY to UID:1/RID:1 is a singleton. It can get invited to UID:1/RID:1 in the same way it could get invited to any other singleton. UID:1/RID:1 has its own independent versioning just like any other singleton. Do you understand this yet? With that in mind read my responses to your questions. "Doug Royer" wrote in message news:3F3841D1.9000005@Royer.com... > > > Michael Fair wrote: > > > >>Now how do It tell if I missed SEQUENCE:Z ? > >>I no longer can - don't do it that way. > > > > > > If you are saying that "Z" was a recurring description, > > and that "Z+1" is an instance modification that's a > > bit different. > > > > If the CUA thinks there's something fishy about the > > SEQUENCE numbers it can send a REFRESH if it likes. > > And how would it know? You just made an update look > like a new object. Its out of sync and can't even > know that it is out of sync. It would know because it received a message for the singleton UID:1/RID:1 which because the RID value is not null, it knows should be part of a recurring set. However, it has no records for a UID:1/RID:NULL recurring event description object on its calendar. Speaking on behalf of the CUA: "Hmm, I just received an invite to the singleton UID:1/RID:1 however I have no record of a UID:1 object that tells me which RIDs are actually valid. Something is fishhy. Well I'll just assume that this object I received is valid, process it like the singleton that it is and request a REFRESH for the UID:1/RID:NULL object. I probably just missed a message somewhere." That's how it knows. > > In fact, if Z+1 is the very first instance in the > > entire set of events refrenced by the recurring series, > > and it only describes an instance of a recurring event, > > it SHOULD request a REFRESH and use it to single that > > it might have missed a message. Right after it puts > > it on the calendar and REPLYs to it as a new invite. > > How would it know that? You sent a modification (or > was it a new event?). Doesn't matter what I sent, it gets processed as a new singleton UID:1/RID:1. The absence of UID:1/RID:NULL from my calendar indicates I might have missed something. > > This behavior should be exactly the same in both models. > > > > Are you saying that in the 'current-value' if Z described > > a recurring event, and Z+1 described an instance update, > > and the CUA saw Z+1 (the update) before it saw Z that the > > CUA should ignore or refrain from processing the message > > at all until it sees Z? > > > > Tsk, Tsk Doug that's not good. > > But it can happen over iMIP. Objects can get out of > order. Just check the Received-by lines compared > to the 'Date' lines of email on this WG list. > They are not all in order by 'Date' or 'Received-by'. > They are just mostly ordered by one or the other. I totally know it can happen, I never said it couldn't. I never said I didn't even want it to. The fact that it can happen is the entire reason a fixed-id model is totally required. If the 'current-value' can't hack it in that environment it should get out of the kitchen. It's been repeatedly shown how the 'current-value' model falls flat on its face when faced with trying to deal with missequenced messages. You have not provided any discussion to the contrary yet. Since you seem to have nothing to say about our demonstrations of the 'current-value' falling flat on its face in this regard, I can only assume that you agree that 'current-value' model falls flat on its face. But rather than conceed to the flaws and discuss workable solutions, you choose to ignore what we say so you can continue to try to harp on a flaw in the fixed-id model that just isn't there. The fixed-id as has been continuously demonstrated to perform exceedingly well in this exact situation. > > But to give you the benefit of the doubt. > > > > Doug, in the 'current-value' model what should a CUA > > do if it received Z+1 (the update to an instance) before > > it saw Z (which described the recurring event)? > > As you would NOT invite someone with an object that > also looked like a modification, it could tell that > it was a modification and do a REFRESH. But because > you want that exact same object it to also look like > an invitation it can no longer tell in anyone's model. I don't get it. You didn't answer the question. What does the CUA do with the message it receives? Does it put on the calendar or not? Does it ask the participant if they want to go or not? Does it send a REPLY or not? Whatever logic you are you using for the 'current-value' model to detect that it should a REFRESH request can also be used in the 'fixed-id' model I assure you. Are you assuming that a REQUEST for a new object can't trigger a REFRESH while the CUA processes it? If it helps you understand this better I can call it an update to a missed object without losing any ground or changing any semantics. It doesn't track iTIP, but you don't seem to care about that on this point anyway. Ok fine, let's pursue this pedantic exercise. Here goes: Doug, in the fixed-id model a message which to you looks like an update (note this is not a reschedule! No incrementing of the SEQUENCE from the ORGANIZER's copy is done) is used to invite a new CU to an instance of a recurring event. The CUA will process it as an update to an object that doesn't exist (wtf?). The CUA will put it on its calendar, it will send a REPLY with the partstat set according to the CU's preference, and processing it will trigger a REFRESH request. Does that make you happier? The net result is the exact same. A REFRESH got sent and the user got invited to singleton they were supposed to be invited to. You just chose to process it in a way that doesn't follow the terminology of sections 2.1.5 or 3.2.2. -- Michael -- From owner-ietf-calendar@mail.imc.org Mon Aug 11 22:53: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 WAA14546 for ; Mon, 11 Aug 2003 22:53:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C2k4qt003502 for ; Mon, 11 Aug 2003 19:46:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C2k4XC003501 for ietf-calendar-bks; Mon, 11 Aug 2003 19:46:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C2k3qt003492 for ; Mon, 11 Aug 2003 19:46:03 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mPBz-0006iO-00 for ; Tue, 12 Aug 2003 04:47:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mPBy-0006iG-00 for ; Tue, 12 Aug 2003 04:47:22 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mPAi-0000nH-00 for ; Tue, 12 Aug 2003 04:46:04 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 19:44:51 -0700 Lines: 53 Message-ID: References: <3F38270C.7050106@Royer.com> <3F3848E5.3000205@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:3F3848E5.3000205@Royer.com... > > > Michael Fair wrote: > > While not in direct reply to this response, at the > > end of at least two messages, Bruce has asked a > > specific and direct question of you Doug. > > > > Does each instance of a recurring event have its own > > SEQEUNCE or is there one SEQUENCE value for the entire > > recurring series which they all share? > > > > In case the question isn't clear: > > If I have a new recurring event and the only > > I change I make is to update one instance in > > which I use SEQUENCE:1, and then I go to > > update a totally different instance, is the > The rules are in iCal/iTIP, so I am not sure of your question. Ok let me try again and I'll make it even easier. I schedule UID:1 to recur every Friday this year. Here I use SEQUENCE: 0 step one: Reschedule Friday, June 13th to Thursday, June 12th. Here I use SEQUENCE:1 step two: Reschedule Thrusday, Jan 3rd to Thursday, Jan 2nd Here I use SEQUENCE:___ <-- Fill in that blank. The fixed-id model says that it's 1. This is consistent with section 3.7.1 which says: ... the protocol is designed so that each recurring instance may be both referenced and versioned ... Your model says that it is...? > There is an example in iTIP that covers that case exactly. No there isn't. Prove it. 4.4.2 Only covers how to do the first "step one", it doesn't even touch doing the second step. 4.4.7 Introduces an "Add" which changes the entire event set and effectively updates the SEQUENCE number for all instances to 2. Again this only a step one example. From owner-ietf-calendar@mail.imc.org Mon Aug 11 23:00: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 XAA14769 for ; Mon, 11 Aug 2003 23:00:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C2s2qt003828 for ; Mon, 11 Aug 2003 19:54:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C2s2I6003827 for ietf-calendar-bks; Mon, 11 Aug 2003 19:54:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C2s0qt003818 for ; Mon, 11 Aug 2003 19:54:00 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C2rZEB006636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 19:53:41 -0700 Message-ID: <3F3856A9.5040507@Royer.com> Date: Mon, 11 Aug 2003 20:53:29 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050804020401030209010800" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050804020401030209010800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > I don't know what this hangup on modification > versus new object is about? That idea does not work for all cases. Your CUA will be out of SYNC with the organizer view if iMIP objects that are sent as updates are interpreted as new objects - when received out of order via iMIP. You can pretend that out of order objects will not happen via iMIP all you want. It is not true. Servers queue up outgoing email all of the time and for reasons of system load can send them out in an order that is random. Your CUA will call it a new item then ignore the SEQUENCE:x-1 object because it thinks it is older. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050804020401030209010800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAyNTMyOVowIwYJKoZIhvcNAQkEMRYEFBS1Bhml 8xSSJvmeLv2fJtMNQ/5dMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEXQuLqsIvsZDrf9rRyeXid/apNpzUCJXZ+5kyg4Cbsmh5xXLI2e hJkoXKl1HXHvB91qpJy8AH0BDViEbrVosk5bu+wzgAszmw1YNxOuxentS/nH2/0AldbmkjQo jQbc1maQJoCrB9T/BPdBudYK4AbagPXSE06SQqWlzgoXKE672dq2j/3KgPAa2bhJKL8r4Wfe 4xi581TllMZr3MsE5UFNPvA458i+X+QxgO9tbl/REYc1DLWpsNVvv0xV6st1PAdtgBz1FmX/ quKnBiyB9W6ZZyaT3mil2XcqvRN2Xubn+1kgVmX2iO73VX/+RPhgwJCWoMtZtPBud8KK0gk/ p/IAAAAAAAA= --------------ms050804020401030209010800-- From owner-ietf-calendar@mail.imc.org Mon Aug 11 23:24:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15163 for ; Mon, 11 Aug 2003 23:24:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C3GMqt004750 for ; Mon, 11 Aug 2003 20:16:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C3GMAC004748 for ietf-calendar-bks; Mon, 11 Aug 2003 20:16:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C3GJqt004743 for ; Mon, 11 Aug 2003 20:16:20 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7C3FWEB006898 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 20:15:35 -0700 Message-ID: <3F385BCF.8080601@Royer.com> Date: Mon, 11 Aug 2003 21:15:27 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F38270C.7050106@Royer.com> <3F3848E5.3000205@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090702000806010403040602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090702000806010403040602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F3848E5.3000205@Royer.com... > >> >>Michael Fair wrote: >> >>>While not in direct reply to this response, at the >>>end of at least two messages, Bruce has asked a >>>specific and direct question of you Doug. >>> >>>Does each instance of a recurring event have its own >>>SEQEUNCE or is there one SEQUENCE value for the entire >>>recurring series which they all share? >> >> > >> >>>In case the question isn't clear: >>>If I have a new recurring event and the only >>>I change I make is to update one instance in >>>which I use SEQUENCE:1, and then I go to >>>update a totally different instance, is the > > >>The rules are in iCal/iTIP, so I am not sure of your question. > > > Ok let me try again and I'll make it even easier. Your example is the same as the one I replied to. Re-read my post. > >>There is an example in iTIP that covers that case exactly. > > > No there isn't. Prove it. Do you want me to send you a copy of iTIP? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090702000806010403040602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjAzMTUyN1owIwYJKoZIhvcNAQkEMRYEFBFgR67/ DOvK0a+G/N2P74MjcTcBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJIv7Eicx4J+yloQ+0OMM45pMXlI7URTwdRO8J1x3GXOvIThUeST baDmHqgBYdiVOrbgwufJc3EKWMEBYBN9tg4X9jTIjVTyjxhq93tNB+Y+M3HBKSVir+HGmABR LXC8Iun0rVrYEMjvP+xhi4O/+uYKBscGhOk6gpMpZS6ILdWPi+Z67KtJVHfugf/vlpF5JgJn s4mL7LQJns4GvI+wS6oeKzUxcKFjdQxZx3IyVJ9oraNQQGDqDBmCjTuBxa6wE8EqD4mGGrmf qy2TQ8UlndrYEQs1tCZYf+ilBRumNkweSX7vgb44VBRh5DzZyZqfov//GwV0S0mBHyhHpq8n 0ucAAAAAAAA= --------------ms090702000806010403040602-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 00: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 AAA15948 for ; Tue, 12 Aug 2003 00:05:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C3uKqt006300 for ; Mon, 11 Aug 2003 20:56:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C3uKJl006299 for ietf-calendar-bks; Mon, 11 Aug 2003 20:56:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C3uHqt006289 for ; Mon, 11 Aug 2003 20:56:18 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mQHx-00076c-00 for ; Tue, 12 Aug 2003 05:57:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mQHw-00076U-00 for ; Tue, 12 Aug 2003 05:57:36 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mQGh-0001pm-00 for ; Tue, 12 Aug 2003 05:56:19 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 20:55:03 -0700 Lines: 90 Message-ID: References: <3F38270C.7050106@Royer.com> <3F3848E5.3000205@Royer.com> <3F385BCF.8080601@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:3F385BCF.8080601@Royer.com... > > > Michael Fair wrote: > > "Doug Royer" wrote in message > > news:3F3848E5.3000205@Royer.com... > > > >> > >>Michael Fair wrote: > >> > >>>While not in direct reply to this response, at the > >>>end of at least two messages, Bruce has asked a > >>>specific and direct question of you Doug. > >>> > >>>Does each instance of a recurring event have its own > >>>SEQEUNCE or is there one SEQUENCE value for the entire > >>>recurring series which they all share? > >> > >> > > >> > >>>In case the question isn't clear: > >>>If I have a new recurring event and the only > >>>I change I make is to update one instance in > >>>which I use SEQUENCE:1, and then I go to > >>>update a totally different instance, is the > > > > > >>The rules are in iCal/iTIP, so I am not sure of your question. > > > > > > Ok let me try again and I'll make it even easier. > > Your example is the same as the one I replied to. Re-read > my post. You said "If you update any date or recurrence rule (and other things), then you have to update the SEQUENCE" ... " the booked object is at '2'." That means - despite your unwillingness to give a clear answer to what the SEQUENCE number should be, or whether or not all instances of the same recurring event have the same SEQUENCE - you believe that all instances of a recurring event share the same SEQUENCE. Right? As in when I reschedule one instance of a recurring event, the SEQUENCE number for all instances increments. This is distinctly different from the iTIP where each instance is both referenced and versioned. Rescheduling an instance of a recurring event is _not_ an update to "any date or recurrence rule (and other things)." > >>There is an example in iTIP that covers that case exactly. > > > > > > No there isn't. Prove it. > > Do you want me to send you a copy of iTIP? That would be useless I have already read iTIP and have seen that it is not there, reposting iTIP will just waste hard drive space and bandwidth. I want you to prove that iTIP has an example that covers that case because I say it isn't there and therefore one of us is in error. If you say it is there point me to it. It's pretty easy actually. Either paste the section number along with the relevant example(s) text or just give a section number and I can read it for myself. Just in case you misunderstood them, sections 4.4.2 and 4.4.7 do not cover that case. They cover different cases which I explicitly described. Is there somewhere else in iTIP that has examples covering the modification of recurrence instances that I am missing? You say that I am, I say that I am not, you can shut me up completely by just citing the example you claim to be there. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 00:17: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 AAA16119 for ; Tue, 12 Aug 2003 00:17:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C496qt006891 for ; Mon, 11 Aug 2003 21:09:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C496dF006889 for ietf-calendar-bks; Mon, 11 Aug 2003 21:09:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C494qt006883 for ; Mon, 11 Aug 2003 21:09:04 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mQUK-0007Bk-00 for ; Tue, 12 Aug 2003 06:10:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mQM7-00078j-00 for ; Tue, 12 Aug 2003 06:01:55 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mQKr-0001vf-00 for ; Tue, 12 Aug 2003 06:00:37 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 20:59:22 -0700 Lines: 29 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> <3F381A2A.6080900@Royer.com> <3F384245.5020301@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:3F384245.5020301@Royer.com... > > > Michael Fair wrote: > > All I can say Doug is show me the code. > > > > Please show me the chain of messages that go between > > the different CUA's and what in iTIP tells each CUA > > how to process these messages. > > > > Here's the task. > > Here is the answer: Read iTIP the example is in iTIP. > It goes through great pains to explain that process. I read it. It's not there. Prove it. Tell me which sections to read. The section does not exist. If you cannot cite me a section number(s) I will take that to mean that you are just bull headed and cannot admit when you're wrong. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 00:40: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 AAA16507 for ; Tue, 12 Aug 2003 00:40:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C4Twqt008400 for ; Mon, 11 Aug 2003 21:29:58 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7C4TwAU008399 for ietf-calendar-bks; Mon, 11 Aug 2003 21:29:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7C4Ttqt008389 for ; Mon, 11 Aug 2003 21:29:56 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mQoV-0007PI-00 for ; Tue, 12 Aug 2003 06:31:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mQoU-0007P8-00 for ; Tue, 12 Aug 2003 06:31:14 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mQnE-0002gu-00 for ; Tue, 12 Aug 2003 06:29:56 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Mon, 11 Aug 2003 21:28:36 -0700 Lines: 145 Message-ID: References: <3F32E092.3030301@Royer.com> <3F33CD59.4070509@Royer.com> <3F35158F.40303@Royer.com> <3F3684A6.9020007@Royer.com> <3F36AA86.8000606@Royer.com> <20030811092404.M97253@asitturnsout.org> <3F3826BE.2090000@Royer.com> <3F3836F6.3000208@Royer.com> <3F384B93.9020209@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:3F384B93.9020209@Royer.com... > > > Michael Fair wrote: > >>And that is my point. iTIP already tells you how to > >>invite an ATTENDEE. And the ORGANIZER is already > >>going to have to track ATTENDEE instance attendance. > > > > > > They track the instance attendence in the components > > referenced by the UID/RID. > > iTIP: > > Hence, CUAs must persist the following component properties: "UID", > "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each > "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" > and "DTSTAMP" property values associated with the "Attendee's" > response. > > And as it says **Attendee's response** it is talking about the > ORGANIZER CUA. Now what I think you meant here is that the values of "SEQUENCE" and "DTSTAMP" associated with the "REPLY" from an Attendee are stored in the Organizer's CUA, I totally agree with. The Attendee's responses must be stored on the ORGANIZER's CUA which contains the master copy of the event and any responses different to that of the master are stored in the instance component that represents the instance. This is so that the ORGANIZER's CUA can figure out whether or not a REPLY is more or less recent than the one it already has. No where does iTIP say that information stored with the Attendee's response can or should be be used to disambiguate an event component when you have multiple copies of it floating around. It even says you can't have multiple copies of the same UID (except for different SEQUENCE/DTSTAMP values). That section of iTIP is so that the ORGANIZER's CUA can figure out whether or not an Attendee has responded to the latest version of an event, and whether or not the REPLY is has just received is newer or older then the one it already has. > > Let's assume a world where everyone always got all > > information. I know it's not how you work, but it > > is allowed by the RFC and I think it makes things > > easier because you just know that everyone always > > gets everything (no intellignece needed). > > > > If I do a "REFRESH" on a UID/RID I'm asking for > > the latest version of that component which, in our > > transparent world of pretend for the moment, will > > include the attendence status for each of the > > attendees of that instance. > > No, it will include the attendee status of at least > yourself and MAY include other attendees. It could > be a massive security problem at public events. > Lets see if the president is attending, at which game. > > We covered this before. Do you disagree? Yes I disagree. And the last time we covered it was under the same circumstance. I laid out certain assumptions (valid within the RFC) that defined the behavior of the RFC. I identified when I was using the assumption to dictate certain values that would be contained in the response. I said the CUA will always send all information. Therefore it will always send all information. It's my CUA to dictate that with. This CUA is not in violation of the RFCs and that is the behavior I requested. If you believe that the behavior violates the RFC in some way the say so, point out where it says that it is in violation, and assuming I read it to be in violation as well I will alter the assumption or concede the argument (if the assumption was the foundation of the argument). If you can't operate in the context of assumptions for the purposes of establishing common ground then this conversation is going to be longer than I thought. > > If I do a "REFRESH" on just a UID that references > > a recurring event I am asking for the latest version > > of that component which, in our transparent world of > > pretend for the moment, will include not only the > > base attendence list for the master component, but > > will also include the attendence status for each > > and every attendee in every instance where something > > is different. > > No. As explained above. Yes. As explained above. (This conversation goes nowhere really fast) > If it did, then it still does not mean that the object > sent to that attendee contains instances where that attendee > does not need to know about and for the reasons explained above. I said that was the behavior of the CUA and therefore it must send out all information. That behavior does not violate the RFC. It matters not that the behavior isn't required, it's the behavior I defined for the purposes of the conversation. > There is no reason that an attendee need to know who is > attending or when other meeting are taking place. First, all Attendees are attending all meetings because that's what I said so they do need to know about all meetings. Or don't you understand what a declared assumption is? Or do I need to put it in some other format so that you can understand it? Or are you just afraid that if I was actually allowed to demonstrate the points you'll find out I was right and your model will fall apart? I say let the models defend themselves, we just describe the appropriate behavior that model will take and decide if it is desirable/acceptable. If you have an example where you think the fixed-id model breaks down please let us know and we can discuss it and hey, you might even be right about it. We will simply represent the fixed-id model as best we can and use iTIP and iCal to defend why that behavior is the correct one. We will also put the 'current-value' model under the same microscope and see each performs. The answer should be in the results of running the models through trials not bickering back and forth. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 10:29: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 KAA16638 for ; Tue, 12 Aug 2003 10:29:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CEDbqt072810 for ; Tue, 12 Aug 2003 07:13:37 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CEDbw3072809 for ietf-calendar-bks; Tue, 12 Aug 2003 07:13:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CEDaqt072802 for ; Tue, 12 Aug 2003 07:13:36 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F35158F.40303@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Aug 2003 10:13:26 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/12/2003 10:13:29 AM, Serialize complete at 08/12/2003 10:13:29 AM Content-Type: multipart/alternative; boundary="=_alternative 004DCAF985256D80_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004DCAF985256D80_= Content-Type: text/plain; charset="US-ASCII" Doug continued on 08/09/2003 11:38:55 AM: > You did not send out a new invitation, you sent out > a modification. Your not removing any ambiguity, your > adding one. Doug is having a big problem trying to distinguish an invitation from a reschedule from an update given the existing iTIP text and trying to factor in message missequencing or loss. He has repeatedly asked questions like "How do you disambiguate that from an update to a missed object?" or inaccurately said things like " you are proposing a new way to invite ATTENDEEs." Tom (Robert) and I have repeatedly pointed to the exact text in iTIP that says how you differentiate the overloaded REQUEST method. iTIP Section 3.2.2 REQUEST says: If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. and since we are dealing with a repeating instance the key value (per iTIP Section 2.1.5) is UID / RECURRENCE-ID and not just UID alone. iTIP Section 3.2.2.1 Rescheduling an Event describes detecting a reschedule as: If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is greater than the value for the existing event, then the "REQUEST" method describes a rescheduling of the event. and again since we are dealing with a repeating instance the key value to use is UID / RECURRENCE-ID instead of just UID. iTIP Section 3.2.2.2 Updating or Reconfirmation of an Event describes a non-reschedule update as: If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar and that the "SEQUENCE" property value in the "REQUEST" is the same as the value for the existing event, then the "REQUEST" method describes an update of the event details, but no rescheduling of the event. and the same UID / RECURRENCE-ID primary key would be used here since we are referring to a repeating instance. This is NOT a new proposal as Doug suggests; its merely reading and understanding the existing iTIP text. So why does Doug not understand these distinctions? The answer is because this does not work for his delta RECURRENCE-ID model. The texts above CANNOT be used with a model where the key used to first identify the instance in question changes on each reschedule! Why you may ask? Simple, because if you cannot follow the chain of reschedules for each instance, you cannot accurately match the UID / RECURRENCE-ID value in the REQUEST with the correct instance you have. Even Doug has agreeded (albeit tacitly) that the ONLY way to handle this case is to destroy ALL instances the recipient has and to ask the Organzier to recreate them all using a "full REFRESH". If you understand the fixed RECURRENCE-ID model, you would see that this is NEVER EVER necessary; lost or missequenced messages are NEVER a problem because you can easily match the REQUEST to the correct instance. Despite Dougs wishes to the contrary, missed REQUESTS (invitations OR reschedules OR updates) to any instance are never a concern in the fixed RECURRENCE-ID model since the newer (ie: higher valued SEQUENCE) REQUEST is a full snapshot of that instance and as such NOTHING in the obsoleted (missed or recieved) REQUESTs matters. If you rely on Dougs delta RECURRENCE-ID model then you will find that each REQUEST does rely on items in previous REQUESTS: DTSTART, RECURRENCE-ID and SEQUENCE. This is not a fault tolerant design and thats exactly why we moved away from them before we passed Last Call. (If you can find the early iCalendar / iTIP drafts you will see we did use a delta model for a while and then we ran into fault tolerance concerns for iTIP and we changed the design). Doug has also persisted in claiming that iTIP says that no RECURRENCE-IDs are in an invitation. This is patently false. There is not shred of text or restriction table in iTIP that even remotely says this. Does anyone see text to this effect in the citations above? I didnt think so. If you check the restriction tables it makes NO mention of this. Not even the examples in the back of iTIP that Doug is designing to say this! So where does this idea come from? Simple, it derives from the delta models need to get the repeat instances information to the invitees BEFORE any workflow can proceed. Otherwise the invitee has no way to start the process! However even that is a failed assumption because it is perfectly legal and legit to NEVER reschedule the instances and to later add someone. Lets see how... For example, Bob, Pat and Doug agree to have a daily conference call each day this week on the remaining CAP issues. They decide on the times during the last call (or they play phone tag) and then Pat sends out the REQUEST to Bob and Doug confirming it. Bob REPLYs his acceptance and adds a COMMENT:I think Steve should be on the last one for final agreement. Pat agrees and she sends Steve the following invitation: BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1com RECURRENCE-ID:20030815T210000Z SEQUENCE:0 ORGANIZER:Mailto:Pat@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Pat@example.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARSTAT=ACCEPTED:Mailto:Bob@example.com ATTENDEE;ROLE=REQ-PARTICIPANT:Mailto:Doug@example.com ATTENDEE;ROLE=OPT-PARTICIPANT:Mailto:Steve@example.com DESCRIPTION:IETF-CnS Conference Call on CAP issues. Lets review the issues left on the table\, what to do with them\, and the solutions to the issues we solved. CLASS:PUBLIC SUMMARY:IETF CalSch Conf Call - CAP Issues DTSTART:20030815T210000Z DTEND:20030815T220000Z LOCATION:Conference Call: 800.555.1212\, Call 12345 DTSTAMP:20030812T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR According to Dougs version of the iTIP model, Pat would NOT send a RECURRENCE-ID on the REQUEST since its the invitation. However this is semantically wrong: no RECURRENCE-ID means the entry is non-repeating (or you are referring to the entire set of instances if it is). iTIP clearly shows RECURRENCE-ID in its restriction table: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. and it sounds as if Doug does not grasp the meaning/use correctly. Since Pat is only inviting Steve to a single instance, the REQUEST is therefore referring to a particular one and as such needs to have the RECURRENCE-ID in it. The reason that Doug says this is how he woudl send it is because thats the only way he can send it in the delta RECURRENCE-ID model; he has to first send Steve the definition of the instances before he can do ANY workflow on them. However this is NEVER described in iTIP nor is it needed if you look at iTIP with iCalendars fixed RECURRENCE-ID model. Since each instance can be distinctly referenced no matter its SEQUENCE (and thus no matter if iTIP messages are missequenced or lost), there is no need to first send a defintion and then send other REQUESTS. If Pat needed to reschedule the Friday instance for some reason then she can send a reschedule to everyone that looks like: BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1com RECURRENCE-ID:20030815T210000Z SEQUENCE:1 ORGANIZER:Mailto:Pat@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Pat@example.com ATTENDEE;ROLE=REQ-PARTICIPANT:Mailto:Bob@example.com ATTENDEE;ROLE=REQ-PARTICIPANT:Mailto:Doug@example.com ATTENDEE;ROLE=OPT-PARTICIPANT:Mailto:Steve@example.com DESCRIPTION:IETF-CnS Conference Call on CAP issues. Lets review the issues left on the table\, what to do with them\, and the solutions to the issues we solved. CLASS:PUBLIC SUMMARY:IETF CalSch Conf Call - CAP Issues COMMENT:Some of us cannot make that time so Im moving it back an hour since that worked before. DTSTART:20030815T220000Z DTEND:20030815T221000Z LOCATION:Conference Call\: 800.555.1212\, Call 12345 DTSTAMP:20030812T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR That assumes of course you dont ignore the iCalendar paragraph that exactly matches this example: the RECURRENCE-ID stays at the original Friday date/time. If you look at misordering of the delivery for these 2 to Steve (or say the 1st REQUEST got lost) using Dougs delta RECURRENCE-ID model then Steve has NO way to know if this is an update or a reschedule to an instance he should know about or if this is Pats invitation to him. Now, depending if you correctly apply iTIP Sections 2.1.5 and 3.2.2 Steve would treat this like an invitation (correct behaviour; incorrect potential results though) or not (incorrect behaviour; potential results are unknown). Under the delta RECURRENCE-ID model, since Steve cannot distinguish between a missequenced reschedule REQUEST and an invitation REQUEST, the only thing he could do would be to throw it away and ask Pat to resend a REQUEST with no-RECURRENCE-IDs in it. Hmm, an interesting idea but since REFRESH allows for ATTENDEEs to ask for REFESHs on particular RECURRENCE-IDs (check iTIP) I have to wonder why this is in iTIP if RECURRENCE-ID values can change on each reschedule. There would be NO certain way for the Organzier to correctly determine exactly which RECURRENCE-ID the ATTENDEE is referring to since there is NO SEQUENCE property on the REFRESH. Why does it matter you ask? Simple, if the models intent was to be able to refresh a particular instance (_exactly_ what iTIP 3.2.6 says) then there is no need for SEQUENCE since the REFRESH was targeted at a particular instance. This works ONLY for a fixed RECURRENCE-ID model since its unambiguous which instance the REFRESH with RECURRENCE-ID is referring to. Otherwise the Organzier has NO way to know which actual instance the RECURRENCE-ID refers to! If you follow the above 2 REQUESTs to Steve using iCalendars fixed RECURRENCE-ID model then you will see that missequencing or loss is NOT a problem and Steve can easily deal with it with out any back and forth full REFRESHs. After all, if one REQUEST can get lost, so can the "full REFRESH" REQUEST that Pat sends. I seemed to added more than intended here but I have done so in the hope that it would be clear to folks (maybe even Doug) that: 1: NONE of my analysis are "new proposals" as Doug would have everyone think; I was simply analyzing how iTIP would perform using Dougs delta RECURRENCE-ID model and the iCalendar fixed RECURRENCE-ID model. 2: The iTIP process is only fault tolerant if the RECURRENCE-ID model is a fixed one; a delta RECURRENCE-ID model is fault prone and hard to recover from completely (no guarantees there even). 3: Doug is adding new semantics that simply do NOT exist in iTIP for determining invitation from other meanings of REQUEST (ie: SEQUENCE cannot be 0 or RECURRENCE-ID cannot be on the invitation) are simply NOT in iTIP no matter how much one wishes for 'em. These are all artifacts of how iTIP _needs_ to function if you adopt a RECURRENCE-ID model, its not how iTIP is currently written. 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 004DCAF985256D80_= Content-Type: text/html; charset="US-ASCII"
Doug continued on 08/09/2003 11:38:55 AM:
> You did not send out a new invitation, you sent out
> a modification. Your not removing any ambiguity, your
> adding one.
Doug is having a big problem trying to distinguish an invitation from a reschedule from an update given the existing iTIP text and trying to factor in message missequencing or loss.  He has repeatedly asked questions like "How do you disambiguate that from an update to a missed object?" or inaccurately said things like " you are proposing a new way to invite ATTENDEEs."

Tom (Robert) and I have repeatedly pointed to the exact text in iTIP that says how you differentiate the overloaded REQUEST method.  iTIP Section 3.2.2 REQUEST says:

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

and since we are dealing with a repeating instance the key value (per iTIP Section 2.1.5) is UID / RECURRENCE-ID and not just UID alone.  iTIP Section 3.2.2.1 Rescheduling an Event describes detecting a reschedule as:

                   If the recipient CUA of a "REQUEST" method finds that
  the "UID" property value already exists on the calendar, but that the
  "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
  greater than the value for the existing event, then the "REQUEST"
  method describes a rescheduling of the event.

and again since we are dealing with a repeating instance the key value to use is UID / RECURRENCE-ID instead of just UID.  iTIP Section 3.2.2.2 Updating or Reconfirmation of an Event describes a non-reschedule update as:

                               If the recipient CUA of a "REQUEST"
  method finds that the "UID" property value already exists on the
  calendar and that the "SEQUENCE" property value in the "REQUEST" is
  the same as the value for the existing event, then the "REQUEST"
  method describes an update of the event details, but no rescheduling
  of the event.

and the same UID / RECURRENCE-ID primary key would be used here since we are referring to a repeating instance.

This is NOT a new proposal as Doug suggests; its merely reading and understanding the existing iTIP text.  

So why does Doug not understand these distinctions?  The answer is because this does not work for his delta RECURRENCE-ID model.  

The texts above CANNOT be used with a model where the key used to first identify the instance in question changes on each reschedule!  Why you may ask?  Simple, because if you cannot follow the chain of reschedules for each instance, you cannot accurately match the UID / RECURRENCE-ID value in the REQUEST with the correct instance you have.  Even Doug has agreeded (albeit tacitly) that the ONLY way to handle this case is to destroy ALL instances the recipient has and to ask the Organzier to recreate them all using a "full REFRESH".

If you understand the fixed RECURRENCE-ID model, you would see that this is NEVER EVER necessary; lost or missequenced messages are NEVER a problem because you can easily match the REQUEST to the correct instance.

Despite Dougs wishes to the contrary, missed REQUESTS (invitations OR reschedules OR updates) to any instance are never a concern in the fixed RECURRENCE-ID model since the newer (ie: higher valued SEQUENCE) REQUEST is a full snapshot of that instance and as such NOTHING in the obsoleted (missed or recieved) REQUESTs matters.  If you rely on Dougs delta RECURRENCE-ID model then you will find that each REQUEST does rely on items in previous REQUESTS: DTSTART, RECURRENCE-ID and SEQUENCE.  This is not a fault tolerant design and thats exactly why we moved away from them before we passed Last Call.  (If you can find the early iCalendar / iTIP drafts you will see we did use a delta model for a while and then we ran into fault tolerance concerns for iTIP and we changed the design).

Doug has also persisted in claiming that iTIP says that no RECURRENCE-IDs are in an invitation.  This is patently false.  There is not shred of text or restriction table in iTIP that even remotely says this.  Does anyone see text to this effect in the citations above?  I didnt think so.  If you check the restriction tables it makes NO mention of this.  Not even the examples in the back of iTIP that Doug is designing to say this!   So where does this idea come from?

Simple, it derives from the delta models need to get the repeat instances information to the invitees BEFORE any workflow can proceed.  Otherwise the invitee has no way to start the process!  However even that is a failed assumption because it is perfectly legal and legit to NEVER reschedule the instances and to later add someone.  Lets see how...

For example, Bob, Pat and Doug agree to have a daily conference call each day this week on the remaining CAP issues.  They decide on the times during the last call (or they play phone tag) and then Pat sends out the REQUEST to Bob and Doug confirming it.  Bob REPLYs his acceptance and adds a COMMENT:I think Steve should be on the last one for final agreement.  Pat agrees and she sends Steve the following invitation:

   BEGIN:VCALENDAR
  METHOD:REQUEST
  PRODID:-//RDU Software//NONSGML HandCal//EN
  VERSION:2.0
  BEGIN:VEVENT
  UID:guid-1@host1com
  RECURRENCE-ID:20030815T210000Z
  SEQUENCE:0
  ORGANIZER:Mailto:Pat@example.com
  ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Pat@example.com
  ATTENDEE;ROLE=REQ-PARTICIPANT;PARSTAT=ACCEPTED:Mailto:Bob@example.com
  ATTENDEE;ROLE=REQ-PARTICIPANT:Mailto:Doug@example.com
  ATTENDEE;ROLE=OPT-PARTICIPANT:Mailto:Steve@example.com
  DESCRIPTION:IETF-CnS Conference Call on CAP issues.  Lets review
    the issues left on the table\, what to do with them\, and the
    solutions to the issues we solved.
  CLASS:PUBLIC
  SUMMARY:IETF CalSch Conf Call - CAP Issues
  DTSTART:20030815T210000Z
  DTEND:20030815T220000Z
  LOCATION:Conference Call: 800.555.1212\, Call 12345
  DTSTAMP:20030812T093000Z
  STATUS:CONFIRMED
  END:VEVENT
  END:VCALENDAR

According to Dougs version of the iTIP model, Pat would NOT send a RECURRENCE-ID on the REQUEST since its the invitation.  However this is semantically wrong: no RECURRENCE-ID means the entry is non-repeating (or you are referring to the entire set of instances if it is).  iTIP clearly shows RECURRENCE-ID in its restriction table:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise it
                           MUST NOT be present.

and it sounds as if Doug does not grasp the meaning/use correctly.  Since Pat is only inviting Steve to a single instance, the REQUEST is therefore referring to a particular one and as such needs to have the RECURRENCE-ID in it.  The reason that Doug says this is how he woudl send it is because thats the only way he can send it in the delta RECURRENCE-ID model; he has to first send Steve the definition of the instances before he can do ANY workflow on them.

However this is NEVER described in iTIP nor is it needed if you look at iTIP with iCalendars fixed RECURRENCE-ID model.  Since each instance can be distinctly referenced no matter its SEQUENCE (and thus no matter if iTIP messages are missequenced or lost), there is no need to first send a defintion and then send other REQUESTS.

If Pat needed to reschedule the Friday instance for some reason then she can send a reschedule to everyone that looks like:

   BEGIN:VCALENDAR
  METHOD:REQUEST
  PRODID:-//RDU Software//NONSGML HandCal//EN
  VERSION:2.0
  BEGIN:VEVENT
  UID:guid-1@host1com
  RECURRENCE-ID:20030815T210000Z
  SEQUENCE:1
  ORGANIZER:Mailto:Pat@example.com
  ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Pat@example.com
  ATTENDEE;ROLE=REQ-PARTICIPANT:Mailto:Bob@example.com
  ATTENDEE;ROLE=REQ-PARTICIPANT:Mailto:Doug@example.com
  ATTENDEE;ROLE=OPT-PARTICIPANT:Mailto:Steve@example.com
  DESCRIPTION:IETF-CnS Conference Call on CAP issues.  Lets review
    the issues left on the table\, what to do with them\, and the
    solutions to the issues we solved.
  CLASS:PUBLIC
  SUMMARY:IETF CalSch Conf Call - CAP Issues
   COMMENT:Some of us cannot make that time so Im moving it back an
    hour since that worked before.
  DTSTART:20030815T220000Z
  DTEND:20030815T221000Z
  LOCATION:Conference Call\: 800.555.1212\, Call 12345
  DTSTAMP:20030812T093000Z
  STATUS:CONFIRMED
  END:VEVENT
  END:VCALENDAR

That assumes of course you dont ignore the iCalendar paragraph that exactly matches this example: the RECURRENCE-ID stays at the original Friday date/time.  

If you look at misordering of the delivery for these 2 to Steve (or say the 1st REQUEST got lost) using Dougs delta RECURRENCE-ID model then Steve has NO way to know if this is an update or a reschedule to an instance he should know about or if this is Pats invitation to him.  Now, depending if you correctly apply iTIP Sections 2.1.5 and 3.2.2 Steve would treat this like an invitation (correct behaviour; incorrect potential results though) or not (incorrect behaviour; potential results are unknown).

Under the delta RECURRENCE-ID model, since Steve cannot distinguish between a missequenced reschedule REQUEST and an invitation REQUEST, the only thing he could do would be to throw it away and ask Pat to resend a REQUEST with no-RECURRENCE-IDs in it.

Hmm, an interesting idea but since REFRESH allows for ATTENDEEs to ask for REFESHs on particular RECURRENCE-IDs (check iTIP) I have to wonder why this is in iTIP if RECURRENCE-ID values can change on each reschedule.  There would be NO certain way for the Organzier to correctly determine exactly which RECURRENCE-ID the ATTENDEE is referring to since there is NO SEQUENCE property on the REFRESH.  

Why does it matter you ask?  Simple, if the models intent was to be able to refresh a particular instance (_exactly_ what iTIP 3.2.6 says) then there is no need for SEQUENCE since the REFRESH was targeted at a particular instance.  This works ONLY for a fixed RECURRENCE-ID model since its unambiguous which instance the REFRESH with RECURRENCE-ID  is referring to.  Otherwise the Organzier has NO way to know which actual instance the RECURRENCE-ID refers to!

If you follow the above 2 REQUESTs to Steve using iCalendars fixed RECURRENCE-ID model then you will see that missequencing or loss is NOT a problem and Steve can easily deal with it with out any back and forth full REFRESHs.  After all, if one REQUEST can get lost, so can the "full REFRESH" REQUEST that Pat sends.

I seemed to added more than intended here but I have done so in the hope that it would be clear to folks (maybe even Doug) that:

1: NONE of my analysis are "new proposals" as Doug would have everyone think; I was simply analyzing how iTIP would perform using Dougs delta RECURRENCE-ID model and the iCalendar fixed RECURRENCE-ID model.
2: The iTIP process is only fault tolerant if the RECURRENCE-ID model is a fixed one; a delta RECURRENCE-ID model is fault prone and hard to recover from completely (no guarantees there even).
3: Doug is adding new semantics that simply do NOT exist in iTIP for determining invitation from other meanings of REQUEST (ie: SEQUENCE cannot be 0 or RECURRENCE-ID cannot be on the invitation) are simply NOT in iTIP no matter how much one wishes for 'em.  These are all artifacts of how iTIP _needs_ to function if you adopt a RECURRENCE-ID model, its not how iTIP is currently written.

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 004DCAF985256D80_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 12:10: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 MAA20057 for ; Tue, 12 Aug 2003 12:09:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CG0eqt081719 for ; Tue, 12 Aug 2003 09:00:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CG0dou081718 for ietf-calendar-bks; Tue, 12 Aug 2003 09:00:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CG0cqt081711 for ; Tue, 12 Aug 2003 09:00:38 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7CG0aEB012617 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 09:00:38 -0700 Message-ID: <3F390F1B.8000706@Royer.com> Date: Tue, 12 Aug 2003 10:00:27 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090509060500080300090309" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090509060500080300090309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug continued on 08/09/2003 11:38:55 AM: > > You did not send out a new invitation, you sent out > > a modification. Your not removing any ambiguity, your > > adding one. > > Doug is having a big problem trying to distinguish an invitation from a > reschedule from an update given the existing iTIP text and trying to > factor in message missequencing or loss. He has repeatedly asked > questions like "How do you disambiguate that from an update to a missed > object?" or inaccurately said things like " you are proposing a new way > to invite ATTENDEEs." Bruce is having a hard time understanding that his proposed model does not work. And yes Bruce if you want I'll keep asking the question: How do you disambiguate your new proposal for inviting an attendee from an update to to a missed object? And: What is your justification for the need to invent another method to invite attendees? Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090509060500080300090309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjE2MDAyOVowIwYJKoZIhvcNAQkEMRYEFNcnNUt4 HWpf6KO+A7ig53oCowfjMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGJUYbyCYJ3GqsZVfrVZ0Ga0U6I1798ho8iVfFrNsDRaM8c47EO5 g1T4lhLItMnK+ayFYBsuGDC0XmKThThL4jC/8r0q7cx35MfK0sXUB2X18VEJcWLE+6L2dlC2 DHbxCz6kW8LB7Dlnj4ulLMBN7uWq3KXKqf/AQ2zeSorpo5r6Trx369G4hC7RN+oYr/dnGB23 P6ztxXwHLUZkfCYsf3+vfwQppa5HXvpbYPypXY0TdyVKU83r/kogwvy/tOfYLG2erDamAi50 uSf795yIW2Zy5iynkudpE4D55Hd1oRw0/yIa645SB3ix2IG1W6ZiGQnMmM09Q8HxrBUcva+P /tEAAAAAAAA= --------------ms090509060500080300090309-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 13:47: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 NAA22615 for ; Tue, 12 Aug 2003 13:47:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CHblqt091597 for ; Tue, 12 Aug 2003 10:37:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CHblCF091596 for ietf-calendar-bks; Tue, 12 Aug 2003 10:37:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CHbjqt091591 for ; Tue, 12 Aug 2003 10:37:45 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7CHbiEB013319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 10:37:46 -0700 Message-ID: <3F3925E3.9060702@Royer.com> Date: Tue, 12 Aug 2003 11:37:39 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030507000109050603020509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030507000109050603020509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > So why does Doug not understand these distinctions? The answer is > because this does not work for his delta RECURRENCE-ID model. Why does Burce ignore all facts that show that it makes the object indistigushable from an object with a missed original? > > Doug has also persisted in claiming that iTIP says that no > RECURRENCE-IDs are in an invitation. I can also show *LOTS* of examples of when it will work. Why will Bruce not debat the case when it does not work? Did Bruce already implement his application and its too late? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030507000109050603020509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjE3MzczOVowIwYJKoZIhvcNAQkEMRYEFDbo/M1Z gxAQANH/ZbpkXuGh+nmfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAETJwRp6uB6LxeySBKuHFBkWZb0UsxYC14f13j3f26tEeSWh6gpn SrFrgviSg6B4d641TQeBpsJmMYxsfmNvOl5YpvaaJCvHoiUbfTFJGgsDlYCjWbjsdtnKRsER aYjLuEwefmaMGAlbIBFGos5RyQcdiwywN3DYbNLmgEyNZZHSyNXEztJM9wKID+CrwNATuiGw nwptw/JyN2wKgmV02yG9qXJqGz0QMh6rsD14lhgQKlzZBsYDkPTmrvXocrdAbyapIgzljrLp cdEU/2GMLKatreNW31CTPZvegi65Sai0oWgj8X9LBuNaBWWO87IGFbI/rw5xmbt3RAjXDPrq xGwAAAAAAAA= --------------ms030507000109050603020509-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 14:14: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 OAA23174 for ; Tue, 12 Aug 2003 14:14:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CI1Bqt092581 for ; Tue, 12 Aug 2003 11:01:11 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CI1Bmc092580 for ietf-calendar-bks; Tue, 12 Aug 2003 11:01:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CI19qt092574 for ; Tue, 12 Aug 2003 11:01:10 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F390F1B.8000706@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Aug 2003 13:56:52 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/12/2003 02:01:10 PM, Serialize complete at 08/12/2003 02:01:10 PM Content-Type: multipart/alternative; boundary="=_alternative 00623E8585256D80_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00623E8585256D80_= Content-Type: text/plain; charset="US-ASCII" Doug pondered on 08/12/2003 12:00:27 PM: > Bruce is having a hard time understanding that his proposed model > does not work. Once again you must have a different dictionary than the rest of us. My postings you consider proposals for some model have been clearly labeled and formatted as an analsysis. Ill just chalk this as another dictionary discrepancy like 'original'. >And yes Bruce if you want I'll keep asking the > question: > > How do you disambiguate your new proposal for inviting an > attendee from an update to to a missed object? Once again Ill point you to iTIP Sections 3.2.2 REQUEST, 3.2.2.1 Rescheduling an Event and 3.2.2.2 Updating or Reconfirmation of an Event. 3.2.2 says: If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. and for repeating instances the value used to see if the instance can be found "on the recipient's calendar" is UID / RECURRENCE-ID. That is, if you understand iTIP Section 2.1.5. If not, you use the wrong key to see if the instance in question exists. > What is your justification for the need to invent another method > to invite attendees? If the instance exists then you use SEQUENCE (and DTSTAMP) to determine if the REQUEST is a reschedule (3.2.2.1) or not (3.2.2.2). A reschedule is determined by: If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is greater than the value for the existing event, then the "REQUEST" method describes a rescheduling of the event. and an update is determined by: If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar and that the "SEQUENCE" property value in the "REQUEST" is the same as the value for the existing event, then the "REQUEST" method describes an update of the event details, but no rescheduling of the event. and if you correctly apply iTIP Section 2.1.5 your CUA would use UID and RECURRENCE-ID for the lookup to make this determination before applying SEQUENCE (and DTSTAMP) checking. Doug is trying to create some new semantics that are not currently in iTIP. iTIP defines semantics for interpreting a REQUEST on the recipients side NOT the senders; no matter how you want them to. Thats why the phrase "on the recipients calendar" is used often; because how its interpreted depends on what you have on your calendar so far. If you can consistanly and accuratly identify the instance in question then a missed invitation is no problem; the 'reschedule' that gets sent becomes the invitation and workflow is restored, well only for the fixed RECURRENCE-ID model. This 'recipient centric' phrasing in REQUEST is _only_ a problem if you have a model where you cannot consistanly identify the instance in question of a repeating set. The delta RECURRENCE-ID model Doug promotes is such a model as my analysis (not proposal Doug) on Friday showed. It should start becoming clear that a fixed RECURRENCE-ID is the model in iCalendar and iTIP given all the faults inherent in the use of a changing RECURRENCE-ID model. After all, how can bullet 1 of Section 4.7.2 in iTIP work if the RECURRENCE-ID changes? The UID and RECURRENCE-ID values could not match the correct instnace at different SEQUENCE values if the value changed every time... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00623E8585256D80_= Content-Type: text/html; charset="US-ASCII"
Doug pondered on 08/12/2003 12:00:27 PM:
> Bruce is having a hard time understanding that his proposed model
> does not work.  

Once again you must have a different dictionary than the rest of us.  My postings you consider proposals for some model have been clearly labeled and formatted as an analsysis.  Ill just chalk this as another dictionary discrepancy like 'original'.

>And yes Bruce if you want I'll keep asking the
> question:
>
>     How do you disambiguate your new proposal for inviting an
>     attendee from an update to to a missed object?
Once again Ill point you to iTIP Sections 3.2.2 REQUEST, 3.2.2.1 Rescheduling an Event and 3.2.2.2 Updating or Reconfirmation of an Event.  3.2.2 says:

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

and for repeating instances the value used to see if the instance can be found "on the recipient's calendar" is UID / RECURRENCE-ID.  That is, if you understand iTIP Section 2.1.5.  If not, you use the wrong key to see if the instance in question exists.

>     What is your justification for the need to invent another method
>     to invite attendees?
If the instance exists then you use SEQUENCE (and DTSTAMP) to determine if the REQUEST is a reschedule (3.2.2.1) or not (3.2.2.2).  A reschedule is determined by:

                   If the recipient CUA of a "REQUEST" method finds that
  the "UID" property value already exists on the calendar, but that the
  "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
  greater than the value for the existing event, then the "REQUEST"
  method describes a rescheduling of the event.

and an update is determined by:

                                  If the recipient CUA of a "REQUEST"
  method finds that the "UID" property value already exists on the
  calendar and that the "SEQUENCE" property value in the "REQUEST" is
  the same as the value for the existing event, then the "REQUEST"
  method describes an update of the event details, but no rescheduling
  of the event.

and if you correctly apply iTIP Section 2.1.5 your CUA would use UID and RECURRENCE-ID for the lookup to make this determination before applying SEQUENCE (and DTSTAMP) checking.

Doug is trying to create some new semantics that are not currently in iTIP.  iTIP defines semantics for interpreting a REQUEST on the recipients side NOT the senders; no matter how you want them to.  Thats why the phrase "on the recipients calendar" is used often; because how its interpreted depends on what you have on your calendar so far.   If you can consistanly and accuratly identify the instance in question then a missed invitation is no problem; the 'reschedule' that gets sent becomes the invitation and workflow is restored, well only for the fixed RECURRENCE-ID model.  

This 'recipient centric' phrasing in REQUEST is _only_ a problem if you have a model where you cannot consistanly identify the instance in question of a repeating set.  The delta RECURRENCE-ID model Doug promotes is such a model as my analysis (not proposal Doug) on Friday showed.  It should start becoming clear that a fixed RECURRENCE-ID is the model in iCalendar and iTIP given all the faults inherent in the use of a changing RECURRENCE-ID model.  After all, how can bullet 1 of Section 4.7.2 in iTIP work if the RECURRENCE-ID changes?  The UID and RECURRENCE-ID values could not match the correct instnace at different SEQUENCE values if the value changed every time...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00623E8585256D80_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 14:42: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 OAA24021 for ; Tue, 12 Aug 2003 14:42:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CIUMqt094225 for ; Tue, 12 Aug 2003 11:30:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CIUL9U094224 for ietf-calendar-bks; Tue, 12 Aug 2003 11:30:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CIULqt094219 for ; Tue, 12 Aug 2003 11:30:21 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F3925E3.9060702@Royer.com> To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 12 Aug 2003 14:22:03 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/12/2003 02:30:19 PM, Serialize complete at 08/12/2003 02:30:19 PM Content-Type: multipart/alternative; boundary="=_alternative 00648D2585256D80_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00648D2585256D80_= Content-Type: text/plain; charset="US-ASCII" Doug still wondered on 08/12/2003 01:37:39 PM: > > So why does Doug not understand these distinctions? The answer is > > because this does not work for his delta RECURRENCE-ID model. > > Why does Burce ignore all facts that show that it makes the object > indistigushable from an object with a missed original? The problem of distiction is ONLY an issue for your delta model Doug. Its NOT a problem for a fixed RECURRENCE-ID model as Ive already shown. In case its not clear still, since any later REQUEST obsoletes the pervious ones (per iTIP 2.1.5) then SO WHAT if you missed fixing a typo and a change in LOCATION?!? The new REQUEST has an even more current LOCATION than the missed REQUEST! Since each REQUEST is a full snapshot of the instance then if you get a "more recent version" (higher SEQUENCE/DTSTAMP) before you get an "older version" (lower SEQUENCE/DTSTAMP) then no big deal; you simply add it to your calendar and things are back on track. Well, you can ONLY safely do that with the fixed RECURRENCE-ID model and NOT with Dougs delta model. This is why he still has a problem differentiating. In order for this to work for Dougs model, you MUST get each REQUEST in order. There is NO fault tolerance here as Ive shown because Doug cant match the RECURRENCE-ID to the instance the Organzier was referring to. If you use iCalendars fixed RECURRENCE-IDs then it is fault tolerant and errors are easily recovered from. > I can also show *LOTS* of examples of when it will work. You have yet to show 1 analysis where the delta RECURRENCE-ID model works and recovers from missequenced or lost messages. If you could, you would have shown them in response to my analysis on Friday. Still, Im interested to see where you the analysis from Friday was mistaken given the current text in iTIP. > Did Bruce already implement his application and its too late? Several vendors have implemented iTIP this way and with good reason. Its FAULT TOLERANT and EASILY RECOVERABLE. Your prescious delta model falls far short in these areas as Ive readily demonstrated. PLUS we did NOT try to impart any new semantics based on NON-EXISTANT iTIP prose like "Invitations cannot be at SEQUENCE:0" (where the heck did you read that??) or "RECURRENCE-IDs cannot be in an invitation" (again, where the hell did you get that????) We simply implemented whats in iTIP as it stands now (correctly understanding Section 2.1.5 even). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00648D2585256D80_= Content-Type: text/html; charset="US-ASCII"
Doug still wondered on 08/12/2003 01:37:39 PM:
> > So why does Doug not understand these distinctions?  The answer is
> > because this does not work for his delta RECURRENCE-ID model.  
>
> Why does Burce ignore all facts that show that it makes the object
> indistigushable from an object with a missed original?
The problem of distiction is ONLY an issue for your delta model Doug.  Its NOT a problem for a fixed RECURRENCE-ID model as Ive already shown.

In case its not clear still, since any later REQUEST obsoletes the pervious ones (per iTIP 2.1.5) then SO WHAT if you missed fixing a typo and a change in LOCATION?!?  The new REQUEST has an even more current LOCATION than the missed REQUEST!  Since each REQUEST is a full snapshot of the instance then if you get a "more recent version" (higher SEQUENCE/DTSTAMP) before you get an "older version" (lower SEQUENCE/DTSTAMP) then no big deal; you simply add it to your calendar and things are back on track.  Well, you can ONLY safely do that with the fixed RECURRENCE-ID model and NOT with Dougs delta model.  This is why he still has a problem differentiating.

In order for this to work for Dougs model, you MUST get each REQUEST in order.  There is NO fault tolerance here as Ive shown because Doug cant match the RECURRENCE-ID to the instance the Organzier was referring to.  If you use iCalendars fixed RECURRENCE-IDs then it is fault tolerant and errors are easily recovered from.

> I can also show *LOTS* of examples of when it will work.
You have yet to show 1 analysis where the delta RECURRENCE-ID model works and recovers from missequenced or lost messages.  If you could, you would have shown them in response to my analysis on Friday.  Still, Im interested to see where you the analysis from Friday was mistaken given the current text in iTIP.

> Did Bruce already implement his application and its too late?
Several vendors have implemented iTIP this way and with good reason.  Its FAULT TOLERANT and EASILY RECOVERABLE.  Your prescious delta model falls far short in these areas as Ive readily demonstrated.

PLUS we did NOT try to impart any new semantics based on NON-EXISTANT iTIP prose like "Invitations cannot be at SEQUENCE:0" (where the heck did you read that??) or "RECURRENCE-IDs cannot be in an invitation" (again, where the hell did you get that????)  We simply implemented whats in iTIP as it stands now (correctly understanding Section 2.1.5 even).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00648D2585256D80_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 15:12: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 PAA26242 for ; Tue, 12 Aug 2003 15:12:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CJ5Sqt095626 for ; Tue, 12 Aug 2003 12:05:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CJ5RuC095625 for ietf-calendar-bks; Tue, 12 Aug 2003 12:05:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CJ5Qqt095618 for ; Tue, 12 Aug 2003 12:05:26 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7CJ5PEB014016 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 12:05:27 -0700 Message-ID: <3F393A6F.5050702@Royer.com> Date: Tue, 12 Aug 2003 13:05:19 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020206070208010809040002" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020206070208010809040002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug pondered on 08/12/2003 12:00:27 PM: > > Bruce is having a hard time understanding that his proposed model > > does not work. > > Once again you must have a different dictionary than the rest of us. Once again you ignore the faulty case in your model. Why? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020206070208010809040002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjE5MDUxOVowIwYJKoZIhvcNAQkEMRYEFFtAcxIN GtaI82ZBnpRgOwIo0ZpCMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBABC6z72i5JBwJytFEnMRPUlU4stNz78RmQTvt0izJJ3OZUDfuSvi /buJWb4ezmHQULXQW5wzoEr/AQc756NGHMCWcDMV2Eww+4loxtjm0nWikfEG3/BFd/r6ZIKT 3Q7cONgeulpt44yySxJtcAlFpS0h7+82gU3gWqUu9xYRd+Su1SqHHuT/S8XHbb1hP7EPzi7A Nz0YI1oxLCgTfrD3mks7pLFR2FR8UQFrybxhOElALX8xbKOJR4wuBo7pabjjPNqriMYK+uAV e2t+FtULStsoP5oSXZNWy4O0R8OBX2ZKos5eObJ4lYhSvRVuLpSkDf2K109MTyvB7cH7iK6y tosAAAAAAAA= --------------ms020206070208010809040002-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 15:12: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 PAA26253 for ; Tue, 12 Aug 2003 15:12:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CJ4pqt095595 for ; Tue, 12 Aug 2003 12:04:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CJ4pIY095594 for ietf-calendar-bks; Tue, 12 Aug 2003 12:04:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CJ4oqt095588 for ; Tue, 12 Aug 2003 12:04:50 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7CJ4jEB014000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 12:04:50 -0700 Message-ID: <3F393A47.3040801@Royer.com> Date: Tue, 12 Aug 2003 13:04:39 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090803010701030008000009" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090803010701030008000009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug still wondered on 08/12/2003 01:37:39 PM: > > > So why does Doug not understand these distinctions? The answer is > > > because this does not work for his delta RECURRENCE-ID model. > > > > Why does Burce ignore all facts that show that it makes the object > > indistigushable from an object with a missed original? > > The problem of distiction is ONLY an issue for your delta model Doug. > Its NOT a problem for a fixed RECURRENCE-ID model as Ive already shown. Once again you ignore the problem in your model - why? You simply ignore email that shows the bug. Then you repeat the cases where it works. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090803010701030008000009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjE5MDQzOVowIwYJKoZIhvcNAQkEMRYEFF5rus9i 1+tdGnGtyEtFE9ygCVLiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAAHUhLMWEMJM2nKbBY20VlpQ3Hz9f907aU7XPqEm8WVohcah6as6 /bVz3+nUd4cOqo9ZGzPHeqzAA8wkUwh8RKMPsrZZH1QF7ivUf7rKE+NwFTa7s/DqT3wNXVZO QmilwPax3O+ZxNsFtFKZe6vRf+hbQcphXm6zlze0HjTYOMhCn2635JHY/38tNjLIhhvbgdQx EAcm1Pq9+ulqAVJIjNsJ4KZl6ARXBba02PZM8/qvcEA2o4LZKHinRP6fP+0g9rCJP+mZbiI+ 7axe3xTiaHmOkHrgaVYNp+NB1Jz6lsmUFcEeTHKp6I+Z8xtkTkq1SrzZLyODbFeedBsmGr2v dbQAAAAAAAA= --------------ms090803010701030008000009-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 17:32: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 RAA29865 for ; Tue, 12 Aug 2003 17:32:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CLKFqt002673 for ; Tue, 12 Aug 2003 14:20:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CLKF6b002672 for ietf-calendar-bks; Tue, 12 Aug 2003 14:20:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CLKAqt002653 for ; Tue, 12 Aug 2003 14:20:12 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mga1-0006i6-00 for ; Tue, 12 Aug 2003 23:21:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mga0-0006hw-00 for ; Tue, 12 Aug 2003 23:21:20 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mgYm-0004Hl-00 for ; Tue, 12 Aug 2003 23:20:04 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 14:20:03 -0700 Lines: 163 Message-ID: References: <3F393A47.3040801@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: > Once again you ignore the problem in your model - why? Aside from the fact that you seem to be doing the same thing. I'll try and answer the question. We have responded to every suggested fault you have chosen to submit. We have shown in every case why the fixed-id model supports what you claim it does not. When you have told us that we are ignoring it, we have asked you to either provide a pointer or to repeat yourself which you have not done. I'm asking you now Doug. What error or shortcoming are we ignoring? I promise to respond to it in the followup post to yours. At the end of the email I will either admit there's a problem or declare that your assertion is wrong. Further I will put the 'current-value' model through the same test. Since I am obviously, in your eyes, an incompetent reader who can't grasp what you are saying please treat me as someone who needs to be led by the bit to what you want me to see about this particular failure you seem to say we are ignoring. > You simply ignore email that shows the bug. Then you repeat > the cases where it works. The only case that I can recall where you purported a bug in the fixed-id model was the case where you said it had a problem with overlapping DTSTARTs of different events. Assuming that you need this answer repeated to you I will demonstrate using the fixed-id model how we can take a recurring event of 4 instances, reassign them all to start at the exact same DTSTART in different locations, and then put them all back where they were. I will use SEQ for SEQUENCE and RID for RECURRENCE-ID please don't let slight modification confuse you. Step 1 the recurring event: BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VEVENT UID:1 SEQ:0 RDATE:Jan-3 RDATE:Jan-4 RDATE:Jan-5 RDATE:Jan-6 Location:A END:VEVENT END:VCALENDAR Now for those of who would like a summary of every component that this object has, this is what it looks like: UID:1/SEQ:0/RDATE:Jan-3/.../RDATE:Jan-6/DTSTART:Jan-3/Location:A UID:1/RID:Jan-3/SEQ:0/DTSTART:Jan-3/Location:A UID:1/RID:Jan-4/SEQ:0/DTSTART:Jan-4/Location:A UID:1/RID:Jan-5/SEQ:0/DTSTART:Jan-5/Location:A UID:1/RID:Jan-6/SEQ:0/DTSTART:Jan-6/Location:A Step 2 move the Jan-4/5/6 instance's DTSTART time to Jan-3 and put them in a separate location: BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VEVENT UID:1 RID:Jan-4 SEQ:1 DTSTART:Jan-3 Location:B END:VEVENT BEGIN:VEVENT UID:1 RID:Jan-5 SEQ:1 DTSTART:Jan-3 Location:C END:VEVENT BEGIN:VEVENT UID:1 RID:Jan-6 SEQ:1 DTSTART:Jan-3 Location:D END:VEVENT END:VCALENDAR Now for those of you still reading a summarized description of each component in this state would be the following: UID:1/SEQ:0/RDATE:Jan-3/.../RDATE:Jan-6/DTSTART:Jan-3/Location:A UID:1/RID:Jan-3/SEQ:0/DTSTART:Jan-3/Location:A UID:1/RID:Jan-4/SEQ:1/DTSTART:Jan-3/Location:B UID:1/RID:Jan-5/SEQ:1/DTSTART:Jan-3/Location:C UID:1/RID:Jan-6/SEQ:1/DTSTART:Jan-3/Location:D Now again, to put them all back: BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VEVENT UID:1 RID:Jan-4 SEQ:2 DTSTART:Jan-4 Location:A END:VEVENT BEGIN:VEVENT UID:1 RID:Jan-5 SEQ:2 DTSTART:Jan-5 Location:A END:VEVENT BEGIN:VEVENT UID:1 RID:Jan-6 SEQ:2 DTSTART:Jan-6 Location:A END:VEVENT END:VCALENDAR Done. That's it. Here's the final state summary of each component: UID:1/SEQ:0/RDATE:Jan-3/.../RDATE:Jan-6/DTSTART:Jan-3/Location:A UID:1/RID:Jan-3/SEQ:0/DTSTART:Jan-3/Location:A UID:1/RID:Jan-4/SEQ:2/DTSTART:Jan-4/Location:A UID:1/RID:Jan-5/SEQ:2/DTSTART:Jan-5/Location:A UID:1/RID:Jan-6/SEQ:2/DTSTART:Jan-6/Location:A -------------------------------------------------- Ok Doug, your turn. Please show me how to do this same example using your 'current-value' model. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 18:21: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 SAA01585 for ; Tue, 12 Aug 2003 18:21:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CMDQqt007424 for ; Tue, 12 Aug 2003 15:13:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CMDPn7007423 for ietf-calendar-bks; Tue, 12 Aug 2003 15:13:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CMDOqt007416 for ; Tue, 12 Aug 2003 15:13:24 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7CMDOEB015488 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 15:13:26 -0700 Message-ID: <3F39667F.4060007@Royer.com> Date: Tue, 12 Aug 2003 16:13:19 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F393A47.3040801@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040407020501020706090500" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040407020501020706090500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>Once again you ignore the problem in your model - why? > I showed you the problem. Your responded to it. And you still pretend I did not explain it. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040407020501020706090500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjIyMTMxOVowIwYJKoZIhvcNAQkEMRYEFKGhH+tC d9sqez0BdBLU47EwIfonMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEWsXSEe3bPfyB967IKMuGL3XjLK4JXF01rKqGviwTspa7xk/Pqp yhjzpiVeI8m8/68oB41EHYrjk2lgsprmebk+TzSVrwDQEpJ15mol70srq3UaublxIMckUH5B TlFrcM6o+xd6qzG2QQe06wsQTdCfjJF5AfN3+OP69VCe0UiZmhYeddq9WAfxwU1r9bXVMs23 oL8BBvVGJQq1gXSheQ4boySjfyNksbhcYyVOqhgCHmyHbrg6KXqyGm7z2EWacHHK9RysJ/ls MTO4PkD/gtdvEDA/9ZF6GNq/OCLlerACXi9nU4uD6I45otTqWfVuXdWB2/5YiEGsEezImEBz CU8AAAAAAAA= --------------ms040407020501020706090500-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 18:48: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 SAA02066 for ; Tue, 12 Aug 2003 18:48:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CMchqt010092 for ; Tue, 12 Aug 2003 15:38:43 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CMchX1010091 for ietf-calendar-bks; Tue, 12 Aug 2003 15:38:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from DrPepper (adsl-67-119-131-54.dsl.lsan03.pacbell.net [67.119.131.54]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CMcgqt010086 for ; Tue, 12 Aug 2003 15:38:42 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 5E23A8113E3; Tue, 12 Aug 2003 15:38:44 -0700 (PDT) Received: from cocacola (unknown [192.168.1.102]) by DrPepper (Postfix) with ESMTP id 4DA5A8113E1 for ; Tue, 12 Aug 2003 15:38:43 -0700 (PDT) Message-ID: <008f01c36122$7c26b640$6601a8c0@daclubhouse.net> From: "Michael Fair" To: References: <3F393A47.3040801@Royer.com> <3F39667F.4060007@Royer.com> Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 15:38:43 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit When did you show me the problem? What email? ----- Original Message ----- From: "Doug Royer" Newsgroups: gmane.ietf.calendar Sent: Tuesday, August 12, 2003 3:13 PM Subject: Re: RECURRENCE-ID discussion > > > Michael Fair wrote: > >>Once again you ignore the problem in your model - why? > > > > I showed you the problem. Your responded to it. And > you still pretend I did not explain it. > > > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Tue Aug 12 19:10: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 TAA02436 for ; Tue, 12 Aug 2003 19:10:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CN2Lqt010886 for ; Tue, 12 Aug 2003 16:02:21 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CN2L9Y010885 for ietf-calendar-bks; Tue, 12 Aug 2003 16:02:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CN2Iqt010880 for ; Tue, 12 Aug 2003 16:02:19 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19miAy-0007UJ-00 for ; Wed, 13 Aug 2003 01:03:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19miAw-0007UB-00 for ; Wed, 13 Aug 2003 01:03:34 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mi9i-0006i3-00 for ; Wed, 13 Aug 2003 01:02:18 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 16:02:18 -0700 Lines: 105 Message-ID: References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@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: > Michael Fair wrote: > > I don't know what this hangup on modification > > versus new object is about? > > > That idea does not work for all cases. Assuming that we are still talking about Z-1 being a recurring event and Z is an instance modify then it does work. It works very well. I am so far the only one on this list who has potentially shown a sequence of messages that _might_ cause an inconsistency using the fixed-id model because there is one circumstance under which the RECURRENCE-ID _might_ change. And in fact, it happens to be the same sequence of messages that causes the 'current-value' model to fall apart. > Your CUA will be out of SYNC with the organizer view > if iMIP objects that are sent as updates are interpreted > as new objects - when received out of order via iMIP. Why would it be out of sync? The Z message is totally and completely a self contained update with all information from the You can pretend that out of order objects will not > happen via iMIP all you want. It is not true. It's good that we can agree on this. Forever more neither one of us has to prove that messages can arrive out of order, it can just be accepted that they might. Further, all of us will have to defend what our respective models do when it receives messages out of order. > Servers queue up outgoing email all of the time > and for reasons of system load can send them out in an > order that is random. Your CUA will call it a new > item then ignore the SEQUENCE:x-1 object because > it thinks it is older. The fixed-id model doesn't ever need to see the SEQ:x-1 object to know that it has the latest version of the instance. I think you believe that if X was recurrence instance modify, and X-1 was a recurring event definition, that we would ignore X-1 and that would be bad. And if the fixed-id model did ignore it, you would be right, it would be bad. But it doesn't ignore it so you just misunderstand the model. If we receive an instance update with UID:1/RID:1/SEQ:1 we will put it on the caledar as a recurring event instance with the primary key UID:1/RID:1. If afterward we recieve a full blown recurring event UID:1/SEQ:0 we will not ignore it because we haven't seen a message for event UID:1/RID:NULL before. We will process this new event message and add every instance that we have not already seen (i.e. we will skip UID:1/RID:1 because we already have that object at a SEQ > 0). The easiest way for you to think about this is using SQL. An event in the iTIP model has a primary key of: UID: NOT NULL UNIQUE RECURRENCE-ID: DEFAULT VALUE NULL events primary key (UID, RECURRENCE-ID); Note that in this definition RECURRENCE-ID could be NULL and is NULL unless otherwise specified. So in the iTIP model all events that do not have a RECURRENCE-ID in them effectively have a RECURRENCE-ID of NULL. So when we recieve the first for message UID:1/RID:1 we look in our calendar and don't find one. We process it as a new event and put that instance on the calendar using the primary key UID:1/RID:1. Then when we later receive a message for UID:1/RID:NULL we look in our table and again don't find one. We process it as a new event and now put the entire series on our calendar. When we process the UID:1/RID:null series, we don't clobber the UID:1/RID:1 we have as that would be stupid. UID:1/RID:1 is at SEQ:1 whereas UID:1/RID:NULL is at SEQ:0. As such, our SEQ:1 version of UID:1/RID:1 trumps UID:1/RID:NULL's implied SEQ:0 version of the same event. Same goes for DTSTAMP in case the SEQUENCE values happen to match. This is all very clear from reading 2.1.5. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 19:45: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 TAA03986 for ; Tue, 12 Aug 2003 19:45:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CNaOqt011908 for ; Tue, 12 Aug 2003 16:36:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CNaOSD011907 for ietf-calendar-bks; Tue, 12 Aug 2003 16:36:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CNaMqt011902 for ; Tue, 12 Aug 2003 16:36:23 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7CNaMEB016220 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 16:36:24 -0700 Message-ID: <3F3979F1.9070505@Royer.com> Date: Tue, 12 Aug 2003 17:36:17 -0600 From: Doug Royer 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: RECURRENCE-ID discussion References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010604020902050207020406" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010604020902050207020406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>Michael Fair wrote: >> >>>I don't know what this hangup on modification >>>versus new object is about? >> >> >>That idea does not work for all cases. > > > Assuming that we are still talking about Z-1 being > a recurring event and Z is an instance modify then > it does work. It works very well. Thank you for acknowledging that you did see the email. The example did NOT include the sequence of events that your email replied to, and it does not address the issue. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010604020902050207020406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMjIzMzYxN1owIwYJKoZIhvcNAQkEMRYEFDbdjxdl zkRDoypKHd0lbBaBfR/CMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAFNhIghqBVdqp9NScd1hSa7OcnyQXlctwugfmt7EyvF6CDJzVhmB hVHu4JK/peVuNhWsw5n0HbBZHEISgxqOf2Xl/ESfseHRyx6oGnNqUM3V9uevqg4bhb9NXAEO to1N8bGpjNWRdr8zU2SgYkCb0+830uqfSo3h5p3O7ZS31BMvFim9oABoIx8cbz9DU/ZfCfHW OmkASRbI4Ghs9vUarGE5ojgjshb7AWhcjaDP8qWjDC6aJQCrN+OpA5RAq3YSipCGGbUBm/3b 9p0B1/RunMH0I5bphJgNHaE82rTkwtNEglK1YyoA8xeV69kAhKknlTtMYeGk81ZlAZU1pjAf GmoAAAAAAAA= --------------ms010604020902050207020406-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 19:51:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04065 for ; Tue, 12 Aug 2003 19:51:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CNh7qt012120 for ; Tue, 12 Aug 2003 16:43:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CNh7C2012119 for ietf-calendar-bks; Tue, 12 Aug 2003 16:43:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CNh6qt012114 for ; Tue, 12 Aug 2003 16:43:06 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7CNh72O007263; Tue, 12 Aug 2003 17:43:07 -0600 (MDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7CNh6aJ023220; Tue, 12 Aug 2003 16:43:06 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJJ006UZ5VUGP@ha13sca-mail1.sfbay.sun.com>; Tue, 12 Aug 2003 16:43:06 -0700 (PDT) Date: Tue, 12 Aug 2003 16:43:09 -0700 From: Satya Vempati Subject: RE: RECURRENCE-ID discussion To: Michael Fair , "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT On a related note, is there a part of the RFC that states that the SEQUENCE number should always be incremented by 1? The RFC's talk of incrementing, but as far as I can tell, the increments can vary. If sequence number increments are not always 1, will the changing RECURRENCE-ID model work? -----Original Message----- From: Michael Fair [mailto:michael@daclubhouse.net] Sent: Tuesday, August 12, 2003 4:02 PM To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion > Michael Fair wrote: > > I don't know what this hangup on modification > > versus new object is about? > > > That idea does not work for all cases. Assuming that we are still talking about Z-1 being a recurring event and Z is an instance modify then it does work. It works very well. I am so far the only one on this list who has potentially shown a sequence of messages that _might_ cause an inconsistency using the fixed-id model because there is one circumstance under which the RECURRENCE-ID _might_ change. And in fact, it happens to be the same sequence of messages that causes the 'current-value' model to fall apart. > Your CUA will be out of SYNC with the organizer view > if iMIP objects that are sent as updates are interpreted > as new objects - when received out of order via iMIP. Why would it be out of sync? The Z message is totally and completely a self contained update with all information from the You can pretend that out of order objects will not > happen via iMIP all you want. It is not true. It's good that we can agree on this. Forever more neither one of us has to prove that messages can arrive out of order, it can just be accepted that they might. Further, all of us will have to defend what our respective models do when it receives messages out of order. > Servers queue up outgoing email all of the time > and for reasons of system load can send them out in an > order that is random. Your CUA will call it a new > item then ignore the SEQUENCE:x-1 object because > it thinks it is older. The fixed-id model doesn't ever need to see the SEQ:x-1 object to know that it has the latest version of the instance. I think you believe that if X was recurrence instance modify, and X-1 was a recurring event definition, that we would ignore X-1 and that would be bad. And if the fixed-id model did ignore it, you would be right, it would be bad. But it doesn't ignore it so you just misunderstand the model. If we receive an instance update with UID:1/RID:1/SEQ:1 we will put it on the caledar as a recurring event instance with the primary key UID:1/RID:1. If afterward we recieve a full blown recurring event UID:1/SEQ:0 we will not ignore it because we haven't seen a message for event UID:1/RID:NULL before. We will process this new event message and add every instance that we have not already seen (i.e. we will skip UID:1/RID:1 because we already have that object at a SEQ > 0). The easiest way for you to think about this is using SQL. An event in the iTIP model has a primary key of: UID: NOT NULL UNIQUE RECURRENCE-ID: DEFAULT VALUE NULL events primary key (UID, RECURRENCE-ID); Note that in this definition RECURRENCE-ID could be NULL and is NULL unless otherwise specified. So in the iTIP model all events that do not have a RECURRENCE-ID in them effectively have a RECURRENCE-ID of NULL. So when we recieve the first for message UID:1/RID:1 we look in our calendar and don't find one. We process it as a new event and put that instance on the calendar using the primary key UID:1/RID:1. Then when we later receive a message for UID:1/RID:NULL we look in our table and again don't find one. We process it as a new event and now put the entire series on our calendar. When we process the UID:1/RID:null series, we don't clobber the UID:1/RID:1 we have as that would be stupid. UID:1/RID:1 is at SEQ:1 whereas UID:1/RID:NULL is at SEQ:0. As such, our SEQ:1 version of UID:1/RID:1 trumps UID:1/RID:NULL's implied SEQ:0 version of the same event. Same goes for DTSTAMP in case the SEQUENCE values happen to match. This is all very clear from reading 2.1.5. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 20:33:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05083 for ; Tue, 12 Aug 2003 20:33:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D0P1qt013527 for ; Tue, 12 Aug 2003 17:25:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D0P14H013526 for ietf-calendar-bks; Tue, 12 Aug 2003 17:25:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D0Owqt013518 for ; Tue, 12 Aug 2003 17:24:59 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mjSy-00081h-00 for ; Wed, 13 Aug 2003 02:26:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mjSx-00081Z-00 for ; Wed, 13 Aug 2003 02:26:15 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mjRj-0008F0-00 for ; Wed, 13 Aug 2003 02:24:59 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 17:24:59 -0700 Lines: 150 Message-ID: References: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On a related note, is there a part of the RFC that states > that the SEQUENCE number should always be incremented by 1? There is nothing iTIP that says it. And since messages can get lost there's no gaurantee that you will see monotonic increments anyway. So both models need to handle that case. But there is this from iCal (2445): 4.8.7.4 Sequence Number Property Name: SEQUENCE ... It is monotonically incremented by the "Organizer's" CUA each time the "Organizer" makes a significant revision to the calendar component. ... > If sequence number increments are not always 1, will the changing > RECURRENCE-ID model work? Well it will be no more broken than it already is... Not monotonically incrementing the SEQUENCE will simply make recipient CUAs think they missed something and in either model send a REFRESH. Since there really wasn't any actual missed data just a bad SEQUENCE jump the REFRESH is mostly a non-op. -- Michael -- > -----Original Message----- > From: Michael Fair [mailto:michael@daclubhouse.net] > Sent: Tuesday, August 12, 2003 4:02 PM > To: ietf-calendar@imc.org > Subject: Re: RECURRENCE-ID discussion > > > > > Michael Fair wrote: > > > I don't know what this hangup on modification > > > versus new object is about? > > > > > > That idea does not work for all cases. > > Assuming that we are still talking about Z-1 being > a recurring event and Z is an instance modify then > it does work. It works very well. > > I am so far the only one on this list who has potentially > shown a sequence of messages that _might_ cause an > inconsistency using the fixed-id model because there is > one circumstance under which the RECURRENCE-ID _might_ change. > > And in fact, it happens to be the same sequence of messages > that causes the 'current-value' model to fall apart. > > > Your CUA will be out of SYNC with the organizer view > > if iMIP objects that are sent as updates are interpreted > > as new objects - when received out of order via iMIP. > > Why would it be out of sync? > > The Z message is totally and completely a self contained > update with all information from the to that instance. > > > > > You can pretend that out of order objects will not > > happen via iMIP all you want. It is not true. > > It's good that we can agree on this. Forever more neither > one of us has to prove that messages can arrive out of order, > it can just be accepted that they might. > > Further, all of us will have to defend what our respective > models do when it receives messages out of order. > > > Servers queue up outgoing email all of the time > > and for reasons of system load can send them out in an > > order that is random. Your CUA will call it a new > > item then ignore the SEQUENCE:x-1 object because > > it thinks it is older. > > The fixed-id model doesn't ever need to see the SEQ:x-1 > object to know that it has the latest version of the instance. > > I think you believe that if X was recurrence instance modify, > and X-1 was a recurring event definition, that we would ignore > X-1 and that would be bad. > > And if the fixed-id model did ignore it, you would be right, > it would be bad. > > But it doesn't ignore it so you just misunderstand the model. > > If we receive an instance update with UID:1/RID:1/SEQ:1 we > will put it on the caledar as a recurring event instance > with the primary key UID:1/RID:1. > > If afterward we recieve a full blown recurring event > UID:1/SEQ:0 we will not ignore it because we haven't > seen a message for event UID:1/RID:NULL before. > > We will process this new event message and add every instance > that we have not already seen (i.e. we will skip UID:1/RID:1 > because we already have that object at a SEQ > 0). > > The easiest way for you to think about this is using SQL. > An event in the iTIP model has a primary key of: > UID: NOT NULL UNIQUE > RECURRENCE-ID: DEFAULT VALUE NULL > events primary key (UID, RECURRENCE-ID); > > Note that in this definition RECURRENCE-ID could be NULL > and is NULL unless otherwise specified. > > So in the iTIP model all events that do not have a > RECURRENCE-ID in them effectively have a RECURRENCE-ID > of NULL. > > So when we recieve the first for message UID:1/RID:1 we look > in our calendar and don't find one. We process it as a > new event and put that instance on the calendar using the > primary key UID:1/RID:1. > > Then when we later receive a message for UID:1/RID:NULL > we look in our table and again don't find one. We process > it as a new event and now put the entire series on our > calendar. When we process the UID:1/RID:null series, > we don't clobber the UID:1/RID:1 we have as that would > be stupid. UID:1/RID:1 is at SEQ:1 whereas UID:1/RID:NULL > is at SEQ:0. As such, our SEQ:1 version of UID:1/RID:1 > trumps UID:1/RID:NULL's implied SEQ:0 version of the > same event. Same goes for DTSTAMP in case the SEQUENCE > values happen to match. > > This is all very clear from reading 2.1.5. > > -- Michael -- > > > > > From owner-ietf-calendar@mail.imc.org Tue Aug 12 20:57:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05516 for ; Tue, 12 Aug 2003 20:57:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D0naqt015058 for ; Tue, 12 Aug 2003 17:49:36 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D0naAe015056 for ietf-calendar-bks; Tue, 12 Aug 2003 17:49:36 -0700 (PDT) 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.9/8.12.8) with ESMTP id h7D0nZqt015036 for ; Tue, 12 Aug 2003 17:49:35 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7D0nWkZ008716; Tue, 12 Aug 2003 17:49:32 -0700 (PDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7D0nWhD007589; Tue, 12 Aug 2003 17:49:32 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJJ0082O8YKE4@ha13sca-mail1.sfbay.sun.com>; Tue, 12 Aug 2003 17:49:32 -0700 (PDT) Date: Tue, 12 Aug 2003 17:49:34 -0700 From: Satya Vempati Subject: RE: RECURRENCE-ID discussion To: Michael Fair , "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT From Merriam-Webster: Monotonically: 2 : having the property either of never increasing or of never decreasing as the values of the independent variable or the subscripts of the terms increase I read this to mean that the SEQUENCE number will never decrease. But, in that case, the changing RECURRENCE-ID model will send the REFRESH for EVERY updated component. -----Original Message----- From: Michael Fair [mailto:michael@daclubhouse.net] Sent: Tuesday, August 12, 2003 5:25 PM To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion > On a related note, is there a part of the RFC that states > that the SEQUENCE number should always be incremented by 1? There is nothing iTIP that says it. And since messages can get lost there's no gaurantee that you will see monotonic increments anyway. So both models need to handle that case. But there is this from iCal (2445): 4.8.7.4 Sequence Number Property Name: SEQUENCE ... It is monotonically incremented by the "Organizer's" CUA each time the "Organizer" makes a significant revision to the calendar component. ... > If sequence number increments are not always 1, will the changing > RECURRENCE-ID model work? Well it will be no more broken than it already is... Not monotonically incrementing the SEQUENCE will simply make recipient CUAs think they missed something and in either model send a REFRESH. Since there really wasn't any actual missed data just a bad SEQUENCE jump the REFRESH is mostly a non-op. -- Michael -- > -----Original Message----- > From: Michael Fair [mailto:michael@daclubhouse.net] > Sent: Tuesday, August 12, 2003 4:02 PM > To: ietf-calendar@imc.org > Subject: Re: RECURRENCE-ID discussion > > > > > Michael Fair wrote: > > > I don't know what this hangup on modification > > > versus new object is about? > > > > > > That idea does not work for all cases. > > Assuming that we are still talking about Z-1 being > a recurring event and Z is an instance modify then > it does work. It works very well. > > I am so far the only one on this list who has potentially > shown a sequence of messages that _might_ cause an > inconsistency using the fixed-id model because there is > one circumstance under which the RECURRENCE-ID _might_ change. > > And in fact, it happens to be the same sequence of messages > that causes the 'current-value' model to fall apart. > > > Your CUA will be out of SYNC with the organizer view > > if iMIP objects that are sent as updates are interpreted > > as new objects - when received out of order via iMIP. > > Why would it be out of sync? > > The Z message is totally and completely a self contained > update with all information from the to that instance. > > > > > You can pretend that out of order objects will not > > happen via iMIP all you want. It is not true. > > It's good that we can agree on this. Forever more neither > one of us has to prove that messages can arrive out of order, > it can just be accepted that they might. > > Further, all of us will have to defend what our respective > models do when it receives messages out of order. > > > Servers queue up outgoing email all of the time > > and for reasons of system load can send them out in an > > order that is random. Your CUA will call it a new > > item then ignore the SEQUENCE:x-1 object because > > it thinks it is older. > > The fixed-id model doesn't ever need to see the SEQ:x-1 > object to know that it has the latest version of the instance. > > I think you believe that if X was recurrence instance modify, > and X-1 was a recurring event definition, that we would ignore > X-1 and that would be bad. > > And if the fixed-id model did ignore it, you would be right, > it would be bad. > > But it doesn't ignore it so you just misunderstand the model. > > If we receive an instance update with UID:1/RID:1/SEQ:1 we > will put it on the caledar as a recurring event instance > with the primary key UID:1/RID:1. > > If afterward we recieve a full blown recurring event > UID:1/SEQ:0 we will not ignore it because we haven't > seen a message for event UID:1/RID:NULL before. > > We will process this new event message and add every instance > that we have not already seen (i.e. we will skip UID:1/RID:1 > because we already have that object at a SEQ > 0). > > The easiest way for you to think about this is using SQL. > An event in the iTIP model has a primary key of: > UID: NOT NULL UNIQUE > RECURRENCE-ID: DEFAULT VALUE NULL > events primary key (UID, RECURRENCE-ID); > > Note that in this definition RECURRENCE-ID could be NULL > and is NULL unless otherwise specified. > > So in the iTIP model all events that do not have a > RECURRENCE-ID in them effectively have a RECURRENCE-ID > of NULL. > > So when we recieve the first for message UID:1/RID:1 we look > in our calendar and don't find one. We process it as a > new event and put that instance on the calendar using the > primary key UID:1/RID:1. > > Then when we later receive a message for UID:1/RID:NULL > we look in our table and again don't find one. We process > it as a new event and now put the entire series on our > calendar. When we process the UID:1/RID:null series, > we don't clobber the UID:1/RID:1 we have as that would > be stupid. UID:1/RID:1 is at SEQ:1 whereas UID:1/RID:NULL > is at SEQ:0. As such, our SEQ:1 version of UID:1/RID:1 > trumps UID:1/RID:NULL's implied SEQ:0 version of the > same event. Same goes for DTSTAMP in case the SEQUENCE > values happen to match. > > This is all very clear from reading 2.1.5. > > -- Michael -- > > > > > From owner-ietf-calendar@mail.imc.org Tue Aug 12 21: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 VAA05786 for ; Tue, 12 Aug 2003 21:11:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D13dqt015975 for ; Tue, 12 Aug 2003 18:03:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D13duL015974 for ietf-calendar-bks; Tue, 12 Aug 2003 18:03:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D13bqt015966 for ; Tue, 12 Aug 2003 18:03:38 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7D13d2O012405; Tue, 12 Aug 2003 19:03:39 -0600 (MDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7D13dhD012058; Tue, 12 Aug 2003 18:03:39 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJJ008DF9M3E4@ha13sca-mail1.sfbay.sun.com>; Tue, 12 Aug 2003 18:03:39 -0700 (PDT) Date: Tue, 12 Aug 2003 18:03:41 -0700 From: Satya Vempati Subject: RE: RECURRENCE-ID discussion To: Michael Fair , "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Why do you need to send a REFRESH in the fixed recurrence-id model? If your last SEQUENCE was 2 and the current SEQUENCE is 4 why can't you merely update the component? -----Original Message----- From: Michael Fair [mailto:michael@daclubhouse.net] Sent: Tuesday, August 12, 2003 5:25 PM To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion > On a related note, is there a part of the RFC that states > that the SEQUENCE number should always be incremented by 1? There is nothing iTIP that says it. And since messages can get lost there's no gaurantee that you will see monotonic increments anyway. So both models need to handle that case. But there is this from iCal (2445): 4.8.7.4 Sequence Number Property Name: SEQUENCE ... It is monotonically incremented by the "Organizer's" CUA each time the "Organizer" makes a significant revision to the calendar component. ... > If sequence number increments are not always 1, will the changing > RECURRENCE-ID model work? Well it will be no more broken than it already is... Not monotonically incrementing the SEQUENCE will simply make recipient CUAs think they missed something and in either model send a REFRESH. Since there really wasn't any actual missed data just a bad SEQUENCE jump the REFRESH is mostly a non-op. -- Michael -- > -----Original Message----- > From: Michael Fair [mailto:michael@daclubhouse.net] > Sent: Tuesday, August 12, 2003 4:02 PM > To: ietf-calendar@imc.org > Subject: Re: RECURRENCE-ID discussion > > > > > Michael Fair wrote: > > > I don't know what this hangup on modification > > > versus new object is about? > > > > > > That idea does not work for all cases. > > Assuming that we are still talking about Z-1 being > a recurring event and Z is an instance modify then > it does work. It works very well. > > I am so far the only one on this list who has potentially > shown a sequence of messages that _might_ cause an > inconsistency using the fixed-id model because there is > one circumstance under which the RECURRENCE-ID _might_ change. > > And in fact, it happens to be the same sequence of messages > that causes the 'current-value' model to fall apart. > > > Your CUA will be out of SYNC with the organizer view > > if iMIP objects that are sent as updates are interpreted > > as new objects - when received out of order via iMIP. > > Why would it be out of sync? > > The Z message is totally and completely a self contained > update with all information from the to that instance. > > > > > You can pretend that out of order objects will not > > happen via iMIP all you want. It is not true. > > It's good that we can agree on this. Forever more neither > one of us has to prove that messages can arrive out of order, > it can just be accepted that they might. > > Further, all of us will have to defend what our respective > models do when it receives messages out of order. > > > Servers queue up outgoing email all of the time > > and for reasons of system load can send them out in an > > order that is random. Your CUA will call it a new > > item then ignore the SEQUENCE:x-1 object because > > it thinks it is older. > > The fixed-id model doesn't ever need to see the SEQ:x-1 > object to know that it has the latest version of the instance. > > I think you believe that if X was recurrence instance modify, > and X-1 was a recurring event definition, that we would ignore > X-1 and that would be bad. > > And if the fixed-id model did ignore it, you would be right, > it would be bad. > > But it doesn't ignore it so you just misunderstand the model. > > If we receive an instance update with UID:1/RID:1/SEQ:1 we > will put it on the caledar as a recurring event instance > with the primary key UID:1/RID:1. > > If afterward we recieve a full blown recurring event > UID:1/SEQ:0 we will not ignore it because we haven't > seen a message for event UID:1/RID:NULL before. > > We will process this new event message and add every instance > that we have not already seen (i.e. we will skip UID:1/RID:1 > because we already have that object at a SEQ > 0). > > The easiest way for you to think about this is using SQL. > An event in the iTIP model has a primary key of: > UID: NOT NULL UNIQUE > RECURRENCE-ID: DEFAULT VALUE NULL > events primary key (UID, RECURRENCE-ID); > > Note that in this definition RECURRENCE-ID could be NULL > and is NULL unless otherwise specified. > > So in the iTIP model all events that do not have a > RECURRENCE-ID in them effectively have a RECURRENCE-ID > of NULL. > > So when we recieve the first for message UID:1/RID:1 we look > in our calendar and don't find one. We process it as a > new event and put that instance on the calendar using the > primary key UID:1/RID:1. > > Then when we later receive a message for UID:1/RID:NULL > we look in our table and again don't find one. We process > it as a new event and now put the entire series on our > calendar. When we process the UID:1/RID:null series, > we don't clobber the UID:1/RID:1 we have as that would > be stupid. UID:1/RID:1 is at SEQ:1 whereas UID:1/RID:NULL > is at SEQ:0. As such, our SEQ:1 version of UID:1/RID:1 > trumps UID:1/RID:NULL's implied SEQ:0 version of the > same event. Same goes for DTSTAMP in case the SEQUENCE > values happen to match. > > This is all very clear from reading 2.1.5. > > -- Michael -- > > > > > From owner-ietf-calendar@mail.imc.org Tue Aug 12 21:12:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05838 for ; Tue, 12 Aug 2003 21:12:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D167qt016051 for ; Tue, 12 Aug 2003 18:06:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D167BW016050 for ietf-calendar-bks; Tue, 12 Aug 2003 18:06:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D165qt016044 for ; Tue, 12 Aug 2003 18:06:06 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7D165EB016812 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 18:06:07 -0700 Message-ID: <3F398EF8.4030904@Royer.com> Date: Tue, 12 Aug 2003 19:06:00 -0600 From: Doug Royer 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: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030608000401010707000805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030608000401010707000805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: > On a related note, is there a part of the RFC that states that the > SEQUENCE number should always be incremented by 1? Yes - its in iCal where SEQUENCE is defined. > The RFC's talk of > incrementing, but as far as I can tell, the increments can vary. What an attendee sees can vary if they are or are not part of versions of the object. If an ATTENDEE sees an update to an instance and it is more than one behind the current SEQUENCE number that ATTENDEE-CUA is going to have to do a REFRESH in order to get the latest object in order to apply the update. The only exception is when the Bruces new model is used to invite you to a single instance and when it is the first object you get with that UID, then the ATTENDEE has to always do an REFRESH because they broke the uniqueness of single instance updates and called it a new invitation. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030608000401010707000805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzAxMDYwMFowIwYJKoZIhvcNAQkEMRYEFKUwqjSw 2yUa/uyMLwFPdyo+Nv6HMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBALpUjjBSAuLChYV6kmCzEVWvcCY3alzPswd/EjXJPiS06icojAa7 cGlRnboMu08jarsfpTrPG0IQc4CxqJV8meAqSkb2GVUAnXSQ+1mbAOrDKsfRQswd81LMCPKN ne13frCvpM3Jz/iQuY82mNt/4OFgrXqAFus4ACAzZ/32XzBZL+jiRYWEuaAzBdZvshX1VgwQ EDGI15VDmaZyqsqkWDi6JW8uwApIVv+iw52ytKdg89ZVK1KhEUEzr9KrTlxb2alC7cfAPfdO AakwUF7Ur1gugUyPvKHJ6aBbuFuR6DXds1O5RL4M+BD7nKLITw4uN5jzAsbVsUAJKpwKeE4W McEAAAAAAAA= --------------ms030608000401010707000805-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 21:23: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 VAA05946 for ; Tue, 12 Aug 2003 21:23:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D1Fvqt017320 for ; Tue, 12 Aug 2003 18:15:57 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D1Fvkc017319 for ietf-calendar-bks; Tue, 12 Aug 2003 18:15:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D1Ftqt017313 for ; Tue, 12 Aug 2003 18:15:55 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7D1FqEB016882 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 18:15:56 -0700 Message-ID: <3F399142.6030307@Royer.com> Date: Tue, 12 Aug 2003 19:15:46 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080609020108020004080500" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080609020108020004080500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: >>From Merriam-Webster: > Monotonically: > > 2 : having the property either of never increasing or of never decreasing > as the values of the independent variable or the subscripts of the terms > increase > > I read this to mean that the SEQUENCE number will never decrease. It will never decrease. Which is why the Bruce new model of inviting a new attendee to a single instance will not work under some circumstances. If you get an old SEQUENCE you discard it because iTIP declares it obsolete. So an original invite of SEQUENCE:x will be discarded if an update to that instance (SEQUENCE:x+1) is interpreted as the original invitation. The CUA will never know it needs to REFRESH. > But, in that case, the changing RECURRENCE-ID model will send the REFRESH > for EVERY updated component. No and that is shown in iTIP. You can send an entire new object in which case it has the NEW sequence number that is 1 larger. Or you can send an update with a NEW sequence number that is 1 larger. Both will have the same sequence number which will be newer than the attendee has. If it is an update (For those of us that use the iTIP and not the Bruces model to invite) and the attendee does not have that UID, then the CUA will know to do a REFRESH as it has missed the original (or wait for it). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080609020108020004080500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzAxMTU0NlowIwYJKoZIhvcNAQkEMRYEFNYt/ALu U3NJtfndsXjYvx2XJY1dMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJh05DfF2jKNfldZqF1kqjQsCWmZRiLYBao5/CT0AuPmxWfLABZR 6MTn9XzIFDk2YSHS92ngIgvYSl2TInz/qdsi9w26Fq0dmVrVw0O5t8PNOZdIfv/kHFBfx+IN aVaJO50ZGvSq++IAx1iklzyiYH8UvymCb0zXralPLMqP3AJN9jWviJ6XsUbsu/bNsEefq5Vp e/wNBCVriQjv283JfQS0BvmLXvpNqMolbQa+mP5L5a3ZGwFdWMXNmnlknVEsH/MpafZE8iQ4 fYB4pF/ogRy7KO3jmNgK2xO7DUjxymNyT+dTwokjyPuXBQnGg6yBVflLHm8/NAkSRZ7PHwQM h0kAAAAAAAA= --------------ms080609020108020004080500-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 21:27: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 VAA06163 for ; Tue, 12 Aug 2003 21:27:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D1K4qt017657 for ; Tue, 12 Aug 2003 18:20:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D1K3Pn017656 for ietf-calendar-bks; Tue, 12 Aug 2003 18:20:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D1K2qt017651 for ; Tue, 12 Aug 2003 18:20:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7D1K2EB016899 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 18:20:04 -0700 Message-ID: <3F39923D.4060809@Royer.com> Date: Tue, 12 Aug 2003 19:19:57 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060505030608000508080107" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060505030608000508080107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: > Why do you need to send a REFRESH in the fixed recurrence-id model? If > your last SEQUENCE was 2 and the current SEQUENCE is 4 why can't you > merely update the component? I can't speak for Bruces model, for iTIP: If the object is a an iTIP (4.2.3) update, then it is a replacement for the object. No. you do not need to do a REFRESH. If the object is a an iTIP (4.4.2) update, then yes you have to do a REFRESH because you do not have the details to know what to update. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060505030608000508080107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzAxMTk1N1owIwYJKoZIhvcNAQkEMRYEFJvO6LrW RfvRUcqSRw4Dc9cIck75MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAAX+j2R+v4SfDueQkFo0CrJvkkCpL2u1zJ4iTvhtAhNc6yzq4sgY Ll1YUHjQtWoaCCbpWjnBmPUPApSlWd3tHBEBg/kgwVAGldMoMYffKcgO7HF3Jh+u2M0/+5tX velbHEPEo3Xr6hjOf0BBnx2Sd7QSn60PQAXz/bI1jwpw6tuKASiU9g1770Sr55XXjhe9Fc6C VIM0ixr4n+5Nk8hCGgmvJCE4n+e7ZsITRWQPjFBBExG3maLq0pzOO1BYtqI/kkEkKM7oGrRL vgAiAK/+VtSC0mp6fXaifWuVHk2G8JmJ+OkUvtPRqPSq+kD0ezbIofoJ6w8kYRut/lXFlrm9 YCoAAAAAAAA= --------------ms060505030608000508080107-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 21:54: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 VAA06530 for ; Tue, 12 Aug 2003 21:54:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D1l5qt019510 for ; Tue, 12 Aug 2003 18:47:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D1l5Va019509 for ietf-calendar-bks; Tue, 12 Aug 2003 18:47:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D1l1qt019498 for ; Tue, 12 Aug 2003 18:47:02 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mkkM-0004F1-00 for ; Wed, 13 Aug 2003 03:48:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mkkM-0004Et-00 for ; Wed, 13 Aug 2003 03:48:18 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mkj8-0001cy-00 for ; Wed, 13 Aug 2003 03:47:02 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 18:47:01 -0700 Lines: 140 Message-ID: References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@Royer.com> <3F3979F1.9070505@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: > Thank you for acknowledging that you did see the email. I've been trying to figure out what email you've been talking about and you haven't been very helpful. I've been trying to figure out what example you've been talking about and you haven't been very helpful. > The example did NOT include the sequence of events that your > email replied to, and it does not address the issue. Ok since you have still decided to be very unhelpful in calrifying which sequence of the 5 or 6 we have floating around this chain is, I'm going to try guessing. Again. I'm going to assume that it at least has something to do with the email where you made a reference to Z and Z+1. Since that's the one you are grateful that I acknowledged. One of the examples we have floating around that we haven't yet quoted back to you is: " What if I was first invited to SEQUENCE:Z yet I missed Z, so I only see the modification:Z+1. Now how do It tell if I missed SEQUENCE:Z ? " Despite the fact that we have shown several times why this isn't a problem I'll go through it trying to specically use this quote. Since you didn't specify which type of message Z or Z+1 is in terms of whether or not it was an instance or the whole recurring series. I'm going to give two cases. Case 1) A CU being invited just to that particular instance. Case 2) A CU being invited to a whole series but gets just the instance update first. ------------------------------------------------------------------ Case 1) Z+1 = Instance / Z = Instance First the CUA sees: UID:1 RID:1 SEQ:Z+1 DTSTART:newStart ATTENDEE;partstat=NEEDS-ACTION:A The CUA finds neither UID:1/RID:1 nor UID:1/RID:NULL on its calendar which would have been a prior version so it declares it a new event. It finds out from the CU if they would like to attend to formulate a REPLY. It adds UID:1/RID:1/SEQ:Z+1 to the calendar as a new singleton event and sends a REPLY with UID:1/RID:1/SEQ:Z+1. The absence of UID:1/RID:NULL and a SEQUENCE jump > 1 signifies a potential missed message for UID:1/RID:NULL. It sends a REFRESH for UID:1/RID:NULL because that's what it SHOULD do, but it muses that it didn't have to and things would still be compliant and its calendar would still be consistent. Then it sees: UID:1 RID:1 SEQ:Z DTSTART:oldStart ATTENDEE;partstat=NEEDS-ACTION:A It throws this away because it already has a more recent version of UID:1/RID:1. The CUA ends up with a single instance on its calendar at newStart as intended by the ORGANIZER. ------------------------------------------------------------------ ------------------------------------------------------------------ Case 2) Z+1 = instance / Z = whole series First the CUA sees: UID:1 RID:1 SEQ:Z+1 DTSTART:newStart ATTENDEE;partstat=NEEDS-ACTION:A It adds UID:1/RID:1 to the calendar at SEQ:1 as a new event. It finds out from the CU if they would like to attend this instance and sends a REPLY with UID:1/RID:1/SEQ:Z+1. As above it uses the absence of UID:1/RID:NULL and SEQUENCE jump >1 to signify a potentially missed message so it sends for a REFRESH of UID:1/RID:NULL. Then it sees: UID:1 SEQ:Z DTSTART:oldStart ATTENDEE;partstat=NEEDS-ACTION:A RDATE/RRULE:someStuff that describes a set with RID:1 It doesn't throw this one away because it's never seen UID:1/RID:NULL before. The CUA finds out from the CU if they want to attend the whole series except for RID:1 because it already knows the answer to that. The CUA adds UID:1/RID:NULL/SEQ:Z to the calendar and sends a REPLY with UID:1/SEQ:Z. It does not update UID:1/RID:1/SEQ:Z+1 at all because Z+1 is more recent that Z and contains the most recent information as per the ORGANIZER's calendar. The CUA ends up with many instances of the event each matching the ORGANIZER's calendar. Most at Z, one at Z+1. ------------------------------------------------------------------ So Doug, how'd I do? Did I guess the elusive example you claim we are ignoring yet? Do you see any internal inconsistencies or iTIP/iCal violations? Are you ready to put the 'current-value' model through the same sequences as from above yet? I'll even let you show us the code lest you feel that we might get the behavior wrong. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 22:07: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 WAA06786 for ; Tue, 12 Aug 2003 22:07:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D1xcqt020721 for ; Tue, 12 Aug 2003 18:59:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D1xc0I020720 for ietf-calendar-bks; Tue, 12 Aug 2003 18:59:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D1xaqt020715 for ; Tue, 12 Aug 2003 18:59:37 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mkwY-0004Lf-00 for ; Wed, 13 Aug 2003 04:00:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mkwX-0004LV-00 for ; Wed, 13 Aug 2003 04:00:53 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mkvJ-0001pH-00 for ; Wed, 13 Aug 2003 03:59:37 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 18:59:36 -0700 Lines: 34 Message-ID: References: <3F39923D.4060809@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: > If the object is a an iTIP (4.2.3) update > If the object is a an iTIP (4.4.2) update Nothing can ever be a section 4 anything. Doug just doesn't want to admit that section 3 is way more important and supercedes anything in 4. In fact, we would no that there was an error in one of the examples because it didn't do what the above sections said. Section 4 is just examples of how to apply the above sections. It does not a definition of how to determine what a message is. Doug's idea is so broken that if we listened to him all of the following would an update as well: . Invite "Attendees" to an event; . Response to a REFRESH request; . Reconfirm an existing event, without rescheduling it; . Forward a "VEVENT" to another uninvited CU. . For an existing "VEVENT" calendar component, delegate the role of "Attendee" to another CU; . For an existing "VEVENT" calendar component, changing the role of "Organizer" to another CU. They would all have be updates because they all look like what's in Section 4. The truth is that if it's the first time a CUA has seen any of the above it's perfectly safe to treat them as a request for new event. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 22:13: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 WAA06919 for ; Tue, 12 Aug 2003 22:12:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D25tqt021296 for ; Tue, 12 Aug 2003 19:05:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D25tJl021295 for ietf-calendar-bks; Tue, 12 Aug 2003 19:05:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D25sqt021289 for ; Tue, 12 Aug 2003 19:05:54 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7D25u2O004690; Tue, 12 Aug 2003 20:05:56 -0600 (MDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7D25uaJ011298; Tue, 12 Aug 2003 19:05:56 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJJ008TPCHWE4@ha13sca-mail1.sfbay.sun.com>; Tue, 12 Aug 2003 19:05:56 -0700 (PDT) Date: Tue, 12 Aug 2003 19:05:58 -0700 From: Satya Vempati Subject: RE: RECURRENCE-ID discussion To: Doug Royer , "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT <> I can't find a clear sentence that says so. Could you cut and paste the relevant sentence from 2445? -----Original Message----- From: Doug Royer [mailto:Doug@royer.com] Sent: Tuesday, August 12, 2003 6:06 PM To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion Satya Vempati wrote: > On a related note, is there a part of the RFC that states that the > SEQUENCE number should always be incremented by 1? Yes - its in iCal where SEQUENCE is defined. > The RFC's talk of > incrementing, but as far as I can tell, the increments can vary. What an attendee sees can vary if they are or are not part of versions of the object. If an ATTENDEE sees an update to an instance and it is more than one behind the current SEQUENCE number that ATTENDEE-CUA is going to have to do a REFRESH in order to get the latest object in order to apply the update. The only exception is when the Bruces new model is used to invite you to a single instance and when it is the first object you get with that UID, then the ATTENDEE has to always do an REFRESH because they broke the uniqueness of single instance updates and called it a new invitation. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Tue Aug 12 22:15:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06972 for ; Tue, 12 Aug 2003 22:15:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D297qt021630 for ; Tue, 12 Aug 2003 19:09:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D297Iv021629 for ietf-calendar-bks; Tue, 12 Aug 2003 19:09:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D296qt021620 for ; Tue, 12 Aug 2003 19:09:06 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19ml5k-0004Po-00 for ; Wed, 13 Aug 2003 04:10:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mkza-0004NA-00 for ; Wed, 13 Aug 2003 04:04:02 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mkyM-0001tg-00 for ; Wed, 13 Aug 2003 04:02:46 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 19:02:45 -0700 Lines: 17 Message-ID: References: <3F399142.6030307@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 read this to mean that the SEQUENCE number will never decrease. > > It will never decrease. Which is why the Bruce new model of inviting > a new attendee to a single instance will not work under some circumstances. > If you get an old SEQUENCE you discard it because iTIP declares it > obsolete. So an original invite of SEQUENCE:x will be discarded if > an update to that instance (SEQUENCE:x+1) is interpreted as the > original invitation. The CUA will never know it needs to REFRESH. In the fixed-id model it doesn't need the REFRESH. Doug's insistence that it does merely points to his misunderstanding of the model. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 22:24:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07104 for ; Tue, 12 Aug 2003 22:24:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2HCqt022213 for ; Tue, 12 Aug 2003 19:17:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D2HCmA022212 for ietf-calendar-bks; Tue, 12 Aug 2003 19:17:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2HBqt022207 for ; Tue, 12 Aug 2003 19:17:11 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mlDZ-0004U6-00 for ; Wed, 13 Aug 2003 04:18:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mlDY-0004Ty-00 for ; Wed, 13 Aug 2003 04:18:28 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mlCK-0002Ad-00 for ; Wed, 13 Aug 2003 04:17:12 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 19:17:11 -0700 Lines: 52 Message-ID: References: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Why do you need to send a REFRESH in the fixed recurrence-id model? If > your last SEQUENCE was 2 and the current SEQUENCE is 4 why can't you > merely update the component? You can and you do. The instance is totally consistent with itself and fully updated. But you know that you missed a message which _might_ have had to do with the parent series description. For instance imagine the case: UID:1 RID:1 SEQ:2 then (redefine the whole series): UID:1 SEQ:3 then (update the instance again): UID:1 RID:1 SEQ:4 SEQ:4 will absolutely be the most recent version of RID:1. But the thing in the middle that you missed was a redefinition of the entire recurring series. It's because of this possibility that the aggressively consistent CUA will use the >1 SEQUENCE jump to request a REFRESH for the UID:1/RID:NULL event. It does not request a REFRESH for the UID:1/RID:1 event because it already knows about that. You are however absolutely right, and if you know that it's likely SEQ numbers will jump like that then you might define different semantics. I personally suggest semantics where the CUA only sends a REFRESH if it receives information for a new instance of an event for which it has no RID:NULL event entry. So if you are invited to two distinct instances, but not the whole series, you will have sent only two REFRESH requests regardless of how many updates occured. One for each of the first times you saw a new RID. You can also look at section 6.1.7 which talks about this. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 12 22:33: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 WAA07241 for ; Tue, 12 Aug 2003 22:33:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2Pmqt022467 for ; Tue, 12 Aug 2003 19:25:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D2Pmfv022466 for ietf-calendar-bks; Tue, 12 Aug 2003 19:25:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2Plqt022460 for ; Tue, 12 Aug 2003 19:25:47 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7D2PkEB017451 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 19:25:48 -0700 Message-ID: <3F39A1A4.6070204@Royer.com> Date: Tue, 12 Aug 2003 20:25:40 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@Royer.com> <3F3979F1.9070505@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070201000306000106090106" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070201000306000106090106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > Then it sees: > > UID:1 > SEQ:Z > DTSTART:oldStart > ATTENDEE;partstat=NEEDS-ACTION:A > RDATE/RRULE:someStuff that describes a set with RID:1 > > It doesn't throw this one away because it's never seen > UID:1/RID:NULL before. That is not iTIP: 2. The secondary key for referencing a component is the "SEQUENCE" property value. For components where the "UID" is the same, the component with the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values. (1) It gets tossed as it is obsolete. (2) Your CUA would not have a clue that z-1 was ever sent if it gets lost in transit. And the CU would have then acknowledged SEQUENCE:Z telling the ORGANIZER they you agree to the meetings that the CUA has never seen (in z-1). Because newer SEQUENCE REPLYs obsolete older ones. The ATTENDEE-CU and ATTENDEE-CUA having *never* seen (z-1), would NEVER do a REFRESH and never know they had an incomplete list of instances. That's why you can not invite an ATTENDEE by sending an object that looks like an instance modification. Prior to Bruces proposal to add ATTENDEEs in that way, the ATTENDEE-CUA would have known it was an update. Now it thinks it is a new original and complete object. With Bruces model the error checking is busted. In addition, if Z were acknowledged then the ATTENDEE could get on an airplane, they would not see z-1 until they got back (if ever) from a meeting that was canceled in z-1. If that object only looks like a modification, then the ATTENDEE-CUA would know to do a REFRESH and the ATTENDEE would know that they do not have all of the information to make the decision. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070201000306000106090106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzAyMjU0MFowIwYJKoZIhvcNAQkEMRYEFGJTTYLN OBlw2N/sWdxejOYEFD0SMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEuWzG3p+hQXkPuEkKadI/Jbt80p3+1m9l0KE9zhu2i3jXF1Uf8l cMwqeTUxWNUaZaPWVZN8TF2wz07pTHAd4fpkeHQWJMexFI5O4ozzNWcX7rOGw9M/1a6FAm2B VT2Pl8NxPPQlSH3xUDEAG3X8TrHYKcDz2BcLRNtBroqMa/iUU/NW2PtiVU2s1WOkjXJUPtbi LdYW8J9h+eA9HBostPcL3dISSYexTZ6+tNGRPyuIsR3gDVPNOb68BVXYQYPButmJmi5nGktB ckl4c7Heq2Ki5IIdbViAPGNXhBK48Dzl16DgkNmk8k3usGUqEcDFZ0sNNerqlv/UOGtow/yG t1kAAAAAAAA= --------------ms070201000306000106090106-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 22:35: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 WAA07314 for ; Tue, 12 Aug 2003 22:35:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2Svqt022632 for ; Tue, 12 Aug 2003 19:28:57 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D2SvLC022631 for ietf-calendar-bks; Tue, 12 Aug 2003 19:28:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2Stqt022626 for ; Tue, 12 Aug 2003 19:28:56 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7D2SuEB017480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 19:28:57 -0700 Message-ID: <3F39A263.8050405@Royer.com> Date: Tue, 12 Aug 2003 20:28:51 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F39923D.4060809@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040500020705010805090209" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040500020705010805090209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>If the object is a an iTIP (4.2.3) update >>If the object is a an iTIP (4.4.2) update > > > Nothing can ever be a section 4 anything. Your joking right? Your saying that all of section 4 was submitted in error and only a hand full of people since November of 1988 have noticed that 122 pages of 2446 are 'nothing'. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040500020705010805090209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzAyMjg1MVowIwYJKoZIhvcNAQkEMRYEFGL2gzjI yQ5aNU0VGWsa+roYDJZVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIchewdfqu2+Ncpn7g9pMkMfjO7AkgxyD5PLsxgP3nCagOHyepgh ld4jg7EbQw/M92fVsJpxrj1PHOFYsBLzhTOUnaFcYJSUKhcyANvMpopuPAlEscgVavCSTy5B 0ANUpRe2dQTK5Zuc2FhgkcP2xjO6fiVpMNwpuLFqIknw5DDelQiHLkvRGf4B45MHlXX8Ndom BcNCodinpKBfwVy/KpA0DaPLEbMBtEb4ihvkO3V/mh/iO/tFUr5Yid0Fa9YViz1zicqtrW1d bHhcNCu7GT4WliPYldxSfmOAhNUORJogzZB5+6q7pVDmJJi/6YidPKSm1/DcCkwLDleBA9tu naAAAAAAAAA= --------------ms040500020705010805090209-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 22:40: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 WAA07410 for ; Tue, 12 Aug 2003 22:40:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2Wgqt022970 for ; Tue, 12 Aug 2003 19:32:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D2WgnP022969 for ietf-calendar-bks; Tue, 12 Aug 2003 19:32:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2Wfqt022964 for ; Tue, 12 Aug 2003 19:32:41 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7D2WfEB017511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 19:32:43 -0700 Message-ID: <3F39A343.70901@Royer.com> Date: Tue, 12 Aug 2003 20:32:35 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F399142.6030307@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030000070602000402010209" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030000070602000402010209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>>I read this to mean that the SEQUENCE number will never decrease. >> >>It will never decrease. Which is why the Bruce new model of inviting >>a new attendee to a single instance will not work under some > > circumstances. > >>If you get an old SEQUENCE you discard it because iTIP declares it >>obsolete. So an original invite of SEQUENCE:x will be discarded if >>an update to that instance (SEQUENCE:x+1) is interpreted as the >>original invitation. The CUA will never know it needs to REFRESH. > > > In the fixed-id model it doesn't need the REFRESH. > Doug's insistence that it does merely points to his misunderstanding > of the model. No. You keep ignoring the failure by declaring it will not happen. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030000070602000402010209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzAyMzIzNVowIwYJKoZIhvcNAQkEMRYEFLSwZhsr 9XY60SFAYIOtQGh0uCuoMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEe5jswx429rOMItjhs7iGDgI1XR0hZyEwN9oajft3yiYuHgKYMK oEi/7OS0tICvECztkkyiCVIfQfrfYQUuR/g7NIH4u9gAhwqjA4xoB/Bo8i7eIn3ufP285Lri SEMvvbpgbRB7uGg4uJG6E6RMAkAIGhabXkPAy/BCwnCdwhggJ+aRZBH68qwL/3Yz2NIB1GGx fT6VBwmis1NxEGF9z6o7joQr3BpyAVa6OUehyGLtBw/Q995WeYIDWJjF4OirrZPS3QmmZ8Lt 8z2+3Lg8syqJLI0z6i+tCiVCC6u8w2Df1PX9mFMxa6Onz6BX50BzuIdAl5oUACAF9zGuNgGC 4ysAAAAAAAA= --------------ms030000070602000402010209-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 22:40: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 WAA07426 for ; Tue, 12 Aug 2003 22:40:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2YUqt023025 for ; Tue, 12 Aug 2003 19:34:30 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D2YUtb023024 for ietf-calendar-bks; Tue, 12 Aug 2003 19:34:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2YTqt023019 for ; Tue, 12 Aug 2003 19:34:29 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7D2YTEB017519 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Aug 2003 19:34:30 -0700 Message-ID: <3F39A3B0.2000806@Royer.com> Date: Tue, 12 Aug 2003 20:34:24 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RECURRENCE-ID discussion References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050005030708010209050300" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050005030708010209050300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: > <> > > I can't find a clear sentence that says so. Could you cut and paste the > relevant sentence from 2445? It was quoted by someone else on the list, look for mono -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050005030708010209050300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzAyMzQyNFowIwYJKoZIhvcNAQkEMRYEFJvcaw5e sFg50ddUQd2KN2m5aiHHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADTK10ABP/UHRCcVKlFwIJPcVlVDSyDg0ACMml/6Wwhnb/AZu1Nf HIUzzDpyFXrBnLZzzapJL0BiKwWT7VV+c7OK60of77DUqegdgtmmob2CY7xvyg5pIZot5sbb 5Rq8mpQmv8Mf5IPQAHbxq6vHlT741YwRLmIS73iqS5ToLjj0TaE+73lx6KAFcThw4L9NMSsw oJs8wyWnrbtG2/76eZCMRXAj9mY/ZnMODpPP85gD8tp/Z/RUY7V2d5oJjrNLvxH8P8KHIU36 L6JFLmCa1BiZEGsRgsMTdHoPLpcccFElSXq8P5GbznrOHKY3oQIjANLCQECPpzJVcbe6b5RA /7sAAAAAAAA= --------------ms050005030708010209050300-- From owner-ietf-calendar@mail.imc.org Tue Aug 12 22:43: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 WAA07479 for ; Tue, 12 Aug 2003 22:43:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2YYqt023039 for ; Tue, 12 Aug 2003 19:34:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D2YYB6023038 for ietf-calendar-bks; Tue, 12 Aug 2003 19:34:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2YWqt023027 for ; Tue, 12 Aug 2003 19:34:33 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mlUN-0004Zw-00 for ; Wed, 13 Aug 2003 04:35:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mlUM-0004Zo-00 for ; Wed, 13 Aug 2003 04:35:50 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mlT8-0002Oh-00 for ; Wed, 13 Aug 2003 04:34:34 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 19:34:33 -0700 Lines: 29 Message-ID: References: <3F398EF8.4030904@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: > The only exception is when the Bruces new model is used to invite > you to a single instance and when it is the first object you get > with that UID, then the ATTENDEE has to always do an REFRESH because they > broke the uniqueness of single instance updates and called it a > new invitation. First, we didn't break the uniqueness for a single instance. The instance is identified as UID:1/RID:1 (Section 2.1.5) Second, it's not new it's been in iTIP the whole time (Section 3.2.2). Third, we send a REFRESH because we think we might have missed a message that involves the entire series, not because we need it to understand what's going on with that instance. I say we send a REFRESH because it's a nice thing to do, not because we need it. You could never allow the fixed-id to send a REFRESH ever and the instance would stay totally consistent with ORGANIZER's with respect to that instance. I use the fact that the SEQUENCE for an update has jumped more than 1 to indicate that we missed some message that _might_ have had to do with the entire series so the conservative and safe thing to do is to send a REFRESH. As far as the instance for which we received the message we are fully in sync and totally up to date. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 00:42: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 AAA11722 for ; Wed, 13 Aug 2003 00:42:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D4USqt027748 for ; Tue, 12 Aug 2003 21:30:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D4USen027746 for ietf-calendar-bks; Tue, 12 Aug 2003 21:30:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D4UOqt027733 for ; Tue, 12 Aug 2003 21:30:26 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mnIU-0005RO-00 for ; Wed, 13 Aug 2003 06:31:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mnIU-0005RG-00 for ; Wed, 13 Aug 2003 06:31:42 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mnHG-0004NQ-00 for ; Wed, 13 Aug 2003 06:30:26 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 21:30:25 -0700 Lines: 45 Message-ID: References: <3F39923D.4060809@Royer.com> <3F39A263.8050405@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:3F39A263.8050405@Royer.com... > > > Michael Fair wrote: > >>If the object is a an iTIP (4.2.3) update > >>If the object is a an iTIP (4.4.2) update > > > > > > Nothing can ever be a section 4 anything. > > Your joking right? Your saying that all of section 4 > was submitted in error and only a hand full of people > since November of 1988 have noticed that 122 pages > of 2446 are 'nothing'. No, I'm saying that nothing in section 4 is necessary and it does not add any definition to the text. Section 4 merely aids understanding of the above sections but in as much as iTIP describes a way of doing things it is superfluous and is there merely to aid in comprehension of the above text as an example. For example, if I say the color of the sky is determined by looking up when your view of the sky is unobstructed. And I then say "Section 4: Examples" To updates someone's understanding of color of the sky to be blue send: Sky: blue I am not saying that every message that contains the text "Sky: blue" is telling them it is an update the color of their Sky. I'm simply saying that if and when you send an update, that's what it looks like. BTW, all text after the words "For example," in this message are totally superfluous and are merely meant to enhance the reader's comprehension of the above text. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 00:47: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 AAA11866 for ; Wed, 13 Aug 2003 00:47:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D4dFqt028565 for ; Tue, 12 Aug 2003 21:39:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D4dFfR028564 for ietf-calendar-bks; Tue, 12 Aug 2003 21:39:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D4dDqt028558 for ; Tue, 12 Aug 2003 21:39:14 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mnR2-0005VI-00 for ; Wed, 13 Aug 2003 06:40:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mnL0-0005SU-00 for ; Wed, 13 Aug 2003 06:34:18 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mnJm-0004Pf-00 for ; Wed, 13 Aug 2003 06:33:02 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Tue, 12 Aug 2003 21:33:02 -0700 Lines: 19 Message-ID: References: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Satya Vempati" wrote in message news:ISSMTP.2003_10b_.20030812174934.1704B@sun.com... > > From Merriam-Webster: > Monotonically: > > 2 : having the property either of never increasing or of never decreasing > as the values of the independent variable or the subscripts of the terms > increase > > I read this to mean that the SEQUENCE number will never decrease. You might actually be right about this, I know that I, and it appears that many others took this mean increases by 1. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 05:07: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 FAA12989 for ; Wed, 13 Aug 2003 05:07:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D8sUqt059575 for ; Wed, 13 Aug 2003 01:54:30 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D8sUn8059574 for ietf-calendar-bks; Wed, 13 Aug 2003 01:54:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D8sPqt059541 for ; Wed, 13 Aug 2003 01:54:28 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mrPw-0007PN-00 for ; Wed, 13 Aug 2003 10:55:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mrPv-0007PF-00 for ; Wed, 13 Aug 2003 10:55:39 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19mrOi-0000ql-00 for ; Wed, 13 Aug 2003 10:54:24 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Wed, 13 Aug 2003 01:54:23 -0700 Lines: 231 Message-ID: References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@Royer.com> <3F3979F1.9070505@Royer.com> <3F39A1A4.6070204@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: Yay, some actual constructive and debatable text. Thank you very much for adding this to the discussion. > Michael Fair wrote: > > > Then it sees: > > > > UID:1 > > SEQ:Z > > DTSTART:oldStart > > ATTENDEE;partstat=NEEDS-ACTION:A > > RDATE/RRULE:someStuff that describes a set with RID:1 > > > > It doesn't throw this one away because it's never seen > > UID:1/RID:NULL before. To which Doug Royer replied: > That is not iTIP: > > 2. The secondary key for referencing a component is the "SEQUENCE" > property value. For components where the "UID" is the same, the > component with the highest numeric value for the "SEQUENCE" > property obsoletes all other revisions of the component with > lower values. > > (1) It gets tossed as it is obsolete. But it is iTIP and it doesn't get tossed away as the CUA hasn't seen it yet. From the same section (2.1.5): 1. The primary key for referencing a particular iCalendar component is the "UID" property value. To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties. I'm fairly certain that we can all agree that (1) precedes (2) in the iTIP text and therefore (1) must be applied before moving on to (2). A message with addressing of: UID:1 RID:1 SEQ: Is trying to talk about RECURRENCE-ID: 1 of UID: 1. Why do we know that? The presence of a RECURRENCE-ID tells us so as per (1). The second sentence of (1) is very clear the "primary key" for "an instance of a recurring component" is UID/RID. Further, from the REQUEST restriction table we have: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. Therefore the presence of the RECURRENCE-ID property says that we MUST be referring to an instance of, and not the recurring event. I'll say it again, if a message EVER contains RECURRENCE-ID it MUST be referencing an instance of a recurring event. Looking back at (1) we see the primary key for an instance is BOTH the UID AND the RECURRENCE-ID. And by extension therefore a message that does not contain a RECURRENCE-ID CANNOT be referring to an instance of a recurring event and consequently MUST be describing the parent event. Therefore when a message later shows up that references the recurring component itself with no RID, we know we haven't seen it before. We've only seen a message talking about one of this event's instances, but not this event itself. Ironic that this is actually a problem in Doug's single SEQUENCE model. If I schedule UID:1/SEQ:0 and then update RID:1 at SEQ:1 and then update RID:2 at SEQ:2 and then update RID:3 at SEQ:3 as Doug would have you do. Then if his model sees and accepts 3 first, his model then can't process 0,1, or 2 because his application of 2.1.5 ignores section 3.7.1 where each instance is independently versioned. The fixed-id / multisequence model that iTIP/iCal describes does not have this problem. Doug would have you believe that receiving a message for UID:1/RID:1 could a screw up in receiving a message for UID:1/RID:NULL because the SEQUENCE for UID:1/RID:1 was greater than that of UID:1/RID:NULL which it would not. If Doug is right, than iTIP is totally intolerant of receiving an update to an instance before the definition itself. I have asked him in another subthread what his model would do with the first message in the very plausible world where a CUA receives the instance update before the recurrence definition. I believe the answer was throw it out or hold it until it saw the definition. In other words, his model can't process an instance update message unless it has a copy of the set definition. I find this to be rather inconsistent with iTIP's vehemence that it be tolerant of missing any message. An instance of a recurring component is a singleton. It has a special relationship to its parent UID component, but it is its own independently referenced and versioned component. This is evidenced in section 3.7.1: ... meeting instances still need to be referenced ... ... the protocol is designed so that each recurring instance may be both referenced and versioned ... As another consistency problem with Doug's model, if I was going to add/update a comment, or a description, or an X-PROPERTY, or a summary, or the STATUS, or an attatchment, or a RELATED-TO, or a URL to an instance of a recurring event I would use an iTIP message that referenced UID:1/RID:1. Why is an ATTENDEE property any different from other properties? In fact if I was going to change the DTSTART, or the ORGANIZER for that instance, I would again reference UID:1/RID:1. Why is it that Doug believes that the string ATTENDEE need be treated any differently from any of the other properties? As even further evidence, when an ATTENDEE responds to update the status of their attendence for a particular instance, they respond with a message referencing UID:1/RID:1. So if I send a message to a recipient that updates an instance to a recurring event, and this is the first time they've seen that component, and due to the presence of an RID know that it must be referencing a recurring event instance, and they are listed as an ATTENDEE why shouldn't the CUA just accept the message as the latest version of an instance to a recurring event that it currently has no set description for? If it had the set description that's the message it would send. Why should it be any different just because it doesn't have the set description? If it turns out to be the only instance in that series they are ever informed about why does the CUA care about the parent? It would be no different than having the "RELATED-TO" set in some other singleton but not having the events that the event says it is related to. For those of you still reading these long posts, > would have known it was an update. Now it thinks it is a new original > and complete object. With Bruces model the error checking is busted. It's not busted, it thinks it is a new, original, and complete instance of a recurring event. It also happens that what it treats it as, is what it actually is, a complete description of a recurrence instance. > In addition, if Z were acknowledged then the ATTENDEE could get on > an airplane, they would not see z-1 until they got back (if ever) > from a meeting that was canceled in z-1. This is either impossible, plain stupid human error by the ORGANIZER, the actual intended result of the ORGANIZER. I don't think Doug is thinking his assertion through. If someone cancelled the recurring series at Z-1 - and then they go an update a cancelled instance of a recurring event at Z - they either meant to reschedule it in which case it's a good thing our friend didn't cancel their flight, or the ORGANIZER is just being mean, trying to help our friend accumulate frequent flyer miles, or just plain in error in which case no model can really help them. If the recurring event was actually canceled at Z-1 there'd be no Z. It wouldn't exist, it'd have never been created and therefore could never have been misdelivered. Of course if history is an indicator Doug is just going to delete this whole cancellation example from his next post rather than admit he was in error or try and address it. > If that object only looks like a modification, then the ATTENDEE-CUA > would know to do a REFRESH and the ATTENDEE would know that they > do not have all of the information to make the decision. By virtue of receiving an event with both a UID and RID for which neither a UID/RID component nor a UID/RID:NULL component can be found it knows that it might have missed something. The SEQUENCE numbers for each component are tracked separately. UID:1/RID:NULL is at Z UID:1/RID:1 is at Z + N where N=number of instance modifications. UID:1/RID:2 is at Z + J where J=number of instance modifications. I can receive a message for UID:1/RID:1/SEQ:Z+N and then a message for UID:1/RID:2/SEQ:Z+J and then a message for UID:1/SEQ:Z and still keep track that the recurring series was defined at Z, RID:1 is at Z+N, and RID:2 is at Z+J and not get confused. If I ever receive a message for UID:1/SEQ:Z+I where I>N and I>J then I know that the entire series for UID:1 has been rescheduled. If I ever receive a message for UID:1/SEQ:Z+I where IJ then I know that the entire series for UID:1 has been rescheduled inclusive of RID:2, but that my current copy of RID:1 is more recent. If I ever receive a message for UID:1/SEQ:Z+I where I; Wed, 13 Aug 2003 12:16:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DG39qt093143 for ; Wed, 13 Aug 2003 09:03:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DG39mF093142 for ietf-calendar-bks; Wed, 13 Aug 2003 09:03:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DG38qt093134 for ; Wed, 13 Aug 2003 09:03:08 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7DG2xEB023911 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Aug 2003 09:03:03 -0700 Message-ID: <3F3A612E.20005@Royer.com> Date: Wed, 13 Aug 2003 10:02:54 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F398EF8.4030904@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000407080709020101060209" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000407080709020101060209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>The only exception is when the Bruces new model is used to invite >>you to a single instance and when it is the first object you get >>with that UID, then the ATTENDEE has to always do an REFRESH because they >>broke the uniqueness of single instance updates and called it a >>new invitation. > > > First, we didn't break the uniqueness for a single instance. Then why did you incorrectly guess if the sample I sent was an update or a new invite to a single instance? The correct answer = you can not tell as it breaks the uniqueness for a single instance. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000407080709020101060209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzE2MDI1NFowIwYJKoZIhvcNAQkEMRYEFLVOGBRv VoAfcVyjmDLsYbuIBg+RMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAH7rENw46wb8SWdxhLTFDHJPAZgpb/ibFRU/uOlMIkCtgSiiqwCe 6Feep/OGvZ9elgf4q2G9F4NRQ81AoOhEr1VtEd+g5IQVYP6RxmvDPu9/S8KhfqDSfYOUxAYH RX9li0VUVIh/DG+dBaexd03sTv/9Xib8C8mNl4R30WaDO78AqgE5Hv3Qkha1Cb9qFgLYBkv/ bpOIOIgFSMn3n5onuoLxGQC2NbuQCPzt/xxdXftChHj5DgG8LyLXHcVjns9Vh6tcbgEgwXk6 RSsQnwBL4Tf+KTmusxzC/VAFKXWQk9eG/YgTqQqDgkQaaE8/r3PPOyASlSthvhAsHHXL49ce wakAAAAAAAA= --------------ms000407080709020101060209-- From owner-ietf-calendar@mail.imc.org Wed Aug 13 12:23: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 MAA25011 for ; Wed, 13 Aug 2003 12:23:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGDfqt095166 for ; Wed, 13 Aug 2003 09:13:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DGDfC9095165 for ietf-calendar-bks; Wed, 13 Aug 2003 09:13:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGDeqt095157 for ; Wed, 13 Aug 2003 09:13:40 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7DGDdEB024002 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Aug 2003 09:13:40 -0700 Message-ID: <3F3A63AE.30204@Royer.com> Date: Wed, 13 Aug 2003 10:13:34 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@Royer.com> <3F3979F1.9070505@Royer.com> <3F39A1A4.6070204@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040803010806050701080908" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040803010806050701080908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > >>That is not iTIP: >> >> 2. The secondary key for referencing a component is the "SEQUENCE" >> property value. For components where the "UID" is the same, the >> component with the highest numeric value for the "SEQUENCE" >> property obsoletes all other revisions of the component with >> lower values. >> >>(1) It gets tossed as it is obsolete. > > > But it is iTIP and it doesn't get tossed away as the > CUA hasn't seen it yet. It is obsolete - it gets tossed. If an ATTENDEE gets a SEQUENCE:10000 object, how long should it wait be able to process the first 9,999 missing objects with confidence. That is simply ridiculous. All CUA's would then be forced to do a REFRESH just to be sure. I'll go with 1 set of packets and not 5 sets of packets to get the same thing done. Even if that could work reliability - why bother with that complexity? Just send an invite as documented in iTIP. No history needed, no attempting to guess if a packet is an update or an invitation, no manual REFRESH just to be sure? Why break iTIP? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040803010806050701080908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzE2MTMzNFowIwYJKoZIhvcNAQkEMRYEFIxctbPr +Uz10YsUpRZBNOVxWjLcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJ7uye9mUjriiHKr17irqOt+5Q8Gaqfww5ebKn7ypjc/iGU7XwKn 8OwQ0gzmCS9zjcv7pkKj81Wgj9elXFUOLyY9hrlL2FZA4s3Gx94cSJ3wUtgXnHR4Th4CqP/w RVhGUjj47NRzdSbwgQo1zoL9H68rAwO0ZGOnJIZdSp1U6cwrog3lV3J0cB5gJQwjoYycj/Cb x6A33zT8XSRuMpfpGA4ie5zTmdW2rnAuwNAxgfK0CafzITi6E5z2YTBq7zC2XUAf5cwEsWnP PaWwaS2u5r/K/qmAagxiamPO8K9qMyK2tl0Bes4v9rrM8Y1cOoExdhGAQQtYO/Ddm2XXcrCm NFIAAAAAAAA= --------------ms040803010806050701080908-- From owner-ietf-calendar@mail.imc.org Wed Aug 13 14:44: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 OAA00247 for ; Wed, 13 Aug 2003 14:44:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DIY1qt004349 for ; Wed, 13 Aug 2003 11:34:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DIY19f004348 for ietf-calendar-bks; Wed, 13 Aug 2003 11:34:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DIXwqt004337 for ; Wed, 13 Aug 2003 11:33:59 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n0Sn-0003x7-00 for ; Wed, 13 Aug 2003 20:35:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n0Sm-0003wz-00 for ; Wed, 13 Aug 2003 20:35:12 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n0Ra-0000cU-00 for ; Wed, 13 Aug 2003 20:33:58 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Wed, 13 Aug 2003 11:34:03 -0700 Lines: 144 Message-ID: References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@Royer.com> <3F3979F1.9070505@Royer.com> <3F39A1A4.6070204@Royer.com> <3F3A63AE.30204@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:3F3A63AE.30204@Royer.com... > > > > >>That is not iTIP: > >> > >> 2. The secondary key for referencing a component is the "SEQUENCE" > >> property value. For components where the "UID" is the same, the > >> component with the highest numeric value for the "SEQUENCE" > >> property obsoletes all other revisions of the component with > >> lower values. > >> > >>(1) It gets tossed as it is obsolete. > > > > > > But it is iTIP and it doesn't get tossed away as the > > CUA hasn't seen it yet. > > It is obsolete - it gets tossed. If an ATTENDEE gets a SEQUENCE:10000 > object, how long should it wait be able to process the first 9,999 > missing objects with confidence. That is simply ridiculous. If an ATTENDEE's CUA receives a SEQUENCE:10000 object it simply processes it with confidence that is the most recent and up to date version of that object. I've said it before, and I'll say it again. UID:1 and UID:1/RID:1 are not the same obejcts. So a SEQUENCE:10000 object for UID:1/RID:1 is meaningless and has no bearing on what came before it. Let's look at what might have come before it, a prior version of a UID:1/RID:1 object or a UID:1 object. In either case, SEQ:10000 is a more recent version of UID:1/RID:1. The only potential danger, as you suggest, is if the recipient CUA would throw away the UID:1 object at SEQ:<10000, but since it's never seen it before (becuase UID:1 and UID:1/RID:1 are separate objects) it won't. > Even if that could work reliability - why bother with that > complexity? Just send an invite as documented in iTIP. No > history needed, no attempting to guess if a packet is an > update or an invitation, no manual REFRESH just to be sure? > Why break iTIP? We are sending an invite as it is documented in iTIP, I've sent several messages directly quoting iTIP and lots of other sections as consistent support for why iTIP says what it says. It's obvious we don't agree on what iTIP says, it's obvious that both of us claim the other's model breaks iTIP. I'm the only one in this thread who is showing any kind of iTIP evidence (save that last quote you sent) that their model is the right one. I'm also the only on this thread using iTIP to debunk the validity of the other's model. I can't remember the last time in this whole series of message you showed one scrap of iTIP messaging (even after directly asked for it) that can support your claim. I'll do it it again here now to save you the effort of having to hunt for it because I'm generous about helping you clarify what it is I'm referring to and am interested in a constructive conversation here. In your model, if I wanted to invite user's A and B to a single instance of a recurring event RID:1 and RID:2 respectively, assuming that there had been no reschedules so everything is at SEQUENCE:0 I would send them the following: For ATTENDEE A: UID:1 SEQ:0 DTSTAMP:timeOfInviteToA DTSTART:startOfRID:1 For ATTENDEE B: UID:1 SEQ:0 DTSTAMP:timeOfInviteToB DTSTART:startOfRID:2 Right? I mean you wouldn't send A: UID:1 SEQ:0 DTSTAMP:timeOfInviteToA RDATE:dateOfRID:1 DTSTART:startOfRID:1 and then send B: UID:1 SEQ:0 DTSTAMP:timeOfInviteToB RDATE:dateOfRID:2 DTSTART:startOfRID:2 Right? I mean we are talking about singleton's in your model and not a recurring event of one instance? So now B decides to forward the invite to A. B forwards the REQUEST exactly as is: UID:1 SEQ:0 DTSTAMP:timeOfInviteToB DTSTART:startOfRID:2 A's CUA looks on its calendar and finds UID:1/SEQ:0 already exists and so it falls to DTSTAMP. If A was invited first, it will interpret this as being invited to a more recent version of the same event, it will remove its current copy and use the updated one from B. If however, B was invited first, the DTSTAMP will be older and it will throw the message out. In either case, A now believes it is invited to only one event. In the case where the invite to A was older and it replaced its own with B's it now erroniously believes that it is invited to the wrong instance. It in the case where the invite to B was older it will never receive the invite intended. This is not a problem in the model I described as the CUA's will differentiate each invite based on the RID included and figure out that A and B are talking about two separate instances of the same recurring event - and just live with the fact that they have never seen a description of parent event. I find it hard to exactly track how this particular thread of "what iTIP to send" to invite a CU to a particular instance has much of anything to do with 'fixed-id' versus 'current-value' The iTIP inclusive of an RID:1 to specify an invite to a particular instance is just as valid in either model and totally consistent with all other iTIP text. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 15:07: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 PAA01570 for ; Wed, 13 Aug 2003 15:07:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DIxHqt005059 for ; Wed, 13 Aug 2003 11:59:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DIxHEg005058 for ietf-calendar-bks; Wed, 13 Aug 2003 11:59:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DIxEqt005053 for ; Wed, 13 Aug 2003 11:59:16 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n0rG-0004AN-00 for ; Wed, 13 Aug 2003 21:00:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n0rE-0004AF-00 for ; Wed, 13 Aug 2003 21:00:28 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n0q2-0001Je-00 for ; Wed, 13 Aug 2003 20:59:14 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Wed, 13 Aug 2003 11:59:19 -0700 Lines: 89 Message-ID: References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@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:3F3A612E.20005@Royer.com... > > > Michael Fair wrote: > >>The only exception is when the Bruces new model is used to invite > >>you to a single instance and when it is the first object you get > >>with that UID, then the ATTENDEE has to always do an REFRESH because they > >>broke the uniqueness of single instance updates and called it a > >>new invitation. > > > > > > First, we didn't break the uniqueness for a single instance. > > Then why did you incorrectly guess if the sample I sent was > an update or a new invite to a single instance? > > The correct answer = you can not tell as it breaks the uniqueness > for a single instance. It doesn't break the uniqueness for a single instance, prove to me how there is a conflicting copy of UID:1/RID:1 somewhere in the world different than the one I sent? Again you have not yet proven in any way shape or form why I need to know if what you sent was an update. Besides, in another post I even said we can call it an update if it makes you feel better. The CUA still treats it as the most recent version of UID:1/RID:1 that it has seen. And you still have yet to prove what's on the ORGANIZER's calendar that's not on the ATTENDEE's calendar that makes your claim of out of syncness justified. The CUA ended up with the currect objects on its calendar and at their correct versions. If you'd like to debate whether a reference to UID:1/RID:1 can ever be confused with a reference to UID:1/RID:NULL because they share the same SEQUENCE track then let's talk about that. That's actually a productive line of conversation. We have repeatedly said that the SEQUENCE's for instances are independently tracked because both section 2.1.5 and 3.7.1 say that they are. Because they are indepentently tracked when you look up the primary key as per step 1 in 2.1.5 you must consider both UID and RID before you move on to step two. You either can't comprehend what we are saying and are therefore justifying your assertions on a baseless claim that they share the same SEQUENCE track, ignoring it because it makes your position baseless act of crying wolf and you are too embarassed to admit it, or just a bad conversationalist who can't talk about what's important and instead tries to win the argument by repitition instead of proof and dismantlement of the models in concert with quotations from the text in question. Please start either disagreeing with the fundamental premises upon which our arguments are based, such as independent versioning and UID/RID primary keys by quoting iTIP sections which prrof that's not the case or providing examples under which the model, exactly as presented, breaks iTIP mandates, or at least start properly citing how the model works. This back and forth of he said she said where you constantly misrepresent the model is just plain tiresome and makes me think you are just plain ignorant and unresponsive to constructive criticism and unable to participate in a productive conversation. I, on at least one occasion, have admitted where I misunderstood the model you were presenting. I didn't realize that when you invite an ATTENDEE to a recurring instance you branch and fragment the object with the UID in question. Which I directly showed is a violation of the UID uniqueness mandate because not all recipients of the same UID share the same view of the object (with the exception of potential version differences due to unseen messages). You advocate that we violate the uniqueness factor because it seemingly allows us to send fewer messages. I then countered you with both iTIP that says you can't do that, and an implentation reality that if the CU's start passing those objects around to each other they will get confused. You have not defended your model yet, you have not shown any iTIP that says you can/should or must do that, and most importantly you have not shown why this is not a problem for your model. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 16:46:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05305 for ; Wed, 13 Aug 2003 16:46:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKbIqt009576 for ; Wed, 13 Aug 2003 13:37:18 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DKbIRW009575 for ietf-calendar-bks; Wed, 13 Aug 2003 13:37:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKbGqt009564 for ; Wed, 13 Aug 2003 13:37:16 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7DKbFEB026052 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Aug 2003 13:37:17 -0700 Message-ID: <3F3AA176.4090107@Royer.com> Date: Wed, 13 Aug 2003 14:37:10 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@Royer.com> <3F3979F1.9070505@Royer.com> <3F39A1A4.6070204@Royer.com> <3F3A63AE.30204@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010004000003070901070806" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010004000003070901070806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F3A63AE.30204@Royer.com... > >>>>That is not iTIP: >>>> >>>> 2. The secondary key for referencing a component is the "SEQUENCE" >>>> property value. For components where the "UID" is the same, the >>>> component with the highest numeric value for the "SEQUENCE" >>>> property obsoletes all other revisions of the component with >>>> lower values. >>>> >>>>(1) It gets tossed as it is obsolete. >>> >>> >>>But it is iTIP and it doesn't get tossed away as the >>>CUA hasn't seen it yet. >> >>It is obsolete - it gets tossed. If an ATTENDEE gets a SEQUENCE:10000 >>object, how long should it wait be able to process the first 9,999 >>missing objects with confidence. That is simply ridiculous. > > > If an ATTENDEE's CUA receives a SEQUENCE:10000 object it simply > processes it with confidence that is the most recent and up to > date version of that object. You can type it as many times as you want, but why not just send it as documented in iTIP? Whey that extra overhead? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010004000003070901070806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMDM3MTBaMCMGCSqGSIb3DQEJBDEWBBS6 1n2VXpla3/bx98nFuqcmuBIk2TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQBvg8ZYqFs1UvmbVRIgMQSYFcdLtdiWdatR6Yqp5x4+bYbE 1KrRmYLYPAJqYkTSl6sSBu/ixMzu96KS+EJTlbwfbJXEPaAMTsKcYcQkW2+jGJQrM/E9y5Gw vYnJ3ThCWwI2Dr7RJrEiZ69fpu1qSFMYHbF+k8XirAgktRTToqeKZqt9OS8zvDfB3qYHSVyc VKELpis6su8yCEJpvYAD9saw55ntAtnnF9zlzvfXRDoCbw0kPJkYUueKKGoXoRPN7KQO3awJ vIkmMkba+p1dAmysMKLHy3TMu/oZBVW5kSZwkkCLBtp1nIkB2Bfj/YhX5o6jihqKm+pPW9Hc +URlkyYxAAAAAAAA --------------ms010004000003070901070806-- From owner-ietf-calendar@mail.imc.org Wed Aug 13 16:47: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 QAA05347 for ; Wed, 13 Aug 2003 16:47:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKd2qt009813 for ; Wed, 13 Aug 2003 13:39:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DKd21h009812 for ietf-calendar-bks; Wed, 13 Aug 2003 13:39:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKd0qt009805 for ; Wed, 13 Aug 2003 13:39:00 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7DKd0EB026062 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Aug 2003 13:39:01 -0700 Message-ID: <3F3AA1DE.6090403@Royer.com> Date: Wed, 13 Aug 2003 14:38:54 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060507060904070203060100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060507060904070203060100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F3A612E.20005@Royer.com... > >> >>Michael Fair wrote: >> >>>>The only exception is when the Bruces new model is used to invite >>>>you to a single instance and when it is the first object you get >>>>with that UID, then the ATTENDEE has to always do an REFRESH because > > they > >>>>broke the uniqueness of single instance updates and called it a >>>>new invitation. >>> >>> >>>First, we didn't break the uniqueness for a single instance. >> >>Then why did you incorrectly guess if the sample I sent was >>an update or a new invite to a single instance? >> >>The correct answer = you can not tell as it breaks the uniqueness >>for a single instance. > > > It doesn't break the uniqueness for a single instance, prove to > me how there is a conflicting copy of UID:1/RID:1 somewhere in > the world different than the one I sent? > Then why did you incorrectly guess if the sample I sent was an update or a new invite to a single instance? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060507060904070203060100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzIwMzg1NVowIwYJKoZIhvcNAQkEMRYEFGOy6T/j meV7wPB10Y+s5iO+NiSkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBACbIhaQy2DvHZlUIUZ9M/TYTQ8WzPWyBAsbXan6X79czMWco4pW2 hvLZimETVphccWAzIL6TF51aG/f1W1QngNauFp7uzsYEsepdP8tDk7Kt4Aebb3fVlCnLP/GI pAo0c6/crPGfguBEhFmgCNseux7wT0+005nJHLADXi0T38GLMhkupVzXWOczE0QXzvAK5cIv rzldm75mUpJ8C6oSfuzw4XdmdO5qJuIX6hlNciePYT61eyPpyq3+S0H5UO/yY11p9Tr7SF0+ C/VynzHZ+m2xSJ8f7GLPmLMl7b2xL0HIDihwTYl6ljkQWKz7DgC889uVnQ/8MNno8udn/2ki 9xcAAAAAAAA= --------------ms060507060904070203060100-- From owner-ietf-calendar@mail.imc.org Wed Aug 13 17:22:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06320 for ; Wed, 13 Aug 2003 17:22:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLAcqt011134 for ; Wed, 13 Aug 2003 14:10:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DLAb8v011133 for ietf-calendar-bks; Wed, 13 Aug 2003 14:10:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLAbqt011123 for ; Wed, 13 Aug 2003 14:10:37 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: Is there anybody out there supporting Doug's skewed model of iCalendar besides Doug MIME-Version: 1.0 X-Mailer: Lotus Notes Build V603_08102003NP August 10, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Wed, 13 Aug 2003 17:13:44 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/13/2003 05:10:29 PM, Serialize complete at 08/13/2003 05:10:29 PM Content-Type: multipart/alternative; boundary="=_alternative 0073ECA185256D81_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073ECA185256D81_= Content-Type: text/plain; charset="US-ASCII" _____________________ Note: new email address tom_ransdell@notesdev.ibm.com --=_alternative 0073ECA185256D81_= Content-Type: text/html; charset="US-ASCII"
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com --=_alternative 0073ECA185256D81_=-- From owner-ietf-calendar@mail.imc.org Wed Aug 13 17:55: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 RAA07727 for ; Wed, 13 Aug 2003 17:55:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLhMqt012146 for ; Wed, 13 Aug 2003 14:43:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DLhM4H012145 for ietf-calendar-bks; Wed, 13 Aug 2003 14:43:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLhLqt012139 for ; Wed, 13 Aug 2003 14:43:21 -0700 (PDT) (envelope-from anil.srivastava@Sun.COM) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7DLhIRv012298 for ; Wed, 13 Aug 2003 14:43:18 -0700 (PDT) Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by dm-usca19-13.red.iplanet.com (8.11.7+Sun/8.10.2/IPLANET,v1.2) with ESMTP id h7DLgeJ24805 for ; Wed, 13 Aug 2003 14:42:40 -0700 (PDT) Received: from nikita (dhcp-usca15-127-222.red.iplanet.com [192.18.127.222]) by we-gotmail.red.iplanet.com (Sun ONE Messaging Server 6.0 (built Jul 19 2003)) with ESMTPA id <0HJK00605V05U000@we-gotmail.red.iplanet.com> for ietf-calendar@imc.org; Wed, 13 Aug 2003 14:43:18 -0700 (PDT) Date: Wed, 13 Aug 2003 14:43:42 -0700 From: Anil SRIVASTAVA Subject: RE: Is there anybody out there supporting Doug's skewed model of iCalendar besides Doug In-reply-to: To: ietf-calendar@imc.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Not me and I think it is time to put get out of endless cycle we are currently in. Logic, reason are being ignored. ________ Anil SRIVASTAVA anil.srivastava@Sun.COM SunNetwork 2003 Conference and Pavilion Sept 16-18, 2003, San Francisco. Register at: http://www.sun.com/sunnetwork -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Robert_Ransdell@notesdev.ibm.com Sent: Wednesday, August 13, 2003 2:14 PM To: ietf-calendar@imc.org Subject: Is there anybody out there supporting Doug's skewed model of iCalendar besides Doug _____________________ Note: new email address tom_ransdell@notesdev.ibm.com From owner-ietf-calendar@mail.imc.org Wed Aug 13 17:57:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07848 for ; Wed, 13 Aug 2003 17:57:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLmLqt012643 for ; Wed, 13 Aug 2003 14:48:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DLmLjV012642 for ietf-calendar-bks; Wed, 13 Aug 2003 14:48:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLmIqt012620 for ; Wed, 13 Aug 2003 14:48:19 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n3Uo-0005YV-00 for ; Wed, 13 Aug 2003 23:49:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n3Un-0005YN-00 for ; Wed, 13 Aug 2003 23:49:29 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n3Tb-000683-00 for ; Wed, 13 Aug 2003 23:48:15 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Wed, 13 Aug 2003 14:48:20 -0700 Lines: 16 Message-ID: References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@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: > > It doesn't break the uniqueness for a single instance, prove to > > me how there is a conflicting copy of UID:1/RID:1 somewhere in > > the world different than the one I sent? > > > > Then why did you incorrectly guess if the sample I sent was > an update or a new invite to a single instance? Why does it matter? Show me why the CUA's calendar ends up inconsistent with the ORGANIZER's and I'll discuss this with you further. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 18:09:37 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08776 for ; Wed, 13 Aug 2003 18:09:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLxKqt014339 for ; Wed, 13 Aug 2003 14:59:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DLxKFr014338 for ietf-calendar-bks; Wed, 13 Aug 2003 14:59:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLxIqt014328 for ; Wed, 13 Aug 2003 14:59:18 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n3fW-0005fX-00 for ; Thu, 14 Aug 2003 00:00:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n3Za-0005bW-00 for ; Wed, 13 Aug 2003 23:54:26 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n3YO-0006HB-00 for ; Wed, 13 Aug 2003 23:53:12 +0200 From: "Michael Fair" Subject: Re: Is there anybody out there supporting Doug's skewed model of iCalendar besides Doug Date: Wed, 13 Aug 2003 14:53:17 -0700 Lines: 18 Message-ID: References: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doh! How much effort we all could have saved. Please people, don't keep silent on this one. If there is anyone out there besides Doug who still believes that Doug's model is the appropriate model (even if you don't think you are up to defending it), let the list know. If Doug is the only one then it can just be written off as a rouge implementation. Otherwise it is important to get consensus on how the texts are to be implemented and iCal-version-next can clarify what the list decides. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 18:19: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 SAA09606 for ; Wed, 13 Aug 2003 18:19:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DM98qt015835 for ; Wed, 13 Aug 2003 15:09:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DM98rj015834 for ietf-calendar-bks; Wed, 13 Aug 2003 15:09:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DM96qt015826 for ; Wed, 13 Aug 2003 15:09:07 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n3p0-0005l9-00 for ; Thu, 14 Aug 2003 00:10:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n3oy-0005kz-00 for ; Thu, 14 Aug 2003 00:10:20 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n3nm-0006mC-00 for ; Thu, 14 Aug 2003 00:09:06 +0200 From: "Michael Fair" Subject: How many people are there using the fixed-id model? Date: Wed, 13 Aug 2003 15:09:11 -0700 Lines: 11 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since requesting how many people are using Doug's model is a potentially bankrupt question causing the whole list to wait for silence, how many people are using the fixed-id model? Simple replies to this post without any text will be taken as an "I am" post. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 18:19: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 SAA09625 for ; Wed, 13 Aug 2003 18:19:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DM9Eqt015857 for ; Wed, 13 Aug 2003 15:09:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DM9E46015856 for ietf-calendar-bks; Wed, 13 Aug 2003 15:09:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DM9Cqt015846 for ; Wed, 13 Aug 2003 15:09:12 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n3p6-0005lW-00 for ; Thu, 14 Aug 2003 00:10:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n3fk-0005fm-00 for ; Thu, 14 Aug 2003 00:00:48 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n3eY-0006Re-00 for ; Wed, 13 Aug 2003 23:59:34 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Wed, 13 Aug 2003 14:59:40 -0700 Lines: 62 Message-ID: References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@Royer.com> <3F3979F1.9070505@Royer.com> <3F39A1A4.6070204@Royer.com> <3F3A63AE.30204@Royer.com> <3F3AA176.4090107@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: First off, thank you for acknowledging that this method actually works. This is progress. At least now we are arguing about whether or not it's what iTIP says to do and whether or not it actually includes extraneous overhead. > You can type it as many times as you want, but why not just > send it as documented in iTIP? Whey that extra overhead? Where is it documented in iTIP that you should fragment the UID to invite someone to a particular instance of a recurring event? Where is it documented in iTIP that to change the set of ATTENDEE properties for a particular instance you should do it in a way other than the method used to change all other properties for that same instance? Why did you ignore the very real implementation problem with your recommendation which I included in the previous post? Why have you not explained to us why fragmenting the UID as you suggest, to keep various branches of the UID floating around for the different sets of instances that particular ATTENDEEs are invited to, is not in violation of the uniqueness requirement for the primary key of an event? I don't see how this method actually uses any extra overhead except for maybe a little fatter message used on the transport wire (but the same or fewer amount of resources to process it) in two cases: 1) The recipient was invited to the subset of instances at the same moment in time by the ORGANIZER and not piecemeal. or 2) If the recipient is invited to a set of instances but not the whole series AND they request a REFRESH AND the instances haven't ever been renegotiated by the ORGANIZER. Other than those two very specific cases which are hardly worth the effort in optimizing for, the two models use identical resource overhead. If you need me to, I can go through the effort of proving it, but since you thus far have not seemed to care to read/respond to the effort put into explaining it to you I'm going to save my time and energy lest you, or someone else on this list, request the demonstration of why either of these "invite" models use the same overhead in all but those two instances. I'd also like to make you aware that we are totally off the subject of this thread at the moment. We are now debating two different models of inviting a CU to an instance and not the merits/disadvantages of fixed-id/current-value recurrence-id property values. The two discussions are hardly related to each other. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 18:28: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 SAA09822 for ; Wed, 13 Aug 2003 18:28:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMG1qt016890 for ; Wed, 13 Aug 2003 15:16:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DMG1VM016889 for ietf-calendar-bks; Wed, 13 Aug 2003 15:16:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMG0qt016882 for ; Wed, 13 Aug 2003 15:16:00 -0700 (PDT) (envelope-from ki.wong@Sun.COM) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7DMG1ph022570; Wed, 13 Aug 2003 16:16:02 -0600 (MDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7DMG1hD002812; Wed, 13 Aug 2003 15:16:01 -0700 (PDT) Received: from J02K.dvd2kdom.red.iplanet.com (j02k.red.iplanet.com [192.18.144.134]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJK00BDMWIPR9@ha13sca-mail1.sfbay.sun.com>; Wed, 13 Aug 2003 15:16:01 -0700 (PDT) Date: Wed, 13 Aug 2003 15:17:33 -0700 From: Ki Wong Subject: RE: Is there anybody out there supporting Doug's skewed model of iCalendar besides Doug To: "Robert_Ransdell@notesdev.ibm.com" , "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Zt5DUsMLPMfMbKIYJoTkhA)"; DIFFERENCES=Content-Language Content-language: en-USA Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_Zt5DUsMLPMfMbKIYJoTkhA) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT I assume you are refering to the RECURRENCE-ID discussion. We posted the original question a few months ago. Today, we have implemented the fixed RID model. We implemented the fixed RID model mainly for its simplicity, unambiguity and interoperability (Exchange and Notes) . After reading most of the postings for this discussion, I personally still have difficulty to understand Doug's model and the reason why it will be done that way. ki -----Original Message----- From: Robert_Ransdell@notesdev.ibm.com [mailto:Robert_Ransdell@notesdev.ibm.com] Sent: Wednesday, August 13, 2003 2:14 PM To: ietf-calendar@imc.org Subject: Is there anybody out there supporting Doug's skewed model of iCalendar besides Doug _____________________ Note: new email address tom_ransdell@notesdev.ibm.com --Boundary_(ID_Zt5DUsMLPMfMbKIYJoTkhA) Content-id: 0 Content-type: TEXT/html; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT Message
I assume you are refering to the RECURRENCE-ID discussion. We posted the original  question a few months ago. Today, we have implemented the fixed RID model. We implemented the fixed RID model mainly for its simplicity, unambiguity  and interoperability  (Exchange and Notes) .  After reading most of the postings for this  discussion,  I personally  still have difficulty to  understand Doug's model and the reason why  it will be done  that way.
 
ki
-----Original Message-----
From: Robert_Ransdell@notesdev.ibm.com [mailto:Robert_Ransdell@notesdev.ibm.com]
Sent: Wednesday, August 13, 2003 2:14 PM
To: ietf-calendar@imc.org
Subject: Is there anybody out there supporting Doug's skewed model of iCalendar besides Doug


_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com
--Boundary_(ID_Zt5DUsMLPMfMbKIYJoTkhA)-- From owner-ietf-calendar@mail.imc.org Wed Aug 13 18:42: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 SAA10091 for ; Wed, 13 Aug 2003 18:42:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMZZqt018346 for ; Wed, 13 Aug 2003 15:35:35 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DMZZ7S018345 for ietf-calendar-bks; Wed, 13 Aug 2003 15:35:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMZYqt018336 for ; Wed, 13 Aug 2003 15:35:34 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7DMZVRv010676; Wed, 13 Aug 2003 15:35:31 -0700 (PDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7DMZVaJ022283; Wed, 13 Aug 2003 15:35:31 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJK00BC0XF6R9@ha13sca-mail1.sfbay.sun.com>; Wed, 13 Aug 2003 15:35:31 -0700 (PDT) Date: Wed, 13 Aug 2003 15:35:33 -0700 From: Satya Vempati Subject: RE: How many people are there using the fixed-id model? To: Michael Fair , "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT ALL major implementations today use the fixed recurrence-id model. Even if Doug is right in his reading of iTip and iCal, the large body of implementations are against his model. It is unlikely that anyone would want a de jure standard that is at odds with the de facto standard. To do so would create two iCal & iTip standards and would fracture the community. The right question to ask then is, if Doug sees problems with the fixed recurrence model, what text should we add to iCal & iTip to a) make the model work and b) disambiguate the text so that future circular discussions of this sort could be avoided. -----Original Message----- From: Michael Fair [mailto:michael@daclubhouse.net] Sent: Wednesday, August 13, 2003 3:09 PM To: ietf-calendar@imc.org Subject: How many people are there using the fixed-id model? Since requesting how many people are using Doug's model is a potentially bankrupt question causing the whole list to wait for silence, how many people are using the fixed-id model? Simple replies to this post without any text will be taken as an "I am" post. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 19:31: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 TAA11075 for ; Wed, 13 Aug 2003 19:31:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNMiqt019905 for ; Wed, 13 Aug 2003 16:22:44 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNMifW019904 for ietf-calendar-bks; Wed, 13 Aug 2003 16:22:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNMfqt019899 for ; Wed, 13 Aug 2003 16:22:42 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n4yD-0006JM-00 for ; Thu, 14 Aug 2003 01:23:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n4yC-0006JE-00 for ; Thu, 14 Aug 2003 01:23:56 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n4x0-0000M1-00 for ; Thu, 14 Aug 2003 01:22:42 +0200 From: "Michael Fair" Subject: New question in regards to the fixed-id model Date: Wed, 13 Aug 2003 16:22:41 -0700 Lines: 125 Message-ID: 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: In spirit of coming up with what the new text should unambiguously say and not having this answered for myself yet, I have a question about how rescheduling an entire series of events impacts individual instances that may have been previously renegotiated. The scenario goes something like this: I send an invite to a bunch of people: UID:1 SEQ:0 RRULE/RDATE:Every Friday this year. I then move Friday, June 13th, to Thursday, June 12th. UID:1 RID:June 13th SEQ:1 DTSTART:June 12th I then decide to move the entire series to Monday. Since the SEQUENCE of the largest instance in the series is now 1, the next highest value to use for the new SEQUENCE is now 2. This forumla was given to me offline from the list and I can find no real text in iTIP supporting it, but I agree it is what is necessary for the desired outcome. So I send: UID:1 SEQ:2 RRULE/RDATE:Every Monday this year. So now what to do about that Thursday meeting. The SEQUENCE of the rescheduled parent event being at 2 clearly indicates that it supercedes the renegotiation of the instance at 1. Further, the RECURRENCE-ID list described by the set no longer includes June 13th. iCal says that RECURRENCE-IDs are only fixed for a given UID/SEQ pair. Since that pair has now changed it is valid for the RECURRENCE-ID of the instance in question to change. Unless I am misapplying that text. At this point I feel it reasonable to say that the CUA should just cancel the offended out of date instance and assume that the message it just received is the complete latest description. If the CUA wanted to maintain the Thursday rather than Monday occurence, then along with the reschedule to Monday it must include a per-instance update to the now Monday RECURRENCE-ID. This however poses a problem in the case that an individual CU has been invited to that one and only instance because they would never have seen the master recurring event nor its reschedule. Therefore to maintain consistency it must send two messages one with a CANCEL of the old RECURRENCE-ID and another with the new RECURRENCE-ID of Monday. If the recipient's CUA should miss the CANCEL message it will end up with two instances on its calendar. The original as yet uncancelled instance RID:Friday, and the new RID:Monday instance. Save for the CUA receiving the CANCEL message which I can't see any way of resending I see no way to get the recipient's calendar back into sync since they aren't invited to the base recurring event and shouldn't ever receive it. To attempt to answer my own question, there is an example in 4.7.2 Bad RECURRENCE-ID which might resolve the dilemma, but it's format is only in 4.7.2 and in no other example dealing with recurring instances. The example shows an event that has both RECURRENCE-ID and RRULE/RDATE properties. This is the only time I have ever seen that used. If we define that when inviting an individual CU to a particular instance, the ORGANIZER's CUA MUST include both the RECURRENCE-ID of the instance AND the RRULE(s) and/or RDATE(s) (with any EX counterparts) then this whole situation can be avoided. In this case, when the recipient's CUA receives the new description with the now Monday RECURRENCE-ID it can use the RRULE/RDATE/EXRULE/EXDATE information to find out if the set still includes the other instances that it has on its calendar. Since the SEQUENCE of the new instance will be greater and the set will no longer describe the original RID then the CUA will no that the instance in question no longer exists and can remove it. It is the ORGANIZER CUA's responsibility to ensure that any and all instance information it wants copied from the old instances be included in the new updates. The act of updating the SEQUENCE value on the UID/RID:NULL object, implicitly cancels any and all instances whose RECURRENCE-ID no longer exists in the new series. Any thoughts? Or is there something out there I am just misinterpreting/not taking into account? How do other implementations already handle this? -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 19:39: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 TAA11321 for ; Wed, 13 Aug 2003 19:39:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNWGqt020867 for ; Wed, 13 Aug 2003 16:32:16 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNWG50020866 for ietf-calendar-bks; Wed, 13 Aug 2003 16:32:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNWFqt020861 for ; Wed, 13 Aug 2003 16:32:15 -0700 (PDT) (envelope-from cco@asitturnsout.org) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 589B98D7B5 for ; Wed, 13 Aug 2003 16:32:16 -0700 (PDT) From: "Chris Olds" To: ietf-calendar@imc.org Subject: RE: Is there anybody out there supporting Doug's model? Date: Wed, 13 Aug 2003 16:32:16 -0700 Message-Id: <20030813224754.M95918@asitturnsout.org> In-Reply-To: References: X-Mailer: Open WebMail 2.10 20030617 X-OriginatingIP: 63.100.79.162 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 13 Aug 2003 14:43:42 -0700, Anil SRIVASTAVA wrote > Not me and I think it is time to put get out of endless cycle we are > currently in. Logic, reason are being ignored. Me. I agree that logic is being ignored, but I suspect my reasoning is different than Anil's. The current-value model never needs more than a REFRESH request and its response to get back in synch. The fixed model can need an arbitrary (think possibly large N) number of additional messages in order to establish the RID:0 :: DTSTART set mapping in addition to the REFRESH and its response, and the Attendee CUA must retain all of that data. The only advantage the fixed-ID camp has put forward is the ability to schedule multiple instances of a recurring event to the same DTSTART value, which doesn't really strike me as a big win. The disadvantages (more complex CUA logic, more data to persist, more VEVENT objects to send and recieve) seem large to me too. Contrary to Bruce's repeated assertions, when one gets a new version of a VEVENT, complete with it's current recurrence set, there is no obligation to (nor any sense to) throw out the current scheduled instances for that event. If the instance was previously scheduled, it can remain scheduled. If it wasn't there before, it needs to be added. Nothing new here, no reason to say EEK! we must dispose of all data for that UID because we got a new VEVENT with the same UID. iTIP describes, in detail, exactly what one should do with this data, and I don't see anywhere that doing the least useful thing one can think of is even suggested, much less required. As far as Michael's reading of iTIP to allow versioning each instance of a recurrence set independently (i.e., having it's own SEQ value), I can find no support for it in either normative nor example text, and so I think we should stop talking about it (because it is contrary to RFC 2446 and therefore out of scope). /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Wed Aug 13 20:25:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12563 for ; Wed, 13 Aug 2003 20:25:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E0Fmqt022712 for ; Wed, 13 Aug 2003 17:15:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E0FmEh022711 for ietf-calendar-bks; Wed, 13 Aug 2003 17:15:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E0Fkqt022706 for ; Wed, 13 Aug 2003 17:15:46 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7E0FhRv029413; Wed, 13 Aug 2003 17:15:43 -0700 (PDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7E0FhhD026219; Wed, 13 Aug 2003 17:15:43 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJL00DV0227EN@ha13sca-mail1.sfbay.sun.com>; Wed, 13 Aug 2003 17:15:43 -0700 (PDT) Date: Wed, 13 Aug 2003 17:15:45 -0700 From: Satya Vempati Subject: RE: Is there anybody out there supporting Doug's model? To: Chris Olds , "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT <> Could you provide an example. -----Original Message----- From: Chris Olds [mailto:cco@asitturnsout.org] Sent: Wednesday, August 13, 2003 4:32 PM To: ietf-calendar@imc.org Subject: RE: Is there anybody out there supporting Doug's model? On Wed, 13 Aug 2003 14:43:42 -0700, Anil SRIVASTAVA wrote > Not me and I think it is time to put get out of endless cycle we are > currently in. Logic, reason are being ignored. Me. I agree that logic is being ignored, but I suspect my reasoning is different than Anil's. The current-value model never needs more than a REFRESH request and its response to get back in synch. The fixed model can need an arbitrary (think possibly large N) number of additional messages in order to establish the RID:0 :: DTSTART set mapping in addition to the REFRESH and its response, and the Attendee CUA must retain all of that data. The only advantage the fixed-ID camp has put forward is the ability to schedule multiple instances of a recurring event to the same DTSTART value, which doesn't really strike me as a big win. The disadvantages (more complex CUA logic, more data to persist, more VEVENT objects to send and recieve) seem large to me too. Contrary to Bruce's repeated assertions, when one gets a new version of a VEVENT, complete with it's current recurrence set, there is no obligation to (nor any sense to) throw out the current scheduled instances for that event. If the instance was previously scheduled, it can remain scheduled. If it wasn't there before, it needs to be added. Nothing new here, no reason to say EEK! we must dispose of all data for that UID because we got a new VEVENT with the same UID. iTIP describes, in detail, exactly what one should do with this data, and I don't see anywhere that doing the least useful thing one can think of is even suggested, much less required. As far as Michael's reading of iTIP to allow versioning each instance of a recurrence set independently (i.e., having it's own SEQ value), I can find no support for it in either normative nor example text, and so I think we should stop talking about it (because it is contrary to RFC 2446 and therefore out of scope). /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Wed Aug 13 20:29:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12679 for ; Wed, 13 Aug 2003 20:29:57 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E0LFqt022918 for ; Wed, 13 Aug 2003 17:21:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E0LF1S022917 for ietf-calendar-bks; Wed, 13 Aug 2003 17:21:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E0LEqt022912 for ; Wed, 13 Aug 2003 17:21:14 -0700 (PDT) (envelope-from cco@asitturnsout.org) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id AEE978D7B5 for ; Wed, 13 Aug 2003 17:21:15 -0700 (PDT) From: "Chris Olds" To: ietf-calendar@imc.org Subject: Re: New question in regards to the fixed-id model Date: Wed, 13 Aug 2003 17:21:15 -0700 Message-Id: <20030813233844.M20580@asitturnsout.org> In-Reply-To: References: X-Mailer: Open WebMail 2.10 20030617 X-OriginatingIP: 63.100.79.162 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 13 Aug 2003 16:22:41 -0700, Michael Fair wrote > > The scenario goes something like this: > > I send an invite to a bunch of people: > UID:1 > SEQ:0 > RRULE/RDATE:Every Friday this year. > > I then move Friday, June 13th, to Thursday, June 12th. > UID:1 > RID:June 13th > SEQ:1 > DTSTART:June 12th > > I then decide to move the entire series to Monday. > Since the SEQUENCE of the largest instance in the > series is now 1, the next highest value to use for > the new SEQUENCE is now 2. This forumla was given > to me offline from the list and I can find no real > text in iTIP supporting it, but I agree it is what > is necessary for the desired outcome. SEQ is for the whole set, not per-instance. Since you changed an instance (and changing a member of a set changes the set), 2 is the correct value. > So I send: > UID:1 > SEQ:2 > RRULE/RDATE:Every Monday this year. > > So now what to do about that Thursday meeting. All you need to do is add another date, specifying Thursday. If it replaces a meeting from the RRULE/RDATE set, then use EXRULE/EXDATE. If it is in addition use RDATE > iCal says that RECURRENCE-IDs are only fixed for > a given UID/SEQ pair. Since that pair has now > changed it is valid for the RECURRENCE-ID of the > instance in question to change. Unless I am > misapplying that text. Nope, that's exactly how I read it, and how I understand Doug to be reading it. Welcome to the 'current-value' camp! > At this point I feel it reasonable to say that the > CUA should just cancel the offended out of date > instance and assume that the message it just received > is the complete latest description. If the CUA > wanted to maintain the Thursday rather than Monday > occurence, then along with the reschedule to Monday > it must include a per-instance update to the now > Monday RECURRENCE-ID. Sure, although a simple EXDATE would be enough, no RECURRENCE-ID messing about needed. > This however poses a problem in the case that an > individual CU has been invited to that one and > only instance because they would never have seen > the master recurring event nor its reschedule. No problem at all. Nothing says that every Attendee must (or even should) see the same event as the Organizer. There are many reasons that an Organizer might want to present different versions of the event object to different users (or classes of users), and since the Organizer is the only arbiter of what constitutes 'the same event' (for purposes of unambiguous UID assignment), this all works out just fine. > Therefore to maintain consistency it must send two > messages one with a CANCEL of the old RECURRENCE-ID > and another with the new RECURRENCE-ID of Monday. Not needed. The old RECURRENCE-ID message was sent with SEQ:1, and the new (complete) VEVENT was sent with SEQ:2, so any instances a CUA might find in it's calendar that don't match any instance in the new set should be removed anyway. The exception can be included in the complete event definition. If only one attendee was rescheduled from Friday (now Monday) to Tuesday, just send them an exception with SEQ:2, RECURRENCE-ID:Monday and that's it. [ My reasoning for leaving the SEQ at 2 is that the change was initially made before the reschedule of the event set, so the execption, whether general or individual, was present before the change to the set. If these messages arrive out-of order, the CUA will request a REFRESH (to get the complete set), and use either the VEVENT sent to everyone or the sepecific response (whichever arrives first). Since all of these have the same SEQ (and likely the same DTSTAMP), they all have equal priority and should be considered together, which gives the correct result. ] > If the recipient's CUA should miss the CANCEL message > it will end up with two instances on its calendar. > The original as yet uncancelled instance RID:Friday, > and the new RID:Monday instance. No. Getting the complete SEQ:2 event means you have all of the scheduled instances for that UID, and so all the Friday instances get deleted. > Save for the CUA receiving the CANCEL message which > I can't see any way of resending I see no way to get > the recipient's calendar back into sync since they > aren't invited to the base recurring event and shouldn't > ever receive it. Each Attendee MAY have a different view of the event. If the Organizer knew how to send the original version, they know how to send an update. Again, SEQ:2 makes _all_ SEQ:1 data out of date. > Since the SEQUENCE of the new instance will be greater > and the set will no longer describe the original RID > then the CUA will no that the instance in question no > longer exists and can remove it. It is the ORGANIZER > CUA's responsibility to ensure that any and all instance > information it wants copied from the old instances be > included in the new updates. Yes. The examples make this clear. > The act of updating the SEQUENCE value on the > UID/RID:NULL object, implicitly cancels any and all > instances whose RECURRENCE-ID no longer exists in > the new series. > > Any thoughts? Or is there something out there I am > just misinterpreting/not taking into account? > How do other implementations already handle this? Thank you for this clear description of the 'current-value' model, and why it is simpler and less error-prone. I snipped some text describing problems that occur if one uses the 'fixed' model, but that doesn't mean I think they're unimportant, it just means that I want to point out that they don't occur in the 'current-value' model. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Wed Aug 13 20:58: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 UAA13259 for ; Wed, 13 Aug 2003 20:58:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E0mDqt025549 for ; Wed, 13 Aug 2003 17:48:13 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E0mDW2025548 for ietf-calendar-bks; Wed, 13 Aug 2003 17:48:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E0mAqt025534 for ; Wed, 13 Aug 2003 17:48:10 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n6Iw-0002qL-00 for ; Thu, 14 Aug 2003 02:49:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n6Iv-0002qC-00 for ; Thu, 14 Aug 2003 02:49:25 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n6Hj-0002H0-00 for ; Thu, 14 Aug 2003 02:48:11 +0200 From: "Michael Fair" Subject: Re: Is there anybody out there supporting Doug's model? Date: Wed, 13 Aug 2003 17:48:10 -0700 Lines: 214 Message-ID: References: <20030813224754.M95918@asitturnsout.org> 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: Hey Chris, I was wondering what had become of you. :) > The current-value model never needs more than a REFRESH request and its > response to get back in synch. The fixed model can need an arbitrary >(think possibly large N) number of additional messages in order to > establish the RID:0 :: DTSTART set mapping in addition to the > REFRESH and its response, and the Attendee CUA must retain all of > that data. I'll admit that I don't exactly follow what it is you are implying must be tracked since there is never a time where the 'fixed-id' model needs all messages back to the SEQ:0 DTSTART. But I can assure that in the general case of a REFRESH, the response messages of both the 'fixed-id' and 'current-value' models should be virtually identical. Both contain the description of the base set of instances, and both contain follow-up objects that describe per instance differences, and both send one, and only one message to get the recipient fully in sync. Further in the 'fixed-id' model there are fewer cases where being out of sync is even possible and thus oftentimes the REFRESH results in a noop for the CUA. From the examples, section 4.4.7 talks about what a REFRESH reponse looks like. One sentence in particular stands out: ... To convey all instance-specific changes, the "Organizer" must provide the latest event description and the relevant instances. ... Sure in, the 'current-value' model described in the other discussion where every 'instance reschedule' is actually a 'rescheduling of the entire set' where most RID's end up matching at the end, it's _possible_ to get a smaller message, but highly unlikely. You are assuming that the only data that will ever be associated with an instance is defined in the base recurring event. There will be no comments, no attatchements, no attendance differences, no per instance URL, no descriptions, no summaries, and that every instance will always be at the same location and use the same resources. In the event that you ever want to convey any of the above to the recipients (which I think you would) you have to do it in a per instance object. This is the same regardless of the model chosen. You are also assuming that your reschedules of the instances merely changed the date and did not change the start time. Once you change the start time of an instance you MUST provide an independent instance object ot convey that info. However, I will grant you that in the very isolated case that all you did was change the date, and only the date, of a particular instance(s) and you do not wish to convey any other per instance data (which I just find hard to believe) you are correct. The 'current-value' model saves a few bytes on the wire. On the flip side it take the ORGANIZER's CUA the same or more CPU cycles to construct the new recurrence set, and takes about the same or more number of CPU cycles on the recipient's side. The primary distinction is that to say "use this pattern, except this, except that" usually takes more CPU cycles than to say "use this pattern, now update this instance, update that instance" and in the case you want to convey per instance info you have to say the even more complicated "use this pattern, except this, except that, now update this instance, update that instance". > The only advantage the > fixed-ID camp has put forward is the ability to schedule > multiple instances of a recurring event to the same DTSTART > value, which doesn't really strike me as a big win. Granted. It was a pedantic exercise to shut up Doug's insistence that the fixed-id model had some problem with this. Not to mention at the end of that message I said that I could receive those messages in any order concocted and would still end up with the same results which further demonstrated the robustness of the model not just its ablility to handle silly things. > The disadvantages: > (more complex CUA logic, I don't see how it's any more complex that what the CUA already has, it already needs to look for the presence of both UID/RID on every message, and it already has to be prepared to reschedule a particular instance. In fact I see the logic as being very simple. Every object in a message refers to one and exactly one object in the store and if it can't find that object it creates it, if it can it updates it. In the case of updating a recurring series it does the same amount of bookkeeping the 'current-value' model needs to do. > more data to persist This is just false. Last paragraph of section 2.1.5 expressly states that CUA's must track the RID of property of a component. Unless you want to redefine persist, add a missing "may", or call the paragraph an error. > more VEVENT objects to send and recieve) When you are dealing with differences between individual instances the fact is there just are more objects to pass around. See my description above about REFRESH to see how in practice there aren't any more objects to send and receive as the few cases where the 'current-value' can save a few bytes are very extraordinary. In fact, if the 'fixed-id' model wanted to, it could actually use those same semantics to get those exact same results if the CUA bothered to be smart enough to detect them. (The semantics being treat the reschedule of an instance as a reschedule of the entire series.) > Contrary to Bruce's repeated assertions, when one gets a new > version of a VEVENT, complete with it's current recurrence > set, there is no obligation to (nor any sense to) throw out > the current scheduled instances for that event. You are assuming that all instance updates contain the entire recurrence set. There is only one example in all of iTIP that uses those semantics and no where in the prose that says it is even recommended to do so. So the majority of implementations will not include the recurrence set in an instance update. Imagine a situation where a CUA gets every other message. There is an instance A that gets moved 6 times. The CUA will only see three of moves (the even ones) and it will miss three of those moves (the odd ones). Since each message uses an RID of the DTSTART of the message before it, all messages will have a different RID and the CUA will never have an object in its calendar to match the object trying to be addressed. Therefore it will send out three REFRESH requests. No one in the 'current-value' camp has said exactly what the 'current-value' model CUA should do in the case where it receives a message for an instance of a recurring series for which it can find no existing object and the sequence value is larger than anything it has seen before. I've held that if it follows iTIP 2.1.5 it will add it to its calendar and as per 4.7.2 send a REFRESH request. This means that anytime the 'current-value' misses an update, the next instance update it sees will create a new duplicate event. This situation is only resolvable when the new REFRESH response shows up to say which instances are and are not in the set. The CUA can then wipe out all the instances that aren't in the set and be in sync once again. Hopefully to not miss any more instance update messages. Doug, in one or two posts, implied that it will hold the messages until it receives the messages with the proper sequence number in it. > As far as Michael's reading of iTIP to allow versioning each > instance of a recurrence set independently (i.e., having it's > own SEQ value), I can find no support for it in either normative > nor example text, and so I think we should stop talking about > it (because it is contrary to RFC 2446 and therefore out of > scope). If I am indeed misreading the text then I must be corrected. In section 3.7.1 Working With Recurrence Instances the first thing it talks about is how different CUAs might or might not support recurring events. The very first sentence of page 57 (Second paragraph of 3.7.1) says: Since implementations may elect to store recurring events as either a single event object or a collection of discreet, related event objects, the protocol is designed so that each recurring instance may be both referenced and versioned. How do you read that sentence in respect to saying that each recurring instance can be versioned? In fact if we cut it down to just the important and applicable text it says: The protocol is designed so that each recurring instance may be versioned. Regardless of how you interpret the "may" part, and I can think of a few, the end result is that a CUA can and therefore some will track independent versions of each instance in a recurring event. Or do you have an interpretation of that sentence that doesn't allow for the existence of per instance versions? You might just call it an error in the RFC. I can respect that. I have to respect that since there is at least one other sentence in iTIP that the 'fixed-id' model says is an error. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 22:17: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 WAA14581 for ; Wed, 13 Aug 2003 22:17:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E265qt031545 for ; Wed, 13 Aug 2003 19:06:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E265f3031544 for ietf-calendar-bks; Wed, 13 Aug 2003 19:06:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E261qt031539 for ; Wed, 13 Aug 2003 19:06:02 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n7WH-0003N1-00 for ; Thu, 14 Aug 2003 04:07:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n7WG-0003Mt-00 for ; Thu, 14 Aug 2003 04:07:16 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n7V5-0004Jw-00 for ; Thu, 14 Aug 2003 04:06:03 +0200 From: "Michael Fair" Subject: Re: New question in regards to the fixed-id model Date: Wed, 13 Aug 2003 19:06:02 -0700 Lines: 179 Message-ID: References: <20030813233844.M20580@asitturnsout.org> 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: Thanks for responding. I should first say that I haven't switched camps. I'm just trying to make sense of the text as it is written. It was this same logic that I used to figure out that sentence in iTIP that says that RID ends up at its new value is an error. However, it's highly unlikely, though it is not impossible, that I would ever accept the current-value model as it performs so horridly in the presence of missed messages and iTIP on so many occasions and with good reason expects that messages regularly will be received out of order. iTIP and iCal (as evidenced by this whole discussion) is not the clear document we'd all hope it to be. Just to show you how confusing this all can get here's another iTIP fragment from section 3.7.1 Working with recurring instances: An instance of a recurring event is assigned a unique identification,"RECURRENCE-ID" property, when that instance is renegotiated. No one I've seen on either thread here has ever come up a clear interpretation of that text. It could imply that it didn't have a uique RID prior to being renegotiated, or it could mean that when taken with another iTIP possibility that RID's not even be dates at all if DTSTART doesn't describe a calendar time that it gets assigned at the time of renegotiation. But it never says to what, other than to say it is unique. It's just a bizarre piece of text (I was going to ask about it later but it came up). I mean I could actually read it to mean that iCal uses a 'current-value' model up until that instance is renegotiated and it is then fixed from then on forever more until it or the entire series is canceled, but that causes it's own problems. Or I can say that iCal's UID/SEQ pair statement is the most meaningful and if using a 'current-value' this whole statement is pretty much a noop as once the SEQ changes it could possibly invalidate the RID anyway. Or I can say that it uses a 'current-value' model until an instance is renegotiated and then as per iCal's UID/SEQ pair statement it is fixed until the set is redefined and what I end up with is exactly the 'fixed-id' model we've discussing. Anyway on to the real discussion. > > This however poses a problem in the case that an > > individual CU has been invited to that one and > > only instance because they would never have seen > > the master recurring event nor its reschedule. > > No problem at all. > > Nothing says that every Attendee must (or even should) > see the same event as the Organizer. Actually at least two things do. One is the definition of UID which says that it is globally unique. Once you do this you have just created two events with the same UID that describe different sets and have therefore violated global uniqueness of the UID. Second is an implementation issue. Since I don't know what the answer is, I'll pose the situation and just ask you to tell me how the CUA's resolve it. User A and User B get invited to two separate instances 1 and 2 respectively. So now you have three versions of the UID, one for A, one for B, and the original. Both A and B decide the other one should have been invited to their respective instances and forward the event to each other. So both A and B now receive a message describing the same UID, the same SEQ, but different DTSTART. Assuming we did as you suggested they would actaully have two singleton's without so near a mention of a recurring instance, and the ORGANIZER would assume that any replies from either of them were in respect to the respective singleton's it sent them. So first, what will A and B's respective CUAs do when then receive the forwarded messages (for example purposes let's say that A was invited before B and therefore the DTSTAMP for B's event is greater)? And second, assuming you somehow get the CUA's to sort out the mess how will the ORGANIZER interpret their REPLY? Please cite iTIP when saying how the respective CUAs make their decisions. > > Therefore to maintain consistency it must send two > > messages one with a CANCEL of the old RECURRENCE-ID > > and another with the new RECURRENCE-ID of Monday. > > Not needed. The old RECURRENCE-ID message was sent with SEQ:1, > and the new (complete) VEVENT was sent with SEQ:2, You are assuming that every object that refers to an instance always contains a description of the entire set which is false. In fact, only one example in all of iTIP even uses the possibility that a VEVENT might ever do this. I can't tell if it's a mistake (for instance look closely at the RDATE field), an oversight, or what. The example is even internally not consistent with itself as the RECURRENCE-ID used is clearly not one of the set defined by the RRULE/RDATE shown. (This is example is in 4.7.2 at the REQUEST from A) In the case of the individual CU invited to one individual instance, it's perfectly valid for them to never have seen the entire event set (lest we use the fragmented/branching UID method you described which I will only begin to consider after you get get over the two reasons against it above). In fact, my recommended solution was to exactly gaurantee that this assumption could be true. To define that the update to the now Monday RID contains a description of the set. This further implies that the previous instance also described the recurrence set - this may or may not be a desirable leak of extra information. And by inclusion of the set, as you say, the CUA can figure it out from there. > > Any thoughts? Or is there something out there I am > > just misinterpreting/not taking into account? > > How do other implementations already handle this? > > Thank you for this clear description of the 'current-value' > model, and why it is simpler and less error-prone. I snipped > some text describing problems that occur if one uses the 'fixed' > model, but that doesn't mean I think they're unimportant, it > just means that I want to point out that they don't occur in > the 'current-value' model. No problem, I've tried very hard to completely understand what the propenents of the 'current-value' model say it should do so that I am arguing the right assumptions. As you can see it was also part of the inspiration for one of my proposals for recovery. However that proposal is still very error prone in the presence of missed messages. Not coincidently just like the 'current-value' model. That proposal also reveals information that may or may not be desirable to reveal - what the recurrence set for the whole series actually is... It's still a work in progress as far as I'm concerned and the final outcome may be very different. I mean one of my solutions is to introduce a new property, the presence of which means that when the recurrence update is finished, the recurrence-id has now changed, and if not present means the recurrence-id remains what it was. This is actually my favorite proposal but I hesitate to suggest it in case I'm actually missing a solution that is actually in the text. -- Michael -- From owner-ietf-calendar@mail.imc.org Wed Aug 13 22:57: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 WAA15070 for ; Wed, 13 Aug 2003 22:57:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2nAqt032737 for ; Wed, 13 Aug 2003 19:49:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E2nAAn032736 for ietf-calendar-bks; Wed, 13 Aug 2003 19:49:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2n9qt032730 for ; Wed, 13 Aug 2003 19:49:09 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7E2n9EB028746 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Aug 2003 19:49:11 -0700 Message-ID: <3F3AF8A0.1000205@Royer.com> Date: Wed, 13 Aug 2003 20:49:04 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070908080307010803040800" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070908080307010803040800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>>It doesn't break the uniqueness for a single instance, prove to >>>me how there is a conflicting copy of UID:1/RID:1 somewhere in >>>the world different than the one I sent? >>> >> >>Then why did you incorrectly guess if the sample I sent was >>an update or a new invite to a single instance? > > > Why does it matter? Your assertion is above = "It doesn't break the uniqueness for a single instance...". Yet you were unable to tell the difference - both can not be true. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070908080307010803040800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDAyNDkwNFowIwYJKoZIhvcNAQkEMRYEFFqpoYQ3 FhhnjUMrVLXWvvsLJzW3MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIlHBhh+S1klBWG34zWGtcRrYuQYTFcbpixZh4GIXeW0qlVs3adb rhFJc5VrHBzDjJ/D7F7GGGR+OTjXAi0Fb9RUfeUXbAUnU8G4xai2OLlN/qX56o2FffO9UayU PMWT7g2WKxo11gd11ByANMVcqXn/VmWOs0IicIrPzGZX+0KKqCVMQ+QJQYgbHxRht9NDFDO/ fFWt2bIxDbyzOC/Q8/oSd39xlwEthbML29jckBHxW2KTdklCUDb70gHBm/5ea+4bT8chhuZI 8hiReZXNn/1NwUsGYBXRuqidlqJrsW9LHGNINUwGmR62Kkp6XvPKICsFSK+AWpn7RkFU9EsH CdcAAAAAAAA= --------------ms070908080307010803040800-- From owner-ietf-calendar@mail.imc.org Wed Aug 13 22:58: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 WAA15088 for ; Wed, 13 Aug 2003 22:58:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2oAqt032781 for ; Wed, 13 Aug 2003 19:50:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E2oA2s032780 for ietf-calendar-bks; Wed, 13 Aug 2003 19:50:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2o9qt032775 for ; Wed, 13 Aug 2003 19:50:09 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7E2o9EB028768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Aug 2003 19:50:11 -0700 Message-ID: <3F3AF8DC.40108@Royer.com> Date: Wed, 13 Aug 2003 20:50:04 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F37FC58.30406@Royer.com> <3F38291B.9020407@Royer.com> <3F3841D1.9000005@Royer.com> <3F3856A9.5040507@Royer.com> <3F3979F1.9070505@Royer.com> <3F39A1A4.6070204@Royer.com> <3F3A63AE.30204@Royer.com> <3F3AA176.4090107@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000104070504030505060100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000104070504030505060100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > First off, thank you for acknowledging that this method > actually works. I said no such thing. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000104070504030505060100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDAyNTAwNFowIwYJKoZIhvcNAQkEMRYEFN4SHEXv JBmaP2EfQsHsAF38CjujMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAIJ7CjhHTouKD9D9nXqXzp2PpdA9FriUtng672nuQxsfjOLHzW3q k/UNIolg5OoeeUv6l41cXVuIF+qTh5DViHD2Rc6Ig7AgEmn2rsCe3/eYoFaMDNkwp+k9Sl++ RXcrgzD20vKlN24aaln5NiEVh6ecPZUa76KcoNL/ffXhU/UQ4L0RBGmS8DA3sf01+ubJq2HI CIzXl288NbQfeaTVOkkqCYZYpFLEgd5n3idJsZve6L24mHgL0n+wB/nBahDPn/i0PVz2GhhI rJ6x+u9hyq2tvG3CnDgGK1SyGERW+LR1QyfoOPe267EdcwLP2ukV2b3oi4lQbEe3EDBuKWj/ E14AAAAAAAA= --------------ms000104070504030505060100-- From owner-ietf-calendar@mail.imc.org Wed Aug 13 23:07:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15276 for ; Wed, 13 Aug 2003 23:07:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E30Jqt033220 for ; Wed, 13 Aug 2003 20:00:19 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E30JxQ033219 for ietf-calendar-bks; Wed, 13 Aug 2003 20:00:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E30Iqt033214 for ; Wed, 13 Aug 2003 20:00:18 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7E30IEB028823 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Aug 2003 20:00:20 -0700 Message-ID: <3F3AFB3D.7020108@Royer.com> Date: Wed, 13 Aug 2003 21:00:13 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: New question in regards to the fixed-id model References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000206050909030503030703" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000206050909030503030703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > In spirit of coming up with what the new text should > unambiguously say and not having this answered for > myself yet, I have a question about how rescheduling > an entire series of events impacts individual instances > that may have been previously renegotiated. I am still confused as to why anyone would want to make it that complicated as you had below. Why not just send a new entire object to the effected attendees? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000206050909030503030703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDAzMDAxM1owIwYJKoZIhvcNAQkEMRYEFD9BDYnM hVAgOvp8eiLEM3UwdoVzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBABnl1mR8LKlidfng00xuFEaez1BIsL/kWVxbauKZn21CsHa8yWFf /sODCLC6jtSU0d0r3wcol+DQ3jnxtPEgdR9IKaLC9AeDvpbQPfXvFfhw/Oug0XBmtW8vaZGP Lxdtzhj1DhQt0MFxIDqVbgiyCZHU9Vth6zbyzx/dE9tVUSk/1fq2JfekQxI4PPlv6IfuMm+d u4mfV2s9hz5XjadHDK3W9utIrgRQLH8DACPxJ5U17FMkrHwwjm5jBPnjJgFU4pbdyrMsm3+R vwXUNAOVdnDi4KmkD07l6Kom1Fq7AD2lmy5uxCpETwS4TNgFKSMjuYwMdKQL1vAa7xYNhwUB G70AAAAAAAA= --------------ms000206050909030503030703-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 00:19:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16205 for ; Thu, 14 Aug 2003 00:19:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E4AWqt035312 for ; Wed, 13 Aug 2003 21:10:32 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E4AWLb035311 for ietf-calendar-bks; Wed, 13 Aug 2003 21:10:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E4ARqt035296 for ; Wed, 13 Aug 2003 21:10:30 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n9Sh-00048o-00 for ; Thu, 14 Aug 2003 06:11:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19n9Sh-00048g-00 for ; Thu, 14 Aug 2003 06:11:43 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19n9RV-0006PF-00 for ; Thu, 14 Aug 2003 06:10:29 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Wed, 13 Aug 2003 21:10:28 -0700 Lines: 37 Message-ID: References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@Royer.com> <3F3AF8A0.1000205@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:3F3AF8A0.1000205@Royer.com... > > > Michael Fair wrote: > >>>It doesn't break the uniqueness for a single instance, prove to > >>>me how there is a conflicting copy of UID:1/RID:1 somewhere in > >>>the world different than the one I sent? > >>> > >> > >>Then why did you incorrectly guess if the sample I sent was > >>an update or a new invite to a single instance? > > > > > > Why does it matter? > > Your assertion is above = "It doesn't break the uniqueness for a single > instance...". Yet you were unable to tell the difference - both > can not be true. I don't understand this assessment. If you receive an event with UID: blahblahwoofwoof (whether that be UID: blahblah/RID:woofwoof or UID:blahblahwoofwoof) as long as there is only one blahblahwoofwoof in existence and it is unique. Why does it matter if the first time you saw blahblahwoofwoof was an update or its orginal creation? It is still blahblahwoofwoof, there is only one blahblahwoofwoof and you end up with the latest copy of it on your calendar. -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Aug 14 00:38: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 AAA16687 for ; Thu, 14 Aug 2003 00:38:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E4Toqt036229 for ; Wed, 13 Aug 2003 21:29:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E4To3R036228 for ietf-calendar-bks; Wed, 13 Aug 2003 21:29:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E4Tmqt036223 for ; Wed, 13 Aug 2003 21:29:48 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7E4TnEB029413 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Aug 2003 21:29:51 -0700 Message-ID: <3F3B1038.9050003@Royer.com> Date: Wed, 13 Aug 2003 22:29:44 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@Royer.com> <3F3AF8A0.1000205@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010002090303020900090807" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010002090303020900090807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F3AF8A0.1000205@Royer.com... > >> >>Michael Fair wrote: >> >>>>>It doesn't break the uniqueness for a single instance, prove to >>>>>me how there is a conflicting copy of UID:1/RID:1 somewhere in >>>>>the world different than the one I sent? >>>>> >>>> >>>>Then why did you incorrectly guess if the sample I sent was >>>>an update or a new invite to a single instance? >>> >>> >>>Why does it matter? >> >>Your assertion is above = "It doesn't break the uniqueness for a single >>instance...". Yet you were unable to tell the difference - both >>can not be true. > > > I don't understand this assessment. I sent a BEGIN/END VCALENDAR object and asked you what it was. Your guessed incorrectly. Why? Because you could NOT tell if it was a NEW single instance invite OR an single instance modification. Which is why I am still saying you are breaking the iTIP flow if you invite NEW attendees that way. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010002090303020900090807 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDA0Mjk0NFowIwYJKoZIhvcNAQkEMRYEFMsF7hFA JT+0HRlvdouflEKRMxg/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBADh7hffdiqIGMY31Z6LcK1MdYv1ID8Io2q5GFyUhDuIuJGCvYnwj kUgqwLunq0FNpBV/U0hmgcXuXoBuS5+dtd4E5FGL0RTAYnSaPYR0fHzSgiKY6MzFmOUnm81M KLEEQKbUBdmyidcbAWbrBkOF+6e/tnECRXsQR8hiuvIfRLdlh3cZhVUlwztDAl6YzjLHI2jI xtw1N7s8axcyifk6t0qDwTqTzA7K+NNfaWzbA/5pQdf7cM/ChQE6CuVmng2zBWyLAIh1fhXM knMndc2xBD7liBbTJ69sF4mKzzfOmTvnPkxuoNHq1vTwe+GDdKAtErsyCuRZPycUOusPUJL6 +rUAAAAAAAA= --------------ms010002090303020900090807-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 01:54: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 BAA18029 for ; Thu, 14 Aug 2003 01:54:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E5irqt039603 for ; Wed, 13 Aug 2003 22:44:53 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E5iruN039602 for ietf-calendar-bks; Wed, 13 Aug 2003 22:44:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E5inqt039597 for ; Wed, 13 Aug 2003 22:44:51 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nAw1-0004kv-00 for ; Thu, 14 Aug 2003 07:46:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nAw0-0004kn-00 for ; Thu, 14 Aug 2003 07:46:04 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nAuo-0007t1-00 for ; Thu, 14 Aug 2003 07:44:50 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Wed, 13 Aug 2003 22:44:50 -0700 Lines: 98 Message-ID: References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@Royer.com> <3F3AF8A0.1000205@Royer.com> <3F3B1038.9050003@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:3F3B1038.9050003@Royer.com... > > > Michael Fair wrote: > > "Doug Royer" wrote in message > > news:3F3AF8A0.1000205@Royer.com... > > > >> > >>Michael Fair wrote: > >> > >>>>>It doesn't break the uniqueness for a single instance, prove to > >>>>>me how there is a conflicting copy of UID:1/RID:1 somewhere in > >>>>>the world different than the one I sent? > >>>>> > >>>> > >>>>Then why did you incorrectly guess if the sample I sent was > >>>>an update or a new invite to a single instance? > >>> > >>> > >>>Why does it matter? > >> > >>Your assertion is above = "It doesn't break the uniqueness for a single > >>instance...". Yet you were unable to tell the difference - both > >>can not be true. > > > > > > I don't understand this assessment. > > I sent a BEGIN/END VCALENDAR object and asked you what it was. > Your guessed incorrectly. Why? Because you could NOT tell > if it was a NEW single instance invite OR an single instance > modification. Which is why I am still saying you are breaking > the iTIP flow if you invite NEW attendees that way. But you're missing the point. The point isn't to make all users of the internet in following some pedantic excercise of what really happened. If that was the case then every CUA would always have to get every message. That way you would know that first it was this, and then it was that, and then it turned here, and then it went there, etc. The point is that you end up with the same object the ORGANIZER has and you stay in sync with the same object the organizer has sent in the most efficient and fast way possible. That is what happens. That is what I care about. That is the whole point of being able to miss messages to begin with. Whether it was an update and I treated it as a new invite, or it was an actual invite is irrelevant. The _only_ thing relevant is whether or not the CU ends up with the right information on their calendar. This is an engineering task force working group charged with what is essentially is an exercise in distributed message passing using an unreliable communication channel where ensuring that the most recent copy of an object that has reached its intended destination is processable and accurately sticks in their calendar is the most important quality of the mechanism used. Again, until you can say something about how the end result of what actually ends up on the recipient's calendar is faulty there is no use in continuing this discussion. You sent a bunch of messages, I picked the right one and stuck it on my calendar and sent you a REPLY giving you my attendence info. That's what you care about, that's what I care about, that's what the WG cares about, and most importantly that's what the CU cares about. Trying to design a protocol that unnecesarily aatempts to clearly identify "what happened when" is pointless when the goal is to end up at the most recent version and no additonal useful information exists in prior versions. I always am able to process all messages I receive, I always stick the right information on my calendar, and my calendar is never inconsistent with respect to the ORGANIZER's for all information received. This same is not true of the 'current-value' model and until you can say why the information on the calendar is invalid, why it violates iTIP, or why the 'current-value' holds up to the same degree this conversation is over as there is no useful or progressive converstaion being made. You haven't done this yet, and in the one case where you did make an attempt, I directly countered with a more important and prior sequencing text from the exact same section which trumped your assertion. Face it Doug, the model is sound and very defensible within the context of the RFC's save the one line in iTIP that is error as it is contrary to many other references to stated goals and intents from other sections of the RFCs. -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Aug 14 07:12:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06444 for ; Thu, 14 Aug 2003 07:12:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EAu1qt078325 for ; Thu, 14 Aug 2003 03:56:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EAu1W6078324 for ietf-calendar-bks; Thu, 14 Aug 2003 03:56:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EAu0qt078317 for ; Thu, 14 Aug 2003 03:56:00 -0700 (PDT) (envelope-from cco@asitturnsout.org) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 94F248D7B5 for ; Thu, 14 Aug 2003 03:55:59 -0700 (PDT) From: "Chris Olds" To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? Date: Thu, 14 Aug 2003 03:55:59 -0700 Message-Id: <20030814012839.M89810@asitturnsout.org> In-Reply-To: References: <20030813224754.M95918@asitturnsout.org> X-Mailer: Open WebMail 2.10 20030617 X-OriginatingIP: 64.113.15.14 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 13 Aug 2003 17:48:10 -0700, Michael Fair wrote > Hey Chris, > > I was wondering what had become of you. :) I'm still here, I just have a job now, so I can't spend all day on iCAL/CAP :) > > The current-value model never needs more than a REFRESH request and its > > response to get back in synch. The fixed model can need an arbitrary > >(think possibly large N) number of additional messages in order to > > establish the RID:0 :: DTSTART set mapping in addition to the > > REFRESH and its response, and the Attendee CUA must retain all of > > that data. > > I'll admit that I don't exactly follow what it is you are implying > must be tracked since there is never a time where the 'fixed-id' > model needs all messages back to the SEQ:0 DTSTART. It's not that you need to see all of the intermediate messages (it took me a long time to come to that conclusion), but that you need to see all of the RECURRENCE-IDs in order to be sure you're establishing the correct mapping. > But I can assure that in the general case of a REFRESH, the > response messages of both the 'fixed-id' and 'current-value' > models should be virtually identical. Both contain the > description of the base set of instances, and both contain > follow-up objects that describe per instance differences, > and both send one, and only one message to get the recipient > fully in sync. Yes, but the message in the fixed-id model must contain a VEVENT with a RECURRENCE-ID for every instance that has been rescheduled from the original set, regardless of whether or not there was any other instance-specific data. This includes instances (for example) way in the future, that would otherwise use the default values, if a meeting was moved from Friday to Sunday. I'm not saying this is the right way to make this kind of change, but if you do, this is the implication of the fixed-id model. In the current-value model, instances w/o any other data are 'free' (gratis), since they can ride on the base definition. > Further in the 'fixed-id' model there are > fewer cases where being out of sync is even possible and > thus oftentimes the REFRESH results in a noop for the CUA. I don't believe this is true. They may be the same, but I don't see how current-value can be worse. The cases that don't require a REFRESH in the fixed-id cases shouldn't require one in the current-value model. > From the examples, section 4.4.7 talks about what a REFRESH > reponse looks like. > One sentence in particular stands out: > ... > To convey all instance-specific > changes, the "Organizer" must provide the latest event description > and the relevant instances. > ... > This is the same regardless of the model chosen. Agreed. > You are also assuming that your reschedules of the instances > merely changed the date and did not change the start time. > Once you change the start time of an instance you MUST provide > an independent instance object ot convey that info. RDATE values can include times, so I can reschedule a (n otherwise generic) instance by adding to the RDATE or building an RRULE to cover that date & time (possibly along with EXDATE/EXRULE additions too). If the location changed too, then I need to add a VENVENT to the message, with the RID set to the current (in this case, rescheduled) date and time. > However, I will grant you that in the very isolated case that > all you did was change the date, and only the date, of a > particular instance(s) and you do not wish to convey any other > per instance data (which I just find hard to believe) you are > correct. The 'current-value' model saves a few bytes on the > wire. On the flip side it take the ORGANIZER's CUA the same > or more CPU cycles to construct the new recurrence set, and > takes about the same or more number of CPU cycles on the > recipient's side. The primary distinction is that to say > "use this pattern, except this, except that" usually takes > more CPU cycles than to say "use this pattern, now update > this instance, update that instance" and in the case you > want to convey per instance info you have to say the even > more complicated "use this pattern, except this, except that, > now update this instance, update that instance". No. The base event object (the one w/o any RID) will always say "use these dates/times, these patterns, except these dates, these patterns". Any VEVENT objects included in the same message should have the same SEQ and an RID matching a date/time in the current set as defined in the base event object. > > The only advantage the > > fixed-ID camp has put forward is the ability to schedule > > multiple instances of a recurring event to the same DTSTART > > value, which doesn't really strike me as a big win. > > Granted. It was a pedantic exercise to shut up Doug's > insistence that the fixed-id model had some problem > with this. Not to mention at the end of that message > I said that I could receive those messages in any order > concocted and would still end up with the same results > which further demonstrated the robustness of the model > not just its ablility to handle silly things. Except for the detail that once all the events are folded onto the same date they become a single instance, current-value is just as able to handle ordering issues. > > The disadvantages: > > > (more complex CUA logic, > > I don't see how it's any more complex that what the CUA > already has, it already needs to look for the presence of > both UID/RID on every message, and it already has to be > prepared to reschedule a particular instance. In fact > I see the logic as being very simple. > Every object in a message refers to one and exactly one > object in the store and if it can't find that object it > creates it, if it can it updates it. > In the case of updating a recurring series it does the > same amount of bookkeeping the 'current-value' model > needs to do. I call the requirement that a CUA be able to fold a series of events together and then be able to unfold them more complex than tracking the current state of the series. Regardless of whether or not the Organizer is the only one that has to do it, it's still more complex. > > more data to persist > This is just false. > Last paragraph of section 2.1.5 expressly states that CUA's > must track the RID of property of a component. Unless you > want to redefine persist, add a missing "may", or call the > paragraph an error. In the current-value model, all I need to do is track the recurrence set; their start date/times are the RIDs. Fixed-ID requires that I be able to keep track of another recurrence set, and the mapping from that set to the current set. There is no assurance that a CUA won't end up mapping the sequences back to front (the first date in the RID sequence maps to the last date in the current sequence...the last date in the current sequence maps to the first date in the RID (SEQ:0) sequence), and while that would be a stupid thing to do, it would have to be allowed for. > > more VEVENT objects to send and recieve) > When you are dealing with differences between individual > instances the fact is there just are more objects to > pass around. See my description above about REFRESH > to see how in practice there aren't any more objects > to send and receive as the few cases where the > 'current-value' can save a few bytes are very extraordinary. I guess my problems aren't with the best case, or even the expected case. I worry about being able to write code that can deal with stupidity like I described in my previous paragraph. In the current-value model, there is no mapping to keep track of, so I _never_ have to write code to handle the mapping. If no code is needed, I don't have to worry about pathological cases or buggy code (I hate writing code with bugs, but it happens...). > In fact, if the 'fixed-id' model wanted to, it could actually > use those same semantics to get those exact same results > if the CUA bothered to be smart enough to detect them. > (The semantics being treat the reschedule of an instance > as a reschedule of the entire series.) I think you're describing what I would call a change to the recurrence set. I see that as different than a reschedule of the entire series; I would use that term to describe a reschedule of every item, not of a single one. > > Contrary to Bruce's repeated assertions, when one gets a new > > version of a VEVENT, complete with it's current recurrence > > set, there is no obligation to (nor any sense to) throw out > > the current scheduled instances for that event. > > You are assuming that all instance updates contain the entire > recurrence set. There is only one example in all of iTIP that > uses those semantics and no where in the prose that says it > is even recommended to do so. So the majority of implementations > will not include the recurrence set in an instance update. 3.2.6 REFRESH The "REFRESH" method in a "VEVENT" calendar component is used by "Attendees" of an existing event to request an updated description from the event "Organizer". The "REFRESH" method must specify the "UID" property of the event to update. A recurrence instance of an event may be requested by specifying the "RECURRENCE-ID" property corresponding to the associated event. The "Organizer" responds with the latest description and version of the event. I don't see where an Organizer is allowed to respond with less than the complete event if no RECURRENCE-ID is specified. If no RID is present, I would call a CUA that didn't send this attendee's complete view of the event broke. I would expect all implementations to send the current RRULE/RDATE/EXRULE/EXDATE values for this attendee. [[ side note: if Organizers are not expected to send different values based on the identity of the attendee, then why is ATTENDEE a required property for a REFRESH? ]] > Imagine a situation where a CUA gets every other message. > There is an instance A that gets moved 6 times. The CUA > will only see three of moves (the even ones) and it will > miss three of those moves (the odd ones). Since each > message uses an RID of the DTSTART of the message before > it, all messages will have a different RID and the CUA > will never have an object in its calendar to match the > object trying to be addressed. Therefore it will send > out three REFRESH requests. Yep. And after a single response message, it will be up to date. iTIP 4.7.2 says a CUA SHOULD send a refresh request in this case, so current-value semantics do not imply any extra messages. > No one in the 'current-value' camp has said exactly what > the 'current-value' model CUA should do in the case where > it receives a message for an instance of a recurring > series for which it can find no existing object and the > sequence value is larger than anything it has seen before. There is no need to. 4.2.7 describes that situation _exactly_. > I've held that if it follows iTIP 2.1.5 it will add it to > its calendar and as per 4.7.2 send a REFRESH request. This > means that anytime the 'current-value' misses an update, > the next instance update it sees will create a new > duplicate event. This situation is only resolvable when > the new REFRESH response shows up to say which instances > are and are not in the set. The CUA can then wipe out > all the instances that aren't in the set and be in sync > once again. Hopefully to not miss any more instance > update messages. This is why Doug objects to your interpretation of 2.1.5. The more I think about it, the more I tend to agree with him. This is a case where I certainly wouldn't want my CUA to book the time, and unless I told it I wanted to bother with messages it thought might be bogus and expected to be confirmed or denied Real Soon Now, I don't want to hear about it or see it in my calendar. > Doug, in one or two posts, implied that it will hold the > messages until it receives the messages with the proper > sequence number in it. Which will be the response to the REFRESH (or a successor to that object), and all will be right with the world. > > As far as Michael's reading of iTIP to allow versioning each > > instance of a recurrence set independently (i.e., having it's > > own SEQ value), I can find no support for it in either normative > > nor example text, and so I think we should stop talking about > > it (because it is contrary to RFC 2446 and therefore out of > > scope). > > If I am indeed misreading the text then I must be corrected. > > In section 3.7.1 Working With Recurrence Instances the first > thing it talks about is how different CUAs might or might not > support recurring events. The very first sentence of page 57 > (Second paragraph of 3.7.1) says: > > Since implementations may elect to store recurring events > as either a single event object or a collection of discreet, > related event objects, the protocol is designed so that > each recurring instance may be both referenced and versioned. > > How do you read that sentence in respect to saying that > each recurring instance can be versioned? > > In fact if we cut it down to just the important and > applicable text it says: > > The protocol is designed so that each recurring > instance may be versioned. > > > Regardless of how you interpret the "may" part, and I > can think of a few, the end result is that a CUA can > and therefore some will track independent versions > of each instance in a recurring event. This is all good stuff, and my interpretation is, I think, very close to yours. The difference comes when we ask if the versions of instances are independent of each other, and how they relate to the value of SEQ. Since the latter question is really the important one, I'll address that first. If one increases SEQ any time an instance is rescheduled, then you can talk unambiguously about the value of an instance at a particular value of SEQ. A CUA that sees all of the updates (an Organizer, or a fortunate CU's CUA) will be able to track these versions without error. There is nothing that says that a given value of SEQ for an object cannot be correlated with several instance changes, and there is nothing I can find that even implies that the SEQ value for a REQUEST with an RID is independent of the SEQ values seen for the entire event (and 4.2.7 is directly in conflict with that idea). > Or do you have an interpretation of that sentence that > doesn't allow for the existence of per instance versions? No, if you want per-instance versions, by all means go ahead. That doesn't mean that instances have SEQ values independent the base event or other instances. It's consistent with all the text you quoted to increment the per- base-event SEQ value on each instance change, or each time a set of instance changes are sent to Attendees. > You might just call it an error in the RFC. I can respect > that. I have to respect that since there is at least one > other sentence in iTIP that the 'fixed-id' model says is > an error. That's because the fixed-id model _is_ an error. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Thu Aug 14 11:32: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 LAA15296 for ; Thu, 14 Aug 2003 11:32:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFLpqt096860 for ; Thu, 14 Aug 2003 08:21:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EFLpMs096859 for ietf-calendar-bks; Thu, 14 Aug 2003 08:21:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFLnqt096853 for ; Thu, 14 Aug 2003 08:21:50 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7EFLlEB001582 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 08:21:49 -0700 Message-ID: <3F3BA905.8070409@Royer.com> Date: Thu, 14 Aug 2003 09:21:41 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@Royer.com> <3F3AF8A0.1000205@Royer.com> <3F3B1038.9050003@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060106010509050406010504" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060106010509050406010504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>>> >>>>Your assertion is above = "It doesn't break the uniqueness for a single >>>>instance...". Yet you were unable to tell the difference - both >>>>can not be true. >>> >>> >>>I don't understand this assessment. >> >>I sent a BEGIN/END VCALENDAR object and asked you what it was. >>Your guessed incorrectly. Why? Because you could NOT tell >>if it was a NEW single instance invite OR an single instance >>modification. Which is why I am still saying you are breaking >>the iTIP flow if you invite NEW attendees that way. > > > But you're missing the point. So I was right, your not talking iTIP, your talking what you want. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060106010509050406010504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDE1MjE0MVowIwYJKoZIhvcNAQkEMRYEFGhIXAgf l6nX8LyJzP/s5VLRafS0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAJVl4aKGJmJYL1QPQpp1W1iPqbbXLCuhKpSYpUFeQsAWga5YI/UL v01eZAZ3CmVFAtr5uezTrxlnZth4HyH4bglqMOutLWEfqb4LkY4GHio6ujLMd4LDgls19JY0 GLthom3efVadXUxdb9RSBmZk6GhAnqPbiUtGGEcO1Q0fqR4Gcrg2gJd3zTtn1zYs6hy4e76m RQ9zEoFjFIlBWSq8I3Tt/8CaNb1sRXmVYUfkrucuPBSQizos75E/4Pd6M3u5sENMBOS1qPIP 1fe9i74vm4sKI/R7HcTnUAbM0Izr9Njy1nsJBai31QlKPyyfOK6KTIiD986guAOIa1YbSWuN /ZUAAAAAAAA= --------------ms060106010509050406010504-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 11:40: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 LAA15555 for ; Thu, 14 Aug 2003 11:40:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFWCqt097398 for ; Thu, 14 Aug 2003 08:32:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EFWCMo097397 for ietf-calendar-bks; Thu, 14 Aug 2003 08:32:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFWBqt097392 for ; Thu, 14 Aug 2003 08:32:11 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <20030813224754.M95918@asitturnsout.org> To: "Chris Olds" Cc: ietf-calendar@imc.org Subject: RE: Is there anybody out there supporting Doug's model? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 14 Aug 2003 11:28:35 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/14/2003 11:32:05 AM, Serialize complete at 08/14/2003 11:32:05 AM Content-Type: multipart/alternative; boundary="=_alternative 0054C55385256D82_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054C55385256D82_= Content-Type: text/plain; charset="US-ASCII" Chris wrote on 08/13/2003 07:32:16 PM: > The current-value model never needs more than a REFRESH request and its > response to get back in synch. The iCalendar model does not need the REFRESH that the Dougs model does. Plus, there is no guarantee that the REFRESH will get thru or that the 'nuke' REQUEST that it triggers will get back either so the Attendee can do nothing until it does. The iCalendar model never needs the REFRESH since its unambiguious if the missequenced REQUEST is really an invitation to a new instance or a reschedule/update of an existing instance. This all should have been clear from the analysis I posted on Friday where the REQUESTS were missequenced. Even if some of the messages in the analysis were lost, the fixed model recoveres cleanly w/o any need for REFRESHing and waiting (or thrashing). > The fixed model can need an arbitrary (think > possibly large N) number of additional messages in order to establish the > RID:0 :: DTSTART set mapping in addition to the REFRESH and its response, Umm Im not sure where you got this impression. There is NO arbitrary number of messages needed, its simply done in 1 REQUEST. In addition, there is NO need for the REFRESH in the fixed model since if you follow iTIP, if the instance is NOT found on your calendar its an invitation otherwise its a reschedule/update. Only Dougs model actually needs the REFRESH because it cannot differentiate between an invitation to a new instance from a subsequent reschedule to a missed or lost earlier reschedule. The fixed RECURRENCE-ID model does not fail to uniquely identify the instance in question in the case of missequenced or lost message so it has no reliance on the REFRESH mechanism to recover and function. > and > the Attendee CUA must retain all of that data. You have to maintain the current copy anyways (X- properties aside I think) for handling delegation correctly. However you dont have to maintain the SEQUENCE:0 properties PLUS the latest SEQUENCE level properties if thats what you are thinking. The properties at SEQUENCE:10 obsolete those from SEQUENCEs 0 thru 9 and as such they are replace them. Maintaining a fixed RECURRENCE-ID per instnace is no great burden unless you code poorly since you already have to maintain the UID for each instance. > The only advantage the > fixed-ID camp has put forward is the ability to schedule multiple instances of > a recurring event to the same DTSTART value, which doesn't really strike me as > a big win. Chris, go reread my analysis from Friday. That was for a single instance and dealing with missequenced iTIP messages. It shows exactly why a fixed RECURRENCE-ID is much more beneficial than Dougs model. The ability to deal with workflow fault tolerance and recovery is a big factor in the why a fixed RECURRENCE-ID is desirable. There is no confusion like Doug has over "Is this an invitation or a reschedule?", etc. There has been no demonstrable benefit to Dougs model, especially where workflow robustness is concerned. However if I overlooked something Im sure someone can point to it. > The disadvantages (more complex CUA logic, more data to persist, more VEVENT > objects to send and recieve) seem large to me too. Where does this extra complexity come from? Maintaining both a UID AND a RECURRENCE-ID per instance?? Thats no big burden that I see. What extra data to persist? You do not have to save the SEQUENCE:0 data PLUS the current data... If you thought that, you were mistaken. What extra VEVENTs are you thinking must be saved or sent? Just each instance is all you need and you only send whats necessary. If you convolute the reading of iTIP then you need to add all kinds of extra checks and the like. If you base your design on the last line of 3.7.1 and not on the rest of iCalendar and iTIP then I cant help you except to suggest try taking another read of the analysis of both the fixed and delta models and see if you think the same. > Contrary to Bruce's repeated assertions, when one gets a new version of a > VEVENT, complete with it's current recurrence set, there is no obligation to > (nor any sense to) throw out the current scheduled instances for that event. Wrong. If the REQUEST has a RECURRENCE-ID then it wont have RRULEs/RDATEs/etc since its talking about an instance. If the REQUEST has a UID and RDATEs/RRULEs/etc then its defining a set of repeating instances. As such the recipient MUST throw away all existing instances of that UID and recreate the repeat set using whats in the REQUEST (assuming its not "obsolete"). If they do not then they have both stale/incorrect instances and the new instances and this defeats the purpose of the REQUEST. This is EXACTLY what Dougs "full REFRESH" is. Its the ONLY way for Dougs model to get both the invitee and the Organizer back in sync. So now you say that Dougs "full REFRESH" wont do what he says it will? > If the instance was previously scheduled, it can remain scheduled. Then Dougs "full REFRESH" wont achieve anything and the invitees calendar gets cluttered with 'orphaned' or 'defunct' entries now. This is even worse than before... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0054C55385256D82_= Content-Type: text/html; charset="US-ASCII"
Chris wrote on 08/13/2003 07:32:16 PM:
> The current-value model never needs more than a REFRESH request and its
> response to get back in synch.

The iCalendar model does not need the REFRESH that the Dougs model does.  Plus, there is no guarantee that the REFRESH will get thru or that the 'nuke' REQUEST that it triggers will get back either so the Attendee can do nothing until it does.  

The iCalendar model never needs the REFRESH since its unambiguious if the missequenced REQUEST is really an invitation to a new instance or a reschedule/update of an existing instance.  

This all should have been clear from the analysis I posted on Friday where the REQUESTS were missequenced.  Even if some of the messages in the analysis were lost, the fixed model recoveres cleanly w/o any need for REFRESHing and waiting (or thrashing).

>                                 The fixed model can need an arbitrary (think
> possibly large N) number of additional messages in order to establish the
> RID:0 :: DTSTART set mapping in addition to the REFRESH and its response,

Umm Im not sure where you got this impression.  There is NO arbitrary number of messages needed, its simply done in 1 REQUEST.  In addition, there is NO need for the REFRESH in the fixed model since if you follow iTIP, if the instance is NOT found on your calendar its an invitation otherwise its a reschedule/update.  

Only Dougs model actually needs the REFRESH because it cannot differentiate between an invitation to a new instance from a subsequent reschedule to a missed or lost earlier reschedule.  The fixed RECURRENCE-ID model does not fail to uniquely identify the instance in question in the case of missequenced or lost message so it has no reliance on the REFRESH mechanism to recover and function.

> and
> the Attendee CUA must retain all of that data.  

You have to maintain the current copy anyways (X- properties aside I think) for handling delegation correctly.  However you dont have to maintain the SEQUENCE:0 properties PLUS the latest SEQUENCE level properties if thats what you are thinking.  The properties at SEQUENCE:10 obsolete those from SEQUENCEs 0 thru 9 and as such they are replace them.  

Maintaining a fixed RECURRENCE-ID per instnace is no great burden unless you code poorly since you already have to maintain the UID for each instance.

>                                                 The only advantage the
> fixed-ID camp has put forward is the ability to schedule multiple instances of
> a recurring event to the same DTSTART value, which doesn't really strike me as
> a big win.

Chris, go reread my analysis from Friday.  That was for a single instance and dealing with missequenced iTIP messages.  

It shows exactly why a fixed RECURRENCE-ID is much more beneficial than Dougs model.  The ability to deal with workflow fault tolerance and recovery is a big factor in the why a fixed RECURRENCE-ID is desirable.  There is no confusion like Doug has over "Is this an invitation or a reschedule?", etc.

There has been no demonstrable benefit to Dougs model, especially where workflow robustness is concerned.  However if I overlooked something Im sure someone can point to it.

> The disadvantages (more complex CUA logic, more data to persist, more VEVENT
> objects to send and recieve) seem large to me too.
Where does this extra complexity come from?  Maintaining both a UID AND a RECURRENCE-ID per instance??  Thats no big burden that I see.  

What extra data to persist?  You do not have to save the SEQUENCE:0 data PLUS the current data...  If you thought that, you were mistaken.

What extra VEVENTs are you thinking must be saved or sent?  Just each instance is all you need and you only send whats necessary.  If you convolute the reading of iTIP then you need to add all kinds of extra checks and the like.  If you base your design on the last line of 3.7.1 and not on the rest of iCalendar and iTIP then I cant help you except to suggest try taking another read of the analysis of both the fixed and delta models and see if you think the same.

> Contrary to Bruce's repeated assertions, when one gets a new version of a
> VEVENT, complete with it's current recurrence set, there is no obligation to
> (nor any sense to) throw out the current scheduled instances for that event.

Wrong.  If the REQUEST has a RECURRENCE-ID then it wont have RRULEs/RDATEs/etc since its talking about an instance.  If the REQUEST has a UID and RDATEs/RRULEs/etc then its defining a set of repeating instances.  As such the recipient MUST throw away all existing instances of that UID and recreate the repeat set using whats in the REQUEST (assuming its not "obsolete").  If they do not then they have both stale/incorrect instances and the new instances and this defeats the purpose of the REQUEST.

This is EXACTLY what Dougs "full REFRESH" is.  Its the ONLY way for Dougs model to get both the invitee and the Organizer back in sync.  So now you say that Dougs "full REFRESH" wont do what he says it will?

> If the instance was previously scheduled, it can remain scheduled.

Then Dougs "full REFRESH" wont achieve anything and the invitees calendar gets cluttered with 'orphaned' or 'defunct' entries now.  This is even worse than before...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0054C55385256D82_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 12:43: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 MAA17684 for ; Thu, 14 Aug 2003 12:43:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGXAqt003694 for ; Thu, 14 Aug 2003 09:33:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGXAZF003693 for ietf-calendar-bks; Thu, 14 Aug 2003 09:33:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGX9qt003685 for ; Thu, 14 Aug 2003 09:33:09 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7EG7OEB001928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 09:07:26 -0700 Message-ID: <3F3BB3B7.5080308@Royer.com> Date: Thu, 14 Aug 2003 10:07:19 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030107040907080104030105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030107040907080104030105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Chris wrote on 08/13/2003 07:32:16 PM: > > The current-value model never needs more than a REFRESH request and its > > response to get back in synch. > > The iCalendar model does not need the REFRESH that the Dougs model does. > Plus, there is no guarantee that the REFRESH will get thru or that the > 'nuke' REQUEST that it triggers will get back either so the Attendee can > do nothing until it does. You keep ignoring the fact that you made the single instance invite look like an instance update. Each and every time they are going to have to do a REFRESH because they will not know which it is. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030107040907080104030105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDE2MDcxOVowIwYJKoZIhvcNAQkEMRYEFA7PHOKP z9Kwot3oK+Ec/0oH+lYPMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGZX2t7gVYg1cIGmCb2q+zCj1sLVUz0untwUvTwsteEwVH/vA+Yu 79dM2jdVe+JxnRW+KctXUsi37/2okS4+7x+VDXly1ooi9XxtqNwP7LsQqec9FfFBechJwJm1 y0jscJY7jwhdx3i8KX3Z+HgBBoFY4eJnkBr22UprCUmlOBCeqGnJnWqNmL1UKijThQ/cYGQL aDlBSY2EKy5FY86tRjg5nPK1rbVEvxj8ofXxOwWjhXoWMVpnNhQWT3mlj6BnMXx/OAppMkdD cQilRP9OBx1ZfhlG5fjcZRPLhh3NpMuzBeqbv87nOfGDak3J7QAGaEf8TpEdO2cUCqr6oOgB AM4AAAAAAAA= --------------ms030107040907080104030105-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 13:02: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 NAA18151 for ; Thu, 14 Aug 2003 13:02:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGsKqt006037 for ; Thu, 14 Aug 2003 09:54:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGsK7V006036 for ietf-calendar-bks; Thu, 14 Aug 2003 09:54:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGsKqt006031 for ; Thu, 14 Aug 2003 09:54:20 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F3BB3B7.5080308@Royer.com> To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V603_08102003NP August 10, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 14 Aug 2003 12:54:19 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/14/2003 12:54:09 PM, Serialize complete at 08/14/2003 12:54:09 PM Content-Type: multipart/alternative; boundary="=_alternative 005C776585256D82_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C776585256D82_= Content-Type: text/plain; charset="US-ASCII" No you do not understand..... ITip says we do not care... If it is not on your calendar it is an invitation. uid/rid are unique. I never have to do a refresh, I can accept the new data as is. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 08/14/2003 12:07 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: Is there anybody out there supporting Doug's model? Bruce_Kahn@notesdev.ibm.com wrote: > > Chris wrote on 08/13/2003 07:32:16 PM: > > The current-value model never needs more than a REFRESH request and its > > response to get back in synch. > > The iCalendar model does not need the REFRESH that the Dougs model does. > Plus, there is no guarantee that the REFRESH will get thru or that the > 'nuke' REQUEST that it triggers will get back either so the Attendee can > do nothing until it does. You keep ignoring the fact that you made the single instance invite look like an instance update. Each and every time they are going to have to do a REFRESH because they will not know which it is. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 005C776585256D82_= Content-Type: text/html; charset="US-ASCII"
No   you do not understand.....   ITip says we do not care... If it is not on your calendar it is an invitation.  uid/rid are unique.  I never have to do a refresh, I can accept the new data as is.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

08/14/2003 12:07 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: Is there anybody out there supporting Doug's model?







Bruce_Kahn@notesdev.ibm.com wrote:
>
> Chris wrote on 08/13/2003 07:32:16 PM:
>  > The current-value model never needs more than a REFRESH request and its
>  > response to get back in synch.
>
> The iCalendar model does not need the REFRESH that the Dougs model does.
>  Plus, there is no guarantee that the REFRESH will get thru or that the
> 'nuke' REQUEST that it triggers will get back either so the Attendee can
> do nothing until it does.  

You keep ignoring the fact that you made the single instance invite
look like an instance update. Each and every time they are going
to have to do a REFRESH because they will not know which it is.

--

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

                We Do Standards - You Need Standards
--=_alternative 005C776585256D82_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 13:26: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 NAA18865 for ; Thu, 14 Aug 2003 13:26:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHDjqt007274 for ; Thu, 14 Aug 2003 10:13:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EHDjra007273 for ietf-calendar-bks; Thu, 14 Aug 2003 10:13:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHDiqt007266 for ; Thu, 14 Aug 2003 10:13:44 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7EHDgEB002428 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 10:13:44 -0700 Message-ID: <3F3BC341.4050107@Royer.com> Date: Thu, 14 Aug 2003 11:13:37 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040207090000050406040306" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040207090000050406040306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > No you do not understand..... Then answer the question which should be easy to answer below. > ITip says we do not care... No *you* say it does not matter. No such text exists in iTIP. > If it is > not on your calendar it is an invitation. uid/rid are unique. I never > have to do a refresh, I can accept the new data as is. If that is all that is needed then answer the question: (a) Was that object I sent a new invitation? or (b) An update to an instance with a missed original? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040207090000050406040306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQxNzEzMzdaMCMGCSqGSIb3DQEJBDEWBBR9 ud1Dsfwf1wZpCWFzjNLhPRWSzTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQAbjEZGPGC5jz4x/Cbb0Wu9QpNIzrppa5dSZ4+R6Al69Ol+ ul+Kb77jMm0a9l6oSTryaGhAPA+NT1PDM1Eh2nGpg+zPkxVvjWN+p+QDjPZ6eKVbglEVbkEH bAd07LS1VsoU34Z6ZkEPWI3Cdl7mGC/Yc5rqJEFhUm19ZScUMlhVaprBjt2fwy7TlZ8rhlxU qhsezx0tOF3VXInxzA7pffm91tB76S9RteAxqIozzs0gsmrMV7gEmI27HpqJ03b+63mM+WZY R/zdrnOu9thjOy0vAqiq+sRqh4axQAxfjpGpjdXwWdyoOCYBf6f8Nc1Riu16KfRprBRyt9CU BeMgCxm6AAAAAAAA --------------ms040207090000050406040306-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 15:21:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23722 for ; Thu, 14 Aug 2003 15:21:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EIw7qt013504 for ; Thu, 14 Aug 2003 11:58:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EIw7jV013503 for ietf-calendar-bks; Thu, 14 Aug 2003 11:58:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.exchange.ximian.com (mr-nutty.ximian.com [141.154.95.31]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EIw6qt013497 for ; Thu, 14 Aug 2003 11:58:06 -0700 (PDT) (envelope-from danw@ximian.com) Subject: Re: Is there anybody out there supporting Doug's model? From: Dan Winship To: ietf-calendar@imc.org In-Reply-To: <3F3BC341.4050107@Royer.com> References: <3F3BC341.4050107@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1060887569.18067.129.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.5 Date: Thu, 14 Aug 2003 14:59:29 -0400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thu, 2003-08-14 at 13:13, Doug Royer wrote: > > No you do not understand..... > > Then answer the question which should be easy to answer below. > (a) Was that object I sent a new invitation? > or > (b) An update to an instance with a missed original? People aren't saying that the question is easy to answer, they're saying that a conforming CUA *has no reason to care* what the answer is. The icalendar workflow that would need to happen in case (a) would be *exactly* the same as the icalendar workflow that would need to happen in case (b). So why should the CUA care which case it is? You might as well ask "What color are the organizer's eyes?" It's exactly the same situation; the CUA is able to do its job 100% correctly without needing to know the answer. -- Dan From owner-ietf-calendar@mail.imc.org Thu Aug 14 15:22: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 PAA23770 for ; Thu, 14 Aug 2003 15:22:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJA3qt013829 for ; Thu, 14 Aug 2003 12:10:03 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EJA3jW013828 for ietf-calendar-bks; Thu, 14 Aug 2003 12:10:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJ9xqt013811 for ; Thu, 14 Aug 2003 12:10:00 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nNVA-0002th-00 for ; Thu, 14 Aug 2003 21:11:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nNV9-0002tZ-00 for ; Thu, 14 Aug 2003 21:11:11 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nNTz-0004Jx-00 for ; Thu, 14 Aug 2003 21:09:59 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Thu, 14 Aug 2003 12:09:58 -0700 Lines: 59 Message-ID: References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@Royer.com> <3F3AF8A0.1000205@Royer.com> <3F3B1038.9050003@Royer.com> <3F3BA905.8070409@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:3F3BA905.8070409@Royer.com... > > > Michael Fair wrote: > > >>>> > >>>>Your assertion is above = "It doesn't break the uniqueness for a single > >>>>instance...". Yet you were unable to tell the difference - both > >>>>can not be true. > >>> > >>> > >>>I don't understand this assessment. > >> > >>I sent a BEGIN/END VCALENDAR object and asked you what it was. > >>Your guessed incorrectly. Why? Because you could NOT tell > >>if it was a NEW single instance invite OR an single instance > >>modification. Which is why I am still saying you are breaking > >>the iTIP flow if you invite NEW attendees that way. > > > > > > But you're missing the point. > > So I was right, your not talking iTIP, your talking what you want. I am talking iTIP as iTIP is a protocol for distributing calendar information. You have yet to show where in iTIP it says that a CUA must be able to distinguish between a new invite and an update. Let's take the case of a singleton. If you get invited to X and the first object you see is X+1, you treat it as a new invite - you can't distinguish there, but you get the right thing on your calendar and you send an appropriate REPLY. Let's take the case of an entire recurring series. If you get invited to X and the first object you see is X+1, you treat it as a new invite - you can't distinguish there either, but you get the right thing on your calendar and you send an appropriate REPLY. You Doug can't distinguish between a new invite and an update on either of those messages yet you don't seem to assert that anything is broken with them and they are iTIP. Why should a recurring instance be any different? The bottom line is that what iTIP concerns itself with is that you get the right thing on your calendar and you send an appropriate REPLY. This is what happens and you have yet to prove otherwise. -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Aug 14 15: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 PAA23794 for ; Thu, 14 Aug 2003 15:23:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJ6Lqt013672 for ; Thu, 14 Aug 2003 12:06:21 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EJ6L4p013671 for ietf-calendar-bks; Thu, 14 Aug 2003 12:06:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJ6Kqt013666 for ; Thu, 14 Aug 2003 12:06:20 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F3BC341.4050107@Royer.com> To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V603_08102003NP August 10, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 14 Aug 2003 15:03:29 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/14/2003 03:06:25 PM, Serialize complete at 08/14/2003 03:06:25 PM Content-Type: multipart/alternative; boundary="=_alternative 00684B0485256D82_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00684B0485256D82_= Content-Type: text/plain; charset="US-ASCII" It does not matter and the receiver does not care WHAT the chair actually thinks it is. SEE ITIP sections 3.2.2.1 and 3.2.2.2 If the receiver does not have the new REQUEST on his/her calendar than it is an invitation to them no mater what it was to the chair. If the receiver does have the new REQUEST on their calendar than they check the seq number of the new REQUEST against what they have. If the new REQUEST has a higher sequence number than it is a RESCHEDULE to the receiver no mater what it was to the CHAIR. if the new REQUEST has a lower sequence number, than the receiver IGNORES the post since it is stale - IGNORE. if the new REQUEST has the same sequence number and the posted date is greater than the one they currently have than it is an UPDATE if the new REQUEST has the same sequence number but the posted date is less or equal to the one on their calendar than it is sale - IGNORE _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 08/14/2003 01:13 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: Is there anybody out there supporting Doug's model? Robert_Ransdell@notesdev.ibm.com wrote: > > No you do not understand..... Then answer the question which should be easy to answer below. > ITip says we do not care... No *you* say it does not matter. No such text exists in iTIP. > If it is > not on your calendar it is an invitation. uid/rid are unique. I never > have to do a refresh, I can accept the new data as is. If that is all that is needed then answer the question: (a) Was that object I sent a new invitation? or (b) An update to an instance with a missed original? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 00684B0485256D82_= Content-Type: text/html; charset="US-ASCII"
It does not matter and the receiver does not care WHAT the chair actually thinks it is.  SEE ITIP sections 3.2.2.1 and 3.2.2.2
If the receiver does not have the new REQUEST on his/her calendar than it is an invitation to them no mater what it was to the chair.
If the receiver does have the new REQUEST on their calendar than they check the seq number of the new REQUEST against what they have.
If the new REQUEST has a higher sequence number than it is a RESCHEDULE to the receiver no mater what it was to the CHAIR.
if the new REQUEST has a lower sequence number,  than the receiver IGNORES the post since it is stale - IGNORE.
if the new REQUEST has the same sequence number and the posted date is greater than the one they currently have than it is an UPDATE
if the new REQUEST has the same sequence number but the posted date is less or equal to the one on their calendar than it is sale - IGNORE
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

08/14/2003 01:13 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: Is there anybody out there supporting Doug's model?







Robert_Ransdell@notesdev.ibm.com wrote:
>
> No   you do not understand.....

Then answer the question which should be easy to answer below.

> ITip says we do not care...

No *you* say it does not matter. No such text exists in iTIP.

> If it is
> not on your calendar it is an invitation.  uid/rid are unique.  I never
> have to do a refresh, I can accept the new data as is.

If that is all that is needed then answer the question:

                (a) Was that object I sent a new invitation?
      or
        (b) An update to an instance with a missed original?


--

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

                We Do Standards - You Need Standards
--=_alternative 00684B0485256D82_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 15:56:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25020 for ; Thu, 14 Aug 2003 15:56:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJlNqt016580 for ; Thu, 14 Aug 2003 12:47:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EJlNSg016579 for ietf-calendar-bks; Thu, 14 Aug 2003 12:47:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJlMqt016573 for ; Thu, 14 Aug 2003 12:47:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7EJlKEB003561 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 12:47:22 -0700 Message-ID: <3F3BE741.4060305@Royer.com> Date: Thu, 14 Aug 2003 13:47:13 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? References: <3F3BC341.4050107@Royer.com> <1060887569.18067.129.camel@twelve-monkeys.boston.ximian.com> In-Reply-To: <1060887569.18067.129.camel@twelve-monkeys.boston.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030002020804090603000300" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030002020804090603000300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dan Winship wrote: > On Thu, 2003-08-14 at 13:13, Doug Royer wrote: > >>>No you do not understand..... >> >>Then answer the question which should be easy to answer below. > > >> (a) Was that object I sent a new invitation? >> or >> (b) An update to an instance with a missed original? > > > People aren't saying that the question is easy to answer, they're saying > that a conforming CUA *has no reason to care* what the answer is. That is simply incorrect for the reasons I have posted. How long to you wait before knowing you guessed incorrectly? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030002020804090603000300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQxOTQ3MTRaMCMGCSqGSIb3DQEJBDEWBBTJ GvT/xdj14j7s2ynHIie4QCavqTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQC5dIF6exd6tfSJykIGVBO6d3TuOY3u8mLxyt/vtSD49ioR invYSnsxUuXY0Rv7nkBTHdECKD/NWgZLzDDD3c3sgl9T3EY8ClOO6NsCLQC1973e7UUrsvQs QLUhfo/sobteJJlNZddLs17v47SYsicKPY03+4JrJ7cyhqu3pyVFQhuvgXISgzrMfA/PW8G8 TW8nZenkLIzvzcGCB1B9BHl/CUn006l/hE8yx4HmC1IishK2v2F8tgAP0/RedIZOCfECe6TX 4nEVanPeYIrfLmxKzry2ff+0J/lBml5qdvbtJdJaLTUiyvheLPuP66EUFOPiuwzR8PfS/+yd TwqjjV9DAAAAAAAA --------------ms030002020804090603000300-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 16:00: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 QAA25117 for ; Thu, 14 Aug 2003 16:00:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJqsqt016890 for ; Thu, 14 Aug 2003 12:52:54 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EJqspm016889 for ietf-calendar-bks; Thu, 14 Aug 2003 12:52:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJqqqt016882 for ; Thu, 14 Aug 2003 12:52:53 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7EJqmEB003600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 12:52:52 -0700 Message-ID: <3F3BE88A.9090806@Royer.com> Date: Thu, 14 Aug 2003 13:52:42 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080402080801050103000306" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080402080801050103000306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > It does not matter and the receiver does not care WHAT the chair > actually thinks it is. Yes it does, else the CUA is going to incorrectly process the data. Does it wait 1 minute before guessing, 1 hour, 1 day? And as the new SEQUENCE obsolete the old ones, once you have booked the object you will not have a clue when the now ignored old SEQUENCE arrives. At least this is going forward, at least now you guys are acknowledging that they are in fact ambiguous. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080402080801050103000306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQxOTUyNDJaMCMGCSqGSIb3DQEJBDEWBBTj 4mLgZH5wjvrLhkSjT7i6V+y4qjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQAFAF/E55flFKK8yyqcX4NTUGKcs/nZ1SQqzdlgYAFnFMAp lUEyaaFftYnM90XXl0E5CHnMYI4G1xAOwY0cMzOGeYYd2qzqw3Mr7qtfFwE8Wmly7JFMSd+3 drSQIlHu4CMOLOIzgcwFWHASTzszbvCtBf5l4LhYCsiRtpsFV/cT4kAbcjDFb6cYJVkLOkD3 aTTJlTBnPTXIEXXm4dGbbOPeJn2tQa2o4ju01Zkm6n1idgAZ47kMF47EvvS3MRUGpqMQGPyG 4wzDZLWgwrpODoqwKxULiDo+oT98+P5eAFAXJ4/yPD5RiEIHUM7SKBHSnqWNsAAOR9Uxt9Dd VS4HBy1OAAAAAAAA --------------ms080402080801050103000306-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 16:00: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 QAA25133 for ; Thu, 14 Aug 2003 16:00:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJnlqt016725 for ; Thu, 14 Aug 2003 12:49:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EJnjXJ016718 for ietf-calendar-bks; Thu, 14 Aug 2003 12:49:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJnfqt016668 for ; Thu, 14 Aug 2003 12:49:42 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7EJnZEB003573 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 12:49:42 -0700 Message-ID: <3F3BE7C9.7060103@Royer.com> Date: Thu, 14 Aug 2003 13:49:29 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Subject: Re: RECURRENCE-ID discussion References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@Royer.com> <3F3AF8A0.1000205@Royer.com> <3F3B1038.9050003@Royer.com> <3F3BA905.8070409@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030508040603080409030205" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030508040603080409030205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F3BA905.8070409@Royer.com... > >> >>Michael Fair wrote: >> >> >>>>>>Your assertion is above = "It doesn't break the uniqueness for a > > single > >>>>>>instance...". Yet you were unable to tell the difference - both >>>>>>can not be true. >>>>> >>>>> >>>>>I don't understand this assessment. >>>> >>>>I sent a BEGIN/END VCALENDAR object and asked you what it was. >>>>Your guessed incorrectly. Why? Because you could NOT tell >>>>if it was a NEW single instance invite OR an single instance >>>>modification. Which is why I am still saying you are breaking >>>>the iTIP flow if you invite NEW attendees that way. >>> >>> >>>But you're missing the point. >> >>So I was right, your not talking iTIP, your talking what you want. > > > I am talking iTIP as iTIP is a protocol for distributing > calendar information. > > You have yet to show where in iTIP it says that a CUA > must be able to distinguish between a new invite and > an update. So when *you* said ""It doesn't break the uniqueness for a..." (above) But now you are saying, it does but you do not care? So it looks to me as if you have not thought out the problem. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030508040603080409030205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQxOTQ5MzBaMCMGCSqGSIb3DQEJBDEWBBSa MXWz74KctH/G2tEksgMGQsDPEDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQAG3egJBZYzxr5BQXjT+jUadMNKZveXxqsDQT3zdtcV9JQj OhcR4N2FqUDKC5U0UhGJmjGXAzGOzETcR2Hp8vchsG/LCKqnnT/9BddI5mtALUq17SaViTXP dMi0OFpenhRuRiCVviMkeB2hZlbDdjdwgqo6Th6uwiUpOtQ6XGOxRZVdi5HEOPNkCdCFisga 0jBfb4LVAN+tZlgnS7RIajHnCKSg70jSY2WDHTnHZodJc9KVOSn6mLxjkXjp4t9qWIGS+/QW EAbkhLopGXLlpAK1H9U8szMOBc+urKIyahBmuhKM86r0kbBjWOEcK8d+7HdGBVXN1HW2Qb1c nTX1N5ItAAAAAAAA --------------ms030508040603080409030205-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 16:36: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 QAA26104 for ; Thu, 14 Aug 2003 16:36:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EKNlqt017746 for ; Thu, 14 Aug 2003 13:23:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EKNlkw017745 for ietf-calendar-bks; Thu, 14 Aug 2003 13:23:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EKNjqt017740 for ; Thu, 14 Aug 2003 13:23:46 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7EKNjEB003847 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 13:23:47 -0700 Message-ID: <3F3BEFCB.7090000@Royer.com> Date: Thu, 14 Aug 2003 14:23:39 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Uniquness of 4.4.2 Modify A Recurring Instance Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030907090308070003090808" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030907090308070003090808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It has been two days, your CUA sill misinterpreted the object that was sent in e-mail to this list. How long do you wait before sending the REFRESH? Does anyone really believe that any CUA that got that object and thought it was an initial invitation has the correct data for the CU? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030907090308070003090808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQyMDIzMzlaMCMGCSqGSIb3DQEJBDEWBBSs jFjdWZ/nho+A9kg4A5cB4LFVNTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQC23ObI7w/RduUrC2iG/zb9a+1XYL0tmL5r4Q5o6opG9zks R17lkRNhI4SqWr+BIeVAPJ6wdsuzNdxNlM2pkqzGQLK2JnQFRYIWfzwitKnrnNwi2J/+eFEE +3hi9LXuPTfZejN6LMHCAhCAlzpUd/nrti3UT4NtBiwcY9EsecIPqZ5PQRtvSQajicio2aYT pCutKY3rocuZN91wbnp1f8l9LmWd/QAyNYqOnDPRnE1v6LQwSlHEpA9lOPJqXuCGFpRQG2R/ AbKaUIJt2we/Bb7+zPxsN/amhtmVYbAzjjfeOzhLWHzVdwp62nd2zQdLcBMfAKboBodilUI3 AbLd8NYjAAAAAAAA --------------ms030907090308070003090808-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 16:40: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 QAA26213 for ; Thu, 14 Aug 2003 16:40:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EKTXqt017850 for ; Thu, 14 Aug 2003 13:29:33 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EKTXaY017849 for ietf-calendar-bks; Thu, 14 Aug 2003 13:29:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EKTWqt017842 for ; Thu, 14 Aug 2003 13:29:32 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F3BE88A.9090806@Royer.com> To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V603_08102003NP August 10, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 14 Aug 2003 16:02:24 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/14/2003 04:29:33 PM, Serialize complete at 08/14/2003 04:29:33 PM Content-Type: multipart/alternative; boundary="=_alternative 006DAFD485256D82_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006DAFD485256D82_= Content-Type: text/plain; charset="US-ASCII" RECEIVER DOES NOT HAVE TO WAIT.... THE CHAIR IS SUPPOSE TO SEND A CURRENT SNAP SHOT OF THE DATA... YOU IMMEDIATELY ACCEPT/DECLINE/DELEGATE, ETC. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 08/14/2003 03:52 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: Is there anybody out there supporting Doug's model? Robert_Ransdell@notesdev.ibm.com wrote: > > It does not matter and the receiver does not care WHAT the chair > actually thinks it is. Yes it does, else the CUA is going to incorrectly process the data. Does it wait 1 minute before guessing, 1 hour, 1 day? And as the new SEQUENCE obsolete the old ones, once you have booked the object you will not have a clue when the now ignored old SEQUENCE arrives. At least this is going forward, at least now you guys are acknowledging that they are in fact ambiguous. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 006DAFD485256D82_= Content-Type: text/html; charset="US-ASCII"
RECEIVER  DOES NOT HAVE TO WAIT.... THE CHAIR IS SUPPOSE TO SEND A CURRENT SNAP SHOT OF THE DATA... YOU IMMEDIATELY ACCEPT/DECLINE/DELEGATE, ETC.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

08/14/2003 03:52 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: Is there anybody out there supporting Doug's model?







Robert_Ransdell@notesdev.ibm.com wrote:
>
> It does not matter and the receiver does not care WHAT the chair
> actually thinks it is.

Yes it does, else the CUA is going to incorrectly process the
data. Does it wait 1 minute before guessing, 1 hour, 1 day?
And as the new SEQUENCE obsolete the old ones, once you
have booked the object you will not have a clue when
the now ignored old SEQUENCE arrives.

At least this is going forward, at least now you guys are
acknowledging that they are in fact ambiguous.

--

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

                We Do Standards - You Need Standards
--=_alternative 006DAFD485256D82_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 17: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 RAA26875 for ; Thu, 14 Aug 2003 17:03:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EKoGqt018422 for ; Thu, 14 Aug 2003 13:50:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EKoG7T018421 for ietf-calendar-bks; Thu, 14 Aug 2003 13:50:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EKoFqt018416 for ; Thu, 14 Aug 2003 13:50:15 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7EKoEEB004040 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 13:50:16 -0700 Message-ID: <3F3BF601.9030007@Royer.com> Date: Thu, 14 Aug 2003 14:50:09 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080706060607000001010203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080706060607000001010203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > RECEIVER DOES NOT HAVE TO WAIT.... THE CHAIR IS SUPPOSE TO SEND A > CURRENT SNAP SHOT OF THE DATA... YOU IMMEDIATELY > ACCEPT/DECLINE/DELEGATE, ETC. You still are ether not seeing or ignoring the issue. Because you can not tell, your CUA will NEVER know it missed the original. Your CUA is now out of SYNC with the ORGANIZER. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080706060607000001010203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQyMDUwMDlaMCMGCSqGSIb3DQEJBDEWBBQW 7076rFBUaXYSiA9MTGq9cEUR7TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQBNhYMKTgSY64gUwTHT8SSdGfzaoyLVL/Y4iIzvfPJA9oS8 Bh/hOWicHUUU0jhq8Q0kXX+f5E8non9Ohm9LdVsTw3XdMDH4r1HF0qmKlOoUUaNuq4BPZUzS /JuVi8SvepHmUGsJlwiI/tVW8R54Xix37UV3jp7+xoAKAqTsZwb3CXG8rkECfsSIKhdECYDR PQOWy1n24llBWV6w68os0+kORSP8MY7f5w1dAT40Cm81dqw/qgzsIPKsSebD5FQITiQarMJX xyzl5xqQ07nH+oz2v7xsE92iYyxQ4L1X0c/V2WGUmHQIUvqh19WUqKpeiaKIhWCRdEUKo2VR FQwlNL7BAAAAAAAA --------------ms080706060607000001010203-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 18:36: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 SAA00043 for ; Thu, 14 Aug 2003 18:36:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMM5qt021922 for ; Thu, 14 Aug 2003 15:22:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMM3bU021920 for ietf-calendar-bks; Thu, 14 Aug 2003 15:22:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMM2qt021912 for ; Thu, 14 Aug 2003 15:22:03 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F3BF601.9030007@Royer.com> To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V603_08102003NP August 10, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 14 Aug 2003 17:28:42 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/14/2003 06:21:59 PM, Serialize complete at 08/14/2003 06:21:59 PM Content-Type: multipart/alternative; boundary="=_alternative 0075966385256D82_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075966385256D82_= Content-Type: text/plain; charset="US-ASCII" No I am NOT. The chair sent me the correct UNID/RID/SEQ. The chair does not change these again unless he/she does another reschedule for that item. Therefor when I respond with the same UNDI/RID/SEQ I am in sync. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 08/14/2003 04:50 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: Is there anybody out there supporting Doug's model? Robert_Ransdell@notesdev.ibm.com wrote: > > RECEIVER DOES NOT HAVE TO WAIT.... THE CHAIR IS SUPPOSE TO SEND A > CURRENT SNAP SHOT OF THE DATA... YOU IMMEDIATELY > ACCEPT/DECLINE/DELEGATE, ETC. You still are ether not seeing or ignoring the issue. Because you can not tell, your CUA will NEVER know it missed the original. Your CUA is now out of SYNC with the ORGANIZER. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 0075966385256D82_= Content-Type: text/html; charset="US-ASCII"
No I am NOT.   The chair sent me the correct UNID/RID/SEQ.  The chair does not change these again unless he/she does another reschedule for that item.  Therefor when I respond with the same UNDI/RID/SEQ I am in sync.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

08/14/2003 04:50 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: Is there anybody out there supporting Doug's model?







Robert_Ransdell@notesdev.ibm.com wrote:
>
> RECEIVER  DOES NOT HAVE TO WAIT.... THE CHAIR IS SUPPOSE TO SEND A
> CURRENT SNAP SHOT OF THE DATA... YOU IMMEDIATELY
> ACCEPT/DECLINE/DELEGATE, ETC.

You still are ether not seeing or ignoring the issue.
Because you can not tell, your CUA will NEVER know it missed the
original. Your CUA is now out of SYNC with the ORGANIZER.

--

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

                We Do Standards - You Need Standards
--=_alternative 0075966385256D82_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 18:53: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 SAA00823 for ; Thu, 14 Aug 2003 18:53:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMgiqt022730 for ; Thu, 14 Aug 2003 15:42:44 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMgiCW022728 for ietf-calendar-bks; Thu, 14 Aug 2003 15:42:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMggqt022723 for ; Thu, 14 Aug 2003 15:42:42 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7EMgZEB004946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 15:42:44 -0700 Message-ID: <3F3C1053.9040000@Royer.com> Date: Thu, 14 Aug 2003 16:42:27 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Is there anybody out there supporting Doug's model? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020302040509090707090300" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020302040509090707090300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > No I am NOT. It has been two days, your CUA sill misinterpreted the object that was sent in e-mail to this list. How long do you wait before sending the REFRESH? Does anyone really believe that any CUA that got that object and thought it was an initial invitation has the correct data for the CU? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020302040509090707090300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQyMjQyMjdaMCMGCSqGSIb3DQEJBDEWBBTA eCqduEkqJUxsQz+dokzepFWwUTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQAxgP8ABYutt4CofB+sqWqm3DqSshYWSZekfNmGVvnNjrAK 1ssMN1oM8eIpYpz/hvCh3KGdyO1os3pAWwxJKtJwg3OTgQBDl9EgkYpatisGxPaKoCY75trK ros+JkG5XBG1XthNo18MIoAA4MiIaheqIb21p3snNurp1sjsUrYud9SkS70NjEnubE6GFt7Z toX4IXf7gCtNLnlOwLUbDEk0a5zAn3ShmzZlOBm1IbHxkgHjR9pJ5Z8qQxJpstP+JDv+882e l2A6ASZlTbcSc/M3AdO6yySadLwwv8La9F7wrCp8iOT5UwRrlYkpPcUPs2wImzSrWIuUJfVY c2W2H1vmAAAAAAAA --------------ms020302040509090707090300-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 19:22: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 TAA01449 for ; Thu, 14 Aug 2003 19:22:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EN8cqt023892 for ; Thu, 14 Aug 2003 16:08:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EN8c36023885 for ietf-calendar-bks; Thu, 14 Aug 2003 16:08:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from DrPepper (adsl-67-119-131-54.dsl.lsan03.pacbell.net [67.119.131.54]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EN8aqt023877 for ; Thu, 14 Aug 2003 16:08:36 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id AC6D78113E4; Thu, 14 Aug 2003 16:08:38 -0700 (PDT) Received: from cocacola (unknown [192.168.1.102]) by DrPepper (Postfix) with ESMTP id 158398113E1 for ; Thu, 14 Aug 2003 16:08:34 -0700 (PDT) Message-ID: <008801c362b8$fc6fdd80$6601a8c0@daclubhouse.net> From: "Michael Fair" To: References: <20030813233844.M20580@asitturnsout.org> <20030814082803.M19749@asitturnsout.org> Subject: Re: New question in regards to the fixed-id model Date: Thu, 14 Aug 2003 16:08:33 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_00_10,HTML_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > [[ NB: text with > > preceeding is me again, and Michael is > > > /cco ]] > > On Wed, 13 Aug 2003 19:06:02 -0700, Michael Fair wrote > > > > However, it's highly unlikely, though it is not impossible, > > that I would ever accept the current-value model as it > > performs so horridly in the presence of missed messages and > > iTIP on so many occasions and with good reason expects > > that messages regularly will be received out of order. > > I don't understand this statement. If a message w/o a RID is > recieved out of order, the older message is discarded when it > arrives, based on both SEQ and DTSTAMP values. You are assuming that the older message is actually stale information and not valid info dealing with a separate instance or the recurring series itself. Besides, the practice of holding REQUEST messages as you and Doug purport is actually a violation of iTIP section 3.2.2. But given that the 'current-value' model totally breaks down if we do that and I'm interested in the best performing model possible, I'm going to assume that it holds out of sequence messages for later application (if and only if still valid). Let's send four messages to arrive in reverse order: 1) fixed-id and current-value: UID:1 SEQ:0 RDATE: Jan-1 RDATE: Jan-2 RDATE: Jan-3 RDATE: Jan-4 2) fixed-id and current-value: UID:1 RID:Jan-1 SEQ:1 DTSTART:Jan-5 3) UID:1 RID:Jan-2 SEQ:1 <- fixed-id SEQ:2 <- current-value DTSTART:Jan-6 4) UID:1 RID:Jan-3 SEQ:1 <- fixed-id SEQ:3 <- current-value DTSTART:Jan-7 Receive Message 4: fixed-id - treat it as a new invite and put it on the calendar send a REPLY and REFRESH - it'd be nice if the REFRESH and the corresponding REQUEST made it through the system. current-value - send a REFRESH wait for a reply and rely on the hope that neither of the two messages get lost in transit Receive Message 3: fixed-id - treat it as a new invite and put it on the calendar send a REPLY and REFRESH - it'd be nice if the REFRESH and the corresponding REQUEST made it through the system. current-value - send a REFRESH wait for a reply and rely on the hope that neither of the two messages get lost in transit Receive Message 2: fixed-id - treat it as a new invite and put it on the calendar send a REPLY and REFRESH - it'd be nice if the REFRESH and the corresponding REQUEST made it through the system. current-value - send a REFRESH wait for a reply and rely on the hope that neither of the two messages get lost in transit So looks at the scoreboard shall we: Fixed-id: Messages Received: 3 Messages Processed: 3 Accurate Events Scheduled: 3 Current-Value: Messages Received: 3 Messages Processed: 0 Accurate Events Scheduled: 0 And finally: Receive Message 1: fixed-id - Treat it as a new invite and put it on the calendar. Add the Jan-4 instance we didn't know about. Ignore the Jan-1, Jan-2, Jan-3 dates because the calednar already has more recent information. send a REPLY for the event which implicitly applies to the Jan-4 instance but will not override the answers for Jan-5,6,7. current-value - Treat it as a new invite and put it on the calendar. Add the Jan-1,2,3,4 instances. Reprocess our holding queue applying the updates we can. Let's assume optimal implementation where each UID has it's own priority queue for holding unprocessable messages so it can just apply 2,3,4 in order and rather easily. Send a REPLY for the whole series and any additional REPLY for different status info per instance. So now let's look at the scoreboard: Fixed-id: Messages Received: 4 Messages Processed: 4 Accurate Events Scheduled: 4 Current-Value: Messages Received: 4 Messages Processed: 4 Accurate Events Scheduled: 4 So the good news is that after receiving all the messages they are both completely, accurate and totally up-to-date. The bad news is that the current-value model couldn't do a thing until it received the description of the recurring series in message 1. Had message 1 been lost current-value would have been stuck waiting for a REFRESH response to show up. I don't like models that can't process received messages because there is other data that had come before it. Let's take this example a bit further. Three more messages again received in reverse order: 1) fixed-id: UID:1 RID:Jan-1 SEQ:2 DTSTART:Jan-8 current-value: UID:1 RID:Jan-5 SEQ:4 DTSTART:Jan-8 2) fixed-id: UID:1 RID:Jan-1 SEQ:3 DTSTART:Jan-9 current-value: UID:1 RID:Jan-8 SEQ:5 DTSTART:Jan-9 3) fixed-id: UID:1 RID:Jan-1 SEQ:4 DTSTART:Jan-10 current-value: UID:1 RID:Jan-9 SEQ:6 DTSTART:Jan-10 Receive message 3: fixed-id: Update The Jan-1 instance (currently at Jan-5) to Jan-10. Send an attendence status REPLY. Since the sequence jumped more than 1 send a REFRESH - it'd be nice if the messages made it through the transport system. current-value: Stick the message on the UID priority queue, send a REFRESH, and wait for more info. Receive message 2: fixed-id: Throw it out it's old news. current-value: Stick the message on the UID priority queue, send a REFRESH, and wait for more info. So now let's look at the scoreboard: Fixed-id: Messages Received: 2 Messages Processed: 2 Accurate Events Scheduled: 2 (counting the ignore as accurate) Current-Value: Messages Received: 2 Messages Processed: 0 Accurate Events Scheduled: 0 Receive message 1: fixed-id: Throw it out it's old news. current-value: Apply SEQ:4 move Jan-1 to Jan-8 Apply SEQ:5 move Jan-8 to Jan-9 Apply SEQ:6 move Jan-9 to Jan-10 So now let's look at the scoreboard: Fixed-id: Messages Received: 3 Messages Processed: 3 Accurate Events Scheduled: 3 (counting the ignores as accurate) Current-Value: Messages Received: 3 Messages Processed: 3 Accurate Events Scheduled: 3 Please inform me if I have in some way misrepresented the 'current-value' model. Given the two examples above what becomes obvious is the current-value model's reliance on what I'm going to call a "trigger message" it's a particular message, be it the original missed message or the response to a REFRESH that allows for or obsoletes the need for processing of all other messages. This reliance on the trigger mssage is why I say the current-value model is not overly fault tolerant in the presence of missed messages. The fixed-id model can immediately always apply to the most up to date information for whatever data the message happens to contain - it can then immediately throw it out and move on. That is the real advantage to the model. > As I see it, this is as tight as one can get an still be assured > of having a sensible view of the event (yes, it is possible > to still be out of synch, but that reqires missed messages, > and I think we agree that they are unavoidable and both > models have to live with it). Yes, both absolutely must live with missed messages. No, the fixed-id model is tighter - see above. < Snip discussion regarding iTIP/iCal not being totally consistent in all areas with respect to a paragraph. [ If any things the part I snipped was really valuable please bring it back up - it looked like it was going to be an I say it's this - you say it's that - and only a decision on the underlying model will say which it was. ] However leave the following germane portion. > > > Or I can say that it uses a 'current-value' model until > > an instance is renegotiated and then as per iCal's > > UID/SEQ pair statement it is fixed until the set is > > redefined and what I end up with is exactly the > > 'fixed-id' model we've discussing. > > So close... fixed until the instance is rescheduled, > either by the set being redefined or the instance being > modifed by RID. That's again just your interpretation based on that you clearly believe 'current-value' is what iTIP describes. I happen to interpret it differently and defensibly within the context of iTIP. > Fixed-id, as promoted by Bruce, is not what you describe > here; it is fixed at SEQ:0 (or when the instance is first > added to the set, but that has even more problems). Then I should calrify to say that it's the model I've been discussing which is slightly different from Bruce's and someone around here is in error (and I'd be quicker to say me over Bruce and you and Doug over me - we'll all have our own orderings here ;) ). I happen to disagree with Bruce on that point as I read the text differently. However assuming Bruce can explain certain things to me about what happens during an entire series reschedule and figuring out how to match up which instances override which set members I'd probably accept his model as it has the fewest messages and the most accurate potential of any of the models. > > Anyway on to the real discussion. > > > > > > > > > > This however poses a problem in the case that an > > > > individual CU has been invited to that one and > > > > only instance because they would never have seen > > > > the master recurring event nor its reschedule. > > > > > > No problem at all. > > > > > > Nothing says that every Attendee must (or even should) > > > see the same event as the Organizer. > > > > Actually at least two things do. > > > > One is the definition of UID which says that it is globally unique. > > Once you do this you have just created two events with the same > > UID that describe different sets and have therefore violated > > global uniqueness of the UID. < Snip example of a birthday party that always has the same UID/SEQ/DTSTAMP for all instances (exactly one since it was a singleton) as it is totally off topic from the description) > > > Second is an implementation issue. > > Since I don't know what the answer is, I'll pose the situation > > and just ask you to tell me how the CUA's resolve it. > > > > User A and User B get invited to two separate instances 1 and 2 > > respectively. So now you have three versions of the UID, one > > for A, one for B, and the original. > > Both A and B decide the other one should have been invited to > > their respective instances and forward the event to each other. > > > > So both A and B now receive a message describing the same UID, > > the same SEQ, but different DTSTART. Assuming we did as you > > suggested they would actaully have two singleton's without > > so near a mention of a recurring instance, and the ORGANIZER > > would assume that any replies from either of them were in > > respect to the respective singleton's it sent them. > > The organizer has no need to make any assumptions. According to > 3.2.3, the organizer is free to reject party crashers. Please go through step by step about what A and B's CUAs will do when they receive their respective forwarded messages. At this point in this discussion as far as I'm concerned the ORGANIZER will have party crashers to reject because A and B's CUA will be so confused as not even know how to formulate a proper response- and if they do - the ORGANIZER won't even process it becuase it's wires are crossed as it won't even know how to match the REPLY to an event in its calendar. > Since the DTSTART/RRULE in the reply will indicate which > instances A (or B) is responding to Umm - no it won't because the ORGANIZER won't get that far. Where does it ever say that a CUA should EVER look at the DTSTART/RRULE when matching up a REPLY? Secondly, you have still yet to address how A and B even formulated a REPLY to begin with. Again just step through and describe the sequence of events to me and why iTIP says that's how the CUA should handle it. Call me stupid/ignorant/pigheaded or whatever you want. Since both you and Doug have refused to look at this issue I have to lead you to it. I tried to go through the steps using a 'current-value' model as you've described where you branch a different recurring set for each ATTENDEE. It doesn't work in the presence of CU's passing messages around behind the ORGANIZER's back which they can, will, and are absolutely allowed to do. > This is *exactly* the same process as if RIDs are used to > find the correct instances; the organizer knows who is > invited to what, and can check off acceptances against > that list. Actually it's not the same. A and B were invited to different instances (1 and 2 respectively) so when they invite each other A receives an invite to 2 and B to 1 and the CUAs are happy becuase the presence of an RID disambiguates the two events. A and B both send an accept REPLY that includes the RID to the ORGANIZER who then says "Oh 'A' would like to attend 2... Hmm - ok I'll add them" and then "Oh 'B' would like to attend 1... Hmmm - no I send them a CANCEL on RID 1". All I'm asking for is the same scenario described using your model. You'll quickly find that in every single case A and B's CUA MUST do the wrong thing if it follows section 2.1.5. > > So first, what will A and B's respective CUAs do when then > > receive the forwarded messages (for example purposes let's > > say that A was invited before B and therefore the DTSTAMP > > for B's event is greater)? > > They should be aware that the message was sent by someone other > than the organizer, so if they respond to the organizer, they > know they're trying to crash the party. But what you're not thinking of is what iTIP fragments did they receive from each other? How did they figure out it didn't come from the ORGANIZER from what was in the message? What exact iTIP message will they construct to send back to the ORGANIZER and given the instances that the ORGANIZER thinks A and B are associated with how will it interpret the new messages? And most importantly, how does someone figure that out from reading the processing rules of 2.1.5 and REPLY. > > In fact, only one example in all of iTIP even uses the > > possibility that a VEVENT might ever do this. I can't tell > > if it's a mistake (for instance look closely at the RDATE field), > > an oversight, or what. The example is even internally not > > consistent with itself as the RECURRENCE-ID used is clearly > > not one of the set defined by the RRULE/RDATE shown. > > (This is example is in 4.7.2 at the REQUEST from A) > > As noted in the text, the fact that the RECURRENCE-ID is not in the > recurrence set is an additional hint (additional to SEQ:3) that a > REFRESH is needed. The example is consistent, if you read the text. Ok, so I looked at it, and looked at it, and looked at it again, and tried to concoct some situation where that message in iTIP would be valid. Assuming there was just an extra 0 in the RDATE. The text specificly states that the RID listed is not in the set the recipient has on its calendar. It doesn't say anything about what the set was or is supposed to be... So the only example I could come up with is that it is an update to a recurring instance and a reccurence set reschedule at the same time which actually isn't possible. An RID must - given either model - be a member of the current set described by an RRULE/RDATE. I challenge you to some up with a series of events in which the RRULE/RDATE listed does not include the RID listed. The example is inconsistent with itself except for in (supposedly) Bruce's description of the fixed-id model where the RECURRENCE-ID gets described at SEQ:0 and regardless of set redefinition that instance ID is fixed until either the instance, or the whole series is cancelled. > > In the case of the individual CU invited to one individual > > instance, it's perfectly valid for them to never have seen > > the entire event set (lest we use the fragmented/branching > > UID method you described which I will only begin to consider > > after you get get over the two reasons against it above). > > Have I done that? I don't think of it as either fragmented or > branching, but just the way things are as a result of the fact > that it is _likely_ (IMHO) that *only* the Organizing CUA will > EVER have the complete picture of an event. This assumption about the CUA is patently false. CUs will forward stuff around behind the ORGANIZER's back and share info with each other which must be consistent. Again, this is EXACTLY what my forwarding around of invites to specific instances is about. Both you and Doug seem to be overlooking the fact that CUs will forward things to each other and that the messages that get forwarded in your model MUST make the recipient of those messages do the wrong thing because you have fragmented the UID. A fragmentation/branching of the UID simply means that you have more than one object with the same UID in your store. The moment you create a singleton event with the same UID as a recurring event to invite an individual CU to a particular instance you now have two distinctly separate objects identifiable by the same UID and it takes looking at who the message came from to sort out which one the message is referring which iTIP strictly tried to protect against when it declared that each UID must be globally unique (global includes even within the ORGANIZER's calendar). < Rest of text snipped as it was either covered above, didn't appear to be very germane, or came from the singleton suprise party answer that very clearly did not address the issues I was proposing. > -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Aug 14 19:40: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 TAA01855 for ; Thu, 14 Aug 2003 19:40:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENQsqt024836 for ; Thu, 14 Aug 2003 16:26:54 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ENQsLR024835 for ietf-calendar-bks; Thu, 14 Aug 2003 16:26:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENQpqt024817 for ; Thu, 14 Aug 2003 16:26:52 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nRVi-0004tZ-00 for ; Fri, 15 Aug 2003 01:28:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nRVh-0004tR-00 for ; Fri, 15 Aug 2003 01:28:01 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nRUX-000292-00 for ; Fri, 15 Aug 2003 01:26:49 +0200 From: "Michael Fair" Subject: Re: RECURRENCE-ID discussion Date: Thu, 14 Aug 2003 16:26:49 -0700 Lines: 91 Message-ID: References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@Royer.com> <3F3AF8A0.1000205@Royer.com> <3F3B1038.9050003@Royer.com> <3F3BA905.8070409@Royer.com> <3F3BE7C9.7060103@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:3F3BE7C9.7060103@Royer.com... > > > Michael Fair wrote: > > "Doug Royer" wrote in message > > news:3F3BA905.8070409@Royer.com... > > > >> > >>Michael Fair wrote: > >> > >> > >>>>>>Your assertion is above = "It doesn't break the uniqueness for a > > > > single > > > >>>>>>instance...". Yet you were unable to tell the difference - both > >>>>>>can not be true. > >>>>> > >>>>> > >>>>>I don't understand this assessment. > >>>> > >>>>I sent a BEGIN/END VCALENDAR object and asked you what it was. > >>>>Your guessed incorrectly. Why? Because you could NOT tell > >>>>if it was a NEW single instance invite OR an single instance > >>>>modification. Which is why I am still saying you are breaking > >>>>the iTIP flow if you invite NEW attendees that way. > >>> > >>> > >>>But you're missing the point. > >> > >>So I was right, your not talking iTIP, your talking what you want. > > > > > > I am talking iTIP as iTIP is a protocol for distributing > > calendar information. > > > > You have yet to show where in iTIP it says that a CUA > > must be able to distinguish between a new invite and > > an update. > > > So when *you* said ""It doesn't break the uniqueness for a..." (above) > But now you are saying, it does but you do not care? > > So it looks to me as if you have not thought out the problem. Actually I'm not saying that at all. Let's recap shall we: Michael: It doesn't break the uniqueness because there is only master _object_ in the universe and all replicas contain information about that master _object_. Doug: But you couldn't tell if the _message_ was an invite or an update. Michael: I don't care what the _message_ was - the point is to get the proper unique _object_ onto the calendar. You're missing the point about the _object and getting hung about the _message_. Doug: So I was right you're not talking iTIP. Michael: I am talking iTIP as iTIP is about passing around iCal objects and making sure the iCal objects on everybody's calendar remain up to date. Doug: So originally you said the _message_ was unique and now you're saying it isn't. Sounds like you haven't thought it through. Michael: The single instance in question is an _object_. It is passed around in a _message_ for purposes of getting the most up to date version of itself on to calendars. Section 2.1.5 describes how to treat the _message_ given whether or not the _object_ already exists on the recipient's calendar. A _message_ doesn't have to be uniquely identifiable. An _object_ must be globally uniquely identifiable. If you can't understand this, nor can you demonstrate how in any way shape or form how any of the calendar's end up with the wrong _object_ on them then I can't help you anymore. I do not have the skills to put it any more plainly and you lack the comprehension and/or discussion skills of an 8th grader. -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Aug 14 19:46: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 TAA01937 for ; Thu, 14 Aug 2003 19:46:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENYTqt025205 for ; Thu, 14 Aug 2003 16:34:29 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ENYTnG025204 for ietf-calendar-bks; Thu, 14 Aug 2003 16:34:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENYSqt025199 for ; Thu, 14 Aug 2003 16:34:28 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nRd8-0004wO-00 for ; Fri, 15 Aug 2003 01:35:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nRd7-0004wG-00 for ; Fri, 15 Aug 2003 01:35:41 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nRbx-0002H8-00 for ; Fri, 15 Aug 2003 01:34:29 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Thu, 14 Aug 2003 16:34:28 -0700 Lines: 43 Message-ID: References: <3F3BEFCB.7090000@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:3F3BEFCB.7090000@Royer.com... > > It has been two days, your CUA sill misinterpreted the > object that was sent in e-mail to this list. > > How long do you wait before sending the REFRESH? > > Does anyone really believe that any CUA that got > that object and thought it was an initial invitation > has the correct data for the CU? You know Doug, you are really an ungenerous troll. You can't take a few moments to try and explain the issues you are pointing out and then say we are ignoring them when we can't figure them out. I _think_, based on what I know of your logic skills thus far and your propensity for ignoring posts, that I know what you are trying to say is a problem. Let me see if I got this straight. You believe that using our model: The recipient receives: UID:1 RID:1 SEQ:3 Puts it on its calendar as a new invite. and then the CUA receives: UID:1 SEQ:0 and per 2.1.5 throws it away. Is this right? -- Michael -- From owner-ietf-calendar@mail.imc.org Thu Aug 14 20:04: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 UAA02269 for ; Thu, 14 Aug 2003 20:04:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENr0qt025947 for ; Thu, 14 Aug 2003 16:53:00 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ENr0Po025946 for ietf-calendar-bks; Thu, 14 Aug 2003 16:53:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENqxqt025941 for ; Thu, 14 Aug 2003 16:52:59 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7ENqwEB005429 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 16:53:00 -0700 Message-ID: <3F3C20D5.5080600@Royer.com> Date: Thu, 14 Aug 2003 17:52:53 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RECURRENCE-ID discussion References: <3F398EF8.4030904@Royer.com> <3F3A612E.20005@Royer.com> <3F3AA1DE.6090403@Royer.com> <3F3AF8A0.1000205@Royer.com> <3F3B1038.9050003@Royer.com> <3F3BA905.8070409@Royer.com> <3F3BE7C9.7060103@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090801090800070804010206" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090801090800070804010206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > >> >>So it looks to me as if you have not thought out the problem. > > > Actually I'm not saying that at all. You are: > Let's recap shall we: > Michael: It doesn't break the uniqueness because there is only > master _object_ in the universe and all replicas contain > information about that master _object_. If you can not tell the difference, it is ambiguous. Both can not be true. Ether you knew what it was by looking at it, or you can not. am.big.u.ous \am-'big-y*-w*s\ aj [L ambiguus, fr. ambigere to wander about, fr. ambi- + age]re to drive - more at AGENT 1: doubtful or uncertain esp. from obscurity or indistinctness; also : INEXPLICABLE 2: capable of being understood in two or more possible senses : EQUIVOCAL - am.big.u.ous.ly av You could not tell - it is ambiguous. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090801090800070804010206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQyMzUyNTNaMCMGCSqGSIb3DQEJBDEWBBTw Se7lfQdd5MQBK9/8fQfDerDa0TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQA7WQZUUBYjkgkk2eJXL5dIzkOrEh6QZ33LXFMAevTI6U2S BygR1kO0JwC7F0aU/X7ggowJchTFGYcKGeUGzSTe1o85F896rrDtk7K/KdQEYXupzV8jvm75 16tiEvvXSjWheB1pwk5n3qmNLLu7EmVGn3HBbQHMkDD6B1PLUC+9gXAqzIhFjw+HAdnV+g8A 3hD3+7zIijAH1v0PtkDsfcW2xF4xnl26eg08cgATDjZh23bnYhMgcDV9DvihcGqAsquwtX9Q XFDlk0x272+ydvkVOqmyI8PqkuQxbn5oivGv9QJ5hJRl+1v6oUR35DEmWEm2tq7mU6aEXj0d C9WQTvYQAAAAAAAA --------------ms090801090800070804010206-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 20:09: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 UAA02360 for ; Thu, 14 Aug 2003 20:09:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENvPqt026116 for ; Thu, 14 Aug 2003 16:57:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ENvP4B026115 for ietf-calendar-bks; Thu, 14 Aug 2003 16:57:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENvOqt026109 for ; Thu, 14 Aug 2003 16:57:24 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7ENvOEB005466 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 16:57:25 -0700 Message-ID: <3F3C21DE.3050601@Royer.com> Date: Thu, 14 Aug 2003 17:57:18 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F3BEFCB.7090000@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000909050908040808090800" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000909050908040808090800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F3BEFCB.7090000@Royer.com... > >>It has been two days, your CUA sill misinterpreted the >>object that was sent in e-mail to this list. >> >>How long do you wait before sending the REFRESH? >> >>Does anyone really believe that any CUA that got >>that object and thought it was an initial invitation >>has the correct data for the CU? > > > You know Doug, you are really an ungenerous troll. You send out email that says section 4 of iTIP is 'nothing' and you expect me to just take your word for it that you know that section 4 is 'nothing'. Your logic is busted and you can not figure it out or you are too stubborn to admit it. Your declare that it is unambiguous - then when I prove it is, your declare that it does not matter. When I show that it matters, you declare it is unambiguous. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000909050908040808090800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQyMzU3MThaMCMGCSqGSIb3DQEJBDEWBBSU PhRKMNCnj1uXPxpaHe+N9fem1TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQBeoUXBW8UL+UYVvb7HO4YBaLin8H+ZicEr6FZFQEPhSfJ0 8RZzTocIvOscs23PbpPigfVE0Kr1jHWGVLRspXTGi/noU0B8D1L0ByK2cf/qpebE3gfKznZZ nJTcrRJEeRHleHDScGjYFXei0Pb/yhkpDVJapPXKXhv0VGIc1KKjgnSBfrTxTScFZ3c0LjDh t1rMxilX5ySOJHEGrQYf3uvN7JEvbdyfDcjJ7/eYBOkgxfyld1arzmtZ2Rn1bQIeYA70ne7O 5JebUsHJFflXdq7oSG2jpC1jHdN7LXZEKek9axM40OjLe3B2Bd3F48vtSlHuVbfinD1dW6vP PVfRQphgAAAAAAAA --------------ms000909050908040808090800-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 20:26: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 UAA02555 for ; Thu, 14 Aug 2003 20:26:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F0DKqt026794 for ; Thu, 14 Aug 2003 17:13:20 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F0DJNc026793 for ietf-calendar-bks; Thu, 14 Aug 2003 17:13:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F0DIqt026784 for ; Thu, 14 Aug 2003 17:13:18 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7F0DIEB005571 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Aug 2003 17:13:20 -0700 Message-ID: <3F3C2598.7080808@Royer.com> Date: Thu, 14 Aug 2003 18:13:12 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F3BEFCB.7090000@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080907060104040507060408" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080907060104040507060408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > You believe that using our model: I really do not care about your model. I am talking iTIP. > The recipient receives: > UID:1 > RID:1 > SEQ:3 > > Puts it on its calendar as a new invite. > > and then the CUA receives: > UID:1 > SEQ:0 You still missing the point. 1) What if that packet is lost - as I said in the email? "...oops it got mis mailed.." or something like that. OR What if that sequence:0 arrive AFTER an instance in SEQUENCE:0? Per iTIP your CUA could tell so it could then do a REFRESH. Now as the objects look EXACTLY like each other - some want it to be an invite. No you busted iTIP. 2) The CUA will NEVER know it if SEQUENCE:0 is lost and you act on SEQUNCE:1 as if it were an invite. 3) It used to be able to tell that it should of had SEQUENCE:0, now you can not because Bruce has proposed that a modification to an instance update looks *exactly* like a invite. The CUA can not tell because the invite looks EXACTLY like an update to an existing instance. Your CUA is out of sync and your iMIP CUA/CU will never know. > and per 2.1.5 throws it away. And yes, after you book SEQUENCE:N then per iTIP all objects with a SEQUENCE less than N are obsolete. So you booked SEQUENCE:1 because Bruce wants it to be an invite. Then you get SEQUNCE:0 that is by definition older and obsolete. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080907060104040507060408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTUwMDEzMTJaMCMGCSqGSIb3DQEJBDEWBBTp U4ufpF7bdXWJ5XFOSX2IbEaNhjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQC5F08IObB2EAxPZi9fgPggiZjxdgoX86710FNY0RLQHD+b 1RtPY4k331tyzUuuW8VubGPev0CbpUB8b4pLWZKUdmTl0GyecBmbvgJpe++O4brbl5ax16ry F+PMVL01GXtPYd+KaoJcO8H9gsk05el/t6o6HwbA1Eb+tc1hJEJOeQ2mrhjw5o9DrKMyPK6z yFoOHBxg4Yraa1vR+BE8cY1VmP0SoeuaiWbUWeA24uJJzOf95XKtfGKLBtsxs+0Zjmqj57Bs S/jY6hELYSItwGcE7jUnrkFz6lfz28v2reA9lv66zVRANo6uSmWIOtnTJI6uWE8fID7KVbvT 3LQv78mrAAAAAAAA --------------ms080907060104040507060408-- From owner-ietf-calendar@mail.imc.org Thu Aug 14 21:42:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04042 for ; Thu, 14 Aug 2003 21:42:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F1EXqt029047 for ; Thu, 14 Aug 2003 18:14:33 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F1EXho029046 for ietf-calendar-bks; Thu, 14 Aug 2003 18:14:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F1EPqt029038 for ; Thu, 14 Aug 2003 18:14:31 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nTBr-00019Z-00 for ; Fri, 15 Aug 2003 03:15:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nTBq-00019R-00 for ; Fri, 15 Aug 2003 03:15:38 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nTAg-0004Qx-00 for ; Fri, 15 Aug 2003 03:14:26 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Thu, 14 Aug 2003 18:14:26 -0700 Lines: 191 Message-ID: References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@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: Yay!!! Finally something that we can actually respond to (yet again). Since I'm too lazy to go digging through the archives to figure in which 4 or 5 posts I explained this I'll just do it again, and given the intensity I expect that you will read it all the way through. "Doug Royer" wrote in message news:3F3C2598.7080808@Royer.com... > > > Michael Fair wrote: > > > You believe that using our model: > > I really do not care about your model. I am talking iTIP. Fair enough. So am I. Let's proceed. > > The recipient receives: > > UID:1 > > RID:1 > > SEQ:3 > > > > Puts it on its calendar as a new invite. > > > > and then the CUA receives: > > UID:1 > > SEQ:0 > > You still missing the point. > > 1) What if that packet is lost - as I said in the email? > "...oops it got mis mailed.." or something like that. At the moment the CUA receives the first message, it notices that the object is keyed off the UID/RID. It knows this because of the presence of the RID. It first looks up the UID/RID pair to see if the SEQ of that object matches that of the existing UID/RID. As part of that search, when it can't find the specific object it's looking for, it also looks up the UID only object to see if the RID listed is a member of the current set of valid recurrences. This is the same in both models. Since it was also unable to find the object using the UID only it notices that something is fishy and sends a REFRESH request for the UID only object because it should, not because it needs the contents of that response to process the message. It asks the CU if they want to attend the instance and then sends the appropriate REPLY. It will then receive the second message (response to the REFRESH request) which contains the UID only (RID:NULL in my terminology) along with the UID/RID instance specific update and try to do a lookup on the UID only object. It will not find UID:1/RID:NULL and therefore will treat it as a new request. It will look for any existing instances of the UID that are not contained in the set described by the object to remove them. Since both objects are at SEQ:0 then the RID of the instance that the CUA already has will be in the set. It will find that instance when it does that lookup, it will compare the SEQUENCE values and see they are the same and then it will compare the DTSTAMP fields. It will notice that the DTSTAMP field is greater than the instance's DTSTAMP and know that it needs to update the instance. It being a smart CUA, will look through the rest of the response to see if there is any per instance object associated with the instance it needs to update in the message. It will find that object in the message and check the SEQ/DTSTAMP against that of the UID only object. It will find the DTSTAMP of the instance only object in the message is the same or greater and in either case it will choose the instance specific version or the UID only version to use for the updated of the object on its calendar. If it weren't a smart CUA it would first update the object on its calendar to be that as the UID only object described (again DTSTAMP is greater) and then update it again when it finishes processing the message as it comes across the instance specific version with the same or greater DTSTAMP. In the end it will have sent the REFRESH, received the response, and correctly applied all objects to the calendar. The Doug model of redefining the recurrence set won't help you reduce the amount of processing because you updated something about the instance to cause the SEQ:0 update to happen in the first place. Since you will want to keep whatever data that was, you will have to include a per instance object in the REFRESH response message. If you had reshceudled the instance, which is the only change that sometimes might result in less processing, then you would have had to increase the SEQUENCE value of the instance and therefore the instance would not have been at SEQUENCE 0. > What if that sequence:0 arrive AFTER an instance in > SEQUENCE:0? Per iTIP your CUA could tell so it could > then do a REFRESH. Now as the objects look EXACTLY > like each other - some want it to be an invite. No > you busted iTIP. Since they are about two distinct objects there will be no confusion. It will process the instance at SEQ:0 as above which will trigger a REFRESH. It will then receive the second message which contains the UID only (RID:NULL in my terminology) and try to do a lookup. It will proceed pretty much as above when the above received the REFRESH response except this time it won't update the instance at all because the DTSTAMP will be older than above. It then may or may not receive the response to the REFRESH. Assuming it does, it will repeat the above and update all the objects since the DTSTAMP field of the response is more recent than what's on the calendar. > 2) The CUA will NEVER know it if SEQUENCE:0 is lost and > you act on SEQUNCE:1 as if it were an invite. Sure it does, as I described above it notices that it has received an invite to an object with an RID for a recurring event which it has no prior knowledge of. It can't verify whether or not the RID is valid and thereby sends a REFRESH because that is what it should do as per 6.7.2. > 3) It used to be able to tell that it should of had SEQUENCE:0, > now you can not because Bruce has proposed that a modification > to an instance update looks *exactly* like a invite. You're repating this point again. So just ditto from above. It knows to send a REFRESH. > > and per 2.1.5 throws it away. > > And yes, after you book SEQUENCE:N then per iTIP > all objects with a SEQUENCE less than N are obsolete. > > So you booked SEQUENCE:1 because Bruce wants it to be > an invite. Then you get SEQUNCE:0 that is by definition > older and obsolete. If they were referring to the same objects (which they aren't) you'd be right. By your definition the 'current-value' model is then in serious trouble because it can't move if any instance update is ever missequenced because it needs to reset based on the REFRESH response. I mean let's think about an update to four separate instances SEQ:1,2,3,4 respectively and then say that because of some mishap SEQ:4 arrived first. It has to queue it and wait for a REFRESH that may never come. Then it receives SEQ:3, again queue and wait. Then it receives SEQ:2, again queue and wait. And things get really bad if SEQ:1 just got lost. Your model cannot continue until it receives a REQUEST that is either exactly at SEQ:1 or includes the entire set for the series (response to a REFRESH). -- Michael -- From owner-ietf-calendar@mail.imc.org Fri Aug 15 10:35: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 KAA29332 for ; Fri, 15 Aug 2003 10:35:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FEL7qt097455 for ; Fri, 15 Aug 2003 07:21:07 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FEL7iq097454 for ietf-calendar-bks; Fri, 15 Aug 2003 07:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FEL6qt097449 for ; Fri, 15 Aug 2003 07:21:06 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7FEKBEB011270 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 15 Aug 2003 07:20:13 -0700 Message-ID: <3F3CEC16.6010405@Royer.com> Date: Fri, 15 Aug 2003 08:20:06 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040102060508030705090007" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040102060508030705090007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: >>1) What if that packet is lost - as I said in the email? >> "...oops it got mis mailed.." or something like that. > > > At the moment the CUA receives the first message, it notices > that the object is keyed off the UID/RID. It knows this > because of the presence of the RID. > > It first looks up the UID/RID pair to see if the SEQ > of that object matches that of the existing UID/RID. > > As part of that search, when it can't find the specific > object it's looking for, it also looks up the UID only > object to see if the RID listed is a member of the > current set of valid recurrences. This is the same > in both models. > > Since it was also unable to find the object using the UID only > it notices that something is fishy and sends a REFRESH request > for the UID only object because it should, not because it needs > the contents of that response to process the message. Noting is fishy at all, the object I sent 3 days ago was a copy/paste straight for iTIP. I made up nothing. Is all the CUA had to do was implement iTIP straight from the text. Now Bruces proposal to invite someone forces a valid object to be ambiguous. With Bruces proposal 100% of the time an invitation to a single instance causes (5) round trip packets to be sent (so it does not look 'fishy' as you call it). And an update to a single instance causes (5) round trip packets to be sent (because it is exactly the same 'fishy' packet). What is the justification for this when (1) set would have worked? If you implement iTIP as written, exactly (1) set will be needed to update a single instance. If you implement iTIP as written, exactly (1) set will be needed to invite an ATTENDEE. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040102060508030705090007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTUxNDIwMDZaMCMGCSqGSIb3DQEJBDEWBBSy Dg8gDs/toI/bveHjqdIalOrYozBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQBLUO7svoPtbfgqW5M4NoVhPuQesQtg9/6IN/pU9SistsDu 5JOlMBH1SF6NttTTudG68pTA9XofkBKacdQya/132+BS8wIxKKjcMmnce0GFoW2n3qsaPWkH dPlRY4k3x6v08e4keMpDfO0kmOfQ4hsRmLLYRd8bIsz8WEKt5FZdE9MlAzhlbhJXIQD45+HX EPblfLl7LuY7wWscn+WeajVcrElWfWiFrL1uTVaw5vTtrX9sn6Ql1hyQW5JsraRlRnao6UIk ychbm78NDSkYPp3bx9uNj8OqJXeVI8GRj1+6RaWKfeFtc6TeDtZJ8NJz+A7xRSx9UA/WD7re vPQgJnroAAAAAAAA --------------ms040102060508030705090007-- From owner-ietf-calendar@mail.imc.org Fri Aug 15 15:33: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 PAA10730 for ; Fri, 15 Aug 2003 15:33:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FJIVqt016894 for ; Fri, 15 Aug 2003 12:18:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FJIVkp016893 for ietf-calendar-bks; Fri, 15 Aug 2003 12:18:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FJISqt016886 for ; Fri, 15 Aug 2003 12:18:29 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nk6u-00081V-00 for ; Fri, 15 Aug 2003 21:19:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nk6t-00081N-00 for ; Fri, 15 Aug 2003 21:19:39 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nk5l-00038R-00 for ; Fri, 15 Aug 2003 21:18:29 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Fri, 15 Aug 2003 12:18:28 -0700 Lines: 15 Message-ID: References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@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: Ok Doug, since you haven't answered the question yet, I'm going to ask it again. I send out a recurring event series, I then sent out an instance modification. What does your CUA do if the instance gets there first? If my guess is right - it sends a REFRESH and then holds it. Is that right? -- Michael -- From owner-ietf-calendar@mail.imc.org Fri Aug 15 16:24: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 QAA12174 for ; Fri, 15 Aug 2003 16:24:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FKCHqt018723 for ; Fri, 15 Aug 2003 13:12:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FKCHFh018722 for ietf-calendar-bks; Fri, 15 Aug 2003 13:12:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FKCEqt018713 for ; Fri, 15 Aug 2003 13:12:15 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nkww-0008Om-00 for ; Fri, 15 Aug 2003 22:13:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nkwu-0008Oe-00 for ; Fri, 15 Aug 2003 22:13:24 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nkvm-0004Pa-00 for ; Fri, 15 Aug 2003 22:12:14 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Fri, 15 Aug 2003 13:12:14 -0700 Lines: 168 Message-ID: References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@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:3F3CEC16.6010405@Royer.com... > > > Michael Fair wrote: > > >>1) What if that packet is lost - as I said in the email? > >> "...oops it got mis mailed.." or something like that. > > > > > > At the moment the CUA receives the first message, it notices > > that the object is keyed off the UID/RID. It knows this > > because of the presence of the RID. > > > > It first looks up the UID/RID pair to see if the SEQ > > of that object matches that of the existing UID/RID. > > > > As part of that search, when it can't find the specific > > object it's looking for, it also looks up the UID only > > object to see if the RID listed is a member of the > > current set of valid recurrences. This is the same > > in both models. > > > > Since it was also unable to find the object using the UID only > > it notices that something is fishy and sends a REFRESH request > > for the UID only object because it should, not because it needs > > the contents of that response to process the message. > > Noting is fishy at all, the object I sent 3 days ago was a > copy/paste straight for iTIP. I made up nothing. > Is all the CUA had to do was implement iTIP straight > from the text. Something is totally fishy. The CUA has just received a new reccuring event instance for which it has no set description. Thereby triggering a REFRESH. In fact every reference to a recurring instance in iTIP blatantly assumes that the reipient already has a copy of the recurring series on its calendar. I challenge you to find one example or one scrap of prose that ever talks about receiving a message that refers to an instance when the recipient CUA does not yet have a copy of the recurring series on its calendar. Every example has at least one line before the example that talks about what the recipient already has on its calendar. We have proven that this is not a valid assumption, yet the text never addresses it. Show me I'm wrong by citing something from iTIP that doesn't have an explicit piece of text saying that the recipient CUA already has some version of the event on its calendar. Further, we are not talking about a case where the CUA has a copy of the recurring series on its calendar. We are talking about either a new invite or a missed message. In iTIPs model, contrary to everything in your proposals, it wants the instance update it receives to be both processable, and refer to a globally unique object. Both your models of development, the 'current-value', and per-set-UID, break each (respectively). Now, if as I have proposed in a separate thread, the ORGANIZER sends a description of the recurrence set (RRULE/RDATA/etc) as part of the message to an individual invite then there would be no ambiguity at all because it would be able to verify that the RID specified is indeed in the recurrence set. However without that info, the CUA should send a REFRESH. > Now Bruces proposal to invite someone forces a valid object to > be ambiguous. With Bruces proposal 100% of the time an invitation > to a single instance causes (5) round trip packets to be sent (so > it does not look 'fishy' as you call it). And an update to a single > instance causes (5) round trip packets to be sent (because it is > exactly the same 'fishy' packet). What is the justification for this > when (1) set would have worked? Because the (1) set that you have proposed cannot be forwarded or delegated to any CU that is part of a different set of instances. However, the (1) set that I have proposed (which is an addition to iTIP to include an extra MUST for this particular case) which says to include both a recurrence set description and the RID they are invited to is also totally unambiguous and instantly verifiable. No REFRESH would be needed. Additionaly, it doesn't cause 5 round trips. The first round trip of receiving the instance message and its reply doesn't count as every model has to do at least that. (Well except for those models that can't even process it and are stuck waiting for more info) The second round trip where it receives the whole set and its reply is also ignored because it either didn't happen or all models have to do it as well. The third round trip is the REFRESH and REQUEST response that got triggered by the inital instance message. Your per-set-UID model does manage to avoid this particular round trip, but it breaks forwarding and delegation to other CUs that have a different UID-set. My recommendation to include the complete recurrence set description as part of the invite message also avoids this round trip, but my suggestion does not break when CUs forward or delegate to anyone as my objects are still unique. That's it. There are three potential round trips consisting of 4 to 6 messages (4 using my suggestion or your broken suggestion, 5 if you can't process the initial instance message AND your REPLY is the same as the parent UID, otherwise it is 6 regardless of the model chosen). If we say the ORGANIZER's CUA MUST include the recurrence set description in the message along with the RID when we are inviting a CU to an instance as I've suggested, then the REFRESH becomes unnecassary, but as it stands now iTIP makes no such demand so it cannot be relied on. > If you implement iTIP as written, exactly (1) set will be > needed to update a single instance. In the presence of missed messages there will be at least three sets (as described above) regardless of the model chosen (unless it's broken, or not in iTIP). If all messages are received in order, then there is always exactly 1 message to update an instance. > If you implement iTIP as written, exactly (1) set will be > needed to invite an ATTENDEE. I'm assuming that you are saying that iTIP "exactly as written" somehow justifies splintering the UID for the various invite sets of different CUs. This is broken when CUs are allowed to pass events around for purposes of FORWARDing and DELEGATing. (If it's not broken neither you nor Chris have proven otherwise.) In your suggested model they can't forward, and they can't delegate unamibiguously in all cases, and therefore the model you have proposed is not iTIP and is bankrupt. If you are inviting an end user to a single instance of a recurring series and we are not applying my suggestion that we include the recurrence set for purposes of verification of the RID then there is exactly 2 sets, and no problems when the CUs forward or delegate the messages around. The conversation for a single instance invite goes something like: (Round trip one) S: "You're invited to an instance in a recurring series." C: "Great, here's my REPLY." (Round trip two) C: "Are you sure it's only one instance, I can't verify the RID. Did I miss something?" S: "Nope." -- Michael -- From owner-ietf-calendar@mail.imc.org Fri Aug 15 17:10: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 RAA14009 for ; Fri, 15 Aug 2003 17:10:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FKxQqt020262 for ; Fri, 15 Aug 2003 13:59:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FKxQdq020261 for ietf-calendar-bks; Fri, 15 Aug 2003 13:59:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FKxOqt020255 for ; Fri, 15 Aug 2003 13:59:24 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7FKxJS5014305 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 15 Aug 2003 13:59:25 -0700 Message-ID: <3F3D49A2.6000908@Royer.com> Date: Fri, 15 Aug 2003 14:59:14 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000508080609020306060301" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000508080609020306060301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F3CEC16.6010405@Royer.com... > >> >>Michael Fair wrote: >> >> >>>>1) What if that packet is lost - as I said in the email? >>>> "...oops it got mis mailed.." or something like that. >>> >>> >>>At the moment the CUA receives the first message, it notices >>>that the object is keyed off the UID/RID. It knows this >>>because of the presence of the RID. >>> >>>It first looks up the UID/RID pair to see if the SEQ >>>of that object matches that of the existing UID/RID. >>> >>>As part of that search, when it can't find the specific >>>object it's looking for, it also looks up the UID only >>>object to see if the RID listed is a member of the >>>current set of valid recurrences. This is the same >>>in both models. >>> >>>Since it was also unable to find the object using the UID only >>>it notices that something is fishy and sends a REFRESH request >>>for the UID only object because it should, not because it needs >>>the contents of that response to process the message. >> >>Noting is fishy at all, the object I sent 3 days ago was a >>copy/paste straight for iTIP. I made up nothing. >>Is all the CUA had to do was implement iTIP straight >>from the text. > > > Something is totally fishy. > The CUA has just received a new reccuring event instance for > which it has no set description. Thereby triggering a REFRESH. Correct - and that is all that it should mean. The only thing fishy is forcing the CUA to do a REFRESH to find out if it is an invitation or an update is what is fishy. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000508080609020306060301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNTIwNTkxNFowIwYJKoZIhvcNAQkEMRYEFOutFZLB CVYjgkEhMH5v2Q2nFMAbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBALa1CQzKtTSgK/dsV/j1+EDTxAvZFUjcVModvaRdVcrKlK74o0TK xc3WGPFF/1azjww6tFn0yDLPLg9kjh0KTkAJny0iN4Nf07MNM1UgT10taGjxAWF02Zh4X2O2 HdYF7hDRqiK+hAaEtAa9i1Yy27EX0cOHk6F6dREaJLGzXkBBh40YhdXZ7DHBVtZtqSHte+Fp 8ElLwiXKUtoGRGyIONIQOLna5/0KH+l8yTcBQPwxrOKOz1I5evm9GtV04ijajdhqEDNrTuzL AMjaXHKinOjkBRfJ0jp/Xi8kj4Oipty4/YnGIv0Akk4Oh5gYU+2wcdzlST2Q7IMrtaQyEkky 47sAAAAAAAA= --------------ms000508080609020306060301-- From owner-ietf-calendar@mail.imc.org Fri Aug 15 17:56: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 RAA15144 for ; Fri, 15 Aug 2003 17:56:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FLjEqt022220 for ; Fri, 15 Aug 2003 14:45:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FLjEE6022218 for ietf-calendar-bks; Fri, 15 Aug 2003 14:45:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FLjCqt022212 for ; Fri, 15 Aug 2003 14:45:13 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7FLj8S5014621 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 15 Aug 2003 14:45:09 -0700 Message-ID: <3F3D545D.9050202@Royer.com> Date: Fri, 15 Aug 2003 15:45:01 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070407030103050405040403" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070407030103050405040403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > Ok Doug, > > since you haven't answered the question yet, I'm going > to ask it again. > > I send out a recurring event series, I then sent out an > instance modification. What does your CUA do if the > instance gets there first? [I assume you meant the modification gets there before the initial invitation?] Quickly looking through my code it looks as if this is what I do (+/- a step or two): What I do with unknown an UID that arrives in (iTIP 4.4.2) instance modifications: (I) ORGANIZER is mailto url OR object arrived via iMIP: (I.a) Inform the user and then ask the user: (I.a.1) Request full copy? If selected - send full REFRESH via iMIP and toss the update object. (I.a.2) Toss it (you have waited xx-times [after refresh sent])? If selected - Toss the object. (I.a.3) Wait for the initial invitation to arrive? If selected - Hold it. (II) ORGANIZER is CAP url and ATTENDEE has CAP access to ORGANIZER csid and object came from ATTENDEEs CAP unprocessed queue. (II.a) Do query on ORGANIZER csid and get the object. (II.b) If ATTENDEE had permission and the query returned empty: Assume that the ORGANIZER *may* be in the process of depositing the objects and wait a few minutes and retry (II.a) once. Then if the initial invitation does not arrive and it is not on the ORGANIZERS csid, go to (II.d). (II.c) If ATTENDEE did NOT have permission to query ORGANIZER csid go to (II.d). (II.d) Deposit full REFRESH in ORGANIZER csid. (II.e) If ATTENDEE did not have permission for (II.d), go to (III.a) (III) ORGANIZER is CAP url and ATTENDEE does NOT have CAP access to ORGANIZER csid and object came from ATTENDEEs CAP unprocessed queue. (III.a) ATTENDEE has ORGANIZER iMIP address via other means: Go to (I.a) (III.b) Does NOT have the ORGANIZER iMIP address: Toss it as there is no way to inform ORGANIZER. > If my guess is right - it sends a REFRESH and then holds it. > Is that right? No point in holding it most of the time as you can do a full (not instance) REFRESH. So instance modifications that arrive before the initial invitation get tossed unless the user wants to wait. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070407030103050405040403 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNTIxNDUwMVowIwYJKoZIhvcNAQkEMRYEFAAyYUsJ 4gPVCxpcv32v+PyAi0VSMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAH9oXIq6LqFjaxzTeMy0UFplYTcKyE19T85FoJIdcQRwtliHSzRG Y5y0XrNE9dOda9vj0kpTtfd+Z7MFhg554V9aeSuZvhNaeCUiYqOGZTWl+5DLxKCCnH9ZxipC Dje1+y7N0VvD5rGAETrtF6kl8n17Nhyx/UIPZ1kOiw7BbEpMaZx1AizVvLtZ9qzblt5OHbV5 Bl2Nycn07iNP5pZcG/3Sw5TZ4ihjk/egigyEfgyKqf9J6a15Y21LnGJn25O4Nc/xeYY3fqWU jW0K1WhMNKrVo8FJP37H5MZhcp91VdcwkXWTQecV4YcRG+u4pTngcoewz8ALXIc7wTqBlJhN RRQAAAAAAAA= --------------ms070407030103050405040403-- From owner-ietf-calendar@mail.imc.org Fri Aug 15 18:47: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 SAA17037 for ; Fri, 15 Aug 2003 18:47:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FMZlqt023765 for ; Fri, 15 Aug 2003 15:35:49 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FMZll1023764 for ietf-calendar-bks; Fri, 15 Aug 2003 15:35:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FMZiqt023758 for ; Fri, 15 Aug 2003 15:35:45 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nnBo-00016Y-00 for ; Sat, 16 Aug 2003 00:36:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nnBn-00016Q-00 for ; Sat, 16 Aug 2003 00:36:55 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nnAf-0007jr-00 for ; Sat, 16 Aug 2003 00:35:45 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Fri, 15 Aug 2003 15:35:44 -0700 Lines: 96 Message-ID: References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@Royer.com> <3F3D49A2.6000908@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: The CUA should put the instance it received on the calendar. It should not have to wait for a "trigger message" before making that message processable. Putting it on the calendar as the latest version of an event that it has seen is a very iTIP thing to do. Throwing away or not acting upon good information isn't. It is also specifically in violation of 3.2.2 which explicitly says that it should be treated as a new request. Since you should put it on the calendar AND you should send a REFRESH there is little harm done. Further I've proposed a solution to the need to send a refresh and that is to always include the recurrence set description along with the RID when inviting an individual CU. This would unambiguously identify the message as a verifiable invite to that particular instance. This proposal is totally consistent with all of iTIP, save the new MUST when dealing with this case, and it doesn't break any of the CUs abilities. Contrary to your model which breaks a CUs ability to forward the invite to another CU or delegate to another CU if that CU is aware of a different set of instances. My recommendation is questionable based on whether or not it is desirable. Your recommendation must be thrown out as it is ill-conceived with respect to CUs forwarding information around to each other. -- Michael -- "Doug Royer" wrote in message news:3F3D49A2.6000908@Royer.com... > > > Michael Fair wrote: > > "Doug Royer" wrote in message > > news:3F3CEC16.6010405@Royer.com... > > > >> > >>Michael Fair wrote: > >> > >> > >>>>1) What if that packet is lost - as I said in the email? > >>>> "...oops it got mis mailed.." or something like that. > >>> > >>> > >>>At the moment the CUA receives the first message, it notices > >>>that the object is keyed off the UID/RID. It knows this > >>>because of the presence of the RID. > >>> > >>>It first looks up the UID/RID pair to see if the SEQ > >>>of that object matches that of the existing UID/RID. > >>> > >>>As part of that search, when it can't find the specific > >>>object it's looking for, it also looks up the UID only > >>>object to see if the RID listed is a member of the > >>>current set of valid recurrences. This is the same > >>>in both models. > >>> > >>>Since it was also unable to find the object using the UID only > >>>it notices that something is fishy and sends a REFRESH request > >>>for the UID only object because it should, not because it needs > >>>the contents of that response to process the message. > >> > >>Noting is fishy at all, the object I sent 3 days ago was a > >>copy/paste straight for iTIP. I made up nothing. > >>Is all the CUA had to do was implement iTIP straight > >>from the text. > > > > > > Something is totally fishy. > > The CUA has just received a new reccuring event instance for > > which it has no set description. Thereby triggering a REFRESH. > > Correct - and that is all that it should mean. The only thing > fishy is forcing the CUA to do a REFRESH to find out if > it is an invitation or an update is what is fishy. > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Fri Aug 15 19:36:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17856 for ; Fri, 15 Aug 2003 19:35:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNOjqt025499 for ; Fri, 15 Aug 2003 16:24:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FNOjo4025498 for ietf-calendar-bks; Fri, 15 Aug 2003 16:24:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNOhqt025492 for ; Fri, 15 Aug 2003 16:24:43 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nnxD-0001PZ-00 for ; Sat, 16 Aug 2003 01:25:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nnxC-0001PP-00 for ; Sat, 16 Aug 2003 01:25:54 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nnw4-0000HA-00 for ; Sat, 16 Aug 2003 01:24:44 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Fri, 15 Aug 2003 16:24:43 -0700 Lines: 200 Message-ID: References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@Royer.com> <3F3D545D.9050202@Royer.com> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since it's fairly obvious that we are at a stand still and could argue this back and forth till we're blue in the face with this conversation I am going to appeal to the others on the list to chime in with a vote. I say that it against the spirit of iTIP to hold or throw away any event update message. I say this because iTIP agressively tries to do as much as it can with each message received since it considers the communication channel unreliable and to rely on a "trigger message" to reeastablish workflow is not what the authors seemed to have in mind. I believe that the authors intended every message to be processable and, assuming it was a more recent message, to immediately update the calendar to the degree that the message allows for. I've proposed what I consider a simpler solution to Doug's "ambiguity problem", which while I consider the superfluous REFRESH cycle acceptable overhead, solves Doug's ambiguity problem and doesn't break the CUs ability to FORWARD or DELEGATE like Doug's model does. Whether or not you consider the extra REFRESH a severe detraction, Doug's model is just broken and is not an acceptable solution lest we declare that people can't invite or delegate other CUs when dealing with a recurring event which I find even more unacceptable. I'll give Doug this, under iTIP as written, there is the possibility of a superfluous REFRESH cycle. Why Doug has decided this is a problem I can't tell because the his model is totally broken without them. Given iTIP with one additional clause that says something like: "When inviting a CU to a particular instance of an event the ORGANIZER's CUA MUST include the recurrence descriptors and the RECURRENCE-ID the CU is invited to so that the reipient can validate the RECURRENCE-ID. For all other instance modifications the ORGANIZER's CUA SHOULD not include the reccurence descriptors." We get a totally identifiable set of messages and eliminate any potential confusion about which RIDs are in and not in the set. This is useful when a CU is invited to one or more instances where the RID in question has changed. Since it doesn't have the base event to work off of (since it wasn't invited to that event) it can use the recurrence set to validate the existing instances it has on its calendar. Both Doug's proposal and mine rely on things that are not currently in iTIP. I have an implied must and he has to know who the message came from (which is error prone when CUs can pass the events around, and not even gauranteed over certain communication channels). Not implementing my proposal just means there's an extra REFRESH cycle. Not implementing Doug's proposal means you can't ever invite a CU just to a single instance and you must invite them to the whole event. Further, Doug seems to think that iTIP believes the communication channel is mostly reliable, and that it, for the most part, is not an issue to throw away a message. He must assume that the REFRESH request and its corresponding REQUEST response will always make it through the channel. I think we can all agree that iTIP considers the channel unreliable and that it's totally possible for a REFRESH or its REPONSE to just disappear. I'm fairly certain that no one on this list, save Doug and Chris believe this is the preferred behavior. Chris Olds, as the other proponent of Doug's model, have you solved the CU forwarding and delegation problem? Do you find the 'toss it away or hold it' model is the desirable of the two knowing that there is a model which can perform better then that? Is there anyone else on the list aside from myself, Doug, Bruce, Satya, and Chris who has an opinion one way or the other? Without a vote, or a voice, there will be nothing in the archives to say what the outcome of the WG's consensus was. I'm not aware of any WG dispute resolution procedures... Doug has every right to continue to push his model in this forum until a clear majority has spoken for/against it. As for me, it's pretty obvious that Doug's model has two very undesirable side effects. The first being the inability to apply the most recent information about instances when it arrives out of order, and the second he breaks the CUs ability to delegate and forward messages to CUs who are aware of a different set. -- Michael -- "Doug Royer" wrote in message news:3F3D545D.9050202@Royer.com... > > > Michael Fair wrote: > > Ok Doug, > > > > since you haven't answered the question yet, I'm going > > to ask it again. > > > > I send out a recurring event series, I then sent out an > > instance modification. What does your CUA do if the > > instance gets there first? > > [I assume you meant the modification gets there before the > initial invitation?] > > Quickly looking through my code it looks as if this is > what I do (+/- a step or two): > > What I do with unknown an UID that arrives in (iTIP 4.4.2) > instance modifications: > > (I) ORGANIZER is mailto url OR object arrived via iMIP: > > (I.a) Inform the user and then ask the user: > > (I.a.1) Request full copy? > > If selected - send full REFRESH via iMIP > and toss the update object. > > (I.a.2) Toss it (you have waited xx-times [after refresh sent])? > > If selected - Toss the object. > > (I.a.3) Wait for the initial invitation to arrive? > > If selected - Hold it. > > (II) ORGANIZER is CAP url and ATTENDEE has CAP access to ORGANIZER csid > and object came from ATTENDEEs CAP unprocessed queue. > > (II.a) Do query on ORGANIZER csid and get the object. > > (II.b) If ATTENDEE had permission and the query returned empty: > > Assume that the ORGANIZER *may* be in the process of > depositing the objects and wait a few minutes and retry > (II.a) once. Then if the initial invitation does not arrive > and it is not on the ORGANIZERS csid, go to (II.d). > > (II.c) If ATTENDEE did NOT have permission to query ORGANIZER csid > go to (II.d). > > (II.d) Deposit full REFRESH in ORGANIZER csid. > > (II.e) If ATTENDEE did not have permission for (II.d), go to (III.a) > > (III) ORGANIZER is CAP url and ATTENDEE does NOT have CAP access to > ORGANIZER csid and object came from ATTENDEEs CAP unprocessed queue. > > (III.a) ATTENDEE has ORGANIZER iMIP address via other means: > Go to (I.a) > > (III.b) Does NOT have the ORGANIZER iMIP address: > Toss it as there is no way to inform ORGANIZER. > > > If my guess is right - it sends a REFRESH and then holds it. > > Is that right? > > No point in holding it most of the time as you can do a full > (not instance) REFRESH. So instance modifications that arrive > before the initial invitation get tossed unless the user > wants to wait. > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Fri Aug 15 20:02: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 UAA18400 for ; Fri, 15 Aug 2003 20:02:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNpCqt026599 for ; Fri, 15 Aug 2003 16:51:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FNpCad026598 for ietf-calendar-bks; Fri, 15 Aug 2003 16:51:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNpAqt026592 for ; Fri, 15 Aug 2003 16:51:11 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7FNpAS5015539 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 15 Aug 2003 16:51:12 -0700 Message-ID: <3F3D71E9.6000101@Royer.com> Date: Fri, 15 Aug 2003 17:51:05 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@Royer.com> <3F3D49A2.6000908@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060407070308030803040202" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060407070308030803040202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > My recommendation is questionable based on whether or > not it is desirable. Your recommendation must be thrown > out as it is ill-conceived with respect to CUs forwarding > information around to each other. You know your are ether stupid or a trouble maker that feels they have to insult everyone one this WG list and the authors of iCAL and iTIP who if you read the archives disagree with you. These topics WERE covered on this WG list. Do you really think that this WG has passed iTIP just to annoy you? Do you really think that everyone can not do iTIP and you have the solution? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060407070308030803040202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNTIzNTEwNVowIwYJKoZIhvcNAQkEMRYEFE/t+pJR SEYSFQx5aKZXciPkv9g3MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGjIscLAq+GXhrAGx+gNzlsNOmnjKGxNs9pEQdZD8PQPjHR00IF+ j8UcNorG05Is6FX7EFihBWS0Qc/s8xdkUteuwyX8Zdan27aN5UmLsFRgl/6V2qAGKjd1CpWz B+x01L1vQEXou0IqxUHNIasEnku3dzCoBB4krjMN5xXDeQ/MOGnmQFHV5LNSkeEH05/jScKH U365fnK0Lz/pfpLhMfdRSDiQ7XR+W3OnH8G+lYp1gebZ3g05tlt68P/IPFuruecQLrB0mP2q iqgGrBc9CaowlIv9qal2NAegjRNjb7RzMNFVzNjh+lFfTvi5GzM6ZUcBxWXHh7Sdkv/rws5I Sw0AAAAAAAA= --------------ms060407070308030803040202-- From owner-ietf-calendar@mail.imc.org Fri Aug 15 20:02: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 UAA18416 for ; Fri, 15 Aug 2003 20:02:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNqqqt026649 for ; Fri, 15 Aug 2003 16:52:52 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FNqqrS026648 for ietf-calendar-bks; Fri, 15 Aug 2003 16:52:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNqoqt026641 for ; Fri, 15 Aug 2003 16:52:50 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7FNqoS5015545 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 15 Aug 2003 16:52:52 -0700 Message-ID: <3F3D724D.7000906@Royer.com> Date: Fri, 15 Aug 2003 17:52:45 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@Royer.com> <3F3D545D.9050202@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030907000302020904090205" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030907000302020904090205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > Since it's fairly obvious that we are at a stand still > and could argue this back and forth till we're blue in > the face with this conversation I am going to appeal to > the others on the list to chime in with a vote. > There is NO vote - there is NO proposal, there has been NO draft submitted. And even if there was a draft, the IETF does NOT vote. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030907000302020904090205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNTIzNTI0NVowIwYJKoZIhvcNAQkEMRYEFC1dOtYg vzrQ2gMEzV2p1Hj3XfRUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAHhj9NSXhli5UlnoYKUC5ty/ST9DWg/WA9NkM0XERJcZ7Q2c3TcQ ex42aTWXqqyK0NqNc8t6wnI+o8gLUqngY9t7MAx08EalG8dTn+yp+seg6nwlZ5XuxcvxQPWz xaY20FbMGiaVO3X9y3bwvr+fHxwZsDYk3yQGFPjF1ncC9yFtGFwfBXOKyBDeLxrkfC2OgmUS /vMJWVxG7IsiOlxnU8WoF/Iy+3JVokFVCX4fUkQbxM5hd9KJS7b12A8nAvVDNfPiZzbcJTSe T/ZLt7RInau/b3kOrA6dh73WY45XamHkcjsyc0qvlUk6YY52yrZHQsL9kbUVxBFVLVKyPIMy WCsAAAAAAAA= --------------ms030907000302020904090205-- From owner-ietf-calendar@mail.imc.org Fri Aug 15 22:33: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 WAA20848 for ; Fri, 15 Aug 2003 22:33:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G2OFqt034399 for ; Fri, 15 Aug 2003 19:24:15 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7G2OFen034398 for ietf-calendar-bks; Fri, 15 Aug 2003 19:24:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G2ODqt034382 for ; Fri, 15 Aug 2003 19:24:13 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7G2OAD7013007; Fri, 15 Aug 2003 19:24:10 -0700 (PDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7G2OAhD009522; Fri, 15 Aug 2003 19:24:10 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJO00728XCAPR@ha13sca-mail1.sfbay.sun.com>; Fri, 15 Aug 2003 19:24:10 -0700 (PDT) Date: Fri, 15 Aug 2003 19:24:12 -0700 From: Satya Vempati Subject: RE: Uniquness of 4.4.2 Modify A Recurring Instance To: Michael Fair , "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT From my point of view, this discussion is academic. Since all major implementations use the fixed recurrence model, anyone who wants to interoperate with the likes of Exchange, Notes etc. will need to use the fixed recurrence-id model. Will you implement systems that work with 95% of the market or the other 5% (even if it is right)? It is like designing chairs for people with their knees in the back. At this stage it is clear (at least to me) that we need to rewrite iTip to be unambiguously in sync with most of its implementations. Any other approach defies common sense. Doug seems to be going by the letter of iTip rather than the spirit, and in that sense he may be right. But we should find a way to move forward given the fact that the majority of implementations are against his model. Does anyone know how to take this forward and resolve a contentious issue such as this one? What is the normal IETF process? -----Original Message----- From: Michael Fair [mailto:michael@daclubhouse.net] Sent: Friday, August 15, 2003 4:25 PM To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Since it's fairly obvious that we are at a stand still and could argue this back and forth till we're blue in the face with this conversation I am going to appeal to the others on the list to chime in with a vote. I say that it against the spirit of iTIP to hold or throw away any event update message. I say this because iTIP agressively tries to do as much as it can with each message received since it considers the communication channel unreliable and to rely on a "trigger message" to reeastablish workflow is not what the authors seemed to have in mind. I believe that the authors intended every message to be processable and, assuming it was a more recent message, to immediately update the calendar to the degree that the message allows for. I've proposed what I consider a simpler solution to Doug's "ambiguity problem", which while I consider the superfluous REFRESH cycle acceptable overhead, solves Doug's ambiguity problem and doesn't break the CUs ability to FORWARD or DELEGATE like Doug's model does. Whether or not you consider the extra REFRESH a severe detraction, Doug's model is just broken and is not an acceptable solution lest we declare that people can't invite or delegate other CUs when dealing with a recurring event which I find even more unacceptable. I'll give Doug this, under iTIP as written, there is the possibility of a superfluous REFRESH cycle. Why Doug has decided this is a problem I can't tell because the his model is totally broken without them. Given iTIP with one additional clause that says something like: "When inviting a CU to a particular instance of an event the ORGANIZER's CUA MUST include the recurrence descriptors and the RECURRENCE-ID the CU is invited to so that the reipient can validate the RECURRENCE-ID. For all other instance modifications the ORGANIZER's CUA SHOULD not include the reccurence descriptors." We get a totally identifiable set of messages and eliminate any potential confusion about which RIDs are in and not in the set. This is useful when a CU is invited to one or more instances where the RID in question has changed. Since it doesn't have the base event to work off of (since it wasn't invited to that event) it can use the recurrence set to validate the existing instances it has on its calendar. Both Doug's proposal and mine rely on things that are not currently in iTIP. I have an implied must and he has to know who the message came from (which is error prone when CUs can pass the events around, and not even gauranteed over certain communication channels). Not implementing my proposal just means there's an extra REFRESH cycle. Not implementing Doug's proposal means you can't ever invite a CU just to a single instance and you must invite them to the whole event. Further, Doug seems to think that iTIP believes the communication channel is mostly reliable, and that it, for the most part, is not an issue to throw away a message. He must assume that the REFRESH request and its corresponding REQUEST response will always make it through the channel. I think we can all agree that iTIP considers the channel unreliable and that it's totally possible for a REFRESH or its REPONSE to just disappear. I'm fairly certain that no one on this list, save Doug and Chris believe this is the preferred behavior. Chris Olds, as the other proponent of Doug's model, have you solved the CU forwarding and delegation problem? Do you find the 'toss it away or hold it' model is the desirable of the two knowing that there is a model which can perform better then that? Is there anyone else on the list aside from myself, Doug, Bruce, Satya, and Chris who has an opinion one way or the other? Without a vote, or a voice, there will be nothing in the archives to say what the outcome of the WG's consensus was. I'm not aware of any WG dispute resolution procedures... Doug has every right to continue to push his model in this forum until a clear majority has spoken for/against it. As for me, it's pretty obvious that Doug's model has two very undesirable side effects. The first being the inability to apply the most recent information about instances when it arrives out of order, and the second he breaks the CUs ability to delegate and forward messages to CUs who are aware of a different set. -- Michael -- "Doug Royer" wrote in message news:3F3D545D.9050202@Royer.com... > > > Michael Fair wrote: > > Ok Doug, > > > > since you haven't answered the question yet, I'm going > > to ask it again. > > > > I send out a recurring event series, I then sent out an > > instance modification. What does your CUA do if the > > instance gets there first? > > [I assume you meant the modification gets there before the > initial invitation?] > > Quickly looking through my code it looks as if this is > what I do (+/- a step or two): > > What I do with unknown an UID that arrives in (iTIP 4.4.2) > instance modifications: > > (I) ORGANIZER is mailto url OR object arrived via iMIP: > > (I.a) Inform the user and then ask the user: > > (I.a.1) Request full copy? > > If selected - send full REFRESH via iMIP > and toss the update object. > > (I.a.2) Toss it (you have waited xx-times [after refresh sent])? > > If selected - Toss the object. > > (I.a.3) Wait for the initial invitation to arrive? > > If selected - Hold it. > > (II) ORGANIZER is CAP url and ATTENDEE has CAP access to ORGANIZER csid > and object came from ATTENDEEs CAP unprocessed queue. > > (II.a) Do query on ORGANIZER csid and get the object. > > (II.b) If ATTENDEE had permission and the query returned empty: > > Assume that the ORGANIZER *may* be in the process of > depositing the objects and wait a few minutes and retry > (II.a) once. Then if the initial invitation does not arrive > and it is not on the ORGANIZERS csid, go to (II.d). > > (II.c) If ATTENDEE did NOT have permission to query ORGANIZER csid > go to (II.d). > > (II.d) Deposit full REFRESH in ORGANIZER csid. > > (II.e) If ATTENDEE did not have permission for (II.d), go to (III.a) > > (III) ORGANIZER is CAP url and ATTENDEE does NOT have CAP access to > ORGANIZER csid and object came from ATTENDEEs CAP unprocessed queue. > > (III.a) ATTENDEE has ORGANIZER iMIP address via other means: > Go to (I.a) > > (III.b) Does NOT have the ORGANIZER iMIP address: > Toss it as there is no way to inform ORGANIZER. > > > If my guess is right - it sends a REFRESH and then holds it. > > Is that right? > > No point in holding it most of the time as you can do a full > (not instance) REFRESH. So instance modifications that arrive > before the initial invitation get tossed unless the user > wants to wait. > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Sat Aug 16 06:12:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08603 for ; Sat, 16 Aug 2003 06:12:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GA1Lqt079395 for ; Sat, 16 Aug 2003 03:01:21 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7GA1LGH079394 for ietf-calendar-bks; Sat, 16 Aug 2003 03:01:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GA1Eqt079378 for ; Sat, 16 Aug 2003 03:01:19 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nxt2-00082s-00 for ; Sat, 16 Aug 2003 12:02:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19nxt1-00082k-00 for ; Sat, 16 Aug 2003 12:02:15 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19nxru-0002CW-00 for ; Sat, 16 Aug 2003 12:01:06 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Sat, 16 Aug 2003 03:01:02 -0700 Lines: 194 Message-ID: References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@Royer.com> <3F3D49A2.6000908@Royer.com> <3F3D71E9.6000101@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:3F3D71E9.6000101@Royer.com... > > > Michael Fair wrote: > > > > My recommendation is questionable based on whether or > > not it is desirable. Your recommendation must be thrown > > out as it is ill-conceived with respect to CUs forwarding > > information around to each other. > > You know your are ether stupid or a trouble maker that > feels they have to insult everyone one this WG list Perhaps I am, I don't believe either of those about myself, either way, it doesn't fix your model. The comment remains as posted until proven otherwise. I tried to make your model work - I even invented really smart CUAs - the messages are still unprocessable and highly ambiguous. You haven't provided a description otherwise even after I expressly requested it from you three times. I don't think you're stupid, you just didn't work it out beforehand to account for all the possibilities. You just omitted the part where CUs could forward things around without the ORGANIZER. This is very apparent because you think the ORGANIZER is always the dispensor of information about the given event. It's not, and as a result, your invite model is broke. > and the authors of iCAL and iTIP who if you read the archives > disagree with you. These topics WERE covered on this WG list. I have some issues with the authors and editors that we ended up in this conversation to begin with, but I think they took on an extraordinary task and managed to trail blaze an incredible foundation which is extremely elegant. I actually have a great respect for them. But how you and Bruce can end up on such opposite sides of this issue - seeing that both your names are listed in the contributors section just furthers the evidence that not everybody was on the same page when the draft was last called. Bruce makes very sound arguments which you have thus far not refuted. I similarly brought up some arguments (which Bruce probably already pointed out as well) which you also, thus far, have not refuted. Considering the complexity of the problem, I find it very reasonable for them to have not caught every nuance of dealing with recurring instances. In fact looking through the archives Bruce on several occasions brought up problems that were simply ignored oftentimes relating to this very issue. Plus, I have been searching the archives in hopes that I might find a solution since you so vehemently defend your position and since you have decided to be extraordinarily difficult in gifting the requested information in terms of what the CUAs will do in the situations described and I have yet to find anything. I have yet to find any hard core decision in regards to this particular issue, for which the issues we are discussing now were clearly distinguished. The July 2003 thread is the first thread to detail out the problems with the shifting reccurence-id. For the most part I've seen lots of posts confirming that the text is just plain inconsistent in areas. In my search: I saw the July 1999 thread that Bruce refers to where the general statement was that a response to a REFRESH would most likely contain multiple components. First would be the base at SEQUNCE N, and then would be the instance revs at SEQUNCE >N. That thread didn't account for updates in which the SEQUENCE doesn't rev as it was only discussing updates which did rev the SEQUENCE. I saw where you and Frank got into the entire reccurence set is a single object discussion and all share the same SEQUENCE value back in Feb 2000. This was counter to what was discussed in July 1999 (just 8 months before). Seems people weren't exactly sure what the answer on that one was supposed to be. There was no thread I found between July and Feb that could account for this "flip". The implications of such an action were never addressed until much later where you said handle the attendees smartly during this latest July 2003 thread. But you never answered Robert's declaration that there's a problem with this model becaues you'd be forced to ignore any REPLY's that came in because they were for an old SEQUENCE number. (You had revved the SEQUENCE internally and not told anyone quietly updating their attendance status based on whatever value you happend to have prior). I tried to handle them smartly, but unless I constantly tracked what changed between the SEQUENCE they had and the SEQUENCE I currently have to determine if sufficient information was the same I'd have to send them a new copy of the whole event to get them to the right SEQUENCE number before I could accept any REPLY they sent. This just can't be acceptable. I agree with Robert (Tom) that it's easier just to cancel their event without revving the SEQUENCE number to remove them as an ATTENDEE for an event. I found the thread where you and Bruce talked about needing to change Delegation text in Feb 2002 and you brought up per ATTENDEE objects as the (2) for how ORGANIZER's solve problems like this, but the background of that conversation was that the same primary key info was present and that you weren't changing any workflow defining properties. Here you're saying spin a unique version with different workflow properties just for that attendee and that's where my problem lies because that object can and will get passed around. I found where you originally got into this argument with Graham and it finished without much resolution. I found where Bruce attempted to explain to you the advantages of the fixed-id model which you either can't grasp or are unwilling to consider. I see lots of history with no real thoughtful discussion of the issues we are covering now. I actually see no interop discussions where the fixed-id or current-value models were declared king. I take issue with one and only one part of your invitation model. Two CUs invited to different subsets of the same recurring series will always incorrectly process a forward or delegation. I have posted the scenario at least three times, I have posted what iTIP says the CUAs will do, and I have requested that you prove otherwise. I haven't found it in RFC 2446, I haven't found it in the archives (doesn't mean it's not there - I know - but I've invested a few hours into it), and I haven't seen you post it here. Chris tried to respond to my post thinking I was asserting he couldn't change values based on the ATTENDEE - I'm not saying this at all. I'm saying change whatever you want except for UID/RID/SEQUENCE/reccurence set descriptors because once you start messing with those CUAs will get confused when the CUs pass the info around without going through the original ORGANIZER. Until otherwise addressed, your model is broke. As for the current-value model in general I take issue with the fact that it cannot process messages in the presence of missed messages. However I do not agree that Bruce's fixed at event creation model is the right solution howver I can probably be convinced. > Do you really think that this WG has passed iTIP just > to annoy you? Do you really think that everyone can > not do iTIP and you have the solution? Nope. I don't believe any of the above. I believe that Bruce for a long time now has been the most vocal on issues concerning reccuring events and workflow with them and it seems has largely been ignored (he has a lot of posts requesting feedback that never shows up). I believe that the current-value model is against the spirit of iTIP, and as Satya points out, is actually mute given the existing major vendors doing it the fixed-id way. I believe that the proposals I've presented were in response to what you claim were flaws in the fixed-id model and cinch it up enough as to be workable. It has fewer sensitivities than the 'current-value' model and can handle event reschedules such that none of the prior recurrence-ids are in the new set, without suggesting a new UID should be provided, and it can unambiguously identify the distinction between an invite to a particular instance against a missed message regarding the entire series which you made such a huge issue out of (despite it was only a single superfluous REFRESH which you always require). I believe lots of people can implement iTIP, but none before last month have really sat down and hammered on this whole recurrence-id, instance invite, forward and delegate instances issue and I say that as someone who has spent several hours reading the archives clear back to the end of 1998. -- Michael -- From owner-ietf-calendar@mail.imc.org Sun Aug 17 12:39: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 MAA16108 for ; Sun, 17 Aug 2003 12:39:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HGW3qt022122 for ; Sun, 17 Aug 2003 09:32:03 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7HGW3b4022121 for ietf-calendar-bks; Sun, 17 Aug 2003 09:32:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HGW2qt022116 for ; Sun, 17 Aug 2003 09:32:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7HGW1S5019747 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 17 Aug 2003 09:32:02 -0700 Message-ID: <3F3FADFB.2050102@Royer.com> Date: Sun, 17 Aug 2003 10:31:55 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020500080304010304020301" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020500080304010304020301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: >>From my point of view, this discussion is academic. Since all major > implementations use the fixed recurrence model, anyone who wants to > interoperate with the likes of Exchange, Notes etc. will need to use the > fixed recurrence-id model. Will you implement systems that work with 95% > of the market or the other 5% (even if it is right)? The nice thing about the model in iTIP - it works with both. Thas has been one of my points over and over. The only thing that causes confusion is Brurce's propisal that inviting someone and making it look like an instance modificaiton. That independently breaks both models. The assertion that Exchange does not work with the iTIP model is bogus. I have no idea why anone thinks that - I can not get it to fail using the iTIP model. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020500080304010304020301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNzE2MzE1NVowIwYJKoZIhvcNAQkEMRYEFEMcI3su HcndmclowFj4xKg6Wp/kMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAHEhbCqBrJG786R/XxkCr+J6/JTBitkQ7vjExe3/42awUZJhn7CC KbgoCuy1GnAzov/pCphJg+k+iSUEBKFqq9yhNpJ7Gd4y1APSXkgRLeImaLn5OkEYZT4HvDFy JkNNoTWIH5TPUB4myCg9ppBGk2GokFcdYw96PEDWsF4IFOG+ZXZl36h5U9nyyNMLVw9NcSXh Q/YN9QRUgb/tBxoT93q1GeqeoM97R/vxMLdM5wlrncDed8PT26BI+YIGdnW2khJ2b6iIyTkz BAqrHLMPRmbJc9+joISvZ5PRNcHcicKjiCfECXa+VJEkjwbI4hfOpF+4j7S5yltkCtyjycGk wRsAAAAAAAA= --------------ms020500080304010304020301-- From owner-ietf-calendar@mail.imc.org Sun Aug 17 12:39:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16124 for ; Sun, 17 Aug 2003 12:39:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HGRCqt022035 for ; Sun, 17 Aug 2003 09:27:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7HGRCJc022034 for ietf-calendar-bks; Sun, 17 Aug 2003 09:27:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HGRBqt022029 for ; Sun, 17 Aug 2003 09:27:11 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7HGR9S5019708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 17 Aug 2003 09:27:11 -0700 Message-ID: <3F3FACD7.6040307@Royer.com> Date: Sun, 17 Aug 2003 10:27:03 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F3BEFCB.7090000@Royer.com> <3F3C2598.7080808@Royer.com> <3F3CEC16.6010405@Royer.com> <3F3D49A2.6000908@Royer.com> <3F3D71E9.6000101@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000507070302050405020002" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000507070302050405020002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > > > > Perhaps I am, I don't believe either of those about myself, > either way, it doesn't fix your model. I have proposed no model. Is everything you say as inaccurate? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000507070302050405020002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTcxNjI3MDNaMCMGCSqGSIb3DQEJBDEWBBTo 7djWKXaYTq/I6Vc/p/u/ABOvozBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQAGeLmXHbs10xx+b7UNTVYuLUGcLgWyoY4gHaXhFDyxkMAe ANXfNMIplTHPEhKoLYt/W46xSMOo/wgf/vGaltmG+MZ8imHOXrRIDtfmPPy+8pNyBYvkFWK3 sAIranVslr120A3KXxDt3TQmJXu+3jg4U8jBbZKtbzxgbyhwwJ1RkSG83ZFUTP9/BDFU/kzq PiggtaGLY7U2RLsDw+1N4GX00Pq9QX4nQ+lHtraaqjgf1C3gyODjz3XAk7TAGBS2TovQhwgf SYvVD3/Su9CeEzYk33Duw4tdT6WtxZhxs0QjzKgdalcjvSirPYJ3rVVgno8uguFcOD/2dxGl 2wHUENduAAAAAAAA --------------ms000507070302050405020002-- From owner-ietf-calendar@mail.imc.org Sun Aug 17 23:02: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 XAA26723 for ; Sun, 17 Aug 2003 23:02:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7I2ooqt051774 for ; Sun, 17 Aug 2003 19:50:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7I2ooTk051773 for ietf-calendar-bks; Sun, 17 Aug 2003 19:50:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7I2okqt051767 for ; Sun, 17 Aug 2003 19:50:48 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: Re-currence ID input from original authors MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Sun, 17 Aug 2003 22:50:46 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 08/17/2003 10:50:52 PM, Serialize complete at 08/17/2003 10:50:52 PM Content-Type: multipart/alternative; boundary="=_alternative 000FA29685256D86_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000FA29685256D86_= Content-Type: text/plain; charset="us-ascii" Both Frank and Derik have finished their review of this question and are putting together the answer for the list. I do not know what it is yet - but have asked them to go ahead and post it here directly. Both of them apologize for the delay - their work got in the way of the response. But it's coming - I promise! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 000FA29685256D86_= Content-Type: text/html; charset="us-ascii"
Both Frank and Derik have finished their review of this question and are putting together the answer for the list.  I do not know what it is yet - but have asked them to go ahead and post it here directly.  Both of them apologize for the delay - their work got in the way of the response.  But it's coming - I promise!
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 000FA29685256D86_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 18 10:44:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21349 for ; Mon, 18 Aug 2003 10:44:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IEKPqt012215 for ; Mon, 18 Aug 2003 07:20:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IEKPcZ012214 for ietf-calendar-bks; Mon, 18 Aug 2003 07:20:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IEKOqt012209 for ; Mon, 18 Aug 2003 07:20:24 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7IEKMS5028203 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 18 Aug 2003 07:20:24 -0700 Message-ID: <3F40E0A1.3050800@Royer.com> Date: Mon, 18 Aug 2003 08:20:17 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP -12 status Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050004070407000408060302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050004070407000408060302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have received about 75 typos, grammar, and requests for clarification to the -11 version of CAP. So I could not get them all in this weekend. A couple after I look closer I may bring to the list as I think they may be issues for the list and not just typos. They are all field and: http://INET-Consulting.com/bugzilla I'll try to get -12 out next weekend. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050004070407000408060302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTgxNDIwMTdaMCMGCSqGSIb3DQEJBDEWBBTx xUb7vD3VPT/BWHGOZGXmGBFBnDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQApHpqvWBVmxzJXo/AQmcbxDPFBh6cWUy4xUaULtiklspor Rm0lrmW8bI1TvBEVMtIoN2/KYLSAQvyAn3yNA16djC/JZNxmZccSXvP95wYARwz48EGRmfoI YPDsgb+wl8TezmkMJSDhXAr9Cnw1qLJ0iX4dgELXWIYTyLahL4TZFX6VWKmtLYxxeSlOOkc5 k3ZEKfxiHypvpEqZgNRdhDO4id9VsqL37JJabYu/7h5m1vhNr0eSecFxTNEvXzNUTbYyUtiV gXvjTc0ZoiEMpO3FcDc1D0Ztcz4k00A9RV8erkvQ9CGg13WXdn5w8ZZUdCiZBxaJjdd9p/AO wLae0ytaAAAAAAAA --------------ms050004070407000408060302-- From owner-ietf-calendar@mail.imc.org Mon Aug 18 14:36:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28986 for ; Mon, 18 Aug 2003 14:36:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IIOfqt021316 for ; Mon, 18 Aug 2003 11:24:41 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IIOfoL021315 for ietf-calendar-bks; Mon, 18 Aug 2003 11:24:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from gw.provo.novell.com (gw.provo.novell.com [137.65.47.29]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IIOeqt021310 for ; Mon, 18 Aug 2003 11:24:40 -0700 (PDT) (envelope-from JParker@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Mon, 18 Aug 2003 12:23:07 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Mon, 18 Aug 2003 12:23:20 -0600 From: "Jay Parker" To: , Subject: Re: How many people are there using the fixed-id model? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part87D9F488.1__=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=__Part87D9F488.1__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Novell GroupWise has implemented to the fixed-id model. =20 * Jay >>> "Michael Fair" 8/13/2003 4:09:11 PM >>> Since requesting how many people are using Doug's model is a potentially bankrupt question causing the whole list to wait for silence, how many people are using the fixed-id model? Simple replies to this post without any text will be taken as an "I am" post. -- Michael -- --=__Part87D9F488.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
Novell GroupWise has implemented to the fixed-id model.
 
=97 Jay

>>> "Michael Fair" <michael@daclubhouse.net> = 8/13/2003 4:09:11 PM >>>

Since requesting how many people are = using
Doug's model is a potentially bankrupt question
causing the = whole list to wait for silence,
how many people are using the fixed-id = model?

Simple replies to this post without any text
will be = taken as an "I am" post.

-- Michael --



<= /HTML> --=__Part87D9F488.1__=-- From owner-ietf-calendar@mail.imc.org Mon Aug 18 15:29: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 PAA01745 for ; Mon, 18 Aug 2003 15:29:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IJKOqt023786 for ; Mon, 18 Aug 2003 12:20:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IJKOYI023785 for ietf-calendar-bks; Mon, 18 Aug 2003 12:20:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IJKMqt023774 for ; Mon, 18 Aug 2003 12:20:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7IJKKS5030750 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 18 Aug 2003 12:20:23 -0700 Message-ID: <3F4126EF.9030900@Royer.com> Date: Mon, 18 Aug 2003 13:20:15 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Security considerations Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010603000106020603020702" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010603000106020603020702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The CAP security considerations sections is going to need to be expanded prior to being published as an RFC. So I propose the following new topics: (1) Risks of allowing anonymous UPNs to deposit REQUEST and REFRESH objects. (calendar spam and D.O.S.) (2) Suggest that CS implementations automatically create VCARs that allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY objects for those UIDs if they otherwise do not have access. And they may consider also allowing COUNTER objects for those ATTENDEEs. (3) Suggest that when an object is booked the CS reply with warning messages to the CUA for ATTENDEEs that have CAP urls that do not have local UPNs as those ATTENDEES may be unable to REPLY or REFRESH. Some CSs may wish this to be an error. Others? Suggestions welcome... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010603000106020603020702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTgxOTIwMTVaMCMGCSqGSIb3DQEJBDEWBBQ8 7ax5ZwyIBoMR+PtyDknZ1siJnzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQAHP2oyIDsgnuJNCkB0uVwZeyt7J6S6O/QjK6Zw3xPslkgy BOv6WF+LHforZ322QqPAM1GrGVug4lwotcrYHJpZ1Tvcmt1C5pRyGFvTiNRGDznn/7+jd1ex x55kLZb0mqflI8NBajW38DizQs5xBBCGRsi9iQjHWmbnWKgzE/Bw4HJDBfUwAT6a6oVxw7KR fvaHG0oey55Uv/JRUY+XTWxR1mKfEb+ojesX0ooleR6CP6Wlrik1vLSFGifUu++G9lADZKFI +DWOIOQFYjLbrfWWVhNFT9wjLXEuHcW7JIdIOS/3NzZRB67UVzMoQVyUz0CT0WvrGHROsBMK ZnU+jZTGAAAAAAAA --------------ms010603000106020603020702-- From owner-ietf-calendar@mail.imc.org Mon Aug 18 15:39: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 PAA02137 for ; Mon, 18 Aug 2003 15:39:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IJWBqt024215 for ; Mon, 18 Aug 2003 12:32:11 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IJWBue024214 for ietf-calendar-bks; Mon, 18 Aug 2003 12:32:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IJWAqt024208 for ; Mon, 18 Aug 2003 12:32:10 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7IJWCqB018458 for ; Mon, 18 Aug 2003 13:32:12 -0600 (MDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7IJWBhD010933 for ; Mon, 18 Aug 2003 12:32:11 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HJT00141Y9N45@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Mon, 18 Aug 2003 12:32:11 -0700 (PDT) Date: Mon, 18 Aug 2003 12:32:13 -0700 From: Satya Vempati Subject: RE: Uniquness of 4.4.2 Modify A Recurring Instance To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT I cannot see how the current-value-recurrence-id model and the fixed-recurrence-id model can interoperate. If you (as an attendee) ask for a REFRESH for a UID and RECURRENCE-ID from the current-value-recurrence-id model, your recurrence-id does not match anything that the organizer (who follows the fixed-recurrence-id model) has. How can you do a REFRESH with a UID+RECURRENCE-ID (i.e. one instance of a recurring event)? -----Original Message----- From: Doug Royer [mailto:Doug@royer.com] Sent: Sunday, August 17, 2003 9:32 AM To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Satya Vempati wrote: >>From my point of view, this discussion is academic. Since all major > implementations use the fixed recurrence model, anyone who wants to > interoperate with the likes of Exchange, Notes etc. will need to use the > fixed recurrence-id model. Will you implement systems that work with 95% > of the market or the other 5% (even if it is right)? The nice thing about the model in iTIP - it works with both. Thas has been one of my points over and over. The only thing that causes confusion is Brurce's propisal that inviting someone and making it look like an instance modificaiton. That independently breaks both models. The assertion that Exchange does not work with the iTIP model is bogus. I have no idea why anone thinks that - I can not get it to fail using the iTIP model. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Mon Aug 18 16:04: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 QAA02744 for ; Mon, 18 Aug 2003 16:04:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IJu1qt024998 for ; Mon, 18 Aug 2003 12:56:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IJu0lL024996 for ietf-calendar-bks; Mon, 18 Aug 2003 12:56:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IJtxqt024989 for ; Mon, 18 Aug 2003 12:55:59 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7IJtwS5031029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 18 Aug 2003 12:56:00 -0700 Message-ID: <3F412F49.6070109@Royer.com> Date: Mon, 18 Aug 2003 13:55:53 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080205030605030103070503" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080205030605030103070503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: > I cannot see how the current-value-recurrence-id model and the > fixed-recurrence-id model can interoperate. If you (as an attendee) ask > for a REFRESH for a UID and RECURRENCE-ID from the > current-value-recurrence-id model, your recurrence-id does not match > anything that the organizer (who follows the fixed-recurrence-id model) > has. > > How can you do a REFRESH with a UID+RECURRENCE-ID (i.e. one instance of a > recurring event)? It's ugly, but if the CUA only asks for full REFRESH, then they can always go back into sync. The only time a CUA should need to do a REFRESH is when the (as Michael put it) CUA gets a 'fishy' object. And the uniqueness of an invitation VS the RECURRENCE_ID issue (the subject of your email) are orthogonal. That is Bruces proposal to invite an ATTENDEE with an instance modification is independent of the RECURRENCE-ID model used. I will now unconditionally do a full REFRESH if given a RECURENCE-ID in a REQUEST for a UID that I do not have. Again ugly but if people are going to use instance modification for invitation I do not know of any other fix. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080205030605030103070503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTgxOTU1NTNaMCMGCSqGSIb3DQEJBDEWBBTF 7Vqq2vusEqoFdI9RYMPKi4PvMDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQA92lw1QmK5kdt4k5ZgGU1GH69+BH2S6hv5ObccF7eepe3U OMH+Wxeq+rjj6CDrq/a+Wd/swB81sMPzukmHE8+KTWAprXcBs7S7q+7Ek9FleQtxlq2S0yz8 /JB7fjxygqwBrPDoALG11pAdvZjcBuixw+C2inesBelYpB8J1on/+Je8meg8gbVIxx76Ac/X n4OKTTHA4pBut6qZoFfhJmSf80LKWjojfoQthk9QI4w1n6XdkodpJFjE+ssoEUIpzWRWu3aR w3Txvx8mYLe0KfDfKTdT3REghr4/mUyhCJbvw2SJvqwizWQxzMUdj+YzorZYseYQxi5sNj5o Ud/Ei9rQAAAAAAAA --------------ms080205030605030103070503-- From owner-ietf-calendar@mail.imc.org Mon Aug 18 16:18: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 QAA03157 for ; Mon, 18 Aug 2003 16:18:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IKAuqt025420 for ; Mon, 18 Aug 2003 13:10:56 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IKAuUV025419 for ietf-calendar-bks; Mon, 18 Aug 2003 13:10:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IKAtqt025414 for ; Mon, 18 Aug 2003 13:10:56 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3F412F49.6070109@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance MIME-Version: 1.0 X-Mailer: Lotus Notes Build V603_08102003NP August 10, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Mon, 18 Aug 2003 16:14:11 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/18/2003 04:11:31 PM, Serialize complete at 08/18/2003 04:11:31 PM Content-Type: multipart/alternative; boundary="=_alternative 006E75C985256D86_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E75C985256D86_= Content-Type: text/plain; charset="US-ASCII" But a Full refresh response would be all the events with their Recurrence-ids _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 08/18/2003 03:55 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: Uniquness of 4.4.2 Modify A Recurring Instance Satya Vempati wrote: > I cannot see how the current-value-recurrence-id model and the > fixed-recurrence-id model can interoperate. If you (as an attendee) ask > for a REFRESH for a UID and RECURRENCE-ID from the > current-value-recurrence-id model, your recurrence-id does not match > anything that the organizer (who follows the fixed-recurrence-id model) > has. > > How can you do a REFRESH with a UID+RECURRENCE-ID (i.e. one instance of a > recurring event)? It's ugly, but if the CUA only asks for full REFRESH, then they can always go back into sync. The only time a CUA should need to do a REFRESH is when the (as Michael put it) CUA gets a 'fishy' object. And the uniqueness of an invitation VS the RECURRENCE_ID issue (the subject of your email) are orthogonal. That is Bruces proposal to invite an ATTENDEE with an instance modification is independent of the RECURRENCE-ID model used. I will now unconditionally do a full REFRESH if given a RECURENCE-ID in a REQUEST for a UID that I do not have. Again ugly but if people are going to use instance modification for invitation I do not know of any other fix. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 006E75C985256D86_= Content-Type: text/html; charset="US-ASCII"
But a Full refresh response would be all the events with their Recurrence-ids
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

08/18/2003 03:55 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: Uniquness of 4.4.2 Modify A Recurring Instance







Satya Vempati wrote:
> I cannot see how the current-value-recurrence-id model and the
> fixed-recurrence-id model can interoperate. If you (as an attendee) ask
> for a REFRESH for a UID and RECURRENCE-ID from the
> current-value-recurrence-id model, your recurrence-id does not match
> anything that the organizer (who follows the fixed-recurrence-id model)
> has.
>
> How can you do a REFRESH with a UID+RECURRENCE-ID (i.e. one instance of a
> recurring event)?


It's ugly, but if the CUA only asks for full REFRESH, then they
can always go back into sync.

The only time a CUA should need to do a REFRESH is when the
(as Michael put it) CUA gets a 'fishy' object.

And the uniqueness of an invitation VS the RECURRENCE_ID issue
(the subject of your email) are orthogonal. That is Bruces
proposal to invite an ATTENDEE with an instance modification
is independent of the RECURRENCE-ID model used.

I will now unconditionally do a full REFRESH if given a RECURENCE-ID
in a REQUEST for a UID that I do not have. Again ugly but if
people are going to use instance modification for invitation
I do not know of any other fix.

--

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

                We Do Standards - You Need Standards
--=_alternative 006E75C985256D86_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 18 17:40: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 RAA05613 for ; Mon, 18 Aug 2003 17:40:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILQJqt027778 for ; Mon, 18 Aug 2003 14:26:19 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ILQJbj027777 for ietf-calendar-bks; Mon, 18 Aug 2003 14:26:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILQHqt027772 for ; Mon, 18 Aug 2003 14:26:17 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7ILQHS5031711 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 18 Aug 2003 14:26:18 -0700 Message-ID: <3F414473.4050809@Royer.com> Date: Mon, 18 Aug 2003 15:26:11 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030602080300060500050100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030602080300060500050100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > But a Full refresh response would be all the events with their > Recurrence-ids If I get an INSTANCE modification to an instance that does not exist, then I'll do a REFRESH. What do you do when you get a modification to an instance that does not exist in your calendar? Blindly accept it and accept there is never any way to get the original and never know what to do with future updates that may change that same RECURRENCE-ID you do not have? Wait for an object that may never arrive with a lower sequence number? Do a REFRESH just for that instance that you do not have because it is in the SEQUENCE:0 object you do not have? Do a REFRESH with the same RECURRENCE-ID you just got? Which is a modification to an object you do not have. What do you do with the second instance modification to a UID you do not have? Loop forever? How will you ever know if you missed the original? You use REFRESH by ATTENDEEs of 'existing' events, not new invitations: The "REFRESH" method in a "VEVENT" calendar component is used by "Attendees" of an existing event to request an updated description from the event "Organizer". The "REFRESH" method must specify the "UID" property of the event to update. A recurrence instance of an event may be requested by specifying the "RECURRENCE-ID" property corresponding to the associated event. The "Organizer" responds with the latest description and version of the event. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030602080300060500050100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTgyMTI2MTFaMCMGCSqGSIb3DQEJBDEWBBT+ Q8GXGfrIbOuWKvcW+RPGoPfX/DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQAOMH6OpEZY0dd6A9NsX/698jp8RwSEo0kXR8qI/laI5CMM vpfiq6xcte9T7duSyP3W/AweTjhSK5Xvfv3vfdZkV+NSVgVKYgoZyuyb35CnCDHcc7XgGmhC /AdS0J/94+3ZqQfT+vjTQt+Cu+AREV6p8PdJPCok+G4UN1Su40EuTgAGtCPG8YP/b5ROfmib pLgQ2TfNd2NnEFZsYW1KNXfhQRcVQ4iEJKslTz6Rza3yEKIM/clKWU/FGdKJGFi6rIJQi1FF aeC9zwJRoyUcZraIjQrn65Sivcm8mYpRLNLt4lr671/ov6CvWAmJg4RVW2AmH5a3HgOol1bx j/iK+0LFAAAAAAAA --------------ms030602080300060500050100-- From owner-ietf-calendar@mail.imc.org Tue Aug 19 01:22:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15156 for ; Tue, 19 Aug 2003 01:22:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J56Sqt041121 for ; Mon, 18 Aug 2003 22:06:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7J56RhQ041120 for ietf-calendar-bks; Mon, 18 Aug 2003 22:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J56Qqt041115 for ; Mon, 18 Aug 2003 22:06:26 -0700 (PDT) (envelope-from deriks@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Aug 2003 22:06:29 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Aug 2003 22:06:26 -0700 Received: from DF-BINGO.platinum.corp.microsoft.com ([10.197.0.81]) by DF-BEG.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Aug 2003 22:06:29 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: Re-currence ID input from original authors Date: Mon, 18 Aug 2003 22:07:45 -0700 Message-ID: <228A1748305DFF44B964F14B39865A9523CBDF@DF-BINGO.platinum.corp.microsoft.com> Thread-Topic: Re-currence ID input from original authors Thread-Index: AcNlNDWYoTv3TD+MS8yqZJU6q1BMYgAsTCQA From: "Derik Stenerson" To: , , , X-OriginalArrivalTime: 19 Aug 2003 05:06:29.0490 (UTC) FILETIME=[A62B3D20:01C3660F] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3660F.D387E7AF" ------_=_NextPart_001_01C3660F.D387E7AF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat and Bob: =20 Before the summer holidays, Pat approached the editors of the iCalendar = specification to provide an opinion about an issue of interpretation of = RECURRENCE-ID semantics and behavior that had surfaced in the IETF = CALSCH WG email reflector. =20 In particular, we understand that there was a question of interpretation = about whether the value for the RECURRENCE-ID property for a recurrence = instance will change when the recurrence instance start/end date/time is = modified. =20 We have read through related email threads about the discussions on this = matter and have reviewed relevant sections of the RFC2445/iCalendar and = RFC2446/iTIP. =20 Our opinion is that: =20 1) The issue resides with interpretation of the semantics and behavior = of a property for an iCalendar component; which is defined by = RFC2445/iCalendar alone. =20 2) The RFC2445/iCalendar is the foundation for the suite of IETF = calendaring/scheduling RFCs. The purpose of this specification is to = define the common semantics and behavior for calendar components, = properties and parameters utilized by the companion specifications = (i.e., RFCs 2446 and 2447). These companion specifications were never = intended to be inconsistent from or overriding of the semantics and = behavior defined by RFC2445. =20 3) Considerable discussion was held on semantics and behavior of = recurring events during the IETF deliberations leading to WG consensus = around the definition of iCalendar. It is our belief that the intent of = this consensus is as follows:=20 =20 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.=20 =20 b) An addition of a new recurrence instance to the set would be an = example of an action that would create a new recurrence set - e.g. = changing a Monday weekly meeting to a Monday and Tuesday weekly meeting. = This latter action is an example of an action that *might* also cause = the values of the RECURRENCE-ID properties for each member of the = recurrence set to get redefined (*might* is used here and in the RFC = because it is possible that occurrences in the new recurrence set will = have the same date/time value). But a rescheduling of a member of the = recurrence set would not cause such behavior (i.e., change the value) of = the RECURRENCE-ID property associated with the rescheduled recurrence = instance.=20 =20 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.=20 =20 Both of us remember numerous such use cases being presented to = illustrate the conditions and border-cases for such changes to the = original recurrence instances and the recurrence set. =20 4) It is worth noting that those discussion in the related WG email = threads referring to examples in iTIP are problematic, as section 3 of = RFC2446 was intended to be illustrative text and was not reviewed as = thoroughly as other sections of the RFC for consistency with iCalendar = semantics or conformity to iTIP normative sections. This text defines a = set of examples, or informational material. Further, this text is known = to have numerous typographic errors. =20 5) It is also worth noting that the semantics and behavior confirmed in = (3), above, is validated by existing deployed calendaring/scheduling = systems. A different interpretation of the semantics and behavior would = be counter to this practice today.=20 =20 =20 In summary, the original intention of the iCalendar specification was = that the value of the RECURRENCE-ID for a specific recurrence instance = would remain unchanged for the duration of the existence of the = recurrence set. 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. =20 Frank Dawson and Derik Stenerson =20 =20 =20 This posting is provided "AS IS" with no warranties, and confers no = rights.=20 ________________________________ From: owner-ietf-calendar@mail.imc.org = [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of = pregen@egenconsulting.com Posted At: Sunday, August 17, 2003 7:51 PM Posted To: IETF-Calendar Conversation: Re-currence ID input from original authors Subject: Re-currence ID input from original authors Both Frank and Derik have finished their review of this question and are = putting together the answer for the list. I do not know what it is yet = - but have asked them to go ahead and post it here directly. Both of = them apologize for the delay - their work got in the way of the = response. But it's coming - I promise! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 ------_=_NextPart_001_01C3660F.D387E7AF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

Pat and Bob:

=0A=

 

=0A=

Before the summer holidays, Pat approached the editors = of the =0A= iCalendar specification to provide an opinion about an issue of = interpretation =0A= of RECURRENCE-ID semantics and behavior that had surfaced in the IETF = CALSCH WG =0A= email reflector.

=0A=

 

=0A=

In particular, we understand that there was a question = of =0A= interpretation about whether the value for the RECURRENCE-ID property = for a =0A= recurrence instance will change when the recurrence instance start/end = date/time =0A= is modified.

=0A=

 

=0A=

We have read through related email threads about the = discussions =0A= on this matter and have reviewed relevant sections of the = RFC2445/iCalendar and =0A= RFC2446/iTIP.

=0A=

 

=0A=

Our opinion is that:

=0A=

 

=0A=

1) The issue resides with interpretation of the = semantics and =0A= behavior of a property for an iCalendar component; which is defined by =0A= RFC2445/iCalendar alone.

=0A=

 

=0A=

2) The RFC2445/iCalendar is the foundation for the suite = of IETF =0A= calendaring/scheduling RFCs. The purpose of this specification is to = define the =0A= common semantics and behavior for calendar components, properties and = parameters =0A= utilized by the companion specifications (i.e., RFCs 2446 and 2447). = These =0A= companion specifications were never intended to be inconsistent from or =0A= overriding of the semantics and behavior defined by RFC2445.

=0A=

 

=0A=

3) Considerable discussion was held on semantics and = behavior of =0A= recurring events during the IETF deliberations leading to WG consensus = around =0A= the definition of iCalendar. It is our belief that the intent of this = consensus =0A= is as follows:

=0A=

 

=0A=

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

=0A=

 

=0A=

b) An addition of a new recurrence instance to the set = would be an =0A= example of an action that would create a new recurrence set – e.g. = changing a =0A= Monday weekly meeting to a Monday and Tuesday weekly meeting. This = latter action =0A= is an example of an action that *might* also cause the values of the =0A= RECURRENCE-ID properties for each member of the recurrence set to get = redefined =0A= (*might* is used here and in the RFC because it is possible that = occurrences in =0A= the new recurrence set will have the same date/time value). But a = rescheduling =0A= of a member of the recurrence set would not cause such behavior (i.e., = change =0A= the value) of the RECURRENCE-ID property associated with the rescheduled =0A= recurrence instance.

=0A=

 

=0A=

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

=0A=

 

=0A=

Both of us remember numerous such use cases being = presented to =0A= illustrate the conditions and border-cases for such changes to the = original =0A= recurrence instances and the recurrence set.

=0A=

 

=0A=

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

=0A=

 

=0A=

5) It is also worth noting that the semantics and =0A= behavior confirmed in (3), above, is validated by existing =0A= deployed calendaring/scheduling systems. A different interpretation of = the semantics =0A= and behavior would be counter to this practice today.

=0A=

 

=0A=

 

=0A=

In summary, the original intention of the iCalendar = specification =0A= was that the value of the RECURRENCE-ID for a specific recurrence = instance would =0A= remain unchanged for the duration of the existence of the recurrence = set. =0A= Rescheduling individual recurrence instances did not cause recreation of = the =0A= recurrence set or change the value of the RECURRENCE-ID property for the =0A= associated recurrence instance, but only involved changes to the = start/end of =0A= the recurrence instance.

=0A=

 

=0A=

Frank Dawson and Derik Stenerson

=0A=
 
=0A=

=0A=

 

=0A=

  
This posting is provided "AS IS" with no warranties, and = confers no =0A= rights.


=0A=
=0A=
=0A= From: = owner-ietf-calendar@mail.imc.org =0A= [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of =0A= pregen@egenconsulting.com
Posted At: Sunday, August 17, = 2003 7:51 =0A= PM
Posted To: IETF-Calendar
Conversation: = Re-currence ID =0A= input from original authors
Subject: Re-currence ID input from =0A= original authors


Both Frank =0A= and Derik have finished their review of this question and are putting = together =0A= the answer for the list.  I do not know what it is yet - but have = asked =0A= them to go ahead and post it here directly.  Both of them apologize = for the =0A= delay - their work got in the way of the response.  But it's coming = - I =0A= promise!
___________________
Patricia Egen =0A= Consulting
www.egenconsulting.com
423-875-2652 ------_=_NextPart_001_01C3660F.D387E7AF-- --------------InterScan_NT_MIME_Boundary-- From owner-ietf-calendar@mail.imc.org Tue Aug 19 01:36:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15431 for ; Tue, 19 Aug 2003 01:36:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J5N1qt041675 for ; Mon, 18 Aug 2003 22:23:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7J5N1HR041674 for ietf-calendar-bks; Mon, 18 Aug 2003 22:23:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J5Mvqt041650 for ; Mon, 18 Aug 2003 22:22:58 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19oyyD-0004cZ-00 for ; Tue, 19 Aug 2003 07:23:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19oyyD-0004cR-00 for ; Tue, 19 Aug 2003 07:23:49 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19oyxB-0005v9-00 for ; Tue, 19 Aug 2003 07:22:45 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Mon, 18 Aug 2003 22:22:44 -0700 Lines: 94 Message-ID: References: <3F414473.4050809@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, In theory I think the whole refresh idea might work. As in the set described by the base object will always describe reccurence ids that are in hte update instance components of the message. However, won't the CUA using the current-value model as you described have a problem when with REFRESH when it comes to the SEQUENCE values? In the fixed-id model, as we've been discussing it, the "base" event has a SEQUENCE N whereas each instance has N+MOD where MOD is the number of significant modifications that instance has undergone. The current-value model has based everything on one instance value for the whole object. So the REFRESH will work the first time, but the CUA using a current-value model will take the largest N+MOD in the entire set and use that as the SEQUENCE it's looking for. Since the base object will be at N it could ever "go back" and reset the recurrence set description to what it was originally. -- Michael -- "Doug Royer" wrote in message news:3F414473.4050809@Royer.com... > > > Robert_Ransdell@notesdev.ibm.com wrote: > > > > But a Full refresh response would be all the events with their > > Recurrence-ids > > If I get an INSTANCE modification to an instance that does not exist, > then I'll do a REFRESH. > > What do you do when you get a modification to an instance > that does not exist in your calendar? > > Blindly accept it and accept there is never any > way to get the original and never know what to do with > future updates that may change that same RECURRENCE-ID > you do not have? > > Wait for an object that may never arrive with a lower > sequence number? > > Do a REFRESH just for that instance that you do not have > because it is in the SEQUENCE:0 object you do not have? > > Do a REFRESH with the same RECURRENCE-ID you just got? > Which is a modification to an object you do not have. > > What do you do with the second instance modification to a UID > you do not have? Loop forever? > > How will you ever know if you missed the original? > > You use REFRESH by ATTENDEEs of 'existing' events, not new > invitations: > > The "REFRESH" method in a "VEVENT" calendar component is used by > "Attendees" of an existing event to request an updated description > from the event "Organizer". The "REFRESH" method must specify the > "UID" property of the event to update. A recurrence instance of an > event may be requested by specifying the "RECURRENCE-ID" property > corresponding to the associated event. The "Organizer" responds with > the latest description and version of the event. > > > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Tue Aug 19 02:12: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 CAA27786 for ; Tue, 19 Aug 2003 02:12:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J61jqt043584 for ; Mon, 18 Aug 2003 23:01:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7J61jXd043582 for ietf-calendar-bks; Mon, 18 Aug 2003 23:01:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J61hqt043570 for ; Mon, 18 Aug 2003 23:01:44 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19ozZy-0004pV-00 for ; Tue, 19 Aug 2003 08:02:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19ozZx-0004pN-00 for ; Tue, 19 Aug 2003 08:02:49 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19ozYw-0006eE-00 for ; Tue, 19 Aug 2003 08:01:46 +0200 From: "Michael Fair" Subject: Re: Re-currence ID input from original authors Date: Mon, 18 Aug 2003 23:01:44 -0700 Lines: 215 Message-ID: References: <228A1748305DFF44B964F14B39865A9523CBDF@DF-BINGO.platinum.corp.microsoft.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 hope I'm not overstepping any boundaries here, but there is one question about this model that I have encoutered that I'm not quite certain how to resolve and that's inviting a CU to a single recurring instance for which the CU is not invited to the recurring set. According to my read, this CU may not receive a description of the base recurrence set and therefore will be unable to verify the recurrence-id in question. Should a rescheduling of the base set happen which would invalidate the recurrence-id that CU had originally received, then as far as I can tell, the ORGANIZER's CUA will have to send a cancel of the original instance, and a new invite to the event with the new recurrence-id. The only other option I can see is that in the case a CU is not invited to the base reucrring set, the base recurrence set description is also provided alongside the RECURRENCE-ID. This way, when a CUA receives an object, it can verify that all existing instances on its calendar (which in the case of a single invite will be the one with the wrong RECURRENCE-ID) still exist within the context of the updated recurrence set. Since the SEQUENCE value of the new object will be greater than the SEQUENCE of the old _AND_ the sets are different, then any instance whose recurrence-id does not exist within the new set should be removed. Otherwise, the only recourse I can see is to send the CU a request for the base object, and then another one when the base object is updated - which seems to me that it runs the risk of being treated as invite, regardless of whether or not they are listed as an ATTENDEE (for instance I know that MS Outlook will treat any REQUEST like an invite regardless of what's listed for ATTENDEE). This is the only time where I see there could be a problem since the recipient CUA, which may have never seen the description of the entire series won't be able to tell that the existing event it has with the old RECURRENCE-ID is no longer valid, and the new event it just received replaces that one. This problem slightly expands when you start dealing with invited to certain subsets of the series. Again, I am not trying to waste anyone's time, it's just not clear to me how you communicate a RECURRENCE-ID change when the CU has only been invited to that one instance. -- Michael -- "Derik Stenerson" wrote in message news:228A1748305DFF44B964F14B39865A9523CBDF@DF-BINGO.platinum.corp.microsoft.com... Pat and Bob: Before the summer holidays, Pat approached the editors of the iCalendar specification to provide an opinion about an issue of interpretation of RECURRENCE-ID semantics and behavior that had surfaced in the IETF CALSCH WG email reflector. In particular, we understand that there was a question of interpretation about whether the value for the RECURRENCE-ID property for a recurrence instance will change when the recurrence instance start/end date/time is modified. We have read through related email threads about the discussions on this matter and have reviewed relevant sections of the RFC2445/iCalendar and RFC2446/iTIP. Our opinion is that: 1) The issue resides with interpretation of the semantics and behavior of a property for an iCalendar component; which is defined by RFC2445/iCalendar alone. 2) The RFC2445/iCalendar is the foundation for the suite of IETF calendaring/scheduling RFCs. The purpose of this specification is to define the common semantics and behavior for calendar components, properties and parameters utilized by the companion specifications (i.e., RFCs 2446 and 2447). These companion specifications were never intended to be inconsistent from or overriding of the semantics and behavior defined by RFC2445. 3) Considerable discussion was held on semantics and behavior of recurring events during the IETF deliberations leading to WG consensus around the definition of iCalendar. It is our belief that the intent of this consensus is as follows: 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. b) An addition of a new recurrence instance to the set would be an example of an action that would create a new recurrence set - e.g. changing a Monday weekly meeting to a Monday and Tuesday weekly meeting. This latter action is an example of an action that *might* also cause the values of the RECURRENCE-ID properties for each member of the recurrence set to get redefined (*might* is used here and in the RFC because it is possible that occurrences in the new recurrence set will have the same date/time value). But a rescheduling of a member of the recurrence set would not cause such behavior (i.e., change the value) of the RECURRENCE-ID property associated with the rescheduled recurrence instance. 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. Both of us remember numerous such use cases being presented to illustrate the conditions and border-cases for such changes to the original recurrence instances and the recurrence set. 4) It is worth noting that those discussion in the related WG email threads referring to examples in iTIP are problematic, as section 3 of RFC2446 was intended to be illustrative text and was not reviewed as thoroughly as other sections of the RFC for consistency with iCalendar semantics or conformity to iTIP normative sections. This text defines a set of examples, or informational material. Further, this text is known to have numerous typographic errors. 5) It is also worth noting that the semantics and behavior confirmed in (3), above, is validated by existing deployed calendaring/scheduling systems. A different interpretation of the semantics and behavior would be counter to this practice today. In summary, the original intention of the iCalendar specification was that the value of the RECURRENCE-ID for a specific recurrence instance would remain unchanged for the duration of the existence of the recurrence set. 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. Frank Dawson and Derik Stenerson This posting is provided "AS IS" with no warranties, and confers no rights. ________________________________ From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of pregen@egenconsulting.com Posted At: Sunday, August 17, 2003 7:51 PM Posted To: IETF-Calendar Conversation: Re-currence ID input from original authors Subject: Re-currence ID input from original authors Both Frank and Derik have finished their review of this question and are putting together the answer for the list. I do not know what it is yet - but have asked them to go ahead and post it here directly. Both of them apologize for the delay - their work got in the way of the response. But it's coming - I promise! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 From owner-ietf-calendar@mail.imc.org Tue Aug 19 10:59: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 KAA16393 for ; Tue, 19 Aug 2003 10:59:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JEl0qt001903 for ; Tue, 19 Aug 2003 07:47:00 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JEl0Ha001902 for ietf-calendar-bks; Tue, 19 Aug 2003 07:47:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JEkwqt001897 for ; Tue, 19 Aug 2003 07:46:58 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7JEkuS5006870 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 19 Aug 2003 07:46:58 -0700 Message-ID: <3F42385B.3080409@Royer.com> Date: Tue, 19 Aug 2003 08:46:51 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-calsch-dynamic-upn-00.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080704000707060109060108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080704000707060109060108 Content-Type: multipart/mixed; boundary="------------060601080109050907090703" This is a multi-part message in MIME format. --------------060601080109050907090703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI - pass 0 of a new idea for CALSCH -------- Original Message -------- Subject: I-D ACTION:draft-royer-calsch-dynamic-upn-00.txt Date: Tue, 19 Aug 2003 10:07:34 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : How to create dynamic UPNs for invited ATTENDEEs Author(s) : D. Royer Filename : draft-royer-calsch-dynamic-upn-00.txt Pages : 1 Date : 2003-8-19 This is an extension to the [CAP] and [iMIP] protocols. A CU may wish to invite a UPN to an event where the UPN does not have a account on the CU's CS or the S/MIME key to send encrypted [iMIP] messages. This memo describes two methods to dynamically create UPNs in order for those UPNs to gain access to the 'Organizers' CS and to add authentication to [iMIP]. This memo also includes a description of how to include an [OTP] challenge in an object directed to a CUA. The CUA must compute the password in order to respond to the object. This challenge and its response can be sent in the clear as the values are computed using a secret that would not be known to anyone snooping the line. This adds a level of security to iMIP communications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-calsch-dynamic-upn-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-calsch-dynamic-upn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-calsch-dynamic-upn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------060601080109050907090703 Content-Type: Message/External-body; name="draft-royer-calsch-dynamic-upn-00.txt" Content-Disposition: inline; filename="draft-royer-calsch-dynamic-upn-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-8-19101419.I-D@ietf.org> --------------060601080109050907090703-- --------------ms080704000707060109060108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxOTE0NDY1MVowIwYJKoZIhvcNAQkEMRYEFCsnErhZ Eanm2BEUbK222AmI35eWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGIxM/38A6/iw9+t/SiIgV3UFlox2Csm3ffljee8RlzEWJUUvWSp GdCx/dO2X4BqQ1JPMuHJXV6wCj9U6jGm35rBvgCS7vtGkvrtXEBzJcRLkXEJiJ883w0HNEm7 NZxtzkQdSXGGbq11LO50xRBoyrvScOa3bgdHAHVzMDFKMGegmNGu7au6rukj3ton3/VZeo7w jSpNAKta9JHEDkRNVZoG49v9FNORjz7h1hwiGkmJOccfInnvczQJcUHzgLeDpJsUZXU5bM+l EMpcp5U9w2RFMBap7o5zymGzVtZsBXG8eQMSgmI2vs8FRLzmGnidWCqlD7z8KFIMez8ntuEF 5LQAAAAAAAA= --------------ms080704000707060109060108-- From owner-ietf-calendar@mail.imc.org Tue Aug 19 11:51: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 KAA16392 for ; Tue, 19 Aug 2003 10:59:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JEeCqt001660 for ; Tue, 19 Aug 2003 07:40:12 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JEeCld001659 for ietf-calendar-bks; Tue, 19 Aug 2003 07:40:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JEeBqt001654 for ; Tue, 19 Aug 2003 07:40:11 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7JEe9S5006835 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 19 Aug 2003 07:40:11 -0700 Message-ID: <3F4236C3.9030600@Royer.com> Date: Tue, 19 Aug 2003 08:40:03 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F414473.4050809@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000308070507030804000000" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000308070507030804000000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > Doug, > > In theory I think the whole refresh idea might work. > As in the set described by the base object will always > describe reccurence ids that are in hte update instance > components of the message. However, won't the CUA using > the current-value model as you described have a problem > when with REFRESH when it comes to the SEQUENCE values? No, as they will contain the current state of the object. You toss the old ones. > > Since you can't differentiate a reponse to a REFRESH > from an out of sequence delivery I don't see how the > CUA once it has processed a message where SEQUENCE > was >N it could ever "go back" and reset the recurrence > set description to what it was originally. You do not care about old SEQUENCE data, it is obsolete. When the REFRESH is sent the object that caused the REFRESH to be sent will be at SEQUENCE:X. So any objects that arrive will be (< X), (== X), (> X). So for each object that arrives: If they are (< X), toss them as they are obsolete and the REFRESH reply will update you. They can not be the reply you are waiting for as they are old objects that arrived out of order. If they are (== X) it may be the reply you are waiting for. Use the object. If they are (> X) toss everything else and start from that new SEQUENCE number it may be the reply you want. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000308070507030804000000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTkxNDQwMDNaMCMGCSqGSIb3DQEJBDEWBBSK Jn+TezBdrEm/iudTRA2fFlXtuzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8 oTANBgkqhkiG9w0BAQEFAASCAQB0qInA7K9amKJevKglKylNGChv1qgG706+BIk9zOkhyddE tsqug+nZ2Bq/friRzX+BbE4XvOzE/qnUiT6nCRfSECl0Hotk2PkEObco875Nw2Y356DDGE+l jeuBgE8B2T/yUuXck1lCLcHGa1GDeNRLKVdkXwGPH3fh0Fk48flzNlbVIQBASZkZmkl7iLJR Jar0hV81YEpgyz9SyGYE+WKazIJDlGkhBj6HxmOyMatXybXy5JH+oLajP6Eti7+W7VziSmIZ ud5Z/0wycxZ0t0kl1z7DyqK/WjGBCMyBU+o8+JMM0AO01PC0Jdo0g8XS87X9I1XxsttXtLjQ Dc3d6vc2AAAAAAAA --------------ms000308070507030804000000-- From owner-ietf-calendar@mail.imc.org Tue Aug 19 16:04: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 QAA06190 for ; Tue, 19 Aug 2003 16:04:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZtqt019907 for ; Tue, 19 Aug 2003 12:35:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJZsT1019906 for ietf-calendar-bks; Tue, 19 Aug 2003 12:35:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZpqt019897 for ; Tue, 19 Aug 2003 12:35:52 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19pCHm-0002uK-00 for ; Tue, 19 Aug 2003 21:36:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19pCHl-0002uC-00 for ; Tue, 19 Aug 2003 21:36:53 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19pCGk-00044B-00 for ; Tue, 19 Aug 2003 21:35:50 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Tue, 19 Aug 2003 12:35:45 -0700 Lines: 101 Message-ID: References: <3F414473.4050809@Royer.com> <3F4236C3.9030600@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 don't think you're hearing what I'm saying. Maybe you're thinking of yourself as the ORGANIZER and the fixed-id as the recipient CUA. I'm thinking the other way around. Your CUA is trying to interop with a fixed-id based ORGANIZER. So let's step through this shall we: 1) I send recurring event E at SEQEUNCE N. 2) I send instance reschedule E1 at N+1 - Process just fine. -- CUA now thinks SEQUENCE for E is N+1. -- Redefines recurrence set of E to exclude DTSTART at N and to include DTSTART at N+1 3) I send instance reschedule E1' at N+2 - Can't process - wrong RID. 4) You send for a REFRESH. So I send back a single REQUEST response containing: E at N E1' at N+2 You throw out the object E because you think it's old. You believe that the SEQUENCE to E is now N+1. You started thinking that as soon as you saw E1. E1' has a great SEQUENCE (bigger is better) but you still can't find it on the calendar - wrong RID. You send for a REFRESH. Cycle. Rinse. Repeat. Did that help - or just confuse things more? The primary thing is to work it out on paper. Figure out what messages you are going to receive and what that will do to your calendar and how you will process them. While it might work for a fixed-id model to be on the recipient end of an ORGANIZER who is using a current-value model by virtue of lots of REFRESH requests. The converse is definitely not true. -- Michael -- "Doug Royer" wrote in message news:3F4236C3.9030600@Royer.com... > > > Michael Fair wrote: > > Doug, > > > > In theory I think the whole refresh idea might work. > > As in the set described by the base object will always > > describe reccurence ids that are in hte update instance > > components of the message. However, won't the CUA using > > the current-value model as you described have a problem > > when with REFRESH when it comes to the SEQUENCE values? > > No, as they will contain the current state of the object. > You toss the old ones. > > > > > Since you can't differentiate a reponse to a REFRESH > > from an out of sequence delivery I don't see how the > > CUA once it has processed a message where SEQUENCE > > was >N it could ever "go back" and reset the recurrence > > set description to what it was originally. > > You do not care about old SEQUENCE data, it is obsolete. > > When the REFRESH is sent the object that caused the REFRESH > to be sent will be at SEQUENCE:X. So any objects that > arrive will be (< X), (== X), (> X). So for each > object that arrives: > > If they are (< X), toss them as they are obsolete and > the REFRESH reply will update you. They can not be > the reply you are waiting for as they are old objects > that arrived out of order. > > If they are (== X) it may be the reply you are waiting for. > Use the object. > > If they are (> X) toss everything else and start from > that new SEQUENCE number it may be the reply you want. > > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Tue Aug 19 16:46: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 QAA08308 for ; Tue, 19 Aug 2003 16:46:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JKTsqt023862 for ; Tue, 19 Aug 2003 13:29:54 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JKTsXG023861 for ietf-calendar-bks; Tue, 19 Aug 2003 13:29:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JKTrqt023851 for ; Tue, 19 Aug 2003 13:29:53 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7JKTqS5009807 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 19 Aug 2003 13:29:54 -0700 Message-ID: <3F4288BB.4090708@Royer.com> Date: Tue, 19 Aug 2003 14:29:47 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F414473.4050809@Royer.com> <3F4236C3.9030600@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000900010804040905000903" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000900010804040905000903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > I don't think you're hearing what I'm saying. > > Maybe you're thinking of yourself as the ORGANIZER and > the fixed-id as the recipient CUA. No because the ORGANIZE never sends a REFRESH to itself. > I'm thinking the > other way around. Your CUA is trying to interop with > a fixed-id based ORGANIZER. > > > So let's step through this shall we: > 1) I send recurring event E at SEQEUNCE N. > 2) I send instance reschedule E1 at N+1 - Process just fine. > -- CUA now thinks SEQUENCE for E is N+1. > -- Redefines recurrence set of E to exclude DTSTART at N > and to include DTSTART at N+1 > 3) I send instance reschedule E1' at N+2 - Can't process - wrong RID. > 4) You send for a REFRESH. > > > So I send back a single REQUEST response containing: > E at N > E1' at N+2 There is NO such thing as a single REQUEST invitation. Simply send the object back. There is NO example or text in iCAL, iTIP, or iMIP that says that there is a special REQUEST type that you describe. Someone made it up and it is NOT iTIP. iTIP compliant applications send objects described in iTIP and no such object is described. Can you point to ANY text in ANY RFC to backup your view? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000900010804040905000903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxOTIwMjk0N1owIwYJKoZIhvcNAQkEMRYEFHLuJZWy 6LAeCJ7KdgBz5/dbz9KcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAEHg3ZH5GuYd1me5i5J1uLgjz2Sqv1XeZ1DwFuGvEr6nJj6LXJob mX21shFSKyw+aLFirE1ltqON3piuuPTw/CmJhowibZR0tYzwI2pAXqNJMBeRYfRDsqIYtAkZ Bu3z+8UhGCwsbJ5bn9cItDnH6yyUOGqfnqL5CgucFzoFJFKp9EbtNSSbs4sG4n0am75UXfOl QzZELf9PT4zKpv2Mr5lmuZRXeL4zx8B9wIOEeziq1CtR1hgkPYTIjDbgA1IuIbgFugMlfv+P HuD/XgUqQjV8ReVw/pKcMcjW/e3VyzSsik/gvBLh51wXTsPqltI4V3Bc8EElom4H+YcCtped Iu8AAAAAAAA= --------------ms000900010804040905000903-- From owner-ietf-calendar@mail.imc.org Tue Aug 19 18:22: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 SAA12903 for ; Tue, 19 Aug 2003 18:22:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JM49qt031794 for ; Tue, 19 Aug 2003 15:04:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JM49h9031793 for ietf-calendar-bks; Tue, 19 Aug 2003 15:04:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JM46qt031778 for ; Tue, 19 Aug 2003 15:04:07 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19pEbG-00048J-00 for ; Wed, 20 Aug 2003 00:05:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19pEbF-00048B-00 for ; Wed, 20 Aug 2003 00:05:09 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19pEaF-00086F-00 for ; Wed, 20 Aug 2003 00:04:07 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Tue, 19 Aug 2003 15:04:05 -0700 Lines: 122 Message-ID: References: <3F414473.4050809@Royer.com> <3F4236C3.9030600@Royer.com> <3F4288BB.4090708@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: Let me try this again. There are two things that a current-value CUA must deal with: First - it must be able to send message to other CUAs with the events it creates. Second - it must be able to receive events based on messages from other CUAs. I'm specifically addressing issues with the second model. It seems that from my analysis, (which is just a rehash of Bruce's in a slightly modified form) the current-value CUA cannot participate in any recurring event for which the ORGANIZER uses a fixed-id CUA. From your analysis, the current-value CUA can act as an ORGANIZER's CUA if we just accept that the fixed-id CUAs will simply be sending lots of REFRESH requests. These are two totally separate items. In my analysis, the fixed-id CUA is the ORGANIZER. In your analysis, the current-value CUA is the ORGANIZER. In your analysis, the fixed-id CUA is the recipient. In my analysis, the current-value CUA is the recipient. > Michael Fair wrote: > > I don't think you're hearing what I'm saying. > > > > Maybe you're thinking of yourself as the ORGANIZER and > > the fixed-id as the recipient CUA. > > No because the ORGANIZE never sends a REFRESH to itself. I don't know where in what I said you ever thought I was trying to say that. Just makes it clear your not hearing what I'm saying again. I was saying that perhaps you are only thinking about the first model which is only half the battle towards interoperability. Not once have I ever suggested the ORGANIZER send a REFRESH to itself. > > I'm thinking the > > other way around. Your CUA is trying to interop with > > a fixed-id based ORGANIZER. > > > > > > So let's step through this shall we: > > 1) I send recurring event E at SEQEUNCE N. > > 2) I send instance reschedule E1 at N+1 - Process just fine. > > -- CUA now thinks SEQUENCE for E is N+1. > > -- Redefines recurrence set of E to exclude DTSTART at N > > and to include DTSTART at N+1 > > 3) I send instance reschedule E1' at N+2 - Can't process - wrong RID. > > 4) You send for a REFRESH. > > > > > > So I send back a single REQUEST response containing: > > E at N > > E1' at N+2 > > There is NO such thing as a single REQUEST invitation. Simply > send the object back. Once again we get into this whole message versus object dilemma. There is one and only one message. That message is a REQUEST message. That message contains multiple event components. One of those components is E - the original description of the recurring event. The other of those components is E' - the second modification to one of the instances of that recurring event. The ORGANIZER is a fixed-id ORGANIZER. That's how it sends the object back. > There is NO example or text in iCAL, iTIP, or iMIP that > says that there is a special REQUEST type that you > describe. Someone made it up and it is NOT iTIP. > iTIP compliant applications send objects described in iTIP > and no such object is described. There is, but I'm expecting that once what I'm describing is clarified it will be obvious to you. If you however are still not clear, make your request for RFC citations and I will provide them (Somewhere there is a response to a REFRESH request just after an instance add). > Can you point to ANY text in ANY RFC to backup your view? I can probably point to several sections. I can also point to archives where you even agreed it would be the way I describe it. I can also point to past disccusions in recent threads where you also agreed it would take multiple components to fully describe a recurring event where the instance modifications contained more than just simply date/time deviations from the base event (like comments etc). Again, I'm expecting that you just aren't fully fleshing out what would happen to a current-value CUA trying to interoperate with a fixed-id CUA. There are two scenarios: 1) The current-value CUA is the ORGANIZER 2) The fixed-id CUA is the ORGANIZER In (1) it kind of works with lots of refreshes because what the current-value calls an instance update, to the fixed-id model is actually a rescheduling of the entire recurrence set and it takes a REFRESH to figure it out. In (2) the current-value CUA gets stuck in an endless loop of REFRESH/REQUEST once it has received any updates to an instance for which it triggers a REFRESH. Does that make it any clearer to you yet? -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 19 19:17: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 TAA15303 for ; Tue, 19 Aug 2003 19:17:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JN0Iqt035719 for ; Tue, 19 Aug 2003 16:00:18 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JN0Hij035718 for ietf-calendar-bks; Tue, 19 Aug 2003 16:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JN0Eqt035712 for ; Tue, 19 Aug 2003 16:00:15 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7JN0AS5011314 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 19 Aug 2003 16:00:13 -0700 Message-ID: <3F42ABF5.2070101@Royer.com> Date: Tue, 19 Aug 2003 17:00:05 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F414473.4050809@Royer.com> <3F4236C3.9030600@Royer.com> <3F4288BB.4090708@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040507080909080203050106" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040507080909080203050106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > Let me try this again. > > There are two things that a current-value CUA must deal with: > First - it must be able to send message to other CUAs with > the events it creates. > Second - it must be able to receive events based on messages > from other CUAs. > > I'm specifically addressing issues with the second model. > > It seems that from my analysis, (which is just a rehash > of Bruce's in a slightly modified form) the current-value > CUA cannot participate in any recurring event for which > the ORGANIZER uses a fixed-id CUA. I disagree. >>From your analysis, the current-value CUA can act as an > ORGANIZER's CUA if we just accept that the fixed-id CUAs > will simply be sending lots of REFRESH requests. Not what I said. > These are two totally separate items. > In my analysis, the fixed-id CUA is the ORGANIZER. > In your analysis, the current-value CUA is the ORGANIZER. > In your analysis, the fixed-id CUA is the recipient. > In my analysis, the current-value CUA is the recipient. I disagree. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040507080909080203050106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxOTIzMDAwNVowIwYJKoZIhvcNAQkEMRYEFBHofKvI 4jtyIH5k+bCyU33fUvxnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGs74Xl7o3nQCAL4KS1QSW+xnS5RpJIsT4ehWAzOgIhTcMRcrWol iCXKTqZy4V4k50yTOVwMXRnZOlnXdEIZZhkCvhhtDSoZNAPBfpBZT99wLG1bI0Sh3F9TE1ZO hjc5LA9CfDswLAMy7G7XdcZLsNYQUNPFbbF0ufdrgaK1tZf9+/ZC5C8pENGDUEFDX4BrsG/f 1CpEiVVCcdTAX4ZZ398iPgHLyQoyeVUGwvbiTKAAdT0GPd+Y4+Vq1EmaHarwdYwM4OXrPGhN KBO7/nEtEinSU/I5EMnygIJBsD0A1eMx9H5MvhYsnfOCe0HMWUiNIBA4mr30oLS2FmXcGRnd 4KMAAAAAAAA= --------------ms040507080909080203050106-- From owner-ietf-calendar@mail.imc.org Tue Aug 19 19:55: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 TAA16246 for ; Tue, 19 Aug 2003 19:55:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JNfXqt037347 for ; Tue, 19 Aug 2003 16:41:33 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JNfXfw037346 for ietf-calendar-bks; Tue, 19 Aug 2003 16:41:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JNfUqt037341 for ; Tue, 19 Aug 2003 16:41:31 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19pG7W-0004xr-00 for ; Wed, 20 Aug 2003 01:42:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19pG7V-0004xj-00 for ; Wed, 20 Aug 2003 01:42:33 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19pG6V-0002FG-00 for ; Wed, 20 Aug 2003 01:41:31 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Tue, 19 Aug 2003 16:41:28 -0700 Lines: 107 Message-ID: References: <3F414473.4050809@Royer.com> <3F4236C3.9030600@Royer.com> <3F4288BB.4090708@Royer.com> <3F42ABF5.2070101@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: Ok cool. Progress at least we are talking about the same model where a fixed-id CUA is sending a current-value CUA messages. So why doesn't it happen like I said? Since I know you don't like reading older posts I'll repeat it for you here: Fixed-id CUA ORGANIZER sends: Recurring event at SEQUENCE N. Instance update E1 at SEQUENCE N+1. Instance update E1' at SEQUENCE N+2. Current-value CUA recipient receives: Recurring event at SEQUENCE N. Instance update E1 at N+1. Instance update E1' at N+2. As a result of receiving E1, the current-value CUA incremented the SEQUENCE value of E to N+1. As a result of receiving E1, the current-value CUA modified the recurrence rules of E to exclude the prior DTSTART, and include the new DTSTART. For the current-value CUA to not do these two things opens it to all sort of other craziness. If you'd like to disagree that it does these two things that's fine. Just tell me what it does do and I'll shoulder the burden of proving why it breaks even worse. It now receives E1' it can't find the RECURRENCE-ID which has now been excluded from the set. It sends for a REFRESH and throws the E1' message away. The REQUEST response message arrives. It contains two components: Event E with SEQUENCE N. Event E1' with SEQUENCE N+2 and an RID as generated by E. The current-value CUA throws away the object describing E as it thinks it's old (SEQUENCE wrote in message news:3F42ABF5.2070101@Royer.com... > > > Michael Fair wrote: > > Let me try this again. > > > > There are two things that a current-value CUA must deal with: > > First - it must be able to send message to other CUAs with > > the events it creates. > > Second - it must be able to receive events based on messages > > from other CUAs. > > > > I'm specifically addressing issues with the second model. > > > > It seems that from my analysis, (which is just a rehash > > of Bruce's in a slightly modified form) the current-value > > CUA cannot participate in any recurring event for which > > the ORGANIZER uses a fixed-id CUA. > > I disagree. > > >>From your analysis, the current-value CUA can act as an > > ORGANIZER's CUA if we just accept that the fixed-id CUAs > > will simply be sending lots of REFRESH requests. > > Not what I said. > > > These are two totally separate items. > > In my analysis, the fixed-id CUA is the ORGANIZER. > > In your analysis, the current-value CUA is the ORGANIZER. > > In your analysis, the fixed-id CUA is the recipient. > > In my analysis, the current-value CUA is the recipient. > > I disagree. > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > From owner-ietf-calendar@mail.imc.org Tue Aug 19 20:28: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 UAA18114 for ; Tue, 19 Aug 2003 20:28:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K0EYqt038359 for ; Tue, 19 Aug 2003 17:14:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7K0EYdx038358 for ietf-calendar-bks; Tue, 19 Aug 2003 17:14:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K0EXqt038353 for ; Tue, 19 Aug 2003 17:14:33 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7K0EWS5012094 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 19 Aug 2003 17:14:34 -0700 Message-ID: <3F42BD63.8000907@Royer.com> Date: Tue, 19 Aug 2003 18:14:27 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F414473.4050809@Royer.com> <3F4236C3.9030600@Royer.com> <3F4288BB.4090708@Royer.com> <3F42ABF5.2070101@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070709040101000309010100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070709040101000309010100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > Ok cool. Progress at least we are talking about the > same model where a fixed-id CUA is sending a current-value > CUA messages. I said no such thing. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070709040101000309010100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMDAwMTQyN1owIwYJKoZIhvcNAQkEMRYEFLma1Lx1 SuxpF/q6yOR9SD9Q4PUYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAKsdCIreofLqZ4BPhUnP7dwhObq27eUUEC4Z0t/KEwsCsJ4tvRnf 3/XD6EgE730rNV7811lcEDbtdtV9qR7NUEXz6vFN6R09j7YXRKB8tFEmJooa7Sn0MhmHwS3T JCMzGDA1FeBalIsrEkVpDkcsaZ7tlVqSshcss3WxuU4KOZT7Ipz+qSzElLV6cx+JRn2VHffy z6zT9oHh9bzS6LFOZkcZLjRuRH/YS0W+avVXzOuMxw2E/2QQW3Z+w4S5eyWyvGI3t/E6CBjs HwnN/MjpN8jumBlWTq0xSTYILszXtHTIfS1YsqR8xYfWsKaVotzCAD2mnBfiQ5T5/VNYwL8V Nl8AAAAAAAA= --------------ms070709040101000309010100-- From owner-ietf-calendar@mail.imc.org Tue Aug 19 21:07: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 VAA19310 for ; Tue, 19 Aug 2003 21:07:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K0rHqt041672 for ; Tue, 19 Aug 2003 17:53:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7K0rHmS041670 for ietf-calendar-bks; Tue, 19 Aug 2003 17:53:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K0rEqt041658 for ; Tue, 19 Aug 2003 17:53:15 -0700 (PDT) (envelope-from gic-ietf-calendar-597@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19pHEw-0001Ln-00 for ; Wed, 20 Aug 2003 02:54:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calendar@imc.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19pHEv-0001Lf-00 for ; Wed, 20 Aug 2003 02:54:17 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19pHDv-0003kL-00 for ; Wed, 20 Aug 2003 02:53:15 +0200 From: "Michael Fair" Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance Date: Tue, 19 Aug 2003 17:53:11 -0700 Lines: 32 Message-ID: References: <3F414473.4050809@Royer.com> <3F4236C3.9030600@Royer.com> <3F4288BB.4090708@Royer.com> <3F42ABF5.2070101@Royer.com> <3F42BD63.8000907@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:3F42BD63.8000907@Royer.com... > > > Michael Fair wrote: > > Ok cool. Progress at least we are talking about the > > same model where a fixed-id CUA is sending a current-value > > CUA messages. > > I said no such thing. Nice of you to clarify your own confusion about this. Now that you know you aren't disagreeing with what I was talking about but are instead disagreeing with your own misinterpretation of whatever it was you thought I said, perhaps you can reread my original description of the problem of why your interoperability assertment that the current-value model works with both fixed-id and current-value CUAs is broke and can formulate a more intelligible response. The current-value model cannot interoperate with fixed-id CUAs. It gets into an infinite REFRESH request loop when a fixed-id ORGANIZER reschedules the same instance more than once. It probably happens other times as well, but this is the most easily demonstrated. -- Michael -- From owner-ietf-calendar@mail.imc.org Tue Aug 19 21:50: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 VAA20715 for ; Tue, 19 Aug 2003 21:50:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K1Z3qt046908 for ; Tue, 19 Aug 2003 18:35:03 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7K1Z38j046907 for ietf-calendar-bks; Tue, 19 Aug 2003 18:35:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K1Z2qt046900 for ; Tue, 19 Aug 2003 18:35:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h7K1Z2S5012678 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 19 Aug 2003 18:35:03 -0700 Message-ID: <3F42D03F.3010509@Royer.com> Date: Tue, 19 Aug 2003 19:34:55 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance References: <3F414473.4050809@Royer.com> <3F4236C3.9030600@Royer.com> <3F4288BB.4090708@Royer.com> <3F42ABF5.2070101@Royer.com> <3F42BD63.8000907@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090807000505060203090308" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090807000505060203090308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Fair wrote: > "Doug Royer" wrote in message > news:3F42BD63.8000907@Royer.com... > >> >>Michael Fair wrote: >> >>>Ok cool. Progress at least we are talking about the >>>same model where a fixed-id CUA is sending a current-value >>>CUA messages. >> >>I said no such thing. > > > Nice of you to clarify your own confusion about this. I also said no such thing. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090807000505060203090308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMDAxMzQ1NlowIwYJKoZIhvcNAQkEMRYEFMQ9D9Dm qCRBsBjIPWdjOGZAvqhZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G CSqGSIb3DQEBAQUABIIBAGTvjv+6F/TOoU/Qd8cPeia31TJ3dxmcygvUiiBgOsPjQFRq8dJ1 f6jfvGmwwSXcwsccZK6o3pQT8lFKQlbAyyekorVTuGtzUmkWQN5Fl+19G93GCoyueq7sobwc NvY9SZTnuZdZWoIW+b39iKknr7H7FOxFlILkn5DJgzRugWgCIxzCeSsospIZGn1I3+X1HrDr jzdoht1gom4xSCJpmPUJnjzwUf6ay8JXMTUFnBhdJSYhE+G5jlfC43B9StlL32eSP6vwgNCX J4a4FgIsN+2w76LBILFex4g373pYj2/MI4i+U87MZ+EthL0Qjms+mvxZnLVLIRRo2/WSTRx1 gWYAAAAAAAA= --------------ms090807000505060203090308-- From owner-ietf-calendar@mail.imc.org Tue Aug 19 22:33:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22049 for ; Tue, 19 Aug 2003 22:33:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K29Oqt048783 for ; Tue, 19 Aug 2003 19:09:24 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7K29OrG048782 for ietf-calendar-bks; Tue, 19 Aug 2003 19:09:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K29Kqt048775 for ; Tue, 19 Aug 2003 19:09:23 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender)) by comcast.net (sccrmhc13) with SMTP id <2003082002091801600kmnobe> (Authid: TimHare); Wed, 20 Aug 2003 02:09:18 +0000 Message-Id: <5.2.1.1.0.20030819211020.00a074c0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 19 Aug 2003 22:07:25 -0400 To: IETF Calendaring and Scheduling Working Group From: Tim Hare Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance In-Reply-To: References: <3F414473.4050809@Royer.com> <3F4236C3.9030600@Royer.com> <3F4288BB.4090708@Royer.com> <3F42ABF5.2070101@Royer.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In a message, Michael Fair included the following:

--------------------------------------------------------------------------------------------------------------------------------------------
So let's step through this shall we:
1) I send recurring event E at SEQEUNCE N.
2) I send instance reschedule E1 at N+1 - Process just fine.
  -- CUA now thinks SEQUENCE for E is N+1.
  -- Redefines recurrence set of E to exclude DTSTART at N
     and to include DTSTART at N+1
3) I send instance reschedule E1' at N+2 - Can't process - wrong RID.
4) You send for a REFRESH.
----------------------------------------------------------------------

Perhaps I'm mistaken, but I DON'T think that the CUA  should/would
update the SEQUENCE value for the entire UID (recurrence set) when passed
an update for just one UID/RID combination. In fact, I believe that the
sender of the "updated" information MUST send an update to an
instance with the same SEQUENCE as the entire recurrence set, for any of
this to make sense. I don't know if that is in iTIP, I'm reasoning here -
I will look it up in iTIP but for now bear with me.

I will use this notation, which helps me think about this whole
recurrence set thing (and is borrowed/modified from set notation, so it's
sort of natural):

  Calendar item = UID = [SEQUENCE,RID1,RID2,... RID] for 1 to n
recurrence components. This general term includes non-recurring items
since n can be 1. Note that SEQUENCE is an attribute of the calendar item
and not of each recurrence instance (as I read/interpret iCal).

A calendar store contains a set of items {A,B,C,D,E} - using letters to
match up with Michael's example. For this discussion we will append the
sequence number to each item {A0,B2,C7,D0,E9). Sequence values chosen at
random, since they don't all have to be in lockstep of course.

If we want to change anything about a calendar item as a whole, we
increment SEQUENCE and send an update. For example, {A0,B2,C7,D0,E9}
=> {A1,B2,C7,D0,E9) when we update item A. In this example, of course,
the RIDs stay the same. If A consists of [RID1,RID2,RID3] then the set
can be expanded to:
{[RID1,RID2,RID3],B2,C7,D0,E9}.  According to iTIP this SEQUENCE
update MUST be done for a change to one of the following fields: DTSTART,
DTEND, DUE, RDATE, RRULE, EXDATE, EXRULE, STATUS. These are fields which
in essence change the whole item A0 - note that RDATE or RRULE in essence
perform a replace operation on [RID1,RID2, RID3]. SEQUENCE does NOT need
to be updated if you are updating a part of the set A0. And it is my
contention, that you should NOT update the sequence number as in
Michael's example above, or you DO end up with the problems he states. 

Updating something about one instance of A0, such as changing the time of
RID1 by itself does not require a SEQUENCE update according to iTIP 
(and I think it shouldn't have one, either). It does require that we send
an update and identify the specific instance, i.e. A[RID1]. 

In the fixed-recurrence-ID model, all of the fields which can be updated
in RID1 are _independent_ of the RID. The CUA sends the update with the
fixed RID, and updates its local store as well I assume. Everyone agrees
on what RID1 is because the ID is independent of the fields, and is equal
to the DTSTART of the instance of RID1 at SEQUENCE 0 (when it was
created).

In the changing-recurrence-ID model, the DTSTART field and the ID of RID1
are interdependent, because DTSTART is used as the ID and whenever it
changes, the RID changes. The CUA sends an update, updates its local
store, and in the process changed RID1's ID to RIDx because of the
DTSTART change. If the other end is ALSO using the changing-recurrence-ID
model, the recipient does much the same and both ends are in agreement.

However, interoperability doesn't work well if the ends are one of each
type - one end will change the ID and one will not, and from that point
forward, no one can agree about which instance of the event we're talking
about purely through RID - even though we can at least agree on the UID
we're talking about - to go back to the sets, we know that we want to
update an instance in A0 of {A0,B2,C7,D0,E9} but we with just RID we
can't agree on which of [RID1,RID2,RID3,RIDx] we're talking about.

One of Michael's suggestions during this discussion was to send the
recurrence set definition with every update (I think?) - but identifying
the item by UID and SEQUENCE is enough, since they uniquely identify the
item, and the recurrence definition is "just" a property of the
item. Where it comes in handy is if you are sent one instance of A - say,
A0[RID1] - and you want your local CUA to be smart enough to retain the
recurrence set even though only invited to one instance. This still
doesn't solve interoperability between the two different types of CUAs,
since it does you no good to know the recurrence set when what you want
to know is the specific RID. 

Again thinking logically and not referencing iTIP for specifics, I think
that one way to ensure interoperability is to allow RIDs to be _internal_
to each end, so that either model can be implemented at the endpoints,
and for updates to _one_ instance to require the DTSTART/DTEND or
DTSTART/DURATION of that particular instance. The beginning and end (or
length) of the instance are something that both ends can agree on,
whether or not they agree on the RID. If one follows the
"recommended practices" in iCal/iTIP then muliple instances
with the same start time and duration would be collapsed into one
instance anyway, so there should not be, within A, multiple RIDs with the
same start time and duration.  

To summarize and maybe clarify:

If you update a non-recurring item or the entire recurrence set, you
identify by UID and use SEQUENCE to identify versioning.

If you update one instance of a recurrence set, you identify by UID and
use the time properties of the instance to identify it. 

If you send an update with a sequence less than the sequence at the other
end, the "normal" methods for informing you that you're out of
date apply, and you refresh the entire item, not just one instance, since
SEQUENCE applies to an item and not to an instance of a recurrence set.

Hopefully this may provide a way forward from this point. If you want to
consider an alternate proposal, my other idea involves modification to
iCal to redefine RECURRENCE-ID to be the concatenation of DTSTART and
DTEND of the instance - the same effect as above, but requires us to go
back and change iCAL rather than redefining how iTIP works to match
recurrence-set instances.

Tim Hare






From owner-ietf-calendar@mail.imc.org  Tue Aug 19 22:45: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 WAA22327
	for ; Tue, 19 Aug 2003 22:45:39 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2Qsqt049245
	for ; Tue, 19 Aug 2003 19:26:54 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7K2QsFW049244
	for ietf-calendar-bks; Tue, 19 Aug 2003 19:26:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2Qqqt049232
	for ; Tue, 19 Aug 2003 19:26:52 -0700 (PDT)
	(envelope-from TimHare@comcast.net)
Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender))
          by comcast.net (sccrmhc13) with SMTP
          id <2003082002265001600kplgee>
          (Authid: TimHare);
          Wed, 20 Aug 2003 02:26:50 +0000
Message-Id: <5.2.1.1.0.20030819221406.00a1a360@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Tue, 19 Aug 2003 22:25:05 -0400
To: IETF Calendaring and Scheduling Working Group 
From: Tim Hare 
Subject: List quoting and content?
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: 


re: quoting -  Is it possible to remove quotations before receiving items 
from the mailing list? If I want to see what someone said previously I can 
go to the archives by thread (which is how I am having to catch up after a 
10 days travelling to/from a conference where I didn't have time to read 
the mailing list).

[gentle reminder]
re: content - I've seen some posts discussing writing iTIP to conform to 
current practices of major vendors. While I can appreciate that we don't 
want to vary too far from those (otherwise the vendors won't implement what 
is needed), as a person that is also an eventual  user/consumer of 
iCal/iTIP I think we should focus on making the protocols operate well, 
rather than operate as close as possible to current practice. In theory, 
the two should be nearly congruent, but when they're not, I think it's the 
responsibility of the Working Group to weigh in on the side of what will 
work well.  When the standards work is done - and I know it is hard work 
for all of you and I applaud you for that - if the protocols work well the 
products will work well, and people will buy them. If the products are 
hampered by the protocols, some or all  of the following things will happen:

A) The products will not work very well, and sales will suffer
B) Vendors will implement proprietary protocols, and we will be stuck where 
we were before, with calendar products which don't inter-operate.
C) Someone in the open-source community will develop a one-team standard 
which gets adopted because it _works_ and there will be _no_ sales.

So - let's not lose sight of the interoperability goal, or we will all lose.
[gentle reminder]






From owner-ietf-calendar@mail.imc.org  Wed Aug 20 02:17: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 CAA12252
	for ; Wed, 20 Aug 2003 02:17:04 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K5tTqt057903
	for ; Tue, 19 Aug 2003 22:55:29 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7K5tTDx057902
	for ietf-calendar-bks; Tue, 19 Aug 2003 22:55:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K5tPqt057890
	for ; Tue, 19 Aug 2003 22:55:27 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pLxG-0003M0-00
	for ; Wed, 20 Aug 2003 07:56:22 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19pLxF-0003Lm-00
	for ; Wed, 20 Aug 2003 07:56:21 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pLwG-0001FC-00
	for ; Wed, 20 Aug 2003 07:55:20 +0200
From: "Michael Fair" 
Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance
Date: Tue, 19 Aug 2003 22:55:09 -0700
Lines: 173
Message-ID: 
References:  <3F414473.4050809@Royer.com>  <3F4236C3.9030600@Royer.com>  <3F4288BB.4090708@Royer.com>  <3F42ABF5.2070101@Royer.com>  <5.2.1.1.0.20030819211020.00a074c0@mail.comcast.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: 



"Tim Hare"  wrote in message
news:5.2.1.1.0.20030819211020.00a074c0@mail.comcast.net...
> In a message, Michael Fair included the following:
>
> --------------------------------------------------------------------------
------------------------------------------------------------------
>
> So let's step through this shall we:
> 1) I send recurring event E at SEQEUNCE N.
> 2) I send instance reschedule E1 at N+1 - Process just fine.
>   -- CUA now thinks SEQUENCE for E is N+1.
>   -- Redefines recurrence set of E to exclude DTSTART at N
>      and to include DTSTART at N+1
> 3) I send instance reschedule E1' at N+2 - Can't process - wrong RID.
> 4) You send for a REFRESH.
> ----------------------------------------------------------------------
>
> Perhaps I'm mistaken, but I DON'T think that the CUA  should/would
> update the SEQUENCE value for the entire UID (recurrence set) when passed
> an update for just one UID/RID combination. In fact, I believe that the
> sender of the "updated" information MUST send an update to an
> instance with the same SEQUENCE as the entire recurrence set, for any of
> this to make sense. I don't know if that is in iTIP, I'm reasoning here -
> I will look it up in iTIP but for now bear with me.

Doug has been asserting for a while now that his current-value model
interoperates with both fixed-id and current-value models.
This discussion has mostly been about proving him to be inaccurate
in those beliefs.

Part of Doug's model is that the object is a single recurring event
and that the set definition and all instances share the same
SEQUENCE value.  This most recent (rather one sided) discussion has
been about me pointing out flaws in Doug's interoperability assertions
and him picking out implications I've suggested to which his response
is merely that he has said no such thing and saying nothing to either
refute or confirm what I've presented.

In truth, I say you're right, the SEQUENCE value for a recurring
event only updates when the set gets redefined.  This latest post
from Derik and Frank implicitly concurs with that assumption
because you need to track the base set definition and then
the instance modifications somewhat separately from each other.

Doug has different ideas and defends them rather vehemently.
Since the text isn't clear enough to definitely say one way
or another (but I think we're finally getting some clarity on
this) I've chosen to defend the model I believe iCal/iTIP
presents and bring forth flaws in the model Doug presents as
a matter of workflow discourse.  At each stage I ask him to
confirm or deny that's what his model would do and he has
thus far refuted nothing leaving me with that his model is
broken in several very serious ways as presented.

I had no investment either way about which model was right.
I even started out thinking the current-value model was the
right model.  However, through Bruce's well articulated
messages about the workflow flaws, I flipped sides.  My own
further investigation into this has uncovered different
and varied flaws throughout.  One of Doug's last remaining
assertions is that his model works with both models - but
it doesn't.  I'm attempting to engage him in a conversation
over these issues and thus far his pride has been bigger
than his brains.  I ordinarily wouldn't make such a discussion
this personal, but his complete disregard for respect of his
intelligence and his own abilities to confirm or deny the
workflow discourses presented combined with his propensity
to continue to flout his patently false assertions will
only continue to confuse people.  I suspect that his views
will also color any drafts he comes in contact with in regards
to how the SEQUENCE and RECURRENCE-ID properties come into
play which will make it a further headache for the working
group to constantly have to battle it out with him over
his wildly different views.


> In the fixed-recurrence-ID model, all of the fields which can be updated
> in RID1 are _independent_ of the RID. The CUA sends the update with the
> fixed RID, and updates its local store as well I assume. Everyone agrees
> on what RID1 is because the ID is independent of the fields, and is equal
> to the DTSTART of the instance of RID1 at SEQUENCE 0 (when it was
> created).

Not quite true.
It is the DTSTART as defined at SEQUENCE N, where N is the last
time the set was defined.  Adding instances, and redescribing
the series are two things that redefine the set causing a SEQUENCE
jump.  If you change all Mondays to be all Fridays instead, there
is no longer any DTSTART that is the same as what it was at
SEQUENCE 0 and by consequence there is no longer any object with
an RID that is the same as what it was at SEQUENCE 0.
Minor difference but has huge implications in terms of tracking
and storage.



> One of Michael's suggestions during this discussion was to send the
> recurrence set definition with every update (I think?)

This is limited to only the case where the CU is invited to a
subset of instances from the series and not the series itself.
Since it will not have the series description itself, it will
not have the ability to confirm the validity of an RID.

This is problematic if the entire series gets redescribed
(that whole Mondays to Fridays thing) because the RID in
the new series won't always match the RID from the old
series and the CU will have no way to tell that the object
it just received is an update to an existing event with an
old RID and not a new invite to a new instance with a
new RID.

This is the only time I suggested inclusion of the recurrence
set description because it's the only time a CUA would need
to be able to verify an RID without the presence of the base
event description.

Doug had proposed a model where you branched the UID into
multiple versions for each recipient depending on what set
that recipient was invited to.  This recommendation breaks
horribly if CUs invited to two different subsets of the same
UID try to forward or delegate to each other.  I've asked
Doug, or anyone else ot explain how these CUs can process
these request messages but have not yet seen any responses.



> Hopefully this may provide a way forward from this point. If you want to
> consider an alternate proposal, my other idea involves modification to
> iCal to redefine RECURRENCE-ID to be the concatenation of DTSTART and
> DTEND of the instance - the same effect as above, but requires us to go
> back and change iCAL rather than redefining how iTIP works to match
> recurrence-set instances.

Maintaining compatibility between the two models is not
something worth pursuing.  The fixed-id model as described in
iCal works exceedingly well in all cases save one small subcase
(where a CU is invited to a subset of instances only and the RIDs
change) which I'm sure has a resolution that I'm just not aware
of yet.

Doug just hasn't figured out how broke his assertions are yet,
or he just has too much pride to acknowledge he was wrong.

Either way, every assertion that Doug has put forth about
the workability of the current-value model, tracking SEQUENCE
as one value for all instances plus the base object, and how
to invite people to a particular instance are seriously flawed
in one way or another.

If he, or anyone else would like to have an intelligent
and reasonable discussion over the topics I'm all for it.
At every stage of the conversation I have been careful to
ensure that Doug's right to speak for his model has been
preserved and to ensure that I give him very clear and
specific workflows to work with.  I have cited iTIP and
iCal when appropriate to defend my claims and even given
him latitude to bend the rules a little as long as he can
bend them in such a way that all CUAs can be programmed to
get the right thing on the calendar and send the right
responses that can be matched up with the right events.

At some point though the conversation needs to stop and
the consensus needs to be reached.  I think it's pretty
evident by now that a current-value model and/or tracking
only one SEQUENCE for an entire recurring series are just
problematic in the environments that iCal/iTIP are committed
to working in.

-- Michael --





From owner-ietf-calendar@mail.imc.org  Wed Aug 20 11:33: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 LAA14750
	for ; Wed, 20 Aug 2003 11:33:20 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KFG1qt020678
	for ; Wed, 20 Aug 2003 08:16:01 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7KFG1XK020677
	for ietf-calendar-bks; Wed, 20 Aug 2003 08:16:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KFG0qt020672
	for ; Wed, 20 Aug 2003 08:16:00 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7KFFwS5018686
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 20 Aug 2003 08:15:59 -0700
Message-ID: <3F4390A8.1080003@Royer.com>
Date: Wed, 20 Aug 2003 09:15:52 -0600
From: Doug Royer 
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance
References:  <3F414473.4050809@Royer.com>  <3F4236C3.9030600@Royer.com>  <3F4288BB.4090708@Royer.com>  <3F42ABF5.2070101@Royer.com>  <5.2.1.1.0.20030819211020.00a074c0@mail.comcast.net> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020803080907070003090106"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms020803080907070003090106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Michael Fair wrote:

> ... I'm attempting to engage him in a conversation
> over these issues and thus far his pride has been bigger
> than his brains. 

It has to do with the fact that you keep mis-quoting me
which makes it not a debate, but a temper tantrum by
you when I will not participate in discussion that is
based on your outrageous mis-quotes.

-- 

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

                 We Do Standards - You Need Standards

--------------ms020803080907070003090106
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMDE1MTU1MlowIwYJKoZIhvcNAQkEMRYEFN6TwnUY
17Os3mWILO58esslm8IzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBABkQYIwfErir2+AmBWUnUOBqA9yK5ANPJeLCFn8xpdzX7ROAVvty
0FCcgYc2iiFLafKlwEWPtSft+Kl9bNnZW1xXa6/P7Jj1Kk5H6mU8wQoh5TrNWM6Ja+0ZvuBp
YQyzgL39dV2igCCYI+8xJIQdv8wObIOsgMtTzP+ihJ+/NvMc8B9FmToA8eX9J32FguV3HK4n
2HE2TUYWK7dvqVzuAevgt6xxT9bNvI51raC1qKi+VidJPnPQHpEak3DMvTUVWnzeMxJd25nQ
LI33Ad/J4i2WjEy/GTCxCbdMMQOefuj3kr5+3x3WsJDChj+jrVOXnsvlgxbR0A297oOb0dgt
sWcAAAAAAAA=
--------------ms020803080907070003090106--



From owner-ietf-calendar@mail.imc.org  Wed Aug 20 13:51: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 NAA25148
	for ; Wed, 20 Aug 2003 13:51:32 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHUMqt027527
	for ; Wed, 20 Aug 2003 10:30:22 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7KHUM0w027526
	for ietf-calendar-bks; Wed, 20 Aug 2003 10:30:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHUJqt027520
	for ; Wed, 20 Aug 2003 10:30:20 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pWno-0000sD-00
	for ; Wed, 20 Aug 2003 19:31:20 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19pWnn-0000s5-00
	for ; Wed, 20 Aug 2003 19:31:19 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pWmp-0003eu-00
	for ; Wed, 20 Aug 2003 19:30:19 +0200
From: "Michael Fair" 
Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance
Date: Wed, 20 Aug 2003 10:30:16 -0700
Lines: 99
Message-ID: 
References:  <3F414473.4050809@Royer.com>  <3F4236C3.9030600@Royer.com>  <3F4288BB.4090708@Royer.com>  <3F42ABF5.2070101@Royer.com>  <5.2.1.1.0.20030819211020.00a074c0@mail.comcast.net>  <3F4390A8.1080003@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:3F4390A8.1080003@Royer.com...
>
>
> Michael Fair wrote:
>
> > ... I'm attempting to engage him in a conversation
> > over these issues and thus far his pride has been bigger
> > than his brains.
>
> It has to do with the fact that you keep mis-quoting me
> which makes it not a debate, but a temper tantrum by
> you when I will not participate in discussion that is
> based on your outrageous mis-quotes.

I have merely stated that you have thus far refused to respond
to the workflows presented.  The intelligent person would just
give the requestor the response they are looking for to shut
them up about crying "flaw" where none exists.  If indeed there
was a flaw where the intelligent person had not seen one before,
they would acknowledge the flaw and look for ways to resolve it
if possible.  If there were no ways to resolve it they would
simply declare the model broken and deal with any cleanup of
existing documentation or implementations as best they could
and try and change the model to something stronger moving
forward.  The prideful person would feel disdain for the messenger,
refuse to address the issues, and try to ignore it.  The prideful
person would be too embarassed to acknowledge any kind of flaw
and would thus try and hide from the issues.

Thus far, you have refused to provide one scrap of defense
for the current-value model in any of the most recent flaws
about the current-value model where I have directly asked you
if this is what it would actually do.  You either have no
respect for me and my questions and thus do not feel any
compulsion to answer them (in which case I've shown you more
respect by giving you the opportunity to prove me wrong), or
you don't want to publicly admit that you've been wrong for
what is most likely years now and got deeply entrenched on
the losing side of an issue where you were the only real
defender of your side.

If I am misquoting you then it because I expect that your
responses are to the text I've actually presented on not
something off-topic from the problems I presented.

I presented the problem three times, you misunderstood it,
or are ignoring it and trying to focus on something else.

Once you start responding to the issues presented I won't
confuse your side-tangent answers with something that's
actually on-topic.  Once you start responding to the issues
you'll shut me up pretty quickly assuming you actually
present a consistent workflow.

If I'm misquoting you it's because I'm trying to relate the
answers you're giving with the context of the conversation
and trying to make sense of it.  I can stop that and just
start calling your answers senseless if you would prefer.

I'll ask again lest I be accused of being difficult.

You said that the current-value model interoperates with
both fixed-id and current-value CUAs.  I said no it doesn't
interoperate with fixed-id CUAs and here's proof.  A fixed-id
ORGANIZER will send these messages to your current-value CUA.
Your current-value CUA will process it in this manner resulting
in an infinite loop.

I've asked you three times to clarify what in your model
would prevent it from doing so and you have yet to respond.
Here's a fourth.  Doug what prevents the current-value CUA
from getting into an infinite loop when a fixed-id ORGANIZER
sends the messages I listed in my earlier posts?


Until we see a post from you with some meaningful content
in response to that you are simply trying to fantasize
that the problem doesn't exist or trying to ignore the
messenger as someone you just don't like.  The problem
isn't with me Doug, it's your model.  It's broke unless
you can somehow show us otherwise.

I'd truly like to believe that the current-value model can
interoperate.  I am very serious about that.

If it can, then we can just end this thread here and now and
let it be an implementor's decision.  But I can't because it
isn't.  Fixed-id is as close to being declared king as I think
this WG can get.  Current-value does not interoperate.  Therefore
it's not an implementor's choice and the sooner everyone here,
and this includes you Doug, gets on the same page about that
the sooner we can rest assured the confusion is going to get
cleaned up and the faster we can all agree on text to fix 2446.

-- Michael --





From owner-ietf-calendar@mail.imc.org  Wed Aug 20 14: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 OAA27066
	for ; Wed, 20 Aug 2003 14:23:09 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIAWqt030452
	for ; Wed, 20 Aug 2003 11:10:32 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7KIAWaX030451
	for ietf-calendar-bks; Wed, 20 Aug 2003 11:10:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIAVqt030445
	for ; Wed, 20 Aug 2003 11:10:31 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7KIATS5020648
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 20 Aug 2003 11:10:31 -0700
Message-ID: <3F43B990.7000101@Royer.com>
Date: Wed, 20 Aug 2003 12:10:24 -0600
From: Doug Royer 
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance
References:  <3F414473.4050809@Royer.com>  <3F4236C3.9030600@Royer.com>  <3F4288BB.4090708@Royer.com>  <3F42ABF5.2070101@Royer.com>  <5.2.1.1.0.20030819211020.00a074c0@mail.comcast.net>  <3F4390A8.1080003@Royer.com> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060908020103060405000901"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms060908020103060405000901
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Michael Fair wrote:
> "Doug Royer"  wrote in message
> news:3F4390A8.1080003@Royer.com...
> 
>>
>>Michael Fair wrote:
>>
>>
>>>... I'm attempting to engage him in a conversation
>>>over these issues and thus far his pride has been bigger
>>>than his brains.
>>
>>It has to do with the fact that you keep mis-quoting me
>>which makes it not a debate, but a temper tantrum by
>>you when I will not participate in discussion that is
>>based on your outrageous mis-quotes.
> 
> 
> I have merely stated that you have thus far refused to respond
> to the workflows presented. 

Now your mis-quoting your self.

-- 

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

                 We Do Standards - You Need Standards

--------------ms060908020103060405000901
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMDE4MTAyNFowIwYJKoZIhvcNAQkEMRYEFDrFzhax
krSycpUH8/YcN3t7XTy8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAKiZyY/yBXiW2uR+yA1cI7qXyC195oDCZgzooZ/CsS1FTcUqOCQQ
TCiK+WZtbRaWSe9cpjDG19pE6CiJIIVxfKbdaWlSVbbUWtZmzwHiFWgSwdeVje1HEkVoHeyS
wo6p3QV/iPX2g6zOAbjzt+Vte2UpImkq7cGlIvdjvIynW4FE4cg6N+arEIOrOlxKxIcMXLgw
8e6aW1jy9SWIEH4G2cUjqcxnVJSYH6aq/B7GS4QT5HL0O/cTSbuNvAZw4ZLHV2Y0Gmq3VIrC
xBLlfS6jswCvtVhLYfEMXlIWKctUPkCS+Q3laHGg78zhNGbggPuH8cg4f7PyNU9+0v8FsskN
UbsAAAAAAAA=
--------------ms060908020103060405000901--



From owner-ietf-calendar@mail.imc.org  Wed Aug 20 16:29: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 QAA08446
	for ; Wed, 20 Aug 2003 16:29:39 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKDEqt035207
	for ; Wed, 20 Aug 2003 13:13:14 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7KKDE7J035206
	for ietf-calendar-bks; Wed, 20 Aug 2003 13:13:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKDBqt035199
	for ; Wed, 20 Aug 2003 13:13:12 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pZLR-0002fG-00
	for ; Wed, 20 Aug 2003 22:14:13 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19pZLQ-0002f8-00
	for ; Wed, 20 Aug 2003 22:14:12 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pZKS-0000p4-00
	for ; Wed, 20 Aug 2003 22:13:12 +0200
From: "Michael Fair" 
Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance
Date: Wed, 20 Aug 2003 13:12:57 -0700
Lines: 69
Message-ID: 
References:  <3F414473.4050809@Royer.com>  <3F4236C3.9030600@Royer.com>  <3F4288BB.4090708@Royer.com>  <3F42ABF5.2070101@Royer.com>  <5.2.1.1.0.20030819211020.00a074c0@mail.comcast.net>  <3F4390A8.1080003@Royer.com>  <3F43B990.7000101@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:3F43B990.7000101@Royer.com...
>
>
> Michael Fair wrote:
> > "Doug Royer"  wrote in message
> > news:3F4390A8.1080003@Royer.com...
> >
> >>
> >>Michael Fair wrote:
> >>
> >>
> >>>... I'm attempting to engage him in a conversation
> >>>over these issues and thus far his pride has been bigger
> >>>than his brains.
> >>
> >>It has to do with the fact that you keep mis-quoting me
> >>which makes it not a debate, but a temper tantrum by
> >>you when I will not participate in discussion that is
> >>based on your outrageous mis-quotes.
> >
> >
> > I have merely stated that you have thus far refused to respond
> > to the workflows presented.
>
> Now your mis-quoting your self.

Prove it.  You can provide the proof right alongside the one
that doesn't put any CUA using your model in an infinite loop
once a fixed-id ORGANIZER moves the date of an instance for
the second time.  If you can prove it, I'll be happy to take
it back and stand corrected by you so long as you include it
with the important issues too.


Here's my defense for my quote:
I stated that you have thus far refused to respond to the
workflows presented, which is congruant with you having
pride bigger than your brains.
Until you provide something contrary to that - the argument
stands as posted.  This part of our argument is a waste of
disk space and more importantly a waste of the WG's time
and attention.


Why don't you just answer the question Doug?
What stops a CUA in your model from hitting an infinite loop?

I want you to be right about this.  I don't mind getting egg all
over my face for being wrong about this.  But most importantly
I want to stop wasting the working group's time and attention
and get an answer from that either confirms or refutes that
this is the actual behavior given your model interoperating
with a fixed-id model.

If you are so incompetent at reasonable argumentation that you
cannot send a response to this message that talks about
reccuring events, the current-value model CUA interoperating
with the fixed-id model, and infinite loops then please send
it to me personally and spare the list the agony of having
their time and attention wasted on your refusal to discuss the
issues as presented.  If you can only continue talking about
who's misquoting who I'll be happy to do it, just take it
offline and send it to me personally.

-- Michael --





From owner-ietf-calendar@mail.imc.org  Wed Aug 20 16:40: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 QAA08987
	for ; Wed, 20 Aug 2003 16:40:09 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKOgqt035609
	for ; Wed, 20 Aug 2003 13:24:42 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7KKOgIf035608
	for ietf-calendar-bks; Wed, 20 Aug 2003 13:24:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKOeqt035603
	for ; Wed, 20 Aug 2003 13:24:41 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pZWY-0002o5-00
	for ; Wed, 20 Aug 2003 22:25:42 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19pZWX-0002nx-00
	for ; Wed, 20 Aug 2003 22:25:41 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pZVZ-0001A8-00
	for ; Wed, 20 Aug 2003 22:24:41 +0200
From: "Michael Fair" 
Subject: Dealing with invites to individual instances
Date: Wed, 20 Aug 2003 13:24:26 -0700
Lines: 36
Message-ID: 
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: 


In the wake of Derik and Frank's generous post on
their understanding of how the iCal model works,
and at the risk of further disagreement, I have
a question about inviting CUs to individual
recurrences and not the entire series.


If I invite a CU using UID:1/RID:123/SEQ:0
and then reschedule UID:1 such that instance 123
is no longer a member of the recurrence set, how
do I communicate this change to the CU?

For arguments sake we'll say it got replaced
with RID:ABC.

As I understand it, the CU will never see UID:1
since they aren't invited to it and will only have
received messages about RID:123.

So when a message for RID:ABC shows up how will it
know that this object replaces RID:123 and is not
a new invite to RID:ABC in addition to RID:123?

Again this is strictly limited to when a CU is
not invited to the base recurring set.

Do you send them the base event anyway?
Do you have to cancel RID:123?
Is there something more that I'm missing?
Does something need to be added to iCal/iTIP to handle this case?


Thanks,
-- Michael --





From owner-ietf-calendar@mail.imc.org  Wed Aug 20 17:01: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 RAA10909
	for ; Wed, 20 Aug 2003 17:01:29 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKksqt036415
	for ; Wed, 20 Aug 2003 13:46:54 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7KKkrwR036414
	for ietf-calendar-bks; Wed, 20 Aug 2003 13:46:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKkqqt036409
	for ; Wed, 20 Aug 2003 13:46:52 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7KKkpS5022367
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 20 Aug 2003 13:46:53 -0700
Message-ID: <3F43DE36.4020607@Royer.com>
Date: Wed, 20 Aug 2003 14:46:46 -0600
From: Doug Royer 
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance
References:  <3F414473.4050809@Royer.com>  <3F4236C3.9030600@Royer.com>  <3F4288BB.4090708@Royer.com>  <3F42ABF5.2070101@Royer.com>  <5.2.1.1.0.20030819211020.00a074c0@mail.comcast.net>  <3F4390A8.1080003@Royer.com>  <3F43B990.7000101@Royer.com> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030005090406090300070704"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms030005090406090300070704
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Michael Fair wrote:

> 
> Prove it. 

no

I have added your email address to my spam filter. If anyone cares
about why I will no longer notice or respond to any of your emails to this
list.

-- 

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

                 We Do Standards - You Need Standards

--------------ms030005090406090300070704
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMDIwNDY0NlowIwYJKoZIhvcNAQkEMRYEFBjz7Jkd
U/S8fZCetMSPDGlFWkRnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAFDFf0nIHBBCdepCeJiM74oUSS5Pt9XCB6SXKA2djP00vAao3eiP
TGmDKzQUkrBv0E0PQnM8Gj2Oco5eT/mePScdfCnjkEiq4B4gFYDH3qg24So1/pTWoC6itoG+
P/X/WyHiQDRYLMuyyOuyQRawsTZonZ81otPt5zJBq8pNWFc1X2RGpl+n+0Z5CCGsQ/vIcg5I
UXhvm6m+r+UIj2Ddv7M0PbqeyObyVn8Qy0A6InMaeatSZgzRxLuucLs2oTAIxyJH4CjEat7H
F/86rZGYwmd6PSZGWveMyQi+TKLG9l7J5cuHRDe/kVfzj4jFhq7GpcVIMIm6shXhHO4+jGNE
MNsAAAAAAAA=
--------------ms030005090406090300070704--



From owner-ietf-calendar@mail.imc.org  Wed Aug 20 18:33: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 SAA16693
	for ; Wed, 20 Aug 2003 18:33:52 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMKcqt062001
	for ; Wed, 20 Aug 2003 15:20:38 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7KMKcR1062000
	for ietf-calendar-bks; Wed, 20 Aug 2003 15:20:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from DrPepper (adsl-67-119-131-54.dsl.lsan03.pacbell.net [67.119.131.54])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMKZqt061990
	for ; Wed, 20 Aug 2003 15:20:37 -0700 (PDT)
	(envelope-from michael@daclubhouse.net)
Received: by DrPepper (Postfix, from userid 65534)
	id 6C7BC8113E3; Wed, 20 Aug 2003 15:20:37 -0700 (PDT)
Received: from cocacola (unknown [192.168.1.102])
	by DrPepper (Postfix) with ESMTP
	id AD2BF81079E; Wed, 20 Aug 2003 15:20:35 -0700 (PDT)
Message-ID: <056a01c36769$4617d5a0$6601a8c0@daclubhouse.net>
From: "Michael Fair" 
To: "Mark Swanson" , 
References:  <200308201811.30423.mark@ScheduleWorld.com>
Subject: Re: Dealing with invites to individual instances
Date: Wed, 20 Aug 2003 15:20:33 -0700
Organization: DaClubhouse
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=-1.0 required=5.0
	tests=QUOTED_EMAIL_TEXT,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


> On August 20, 2003 4:24 pm, Michael Fair wrote:
>
> > If I invite a CU using UID:1/RID:123/SEQ:0
> > and then reschedule UID:1 such that instance 123
> > is no longer a member of the recurrence set, how
> > do I communicate this change to the CU?
> >
> > For arguments sake we'll say it got replaced
> > with RID:ABC.
> >
> > As I understand it, the CU will never see UID:1
> > since they aren't invited to it and will only have
> > received messages about RID:123.
>
> I'm not sure what you mean by 'relaced'. Do you mean cancel as in:
>
> 1. CANCEL RID:123
> 2. ADD RID:ABC

Yes, this is what we need the CUA to do, but I don't think we really want
to have to explicitly tell it to do so (However we wouldn't use "ADD"
we'd use "REQUEST").

I think we'd prefer to just be able to send the request for RID:ABC and
have the CUA figure out that it needs to cancel RID:123

The problem is I don't see what in the message for ABC tells it to remove
event 123.

> The CU _will_ see UID:1 as you said "If I invite a CU using UID:1"...
(typo?)
>
> Since the CU contains UID:1 the rest of your questions are answered,
right?

Well there are three events here:
UID:1/RID:NULL
UID:1/RID:123
UID:1/RID:ABC

The CU wasn't invited to the RID:NULL event (aka the entire series) so never
received a REQUEST for it.
And it's common practice not to include the recurrence set description in
messages
referring to just instances.

As a result of these two things, from what I can see, the CUA doesn't have a
way to
validate whether or not the RECURENCE-ID exists in the current set as
described
by the most recent RID:NULL (aka base description) event because it won't
have a
way to see what that set is.

-- Michael --



From owner-ietf-calendar@mail.imc.org  Wed Aug 20 19:06: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 TAA17982
	for ; Wed, 20 Aug 2003 19:06:45 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMtQqt063695
	for ; Wed, 20 Aug 2003 15:55:26 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7KMtQ2l063694
	for ietf-calendar-bks; Wed, 20 Aug 2003 15:55:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMtNqt063688
	for ; Wed, 20 Aug 2003 15:55:24 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pbsP-00055S-00
	for ; Thu, 21 Aug 2003 00:56:25 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19pbsP-00055K-00
	for ; Thu, 21 Aug 2003 00:56:25 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pbrQ-00051C-00
	for ; Thu, 21 Aug 2003 00:55:24 +0200
From: "Michael Fair" 
Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance
Date: Wed, 20 Aug 2003 15:55:20 -0700
Lines: 64
Message-ID: 
References:  <3F414473.4050809@Royer.com>  <3F4236C3.9030600@Royer.com>  <3F4288BB.4090708@Royer.com>  <3F42ABF5.2070101@Royer.com>  <5.2.1.1.0.20030819211020.00a074c0@mail.comcast.net>  <3F4390A8.1080003@Royer.com>  <3F43B990.7000101@Royer.com>  <3F43DE36.4020607@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: 


For the archives sake, it should be noted that Doug
has chosen to neither prove why I was misquoting
myself nor why his model is not interoperable and
results in an infinite loop.

He has instead chosen to ignore the messenger who
was simply trying to get him to focus on the issues
and respond to the workflows as posted.

While his decision is unfortunately not the kind of
closure we all hope for.  I am only left with that he
simply did not like me pressing him for an answer
because he felt I was not worth his time nor his
energy to share what should have been a simple
request, or that he was unable to comply with my
request and rather than admit he was wrong he
decided to ignore me instead.  His version of the
story would probably be that I was constantly
misqouting him.  I leave it to the readers of the
archives to decide.

Given the amount of careful consideration that
went in to formulating the request and that I
really wanted his model to be interoperable for
everyone's sake, I am more inclined to believe
that he simply could not provide any alternative
processing means to what I described and thereby
his CUA ends up in an infinite loop on the second
reschedule of an instance to a recurring event if
the ORGANIZER of that event is using a fixed-id
CUA to schedule the event thereby totally invalidating
any claims of interoperability between the two models.

And with that, I declare the discussion closed.

-- Michael --

"Doug Royer"  wrote in message
news:3F43DE36.4020607@Royer.com...
>
>
> Michael Fair wrote:
>
> >
> > Prove it.
>
> no
>
> I have added your email address to my spam filter. If anyone cares
> about why I will no longer notice or respond to any of your emails to this
> list.
>
> -- 
>
>   Doug Royer                     |   http://INET-Consulting.com
>   -------------------------------|-----------------------------
>   Doug@Royer.com                 | Office: (208)612-INET
>   http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                  |   Cell: (208)520-4044
>
>                  We Do Standards - You Need Standards
>





From owner-ietf-calendar@mail.imc.org  Wed Aug 20 20:24: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 UAA21456
	for ; Wed, 20 Aug 2003 20:24:34 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L09kqt065321
	for ; Wed, 20 Aug 2003 17:09:46 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7L09kAq065320
	for ietf-calendar-bks; Wed, 20 Aug 2003 17:09:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from DrPepper (adsl-67-119-131-54.dsl.lsan03.pacbell.net [67.119.131.54])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L09jqt065315
	for ; Wed, 20 Aug 2003 17:09:45 -0700 (PDT)
	(envelope-from michael@daclubhouse.net)
Received: by DrPepper (Postfix, from userid 65534)
	id 6DA13812C4A; Wed, 20 Aug 2003 17:09:47 -0700 (PDT)
Received: from cocacola (unknown [192.168.1.102])
	by DrPepper (Postfix) with ESMTP
	id DC30681079E; Wed, 20 Aug 2003 17:09:44 -0700 (PDT)
Message-ID: <05f401c36778$831a9640$6601a8c0@daclubhouse.net>
From: "Michael Fair" 
To: "Mark Swanson" , 
References:  <200308201811.30423.mark@ScheduleWorld.com> <056a01c36769$4617d5a0$6601a8c0@daclubhouse.net> <200308201921.49202.mark@ScheduleWorld.com>
Subject: Re: Dealing with invites to individual instances
Date: Wed, 20 Aug 2003 17:09:38 -0700
Organization: DaClubhouse
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=-1.0 required=5.0
	tests=QUOTED_EMAIL_TEXT,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


> On August 20, 2003 6:20 pm, Michael Fair wrote:
>
> >If I invite a CU using UID:1/RID:123/SEQ:0
> >and then reschedule UID:1 such that instance 123
> >is no longer a member of the recurrence set, how
> >do I communicate this change to the CU?
>
> Care to provide some enlightenment on why it would be important to have
the
> CANCEL performed automatically? Am I missing something obvious about the
> CANCEL/REQUEST (2 operations) vs performing it in one operation?

Because event RID:123 was implicitly canceled when it's RECURRENCE-ID
was removed from the set described by UID:1.  At no time was there an
explicit
cancel sent to anyone, further only people who are not invited to the base
event
need be explicitly made aware of such changes.

So here's the sequence of events in more context that might help.

You schedule UID:1 to be a recurring event, on of those instances is
identified by RID:123.  You then invite me to just instance RID:123.

You don't send me a REQUEST for the whole series (UID:1), you send me a
REQUEST for just the instance I'm invitied to (UID:1/RID:123).

You then reschedule the entire series and RID:123 is no longer in the
set and in its place you want RID:ABC.  This is no problem for anyone
who can see both recurrence set descriptions because they can see
that RID:123 is no longer in the set described by UID:1 and remove it
from their calendars.

But I have not seen the recurrence set desciption and still have RID:123 on
my
calendar.  Since I'm not an ATTENDEE of UID:1 proper I won't receive the
reschedule announcement for UID:1 and won't know to remove RID:123.

When a new event shows up referring to RID:ABC I won't know that it was
actually
as a result of a reschedule of UID:1 that resulted in RID:123 no longer
being a
valid event.  Assuming that remains true I'll just add RID:ABC as a second
instance
of UID:1 that I am invited to.

So what is just a single reschedule to everyone else, needs to be a
CANCEL and a REQUEST to me.  Or there needs to be some other
mechanism by which I can detect that RID:123 is no longer a member
of the recurrence set for UID:1.



-- Michael --



From owner-ietf-calendar@mail.imc.org  Wed Aug 20 21:11:24 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23425
	for ; Wed, 20 Aug 2003 21:11:24 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L102qt066385
	for ; Wed, 20 Aug 2003 18:00:02 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7L102Wv066384
	for ietf-calendar-bks; Wed, 20 Aug 2003 18:00:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L101qt066371
	for ; Wed, 20 Aug 2003 18:00:01 -0700 (PDT)
	(envelope-from mark@WebServiceSolutions.com)
Received: from lin.home2.mark (CPE0080c6e8c57c-CM014500005442.cpe.net.cable.rogers.com [24.157.60.247])
	by ns1.webservicesolutions.com (Postfix) with ESMTP
	id 82A914FE9; Thu, 21 Aug 2003 00:59:42 -0400 (EDT)
From: Mark Swanson 
Organization: Web Service Solutions, Inc.
To: "Michael Fair" , 
Subject: Re: Dealing with invites to individual instances
Date: Wed, 20 Aug 2003 21:01:15 -0400
User-Agent: KMail/1.5
References:  <200308201921.49202.mark@ScheduleWorld.com> <05f401c36778$831a9640$6601a8c0@daclubhouse.net>
In-Reply-To: <05f401c36778$831a9640$6601a8c0@daclubhouse.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200308202101.15756.mark@WebServiceSolutions.com>
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


On August 20, 2003 8:09 pm, you wrote:
> > On August 20, 2003 6:20 pm, Michael Fair wrote:
> > >If I invite a CU using UID:1/RID:123/SEQ:0
> > >and then reschedule UID:1 such that instance 123
> > >is no longer a member of the recurrence set, how
> > >do I communicate this change to the CU?
> >
> > Care to provide some enlightenment on why it would be important to have
>
> the
>
> > CANCEL performed automatically? Am I missing something obvious about the
> > CANCEL/REQUEST (2 operations) vs performing it in one operation?
>
> Because event RID:123 was implicitly canceled when it's RECURRENCE-ID
> was removed from the set described by UID:1.  At no time was there an
> explicit

Got it.

> cancel sent to anyone, further only people who are not invited to the base
> event
> need be explicitly made aware of such changes.

Agreed. I can't find anything in iTIP that notifies attendees of disappearing 
recurring instances. It would seem like the courtious thing to do would be to 
send a cancel/request to those attendees.


> So what is just a single reschedule to everyone else, needs to be a
> CANCEL and a REQUEST to me.  Or there needs to be some other
> mechanism by which I can detect that RID:123 is no longer a member
> of the recurrence set for UID:1.

I think you've made a good point. Doing a cancel/request means the problem is 
solved within the iTIP spec - and I've noticed that under those circumstances 
a very hot place would have to freeze over before iTIP would be modified to 
handle it differently. :-)

There's bound to be a number of little implementation details like this. It 
sure would be nice if they were captured in a common location.




-- 
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
Java Web start (JNLP):
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp



From owner-ietf-calendar@mail.imc.org  Wed Aug 20 21:58:45 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25347
	for ; Wed, 20 Aug 2003 21:58:44 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L1j3qt068016
	for ; Wed, 20 Aug 2003 18:45:03 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7L1j3Oj068015
	for ietf-calendar-bks; Wed, 20 Aug 2003 18:45:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L1j0qt068004
	for ; Wed, 20 Aug 2003 18:45:01 -0700 (PDT)
	(envelope-from TimHare@comcast.net)
Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender))
          by comcast.net (sccrmhc13) with SMTP
          id <2003082101385101600kuhpue>
          (Authid: TimHare);
          Thu, 21 Aug 2003 01:38:51 +0000
Message-Id: <5.2.1.1.0.20030820210834.00a193f0@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Wed, 20 Aug 2003 21:37:01 -0400
To: IETF Calendaring and Scheduling Working Group 
From: Tim Hare 
Subject: Re: Dealing with invites to individual instances
In-Reply-To: <200308202101.15756.mark@WebServiceSolutions.com>
References: <05f401c36778$831a9640$6601a8c0@daclubhouse.net>
 
 <200308201921.49202.mark@ScheduleWorld.com>
 <05f401c36778$831a9640$6601a8c0@daclubhouse.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: 


It seems to me that the rescheduling process, either of one instance, or of 
a whole recurrence set, should require the ORGANIZER to notify all 
ATTENDEEs.  Because we allow ATTENDEEs to be added to individual instances, 
there must be at least a partial expansion of the recurrence set to allow 
that - which in essence makes copies of the list of ATTENDEEs (one copy per 
instance),  which can be updated individually. However this is implemented 
by a product, rescheduling should process the entire list of ATTENDEEs and 
notify them, but what I think we're seeing is a place where it sort of 
breaks down..

Therefore, the sequence of events should go something like this, right?

1. ORGANIZER schedules UID:1;RID:123;SEQUENCE:0 for users X,Y, and Z.   In 
essence we have 3 copies of the attendee list, one for each of RIDs 1-3, 
with content (X,Y,Z)
2. Someone, probably ORGANIZER, invites user W to RID:3.  Now we have 
(X,Y,Z);(X,Y,Z);(X,Y,Z,W)  for our lists of attendees.
3. ORGANIZER reschedules UID:1 with RID:ABC and SEQUENCE:1 - SEQUENCE must 
be updated to reschedule. This REQUEST should be sent to all participants 
(X,Y,Z,W)
4. The CUA sees a REQUEST for UID:1, which it has, with SEQUENCE:1 which 
tells it that there's an update involved. This REQUEST includes the new 
recurrence definitions, via RDATE/RRULE/EDATE/ERULE, but no RID according 
to the protocol. Everyone can update their calendar with this... BUT it is 
"wrong" for W to do so. W is not invited to all of the events in the 
recurrence set; and perhaps should not even consider him/herself to be 
invited to any of the new set.

Since W is not explicitly invited to RID:ABC,  we could just say "don't 
send the update to W (or any single-instance attendee)" but that breaks 
because then W has RID:3 still on her/his calendar  when they don't need to 
attend!

The "proper" thing as near as I can reason, is to send the update to 
everyone (X,Y,Z,W) and when W sees the UID:1 SEQUENCE:1 without RID:3, W 
removes UID:1 from the calendar. Barring that, an explicit CANCEL needs to 
be sent to only W.  IF the ORGANIZER desires W to attend RID A,B, or C they 
need to issue a new REQUEST.

This is the only way that I see within iTIP as written to handle this issue 
successfully. It does require separate actions for W, but this can be 
automated during implementation if so desired - when the CUA of the 
ORGANIZER finds single-instance ATTENDEEs, it can prompt the CU to 
determine if they want to invite those people again, and to what instance, 
and generate the required REQUESTs.

Do we need to add this explicitly to iTIP?

Tim Hare




From owner-ietf-calendar@mail.imc.org  Wed Aug 20 23:31: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 XAA28788
	for ; Wed, 20 Aug 2003 23:31:29 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L3HNqt071482
	for ; Wed, 20 Aug 2003 20:17:23 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7L3HNEF071481
	for ietf-calendar-bks; Wed, 20 Aug 2003 20:17:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L3HJqt071476
	for ; Wed, 20 Aug 2003 20:17:21 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pfxt-0003eJ-00
	for ; Thu, 21 Aug 2003 05:18:21 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19pfxs-0003eB-00
	for ; Thu, 21 Aug 2003 05:18:20 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19pfwu-0001cz-00
	for ; Thu, 21 Aug 2003 05:17:20 +0200
From: "Michael Fair" 
Subject: Re: Dealing with invites to individual instances
Date: Wed, 20 Aug 2003 20:17:18 -0700
Lines: 63
Message-ID: 
References: <05f401c36778$831a9640$6601a8c0@daclubhouse.net>  <200308201921.49202.mark@ScheduleWorld.com> <05f401c36778$831a9640$6601a8c0@daclubhouse.net> <200308202101.15756.mark@WebServiceSolutions.com> <5.2.1.1.0.20030820210834.00a193f0@mail.comcast.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: 


Originally I was just thinking about one instance "123" which
was transformed to a new instance "ABC" but I can work with
what has been posted which changes the heart of the example
to be instance "3" either no longer exists or has been replaced
with instance "C".

Either way user "W" now needs to be informed of the update,
but user "W" has not been invited to UID:1 only to instance "3".



> Since W is not explicitly invited to RID:ABC,  we could just say "don't
> send the update to W (or any single-instance attendee)" but that breaks
> because then W has RID:3 still on her/his calendar  when they don't need
> to attend!

While I fully expect that if someone resequences a series, some
instance is going to replace whatever instance came prior, there
might be some merit in the logic.

If I change Mondays - Fridays there's still a 1-1 mapping for
the number of occurences, it was just easier to do that than
to reshcedule each instance.

However, at the moment I change Mondays - Fridays all instances
need to be deleted and recreated anyway.  As the ORGANIZER's CUA
runs through sending messages to the existing ATTENDEE's I see
no reason it couldn't send a CANCEL to all ATTENDEE's of an
instance for which the RECURRENCE-ID is no longer valid and who
is not invited to the base set.

It can then send a new REQUEST either intuitively with some direction
from the ORGANIZER or at the exlpicit instruction of the ORGANIZER.
It would be the CUA's responsibility to inform the ORGANIZER when
a reschedule like this impacts users this way.

> The "proper" thing as near as I can reason, is to send the update to
> everyone (X,Y,Z,W) and when W sees the UID:1 SEQUENCE:1 without RID:3, W
> removes UID:1 from the calendar. Barring that, an explicit CANCEL needs to
> be sent to only W.  IF the ORGANIZER desires W to attend RID A,B, or C
they > need to issue a new REQUEST.

I don't think user "W" should ever see a REQUEST for UID:1 without
a RECURRENCE-ID.  Even if not listed as an ATTENDEE the expected
behavior is that the CUA will think it's an invite to UID:1.



> Do we need to add this explicitly to iTIP?

I don't know.
If we do add new behavior to handle this case then I vote that
it just be made mandatory that the recurrence rules within which
the instance lives MUST be provided whenever the ATTENDEE is
not invited to the base set.  This would solve the problem neatly
because the new "C" REQUEST would describe a new set of dates
which did not include "3".  The CUA would then know that "3"
is no longer a valid RID and can remove it.

-- Michael --





From owner-ietf-calendar@mail.imc.org  Thu Aug 21 12:58: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 MAA14510
	for ; Thu, 21 Aug 2003 12:58:04 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGfYqt042340
	for ; Thu, 21 Aug 2003 09:41:34 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7LGfYU4042339
	for ietf-calendar-bks; Thu, 21 Aug 2003 09:41:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGfVqt042334
	for ; Thu, 21 Aug 2003 09:41:32 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7LGfPS5002084
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 21 Aug 2003 09:41:29 -0700
Message-ID: <3F44F62F.7020006@Royer.com>
Date: Thu, 21 Aug 2003 10:41:19 -0600
From: Doug Royer 
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Dealing with invites to individual instances
References:  <200308201921.49202.mark@ScheduleWorld.com> <05f401c36778$831a9640$6601a8c0@daclubhouse.net> <200308202101.15756.mark@WebServiceSolutions.com>
In-Reply-To: <200308202101.15756.mark@WebServiceSolutions.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080002000905060408080506"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms080002000905060408080506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Swanson wrote:

> 
> Agreed. I can't find anything in iTIP that notifies attendees of disappearing 
> recurring instances. It would seem like the courtious thing to do would be to 
> send a cancel/request to those attendees.

> 
> I think you've made a good point. Doing a cancel/request means the problem is 
> solved within the iTIP spec - and I've noticed that under those circumstances 
> a very hot place would have to freeze over before iTIP would be modified to 
> handle it differently. :-)

Your making it way too complicated. iTIP is a protocol to transfer information
to ATTENDEEs, it is not an extension of the CUA implementation. You
only have to convey the needed information to the ATTENDEE. There does
not need to be an all encompassing object that represents the state of
all ATTENDEEs status on the wire. Just send the effected ATTENDEEs
the information they need.

For:

   UID:U1
   SEQUENCE:S1
   with five instances (I1, I2, I3, I4, and I5).

If ATTENDEEs A1 and A2 are to have instance I1 removed from their
calendar and ATTENDEEs A3 and A4 are not, then bump the SEQUENCE number
in ORGANIZER cal store and send CANCEL:I1 to A1 and A2. You do not
need to send anything to A3 and A4. A1 and A2 reply:

    ORGANIZER now is at SEQUENCE:S1+1
    A1 last responded to SEQUENCE:S1+1
    A2 last responded to SEQUENCE:S1+1
    A3 last responded to SEQUENCE:S1
    A4 last responded to SEQUENCE:S1

    A3 and A4 last responded to SEQUENCE:S1 and it does not matter
    to A3 and A4 because nothing changed they need to care about.

    The ORGANIZER CUA only has to compare the current component
    (SEQUENCE:S1+1 in this example) to the change that the
    ORGANIZER-CU wishes. Simply compare the changes to the
    SEQUENCE:S1+1 object and see which ATTENDEEs it effects.

If later A3 is to be canceled from instance I2. The ORGANIZER-CUA looks
at the object and can tell that it only effects A3, so only
A3 is sent the CANCEL:I2 object. And A3 replies:

    ORGANIZER is now at SEQUENCE:S1+2.
    A1 last responded to SEQUENCE:S1+1
    A2 last responded to SEQUENCE:S1+1
    A3 last responded to SEQUENCE:S1+2
    A4 last responded to SEQUENCE:S1

Now for some reason A2 does a full or instance REFRESH,
so the ORGANIZER sends them an object (S1+2) as it effects A2.
There is no need or requirement that the S1+2 object sent to A3
above look exactly like the object now sent to A2 (for full
REFRESH the current object can use EXDATE, RDATE, RRULE, and
EXRULE to convey the current state of the object), and A2 replies:

    ORGANIZER is now at SEQUENCE:S1+2.
    A1 last responded to SEQUENCE:S1+1
    A2 last responded to SEQUENCE:S1+2
    A3 last responded to SEQUENCE:S1+2
    A4 last responded to SEQUENCE:S1

If later something changes that effects one or more ATTENDEEs.
Lets say all of them because the LOCATION changes. So the
ORGANIZER-CUA bumps the SEQUENCE number to S1+3. And
sends them to A1, A2, A3, and A4. And they reply.

    ORGANIZER is now at  SEQUENCE:S1+3
    A1 last responded to SEQUENCE:S1+3
    A2 last responded to SEQUENCE:S1+3
    A3 last responded to SEQUENCE:S1+3
    A4 last responded to SEQUENCE:S1+3

The ORGANIZER CUA only has to remember the last SEQUENCE number that
an ATTENDEE replied to so that the ORGANIZER/CUA/CU can determine
*IF* the ATTENDEE replied at all. It is NOT used for history.

If the current change effects an ATTENDEE in the 'current' (pre changed) 
object. And if it does send them the update information.

When you reschedule, you bump the SEQUENCE number. It makes the old
instances disappear - that is what a reschedule is. The same is true
of the update shown in iTIP. When the new updated UID is sent with
the new SEQUENCE, the old instances go away.

It does not matter if the ATTENDEE was invited to one or more instances.
It does not matter if the ATTENDEE was invited to the initial instance.
When the ORGANIZER needs to send an ATTENDEE an object - send them
what they need so that the ATTENDEE-CU can decide if they will attend.
No history needed.

The same is true for CANCEL. Simply send the effected ATTENDEEs
a full or instance CANCEL. If it does not effect other ATTENDEEs
then do not send them anything. If anyone does a REFRESH, send
them an object that represents the current ORGANIZER view of the
object as it effects that ATTENDEE.

> There's bound to be a number of little implementation details like this. It 
> sure would be nice if they were captured in a common location.


-- 

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

                 We Do Standards - You Need Standards

--------------ms080002000905060408080506
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq
MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MjExNjQxMTlaMCMGCSqGSIb3DQEJBDEWBBTI
pSFFzoq7g1+kbT4+X4Bg0TG5tDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ
KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv
c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy
aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs
aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8
oTANBgkqhkiG9w0BAQEFAASCAQBsq6nBs6zwCc/Dpbud+QzWL/RAQkcAdRbkApLbybXbSGT4
kgwGaeQn9yZl3Znv7BMLEt/BZPR0N7pG4reH1aiK0i3QhYognrS/rBoFvSE1c/H0xI2kVcpo
wEwb3uCYVZiRyu8kOu5jLfZIiKYRuOAthOhtkOZ2EHtAzdSdackuAQfk5vsovLeeoWJ6XSkF
GQp8JFKpECNUQJR0RvTgpD1HDY2jfba9Eovp1FCTkUkzhDbzhKi43iIjIN3EJE021kJ6ys0C
1HUtykisy0gjRuqI2BjRCwT36ZMQgfxEkW8AnCefIbYWEi5ImN9svuLIfisbRGsjxZUb9hha
gljvhQdWAAAAAAAA
--------------ms080002000905060408080506--



From owner-ietf-calendar@mail.imc.org  Thu Aug 21 13:06:15 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14872
	for ; Thu, 21 Aug 2003 13:06:15 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGoAqt042800
	for ; Thu, 21 Aug 2003 09:50:10 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7LGoApF042799
	for ietf-calendar-bks; Thu, 21 Aug 2003 09:50:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGo8qt042794
	for ; Thu, 21 Aug 2003 09:50:09 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7LGo7S5002254
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 21 Aug 2003 09:50:09 -0700
Message-ID: <3F44F839.5010200@Royer.com>
Date: Thu, 21 Aug 2003 10:50:01 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Dealing with invites to individual instances
References: <05f401c36778$831a9640$6601a8c0@daclubhouse.net>  <200308201921.49202.mark@ScheduleWorld.com> <05f401c36778$831a9640$6601a8c0@daclubhouse.net> <5.2.1.1.0.20030820210834.00a193f0@mail.comcast.net>
In-Reply-To: <5.2.1.1.0.20030820210834.00a193f0@mail.comcast.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060107040508010408040702"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms060107040508010408040702
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Tim Hare wrote:
> 
> It seems to me that the rescheduling process, either of one instance, or 
> of a whole recurrence set, should require the ORGANIZER to notify all 
> ATTENDEEs.  Because we allow ATTENDEEs to be added to individual 
> instances, there must be at least a partial expansion of the recurrence 
> set to allow that - which in essence makes copies of the list of 
> ATTENDEEs (one copy per instance),  which can be updated individually. 
> However this is implemented by a product, rescheduling should process 
> the entire list of ATTENDEEs and notify them, but what I think we're 
> seeing is a place where it sort of breaks down..

Why do you feel that unaffected ATTENDEEs need to see all changes?

In a worst case scenario no two ATTENDEEs would be attending the
same set of instances. Do you feel that is is a violation of iTIP
for the ORGANIZER to send each ATTENDEE (worst case) a unique
object tailored just for them?

-- 

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

                 We Do Standards - You Need Standards

--------------ms060107040508010408040702
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMTE2NTAwMVowIwYJKoZIhvcNAQkEMRYEFBSIlpsA
/WZZJS6PjyOdLl9RdJDWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAEtR6qRHH0jvCxiTi3G1fJbyu8YEWx/37dU2zrZ4p8ENa07ZpDYH
PqnZF9RR1CWiuEjTkRr3VWOt2mzpsFZRPLSfpVVnuS+LZPLyRREBOeQAFHelKgauWjqX1Ezv
9TSBK0cY7IS2zIoUgoSKZ7MJ1/d+OUZmsAp2zMbyRAXROBKOJZuyXEXU+mPYAdkxvsNzeVN8
85o4sQIXZyLDdZTsESEoSU6w4YZteHlAhEJTNDK0WfRrQ+vZJcFG2U/082G36JKisN/LVND7
VamlD4KJoVH/MbxTKs+617liGXJ1EeEf28vU0JZlXAeg7IQiFW++IPQ6YfZbdoDTE1RzupNr
wXYAAAAAAAA=
--------------ms060107040508010408040702--



From owner-ietf-calendar@mail.imc.org  Thu Aug 21 23:32: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 XAA18002
	for ; Thu, 21 Aug 2003 23:32:47 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M34qqt075506
	for ; Thu, 21 Aug 2003 20:04:52 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7M34qlT075505
	for ietf-calendar-bks; Thu, 21 Aug 2003 20:04:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M34oqt075500
	for ; Thu, 21 Aug 2003 20:04:50 -0700 (PDT)
	(envelope-from TimHare@comcast.net)
Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender))
          by comcast.net (rwcrmhc13) with SMTP
          id <20030822030047015007bc65e>
          (Authid: TimHare);
          Fri, 22 Aug 2003 03:00:47 +0000
Message-Id: <5.2.1.1.0.20030821224519.00a13ec0@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 21 Aug 2003 22:58:39 -0400
To: ietf-calendar@imc.org
From: Tim Hare 
Subject: Re: Dealing with invites to individual instances
In-Reply-To: <3F44F62F.7020006@Royer.com>
References: <200308202101.15756.mark@WebServiceSolutions.com>
 
 <200308201921.49202.mark@ScheduleWorld.com>
 <05f401c36778$831a9640$6601a8c0@daclubhouse.net>
 <200308202101.15756.mark@WebServiceSolutions.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: 


Doug - that was a fairly clear explanation, to me. If I am understanding 
things correctly, changing RID:123 to RID:ABC involves  a CANCEL operation 
for the first 3 RIDs (1,2,3) and an ADD operation for the other RIDs 
(A,B,C)  correct? Of course you don't have to ADD as many as you CANCEL or 
vice-versa. The only thing I have a quibble with here is the statement:

>The ORGANIZER CUA only has to remember the last SEQUENCE number that
>an ATTENDEE replied to so that the ORGANIZER/CUA/CU can determine
>*IF* the ATTENDEE replied at all. It is NOT used for history.

I don't think the ORGANIZER CUA has to remember the sequence number per 
attendee if it doesn't want to.... The ORGANIZER "owns" the UID and 
SEQUENCE values,  in a sense.  Because the ORGANIZER controls changes to 
the event represented by UID, it always has the most up-to-date and 
therefore the highest SEQUENCE.

On other related topics,  once I re-read iTIP/iCAL and understood that the 
UID should be globally unique for the event being scheduled/changed, then 
forwarding and delegation no longer seems to me to be a problem either -an 
event can be forwarded or delegated to another CUA - when/if it issues a 
REPLY then it will use the same UID and the ORGANIZER CUA becomes aware of 
that CUA's participation. If the delegated CUA never issues a REPLY then 
under iTIP I see no requirement for the ORGANIZER to worry about that CUA , 
since it can not be aware of it - correct?

Tim Hare 




From owner-ietf-calendar@mail.imc.org  Thu Aug 21 23:34: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 XAA18089
	for ; Thu, 21 Aug 2003 23:34:29 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M3HCqt075867
	for ; Thu, 21 Aug 2003 20:17:12 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7M3HCKN075866
	for ietf-calendar-bks; Thu, 21 Aug 2003 20:17:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M3HAqt075858
	for ; Thu, 21 Aug 2003 20:17:10 -0700 (PDT)
	(envelope-from TimHare@comcast.net)
Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender))
          by comcast.net (sccrmhc11) with SMTP
          id <2003082203133501100ol8fhe>
          (Authid: TimHare);
          Fri, 22 Aug 2003 03:13:35 +0000
Message-Id: <5.2.1.1.0.20030821230005.00a109a0@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 21 Aug 2003 23:11:42 -0400
To: "ietf-calendar@imc.org" 
From: Tim Hare 
Subject: Re: Dealing with invites to individual instances
In-Reply-To: <3F44F839.5010200@Royer.com>
References: <5.2.1.1.0.20030820210834.00a193f0@mail.comcast.net>
 <05f401c36778$831a9640$6601a8c0@daclubhouse.net>
 
 <200308201921.49202.mark@ScheduleWorld.com>
 <05f401c36778$831a9640$6601a8c0@daclubhouse.net>
 <5.2.1.1.0.20030820210834.00a193f0@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: 


I may have covered this in my other post, but I will cover it here just in 
case:

I do not think it is a violation of iTIP to send each ATTENDEE a unique 
object. As I have re-read the protocols, I don't think unaffected ATTENDEEs 
need to see all changes, unless the ATTENDEE is affected, then they MUST 
see the changes. Refering to my previous post, UID:1, RID:123 changed to 
UID:1, RID:ABC - since "W" is invited to instance 3,  W has to be notified 
when 3 disappears. Sending unique objects is, to me, a perfectly acceptable 
way to do it.

Tim Hare

At 10:50 AM 8/21/03 -0600, you wrote:


>Tim Hare wrote:
>>It seems to me that the rescheduling process, either of one instance, or 
>>of a whole recurrence set, should require the ORGANIZER to notify all 
>>ATTENDEEs.  Because we allow ATTENDEEs to be added to individual 
>>instances, there must be at least a partial expansion of the recurrence 
>>set to allow that - which in essence makes copies of the list of 
>>ATTENDEEs (one copy per instance),  which can be updated individually. 
>>However this is implemented by a product, rescheduling should process the 
>>entire list of ATTENDEEs and notify them, but what I think we're seeing 
>>is a place where it sort of breaks down..
>
>Why do you feel that unaffected ATTENDEEs need to see all changes?
>
>In a worst case scenario no two ATTENDEEs would be attending the
>same set of instances. Do you feel that is is a violation of iTIP
>for the ORGANIZER to send each ATTENDEE (worst case) a unique
>object tailored just for them?
>
>--
>
>  Doug Royer                     |   http://INET-Consulting.com
>  -------------------------------|-----------------------------
>  Doug@Royer.com                 | Office: (208)612-INET
>  http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                 |   Cell: (208)520-4044
>
>                 We Do Standards - You Need Standards
>
>




From owner-ietf-calendar@mail.imc.org  Thu Aug 21 23: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 XAA18242
	for ; Thu, 21 Aug 2003 23:37:30 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M3JGqt075939
	for ; Thu, 21 Aug 2003 20:19:16 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7M3JGdc075938
	for ietf-calendar-bks; Thu, 21 Aug 2003 20:19:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M3JDqt075933
	for ; Thu, 21 Aug 2003 20:19:14 -0700 (PDT)
	(envelope-from mark@ScheduleWorld.com)
Received: from lin.home2.mark (CPE0080c6e8c57c-CM014500005442.cpe.net.cable.rogers.com [24.157.60.247])
	by ns1.webservicesolutions.com (Postfix) with ESMTP id 24CD04FE9
	for ; Fri, 22 Aug 2003 03:18:55 -0400 (EDT)
From: Mark Swanson 
Organization: Web Service Solutions, Inc.
To: ietf-calendar@imc.org
Subject: Re: Dealing with invites to individual instances
Date: Thu, 21 Aug 2003 23:20:34 -0400
User-Agent: KMail/1.5
References:  <200308202101.15756.mark@WebServiceSolutions.com> <3F44F62F.7020006@Royer.com>
In-Reply-To: <3F44F62F.7020006@Royer.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200308212320.34374.mark@ScheduleWorld.com>
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


On August 21, 2003 12:41 pm, Doug Royer wrote:

> Your making it way too complicated. iTIP is a protocol to transfer
> information to ATTENDEEs, it is not an extension of the CUA implementation.
> You only have to convey the needed information to the ATTENDEE. There does
> not need to be an all encompassing object that represents the state of all
> ATTENDEEs status on the wire. Just send the effected ATTENDEEs the
> information they need.

I was agreeing with Michael's description, which seems to be identical to 
yours. Just send the affected ATTENDEEs the info they need...


-- 
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
Java Web start (JNLP):
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp



From owner-ietf-calendar@mail.imc.org  Fri Aug 22 06:13: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 GAA14817
	for ; Fri, 22 Aug 2003 06:13:02 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9aQqt016045
	for ; Fri, 22 Aug 2003 02:36:26 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7M9aQ7S016044
	for ietf-calendar-bks; Fri, 22 Aug 2003 02:36:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9aNqt016037
	for ; Fri, 22 Aug 2003 02:36:24 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19q8Lv-00079r-00
	for ; Fri, 22 Aug 2003 11:37:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19q8Lu-00079j-00
	for ; Fri, 22 Aug 2003 11:37:02 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19q8Kz-0004SN-00
	for ; Fri, 22 Aug 2003 11:36:05 +0200
From: "Michael Fair" 
Subject: Re: Dealing with invites to individual instances
Date: Fri, 22 Aug 2003 02:36:09 -0700
Lines: 96
Message-ID: 
References:  <200308202101.15756.mark@WebServiceSolutions.com> <3F44F62F.7020006@Royer.com> <200308212320.34374.mark@ScheduleWorld.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: 



"Mark Swanson"  wrote in message
news:200308212320.34374.mark@ScheduleWorld.com...
>
> On August 21, 2003 12:41 pm, Doug Royer wrote:
>
> > Your making it way too complicated. iTIP is a protocol to transfer
> > information to ATTENDEEs, it is not an extension of the CUA
implementation.
> > You only have to convey the needed information to the ATTENDEE. There
does
> > not need to be an all encompassing object that represents the state of
all
> > ATTENDEEs status on the wire. Just send the effected ATTENDEEs the
> > information they need.
>
> I was agreeing with Michael's description, which seems to be identical to
> yours. Just send the affected ATTENDEEs the info they need...

Doug is actually suggesting something different.

He is suggesting that instead of sending UID:1 with an RID,
don't send an RID at all.  Just send a UID 1 object with
the instance the ORGANIZER wants them to attend.

His reasoning is that the ORGANIZER is in control of the UID
and he can use the ATTENDEE field to figure out what instance
UID:1 means when user "W" sends back a REPLY.

The problem with this is when user "W" forwards or delegates
to user "Y" where "Y" has been invited to a different instance.

They both have the same UID on their calendar.
The UID's do not refer to the same event.
The CUAs must do the wrong thing no matter how they process it.

The case expands appropriately when they are invited to different
subsets of the recurring event described by UID:1.



Assuming for just a second that user "Y" could figure out what
was going on when "W" forwarded the event (not delegated, just
forwarded) when user "Y" sends a REPLY back to the ORGANIZER,
the ORGANIZER will looks in it's table and see the user "Y"/UID:1
is associated with instance "2" (for example).  But the REPLY
was actually for instance "3" which user "W" had forwarded to "Y".

The ORGANIZER has absolutely no way of reconciling this unless
he starts trying to match of DTSTART values.  But then this
gets into a whole messy situation when you start trying to track
different versions from different SEQUENCEs of these "unique"
events that really aren't all that unique.


Doug wants to overload the UID because he thinks he saves some
effort.  But in truth he breaks workflow.  The whole forwarding
and delgation thing aside for a moment, in his model, he can't
even tell if the CU ever received the latest update because in
his model the SEQUENCE number of the ATTENDEE doesn't need to
match the latest SEQUENCE actually sent.  So if an object
is at SEQUENCE:5 but the ATTENDEE response says SEQUENCE:3,
he can't tell if that's because the messages got lost in transit,
or if he never sent four and five because he didn't need to.

He'd have to keep track of SEQUENCE:3 and compare it to the current
version to find out if the changes between 3 and 5 affected this CU.


And the thing I love the most is even more simply than any of this,
if a user at SEQUENCE:3 tries to change their status and the
ORGANIZER has marched on to SEQUENCE:5 - a properly coded CUA should
ignore the SEQUENCE:3 reply and send them a SEQUENCE:5 update and
wait for their response.  This added trip could have been avoided
if he had just sent the SEQUENCE:5 update to begin with rather than
try and code in logic to detect whether or not a change affected
that CU or not.

These are just the low hanging fruits to pick on.
Things can get a lot uglier when you start dealing with out of
sequence responses to delegations, delegation and forwarding of
SEQUENCES between what the CU has and what the ORGANIZER has.


The main premise of Doug's model is that the CU never "spreads
the word" about the UID in question.  He assumes that all data
always gets back to the ORGANIZER before anyone else sees it.

The CUs can, will, and are allowed to delegate and forward to
their hearts content.  Spinning off per ATTENDEE UIDs with just
the info the CU needs introduces loads of confusion.
This approach is just plain stupid.

-- Michael --





From owner-ietf-calendar@mail.imc.org  Fri Aug 22 07: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 HAA17469
	for ; Fri, 22 Aug 2003 07:16:57 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MAvZqt023330
	for ; Fri, 22 Aug 2003 03:57:35 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MAvZsg023329
	for ietf-calendar-bks; Fri, 22 Aug 2003 03:57:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MAvYqt023320
	for ; Fri, 22 Aug 2003 03:57:34 -0700 (PDT)
	(envelope-from cco@asitturnsout.org)
Received: from webmail.asitturnsout.org (localhost [127.0.0.1])
	by albert.asitturnsout.org (Postfix) with ESMTP id 686468D7B5
	for ; Fri, 22 Aug 2003 03:57:33 -0700 (PDT)
From: "Chris Olds" 
To: ietf-calendar@imc.org
Subject: Re: Dealing with invites to individual instances
Date: Fri, 22 Aug 2003 03:57:33 -0700
Message-Id: <20030822105439.M38743@asitturnsout.org>
In-Reply-To: 
References:  <200308202101.15756.mark@WebServiceSolutions.com> <3F44F62F.7020006@Royer.com> <200308212320.34374.mark@ScheduleWorld.com> 
X-Mailer: Open WebMail 2.10 20030617
X-OriginatingIP: 206.124.156.51 (cco)
MIME-Version: 1.0
Content-Type: text/plain;
	charset=iso-8859-1
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


Since I know Doug won't see this, I'm going to try again (I thought I had
already explained this in an understandable way, but that's clearly not the case).

On Fri, 22 Aug 2003 02:36:09 -0700, Michael Fair wrote
> "Mark Swanson"  wrote in message
> news:200308212320.34374.mark@ScheduleWorld.com...
> >
> > On August 21, 2003 12:41 pm, Doug Royer wrote:
> >
> > > Your making it way too complicated. iTIP is a protocol to transfer
> > > information to ATTENDEEs, it is not an extension of the CUA
> > > implementation.
> > > You only have to convey the needed information to the ATTENDEE. There
> > > does not need to be an all encompassing object that represents the state
> > > of all ATTENDEEs status on the wire. Just send the effected ATTENDEEs
> > > the information they need.
> >
> > I was agreeing with Michael's description, which seems to be identical to
> > yours. Just send the affected ATTENDEEs the info they need...
>
> Doug is actually suggesting something different.
>
> He is suggesting that instead of sending UID:1 with an RID,
> don't send an RID at all.  Just send a UID 1 object with
> the instance the ORGANIZER wants them to attend.

This is correct.  The Organizer knows the entire event, including who is
invited to what, and what replies have been recieved.

> His reasoning is that the ORGANIZER is in control of the UID
> and he can use the ATTENDEE field to figure out what instance
> UID:1 means when user "W" sends back a REPLY.
>
> The problem with this is when user "W" forwards or delegates
> to user "Y" where "Y" has been invited to a different instance.

First, delegation is indicated by a message from the delegator and the
delegatee to the Organizer, each clearly marked with information about the
delegation.  If *any* of these messages are seen by the organizer, there is no
problem.  If the organizer misses them all, there is no problem (except that
the Organizing CU won't know of the subtitution).  Either way, no problem.

> They both have the same UID on their calendar.
> The UID's do not refer to the same event.
> The CUAs must do the wrong thing no matter how they process it.

You keep saying this, but without any basis, as far as I can see.

> The case expands appropriately when they are invited to different
> subsets of the recurring event described by UID:1.
>
> Assuming for just a second that user "Y" could figure out what
> was going on when "W" forwarded the event (not delegated, just
> forwarded) when user "Y" sends a REPLY back to the ORGANIZER,

Why couldn't Y figure out what happened?  Is there no indication that the
REQUEST was forwarded from W rather than sent direct from O (the organizer)?
If not, why not?  If that's the case, then anyone can masquerade as O.

> the ORGANIZER will looks in it's table and see the user "Y"/UID:1
> is associated with instance "2" (for example).  But the REPLY
> was actually for instance "3" which user "W" had forwarded to "Y".

This is clearly defined as a "party crasher" scenario in iTIP.  

> The ORGANIZER has absolutely no way of reconciling this unless
> he starts trying to match of DTSTART values.  But then this
> gets into a whole messy situation when you start trying to track
> different versions from different SEQUENCEs of these "unique"
> events that really aren't all that unique.

Yes, those messy and hard to deal with DTSTART values.  Good thing we have
RIDs to handle this problem.... wait a sec!  RECURRENCE-IDs have the same type
as DTSTART values - how is this harder to deal with than getting a REPLY with
a RID?  It's *exactly* the same data, and just as easy to match & track.  I
would expect a CUA to track exactly what each participant has been invited to,
so this seems like basic functionality to me.

> Doug wants to overload the UID because he thinks he saves some
> effort.  But in truth he breaks workflow.  The whole forwarding
> and delgation thing aside for a moment, in his model, he can't
> even tell if the CU ever received the latest update because in
> his model the SEQUENCE number of the ATTENDEE doesn't need to
> match the latest SEQUENCE actually sent.  So if an object
> is at SEQUENCE:5 but the ATTENDEE response says SEQUENCE:3,
> he can't tell if that's because the messages got lost in transit,
> or if he never sent four and five because he didn't need to.

So you're positing a CUA that can avoid sending unneeded messages to
attendees, but is not capable of retaining that fact?  Why?  If the CUA knows
that it sent a SEQ:3 REQUEST to a CU, then it expects a SEQ:3 response.  If
the current SEQ value of the object is at 5, but the last two changes didn't
affect a particular CU, then the SEQ:3 response is as good as a SEQ:5 response
from that CU.  How does the CUA know?  By not throwing away the information
that it avoided sending the extra messages.

> He'd have to keep track of SEQUENCE:3 and compare it to the current
> version to find out if the changes between 3 and 5 affected this CU.

No.  He'd have to see of the SEQ:3 RESPONSE covered all of the SEQ:5 instances
that the CU was invited to, and if they did, that's then end of it.  If the
orgainzer keeps track of the last SEQ value sent to a particular CU, then he
knows what SEQ he needs on a response for it to be valid & complete. Easy.

> And the thing I love the most is even more simply than any of this,
> if a user at SEQUENCE:3 tries to change their status and the
> ORGANIZER has marched on to SEQUENCE:5 - a properly coded CUA should
> ignore the SEQUENCE:3 reply and send them a SEQUENCE:5 update and
> wait for their response.  

Chapter and verse on this?  I know where it says stale REQUESTs should be
discarded; where is the similar language for REPLY objects?

> This added trip could have been avoided
> if he had just sent the SEQUENCE:5 update to begin with rather than
> try and code in logic to detect whether or not a change affected
> that CU or not.

This is not an added trip - it's the one you're saying is required, and Doug's
smart CUA was trying to avoid.  So, AT WORST, it's the same number of messages
as you would mandate every CUA send.  That's why it's an optimization; it
makes no difference to the protocol outcome.

> These are just the low hanging fruits to pick on.
> Things can get a lot uglier when you start dealing with out of
> sequence responses to delegations, delegation and forwarding of
> SEQUENCES between what the CU has and what the ORGANIZER has.

Delegated events are clearly marked, and mentioning them is a red herring.

> The main premise of Doug's model is that the CU never "spreads
> the word" about the UID in question.  He assumes that all data
> always gets back to the ORGANIZER before anyone else sees it.

This is not true, and has not been demonstrated.

> The CUs can, will, and are allowed to delegate and forward to
> their hearts content.  Spinning off per ATTENDEE UIDs with just
> the info the CU needs introduces loads of confusion.

Not if the CUA is capable of retaining information about what iCal objects
have been sent, and to whom.  I wouldn't think this a terrible burden for a CUA.

> This approach is just plain stupid.

Yes, the approach you have postulated is stupid.  You say that a CUA is broken
unless it can match up messages with no recollection of what was sent (content
and SEQ), and can operate correctly when either a) no messages ever reach the
Attendee or b) no messages ever make it back to the Organizer.  Any CUA that
can always produce correct results under these conditions is magic, and should
sell well, once successfully demonstrated...

Real CUAs can look up dates.  Real CUAs can remember what SEQ value was last
sent to (and is therefore expected from) and Attendee.  Real CUAs that can
send invite an Attendee to a subset of an event can build custom REQUEST
objects should be able to match up the REPLY correctly without needing a
different UID (and if they can't, they could just internally generate a UID
per custom invite without the Organizing CU knowing or caring).

I hope you read the whole message this time.  Last time, I used a surprise
party to show why a CU might want his CUA to generate custom objects, all with
the same UID, and you ignored it.  You should take a deep breath, read the
whole thing again, and only then should you respond.

   /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)



From owner-ietf-calendar@mail.imc.org  Fri Aug 22 11:44: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 LAA03577
	for ; Fri, 22 Aug 2003 11:43:59 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFKvqt043390
	for ; Fri, 22 Aug 2003 08:20:57 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MFKvDw043389
	for ietf-calendar-bks; Fri, 22 Aug 2003 08:20:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166] (may be forged))
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFKuqt043212
	for ; Fri, 22 Aug 2003 08:20:56 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7MFJdS5016769
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Fri, 22 Aug 2003 08:19:41 -0700
Message-ID: <3F463486.2000902@Royer.com>
Date: Fri, 22 Aug 2003 09:19:34 -0600
From: Doug Royer 
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Dealing with invites to individual instances
References: <200308202101.15756.mark@WebServiceSolutions.com>  <200308201921.49202.mark@ScheduleWorld.com> <05f401c36778$831a9640$6601a8c0@daclubhouse.net> <200308202101.15756.mark@WebServiceSolutions.com> <5.2.1.1.0.20030821224519.00a13ec0@mail.comcast.net>
In-Reply-To: <5.2.1.1.0.20030821224519.00a13ec0@mail.comcast.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040400080800030002030001"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms040400080800030002030001
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Tim Hare wrote:
> 
> Doug - that was a fairly clear explanation, to me. If I am understanding 
> things correctly, changing RID:123 to RID:ABC involves  a CANCEL 
> operation for the first 3 RIDs (1,2,3) and an ADD operation for the 
> other RIDs (A,B,C)  correct? Of course you don't have to ADD as many as 
> you CANCEL or vice-versa. The only thing I have a quibble with here is 
> the statement:

It does not need to involve a cancel explicitly.

A CANCEL does not *need* to be sent.

So the ORGANIZER could:

   (a) SEND 3 single instance CANCELs
       SEND 3 ADDs

       GET 6 REPLYs

       (2) round trips (you can not mix METHOD values
           in one iMIP packet or one CAP MIME object.

.OR.

   (b) SEND 3 instance modifications.

       GET 3 REPLYs

       (1) round trip

.OR.

   (c) SEND an entire new object to the effected ATTENDEEs.

       GET 1 REPLY

       (1) round trip

The risk of (a) is that they could be rescheduled between the
CANCEL and the ADD. If the ATTENDEEs are resources and not people, that
might be a critical issue.

If done via iMIP the round trips account for more time.

>> The ORGANIZER CUA only has to remember the last SEQUENCE number that
>> an ATTENDEE replied to so that the ORGANIZER/CUA/CU can determine
>> *IF* the ATTENDEE replied at all. It is NOT used for history.
> 
> 
> I don't think the ORGANIZER CUA has to remember the sequence number per 
> attendee if it doesn't want to.... The ORGANIZER "owns" the UID and 
> SEQUENCE values,  in a sense.  Because the ORGANIZER controls changes to 
> the event represented by UID, it always has the most up-to-date and 
> therefore the highest SEQUENCE.

That is all true. What if the ORGANIZER *never* gets a METHOD:REPLY
from one or more ATTENDEEs?

Without remembering which ATTENDEE replied, the ORGANIZER could not
have the information in order to decide who to re-send a REQUEST.
In some situations the ORGANIZER will need to resend, in others
it could be considered an implicit "no thanks".

> On other related topics,  once I re-read iTIP/iCAL and understood that 
> the UID should be globally unique for the event being scheduled/changed, 
> then forwarding and delegation no longer seems to me to be a problem 
> either -an event can be forwarded or delegated to another CUA - when/if 
> it issues a REPLY then it will use the same UID and the ORGANIZER CUA 
> becomes aware of that CUA's participation. If the delegated CUA never 
> issues a REPLY then under iTIP I see no requirement for the ORGANIZER to 
> worry about that CUA , since it can not be aware of it - correct?

True, the ORGANIZER never *has* to worry. It is an application specific
requirement and not an iTIP requirement.

-- 

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

                 We Do Standards - You Need Standards

--------------ms040400080800030002030001
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMjE1MTkzNFowIwYJKoZIhvcNAQkEMRYEFPYVhV7f
FlDq1JZV/mHUptw8nm9sMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAINoww8RQB0weexy/QaA7+KzPTSY3XP5V8rY0O+JLfXd6+CdwZg/
O5Y+L6nJv168nGnz3SfeEUoRzGZbF6rER+m7WVW9bpdxsKc4TUIsNVFQ773G0xcair3XnSuM
RtsiCX5f9pl6gW5FxIerEQ8x9nvSDJD+OOjhrO1NOYK4KT9tfzCpm90X4Rj2oPtvxz1c9xxh
vSsjmQeI/5JM7boUvCutBFYo/munF63bM9yezqeBNoB8zIHsdV4Bm8pSGNq1JLYa9j/8aDfY
Vw5bTLGDN5Uk+URIILnUGenNrYo50joeRK+YsWXi2a3+3b0Fe3Wkyph8D+OfRXFfrJaOeLtC
i1YAAAAAAAA=
--------------ms040400080800030002030001--



From owner-ietf-calendar@mail.imc.org  Fri Aug 22 12:41: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 MAA06283
	for ; Fri, 22 Aug 2003 12:41:48 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGJjqt047286
	for ; Fri, 22 Aug 2003 09:19:45 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MGJjWq047285
	for ietf-calendar-bks; Fri, 22 Aug 2003 09:19:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGJiqt047278
	for ; Fri, 22 Aug 2003 09:19:44 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
To: "ietf-calendar@imc.org" 
Subject: Re: Dealing with invites to individual instances
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Fri, 22 Aug 2003 12:12:59 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/22/2003
 12:19:25 PM,
	Serialize complete at 08/22/2003 12:19:25 PM
Content-Type: multipart/alternative; boundary="=_alternative 0058AB6C85256D8A_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0058AB6C85256D8A_=
Content-Type: text/plain; charset="US-ASCII"

The ONLY TIME  a recurrence-id changes as when you can not map the 
existing set to the new set.
i.e repeats every Monday  becomes repeats every Monday and Thursday.

A reschedule of all the instances in a set is semantically equivalent to 
rescheduling each individual instance, thus the recurrence-id's remain 
fixed.

--=_alternative 0058AB6C85256D8A_=
Content-Type: text/html; charset="US-ASCII"



The ONLY TIME  a recurrence-id
changes as when you can not map the existing set to the new set.

i.e repeats every Monday  becomes
repeats every Monday and Thursday.



A reschedule of all the instances in
a set is semantically equivalent to rescheduling each individual instance,
thus the recurrence-id's remain fixed.


--=_alternative 0058AB6C85256D8A_=--


From owner-ietf-calendar@mail.imc.org  Fri Aug 22 13:24: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 NAA08334
	for ; Fri, 22 Aug 2003 13:24:18 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH0Dqt048594
	for ; Fri, 22 Aug 2003 10:00:13 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MH0Dh3048593
	for ietf-calendar-bks; Fri, 22 Aug 2003 10:00:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH0Cqt048588
	for ; Fri, 22 Aug 2003 10:00:12 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7MH0BS5017831
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Fri, 22 Aug 2003 10:00:12 -0700
Message-ID: <3F464C15.9000604@Royer.com>
Date: Fri, 22 Aug 2003 11:00:05 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Dealing with invites to individual instances
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020209000202000405030501"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms020209000202000405030501
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> The ONLY TIME  a recurrence-id changes as when you can not map the 
> existing set to the new set.
> i.e repeats every Monday  becomes repeats every Monday and Thursday.

Are you sure it does not change at random?

> A reschedule of all the instances in a set is semantically equivalent to 
> rescheduling each individual instance, thus the recurrence-id's remain 
> fixed.

Can you back that up from any text in any RFC?

-- 

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

                 We Do Standards - You Need Standards

--------------ms020209000202000405030501
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMjE3MDAwNVowIwYJKoZIhvcNAQkEMRYEFEZuByx8
UGqL2+DrCNsLxaFXIPZgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAKbOa53ZmMV6HdQBooRbAoKwDGh1hewsAApCf705QoULO49yi78y
azIqaSy8l1Ze6rB1agqO3T2miVC6jDAS3AEmZqYpgcCU2V/g14W0NA4a3ShJaJUZ2Z9hvhE8
+AVjVX4hMJNYGbn3MU9+Yv/L4IbZdqw1N5QCdTRmedU+YJ2hnrtKa5RVYoGwdQgN8QA+VfqL
KZNxKKdPUMEL3rcS3pBZiFGOgLYAK5dxOWjReS4Nq1LdJXLR2c1zWCyTq+QKW7kx2p+WYkBl
m9CJFCRByU4drp4p+a2SawPefMfGN3PxrH2k5Rvuu2W24usXa6uJ2gyuMT74gkNI97KTlnbD
3mMAAAAAAAA=
--------------ms020209000202000405030501--



From owner-ietf-calendar@mail.imc.org  Fri Aug 22 13:31: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 NAA08581
	for ; Fri, 22 Aug 2003 13:31:51 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHA1qt048915
	for ; Fri, 22 Aug 2003 10:10:01 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MHA1S0048914
	for ietf-calendar-bks; Fri, 22 Aug 2003 10:10:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH9xqt048901
	for ; Fri, 22 Aug 2003 10:09:59 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7MH9wS5017920
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Fri, 22 Aug 2003 10:10:00 -0700
Message-ID: <3F464E61.9080406@Royer.com>
Date: Fri, 22 Aug 2003 11:09:53 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Dealing with invites to individual instances
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050509020002070307030102"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms050509020002070307030102
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
>
> A reschedule of all the instances in a set is semantically equivalent to 
> rescheduling each individual instance, thus the recurrence-id's remain 
> fixed.

So your first invitation is to:

	UID:100
	SEQUENCE:0
	DATE:...sep-1...10am...

Then you get:

	UID:100
	SEQUENCE:1
	RRULE;FREQ=DAILY;COUNT=10
	DTSTART:...sep-2...3pm

What is the RECURRENCE-ID for the 1st object?
   ...sep-1...10am... Correct?

So which of the 10 instances has its RECURRENCE-ID fixed to the 1st object?
What are the 10 RECURRENCE-ID's for the 2nd object?

-- 

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

                 We Do Standards - You Need Standards

--------------ms050509020002070307030102
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMjE3MDk1M1owIwYJKoZIhvcNAQkEMRYEFDrsDi+Z
Zq88cxrFBZoPJkRnazGRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAFIt3d3RvbKDIujRTrqzf+HPQcYCGNH+iBgqDt68hU0b83v9nAgO
KZZsymc9phh1JbkhUtkr8NtOcLMmEVpaN3N74FZtM9oDBSnVoY+gqCQTOvdkUEC+9LBTCtJ4
kH8N1c7EvlSG0bvcLnia1XsxnjUZWfCjf2g22SZ9ur9XjahC5cPqAgUFvMV5h9Ct+MmRSaHI
XHUE9iU+atIEjx8J6wWTPWlvZylcxsFnuLM3mCjldF7z+HT6gWV261KENV66bpBtERy1Qv55
BSHc6N+EM6dxLi/DNwiRuZeQL57VN6oHTIDx7BmOqymFgDi6o4EXa7Tvgh4DjAL26ayPD1n0
YMsAAAAAAAA=
--------------ms050509020002070307030102--



From owner-ietf-calendar@mail.imc.org  Fri Aug 22 14:02:32 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10739
	for ; Fri, 22 Aug 2003 14:02:30 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHiYqt050408
	for ; Fri, 22 Aug 2003 10:44:34 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MHiY3G050407
	for ietf-calendar-bks; Fri, 22 Aug 2003 10:44:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHiXqt050396
	for ; Fri, 22 Aug 2003 10:44:34 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F464C15.9000604@Royer.com>
To: "ietf-calendar@imc.org" 
Cc: "ietf-calendar@imc.org" ,
        owner-ietf-calendar@mail.imc.org
Subject: Re: Dealing with invites to individual instances
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Fri, 22 Aug 2003 13:47:50 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/22/2003
 01:44:11 PM,
	Serialize complete at 08/22/2003 01:44:11 PM
Content-Type: multipart/alternative; boundary="=_alternative 00610D7985256D8A_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 00610D7985256D8A_=
Content-Type: text/plain; charset="US-ASCII"

Doug you are insane and should be treated as a spamer.  Don't start this 
again.
See long previous discussion and posting by this group.

Derik Stenerson wrote 
>>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. 

As long as the reschedule can be treated as semantically equivalent to 
changing instance dates, the original pattern has not changed and thus the 
recurrence-ids do not change.

_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/22/2003 01:00 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Dealing with invites to individual instances








Robert_Ransdell@notesdev.ibm.com wrote:
> 
> The ONLY TIME  a recurrence-id changes as when you can not map the 
> existing set to the new set.
> i.e repeats every Monday  becomes repeats every Monday and Thursday.

Are you sure it does not change at random?

> A reschedule of all the instances in a set is semantically equivalent to 

> rescheduling each individual instance, thus the recurrence-id's remain 
> fixed.

Can you back that up from any text in any RFC?

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 00610D7985256D8A_=
Content-Type: text/html; charset="US-ASCII"



Doug you are insane and should be
treated as a spamer.  Don't start this again.

See long previous discussion and
posting by this group.



Derik Stenerson wrote 

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



As long as the reschedule can be treated
as semantically equivalent to changing instance dates, the original pattern
has not changed and thus the recurrence-ids do not change.



_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/22/2003 01:00 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Dealing with invites
to individual instances





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

> The ONLY TIME  a recurrence-id changes as when you can not map
the 

> existing set to the new set.

> i.e repeats every Monday  becomes repeats every Monday and Thursday.



Are you sure it does not change at random?



> A reschedule of all the instances in a set is semantically equivalent
to 

> rescheduling each individual instance, thus the recurrence-id's remain


> fixed.



Can you back that up from any text in any RFC?



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 00610D7985256D8A_=--


From owner-ietf-calendar@mail.imc.org  Fri Aug 22 14:48: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 OAA13043
	for ; Fri, 22 Aug 2003 14:48:57 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MIPCqt051859
	for ; Fri, 22 Aug 2003 11:25:12 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MIPCpR051858
	for ietf-calendar-bks; Fri, 22 Aug 2003 11:25:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MIPBqt051853
	for ; Fri, 22 Aug 2003 11:25:11 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7MIP9S5018846
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Fri, 22 Aug 2003 11:25:12 -0700
Message-ID: <3F465FFB.6080503@Royer.com>
Date: Fri, 22 Aug 2003 12:24:59 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Dealing with invites to individual instances
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050303050208050908010702"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms050303050208050908010702
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> *Doug you are insane and should be treated as a spamer.  Don't start 
> this again.*
> *See long previous discussion and posting by this group.*
> 
> *Derik Stenerson *wrote
>  >>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.
> 
> As long as the reschedule can be treated as semantically equivalent to 
> changing instance dates, the original pattern has not changed and thus 
> the recurrence-ids do not change.

Your misreading Franks and Deriks email. They change when the
set changes. And the reason they change is because there is
not a 1:1 mapping all of the time.

When does the SEQUENCE number get bumped? It includes the folowing:

      .  "DTSTART"
      .  "DTEND"
      .  "RDATE"
      .  "RRULE"
      .  "EXDATE"
      .  "EXRULE"

 From the email you cite above it says: "...remains unchanged for
  as long as the base recurrence set (or pattern) exists. ..."

When you change the pattern - IT CHANGES. It has to because
there would be NO way to match them up.


-- 

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

                 We Do Standards - You Need Standards

--------------ms050303050208050908010702
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq
MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MjIxODI0NTlaMCMGCSqGSIb3DQEJBDEWBBRc
kkTCDDI28LlZPuvdJRZcLktZITBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ
KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv
c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy
aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs
aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8
oTANBgkqhkiG9w0BAQEFAASCAQCid/LneZZ5uibFtN26Jz7ZWAdRYPqru+e81PWad2vrQlMn
1jq8fNjKDL1rIgo3Djw6KLRYrn+YdK4ldfqgOlHYYsiVlrFY3u2HQhHsME2qs65Cy97b0FM5
CFr+s2A8IjO0FWdqOxpDpmo2CIs0ILjxHVSIlO457+OFGcI6xCxbcBSuOrLeuQ2/vrX85sEz
Nb+734TlMtnMTZ42ccRaEMs6rY3blbL+0cJ4x+BQdyi7tprOdvE+1Y96mkgpfAVSjM9+iSJw
KjpHTBzJ7jy+1KeFphQWtaHczxkZqer20Rbqi76AaXanXZas83lOECJuBe+iBxtUc+8Y43zg
l2IDlQseAAAAAAAA
--------------ms050303050208050908010702--



From owner-ietf-calendar@mail.imc.org  Fri Aug 22 15:43: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 PAA16084
	for ; Fri, 22 Aug 2003 15:43:18 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MJFDqt054165
	for ; Fri, 22 Aug 2003 12:15:13 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MJFDlj054164
	for ietf-calendar-bks; Fri, 22 Aug 2003 12:15:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MJF8qt054156
	for ; Fri, 22 Aug 2003 12:15:11 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19qHOI-0003nm-00
	for ; Fri, 22 Aug 2003 21:16:06 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19qHOH-0003ne-00
	for ; Fri, 22 Aug 2003 21:16:05 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19qHNM-0004wT-00
	for ; Fri, 22 Aug 2003 21:15:08 +0200
From: "Michael Fair" 
Subject: Re: Dealing with invites to individual instances
Date: Fri, 22 Aug 2003 12:15:07 -0700
Lines: 231
Message-ID: 
References:  <200308202101.15756.mark@WebServiceSolutions.com> <3F44F62F.7020006@Royer.com> <200308212320.34374.mark@ScheduleWorld.com>  <20030822105439.M38743@asitturnsout.org>
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 have read your entire post.
I'll try and keep it to just the simplest and most demonstrable points.
For simplicity sake, we'll call the instances or instance subset,
users "Y" and "W" were invited to instances "Y" and "W" respectively.
For purposes of calculating DTSTART we'll say that "Y" was invited
first, and thus "W" has the more recent DTSTART.



> > The problem with this is when user "W" forwards or delegates
> > to user "Y" where "Y" has been invited to a different instance.
>
> First, delegation is indicated by a message from the delegator and the
> delegatee to the Organizer, each clearly marked with information about
> the delegation.  If *any* of these messages are seen by the organizer,
> there is no problem.  If the organizer misses them all, there is no
> problem (except that the Organizing CU won't know of the subtitution).
> Either way, no problem.

And if the delegation announcemnt got lost or ORGANIZER simply
received the messages out of order?
Delagatee response, then Delagation announcement.

This also assumes the ORGANIZER was event sent a reply by the
delegatee to begin with which I'll address below.


> > They both have the same UID on their calendar.
> > The UID's do not refer to the same event.
> > The CUAs must do the wrong thing no matter how they process it.
>
> You keep saying this, but without any basis, as far as I can see.

I proved it in the post you didn't comprehend before responding
with an off-topic suprise party.  I'll do it again.
(The problem is that your suprise party left all workflow properties
 the same and just changed non-workflow properties.  I have no
 problem with that.)

Recurring event UID:1 has instances "Y" and "W" to which it separately
invites CUs "Y" and "W" respectively.

So "Y" puts on its calendar:
UID:1
SEQUENCE:0
DTSTART:timeOfY

And "W" puts on its calendar:
UID:1
SEQUENCE:0
DTSTART:timeOfW

To keep it really simple I'll just discuss the "forwarding" part
since that's the least confusing.

User "W" sends "Y" a forwarded REQUEST containing:
UID:1
SEQUENCE:0
DTSTART:timeOfW

"Y" receives the message and on its calendar it finds UID:1.
It says "Oh cool, an update or a reschedule."

"Y" looks at both SEQUENCE values and sees SEQUENCE:0.
"Y" compares the the DTSTAMP values and sees the the UID:1
    it just received is more recent than the one it has.
It says "Great an update I can handle this."

However, it might notice that this didn't come from the
ORGANIZER.  Since there can only be one unique UID:1 and
the ORGANIZER is the master of all updates it will probably
just throw this message out and not process the invite.
**** It just did the wrong thing ****


But let's follow another chain:
Assuming there is no signature or other source authentication
means to verify the message it will update its calendar and it
now no longer has instance "Y" but instead has instance "W".
**** It just did the wrong thing ****


It might not send the ORGANIZER a REPLY because it doesn't
think it needs to as the SEQUENCE didn't change at all.
**** It just did the wrong thing ****


However, It might notice that something is fishy because the
DTSTART changed but SEQUENCE wasn't updated (however I can
easily present a scenario where the SEQUENCE was increased
and it wouldn't notice a thing).  Given that the DTSTART
changed, it might figure out that it should ask the CU and
they then say they can't attend.

So the dutiful CUA sends a REPLY to the ORGANIZER with UID:1
SEQUENCE:0 and a negative attendence.

The ORGANIZER receives this message, it looks in its lookup
table of instance-attendee match ups and finds that UID:1
was attached to instance "Y".  So given the SEQUENCE is the
same but the DTSTAMP is more recent than the one it has it
goes ahead and says that "Y" is no longer coming to instance "Y".
**** It just did the wrong thing ****


No matter how many different variations I tried because UID:1
has been overloaded to mean two different instances the CUAs
can never figure out what the right thing to do is.



> > So if an object
> > is at SEQUENCE:5 but the ATTENDEE response says SEQUENCE:3,
> > he can't tell if that's because the messages got lost in transit,
> > or if he never sent four and five because he didn't need to.

> I would expect a CUA to track exactly what each participant has been
> invited to, so this seems like basic functionality to me.

iTIP certainly never recommends you do this.

However, you are totally right that if a CUA tracked what they
sent in addition to what they received they could figure out
whether or not a CU had responded to the right SEQUENCE yet.
I was incorrectly basing my conclusion from iTIP where such
tracking of what was sent is totally unnecessary.

I will totally grant you that a CUA "could" do this and there
is no reason to stop it from doing so.  But it's not in iTIP
and therefore is not "basic functionality".

I withdraw my argument that the CUA using this model would not
be be able track what SEQUENCE a CUs response should be at if
trying to use this optimization.  Any CUA trying to use the
"splinter the UID" model of inviting CUs to will have to do
this to keep track of expected responses.  It solves that
particular problem quite neatly.

To prevent any confusion however, there are still other problems
you have yet to demonstrate competency in.  Most particularly
having CUs with different versions of the same UID trying to
forward and delegate to each other.




> > And the thing I love the most is even more simply than any of this,
> > if a user at SEQUENCE:3 tries to change their status and the
> > ORGANIZER has marched on to SEQUENCE:5 - a properly coded CUA should
> > ignore the SEQUENCE:3 reply and send them a SEQUENCE:5 update and
> > wait for their response.
>
> Chapter and verse on this?  I know where it says stale REQUESTs should be
> discarded; where is the similar language for REPLY objects?

I am totally wrong about this one too.
Again I was concluding something based on the iTIP model where
splintering UIDs with separate versions is a violation of the
uniqueness property and that increasing a SEQUENCE value meant
that something significant about the event changed.

I had also misapplied a recommendation out of context.

In section "5.2.2 Unexpected Reply from an Unknown Delegate" we have:
   ... If the version of the
   "REPLY" method is out of date the "Organizer" SHOULD treat the
   message as a "REFRESH" message and update the delegate with the
   correct version.

I had not remembered the context of being from an unkown delegate
and had inaccurately recalled that this was a normal part of the
REPLY prose.

Further, given the iTIP model where a SEQUNCE jump always means
an attendence invlidation, treating a REPLY to an old SEQUENCE
makes sense, but is not actually proposed in iTIP.

iTIP in section 3.2.2 simply says that later SEQUENCE versions
(or DTSTAMP as the case might be) obsolete all earlier replies.

I stand corrected.  Thank you.



> Real CUAs that can
> send invite an Attendee to a subset of an event can build custom REQUEST
> objects should be able to match up the REPLY correctly without needing a
> different UID (and if they can't, they could just internally generate a
UID
> per custom invite without the Organizing CU knowing or caring).

I've already posed the forwarding dilemma for custom REQUEST objects
above I have demonstrated it for at least the fifth time now and so
far there has been no response.

Generating a new internal UID would almost work, except now when the
CUs who are invited to the same instances (not instance set, just
same instances) forward messages to each other they won't be able
to figure out they are talkig about something they already know about.



> I hope you read the whole message this time.  Last time, I used a
> surprise party to show why a CU might want his CUA to generate
> custom objects, all with the same UID, and you ignored it.  You
> should take a deep breath, read the whole thing again, and only
> then should you respond.

It would have been nice if you had actually read and understood the
problem before replying with your unrelated suprise party.  It would
have been even better if you had just understood my response to your
suprise party before trying to say that I have neither read nor
understood your response to a problem that was no where near the
situation I described.  (I even told you why it wasn't relevant.)

Not that it matters since I've again duplicated the scenario above,
but in my reposense, just after the part where you say the ORGANIZER
is free to reject party crashers I requested you look at the actual
messages being passed around.  Just above that I put a snip comment
saying why the example was irrelevant.

Here's the post from me that you didn't read/understand/respond to.
It's really long - don't bother replying as the salient parts have
been copied above.

    Subject: Re: New question in regards to the fixed-id model
    Sent: Thursday, August 14, 2003 4:08 PM

-- Michael --





From owner-ietf-calendar@mail.imc.org  Fri Aug 22 16:37: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 QAA18570
	for ; Fri, 22 Aug 2003 16:37:30 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MJpaqt055459
	for ; Fri, 22 Aug 2003 12:51:36 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MJpa3k055458
	for ietf-calendar-bks; Fri, 22 Aug 2003 12:51:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MJpZqt055451
	for ; Fri, 22 Aug 2003 12:51:35 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F465FFB.6080503@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Dealing with invites to individual instances
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Fri, 22 Aug 2003 15:36:47 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/22/2003
 03:51:06 PM,
	Serialize complete at 08/22/2003 03:51:06 PM
Content-Type: multipart/alternative; boundary="=_alternative 006B53FE85256D8A_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 006B53FE85256D8A_=
Content-Type: text/plain; charset="US-ASCII"

I Disagree.  The only time you change the recurrence id is when there is 
no 1:1 mapping.  As long as I just reschedule the existing set and do not 
change the RULE,  the 1:1 mapping is preserved.  Thus changing every 
meeting from Monday to Thursday is just a reschedule of the existing 
pattern.  If I have a repeat set on  Mondays and I change this to  Mondays 
and Thursdays, than I have changed the RULE/pattern so that there is no 
1:1 mapping.  In that case, it is equivalent to canceling the original set 
and creating a new set, THUS the recurrence-id's must be reset.  The 
polite iCal would send a Cancel of the original set and a new invitation.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/22/2003 02:24 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Dealing with invites to individual instances








Robert_Ransdell@notesdev.ibm.com wrote:
> 
> *Doug you are insane and should be treated as a spamer.  Don't start 
> this again.*
> *See long previous discussion and posting by this group.*
> 
> *Derik Stenerson *wrote
>  >>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.
> 
> As long as the reschedule can be treated as semantically equivalent to 
> changing instance dates, the original pattern has not changed and thus 
> the recurrence-ids do not change.

Your misreading Franks and Deriks email. They change when the
set changes. And the reason they change is because there is
not a 1:1 mapping all of the time.

When does the SEQUENCE number get bumped? It includes the folowing:

      .  "DTSTART"
      .  "DTEND"
      .  "RDATE"
      .  "RRULE"
      .  "EXDATE"
      .  "EXRULE"

 From the email you cite above it says: "...remains unchanged for
  as long as the base recurrence set (or pattern) exists. ..."

When you change the pattern - IT CHANGES. It has to because
there would be NO way to match them up.


-- 

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

                 We Do Standards - You Need Standards


--=_alternative 006B53FE85256D8A_=
Content-Type: text/html; charset="US-ASCII"



I Disagree.  The only time you
change the recurrence id is when there is no 1:1 mapping.  As long
as I just reschedule the existing set and do not change the RULE,  the
1:1 mapping is preserved.  Thus changing every meeting from Monday
to Thursday is just a reschedule of the existing pattern.  If I have
a repeat set on  Mondays and I change this to  Mondays and Thursdays,
than I have changed the RULE/pattern so that there is no 1:1 mapping.  In
that case, it is equivalent to canceling the original set and creating
a new set, THUS the recurrence-id's must be reset.  The polite iCal
would send a Cancel of the original set and a new invitation.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/22/2003 02:24 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Dealing with invites
to individual instances





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

> *Doug you are insane and should be treated as a spamer.  Don't
start 

> this again.*

> *See long previous discussion and posting by this group.*

> 

> *Derik Stenerson *wrote

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

> 

> As long as the reschedule can be treated as semantically equivalent
to 

> changing instance dates, the original pattern has not changed and
thus 

> the recurrence-ids do not change.



Your misreading Franks and Deriks email. They change when the

set changes. And the reason they change is because there is

not a 1:1 mapping all of the time.



When does the SEQUENCE number get bumped? It includes the folowing:



      .  "DTSTART"

      .  "DTEND"

      .  "RDATE"

      .  "RRULE"

      .  "EXDATE"

      .  "EXRULE"



 From the email you cite above it says: "...remains unchanged for

  as long as the base recurrence set (or pattern) exists. ..."



When you change the pattern - IT CHANGES. It has to because

there would be NO way to match them up.





-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 006B53FE85256D8A_=--


From owner-ietf-calendar@mail.imc.org  Fri Aug 22 17:51:10 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22729
	for ; Fri, 22 Aug 2003 17:51:09 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MLDWqt058035
	for ; Fri, 22 Aug 2003 14:13:32 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MLDWXO058034
	for ietf-calendar-bks; Fri, 22 Aug 2003 14:13:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MLDUqt058029
	for ; Fri, 22 Aug 2003 14:13:30 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7MLDPS5020528
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Fri, 22 Aug 2003 14:13:27 -0700
Message-ID: <3F46876C.9080102@Royer.com>
Date: Fri, 22 Aug 2003 15:13:16 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Dealing with invites to individual instances
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080303000301050206020602"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms080303000301050206020602
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> I Disagree.  The only time you change the recurrence id is when there is 
> no 1:1 mapping.  As long as I just reschedule the existing set and do 
> not change the RULE,  the 1:1 mapping is preserved.  Thus changing every 
> meeting from Monday to Thursday is just a reschedule of the existing 
> pattern.  If I have a repeat set on  Mondays and I change this to 
>  Mondays and Thursdays, than I have changed the RULE/pattern so that 
> there is no 1:1 mapping.  In that case, it is equivalent to canceling 
> the original set and creating a new set, THUS the recurrence-id's must 
> be reset. 

Thank you for finally agreeing that the RECURRECE-ID does in fact change
and must change in ITIP. And I agree if the only thing that changes
is something that does not change one or more instances, then the
RECURRENCE-IDs do not change. For those the SEQUENCE number might
not be bumped and the only thing the CUA can do then is compare
DTSTAMPs and obsolete the old data.

And it does not matter if you invite one or more ATTENDEEs to one
or more instances. They are exactly the same thing and have exactly
the same problem.

If an instance modificaton is sent to an ATTENDEE then the
RECURRENCE-ID that was modified is changed because it has
to look *exactly* the same as if they have received a full
replacement object which is another valid way to update the
ATTENDEE.

> The polite iCal would send a Cancel of the original set and a 
> new invitation.

I disagree for two reasons:

  (1) The iTIP examples show updates without CANCELs, so that should
      be  sufficient for CUA's to expect them to be updated.

  (2) For ATTENDEEs that are resources, a CANCEL may be catastrophic.
      If for example I book an airline reservation and hotel room
      it could be disastrous to have CANCELed the last room in
      for the conference just because you want to add one day to
      your arrival time.

-- 

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

                 We Do Standards - You Need Standards

--------------ms080303000301050206020602
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMjIxMTMxNlowIwYJKoZIhvcNAQkEMRYEFPUJLUxq
Vx8zYBjFKhEvPDPjkgjkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBALeb6s6RbGx+7E/CaScUNVImNE/uk0NSPp4kqis4NRdKESH6Z3bg
8Yt9IVyTh7RdvU9/QCOyAtlIChJ9gSSUWMf73vGI9Zfx6iF7F6sGcN661VC0kt+kdlow45s8
d5eklueQh9h7NFMr7JOxQH7DmxfWgyK5aSXsNbEE0+D6vI+eJz8cGCW7gcT6oSIm6CWvwvJm
DReGe/eqd3ruh7a4np34GeVeD0eVjstEhI9yrkD6UKyIOkhI4+34GicKaxN18rW7/yaujE3Y
Yd3U1adfOKn2OzGCp+5Bxtg/OI/S1MkGRZDEh0KypGQPavDq/MPJEU6ZrTkjgaGdCgi83WMS
VcoAAAAAAAA=
--------------ms080303000301050206020602--



From owner-ietf-calendar@mail.imc.org  Fri Aug 22 19:08: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 TAA26911
	for ; Fri, 22 Aug 2003 19:08:08 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMiBqt061497
	for ; Fri, 22 Aug 2003 15:44:11 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7MMiB9g061496
	for ietf-calendar-bks; Fri, 22 Aug 2003 15:44:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMi9qt061488
	for ; Fri, 22 Aug 2003 15:44:09 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19qKeZ-0005cj-00
	for ; Sat, 23 Aug 2003 00:45:07 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19qKeY-0005cb-00
	for ; Sat, 23 Aug 2003 00:45:06 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19qKde-0002AR-00
	for ; Sat, 23 Aug 2003 00:44:10 +0200
From: "Michael Fair" 
Subject: Re: Dealing with invites to individual instances
Date: Fri, 22 Aug 2003 15:44:13 -0700
Lines: 39
Message-ID: 
References:  <3F46876C.9080102@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: 


> > The polite iCal would send a Cancel of the original set and a
> > new invitation.
>
> I disagree for two reasons:
>
>   (1) The iTIP examples show updates without CANCELs, so that should
>       be  sufficient for CUA's to expect them to be updated.
>
>   (2) For ATTENDEEs that are resources, a CANCEL may be catastrophic.
>       If for example I book an airline reservation and hotel room
>       it could be disastrous to have CANCELed the last room in
>       for the conference just because you want to add one day to
>       your arrival time.

I also disagree that the polite iCal would necessarily send a cancel
of the original set.

While I don't understand what Doug is referring to in (2), I agree
with Doug about (1).

Simply by providing a description of the updated recurrence set
a CUA can figure out which instances still belong in the set and
which instances don't and cancel/remove the now invalid instances.


The only question that I am dealing with is given that a CANCEL
isn't "usual" for a reschedule REQUEST and is not in iTIP, does
something need to be added to iTIP which says that if a user has
not been invited to the base recurring series and thereby does not
receive a description of the recurrence set (old or new) then
a CANCEL of the old RID MUST be issued along with a REQUEST for
the new RID.

Otherwise, the recipient CUA would have no other way to find out
that the old RECURRENCE-ID is no longer valid.

-- Michael --





From owner-ietf-calendar@mail.imc.org  Fri Aug 22 21:13: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 VAA01360
	for ; Fri, 22 Aug 2003 21:13:54 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0nEqt064530
	for ; Fri, 22 Aug 2003 17:49:14 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7N0nEYG064529
	for ietf-calendar-bks; Fri, 22 Aug 2003 17:49:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0nCqt064522
	for ; Fri, 22 Aug 2003 17:49:13 -0700 (PDT)
	(envelope-from TimHare@comcast.net)
Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender))
          by comcast.net (rwcrmhc13) with SMTP
          id <2003082300070701500h1g6ke>
          (Authid: TimHare);
          Sat, 23 Aug 2003 00:07:07 +0000
Message-Id: <5.2.1.1.0.20030822193937.00a1bd80@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Fri, 22 Aug 2003 20:05:09 -0400
To: IETF Calendaring and Scheduling Working Group 
From: Tim Hare 
Subject: Some things to help the discussion and some  clarifications I
  need
In-Reply-To: 
References: 
 <200308202101.15756.mark@WebServiceSolutions.com>
 <3F44F62F.7020006@Royer.com>
 <200308212320.34374.mark@ScheduleWorld.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: 


First - I think we need to come up with ONE use case of the Recurrence-ID 
problems, or one set, anyway. We need to place it as a document where 
everyone can get it, and base our discussions around that. We keep 
introducing new scenarios, and changing terms (I used X,Y,Z, and W as 
ATTENDEEs in one case, and Michael Fair used Y and W as instances in 
another) - I think this is adding to the confusion. Has anyone got good 
ideas or pointers to somewhere with good examples of notation?

Second - does iTIP explicitly describe protocols for changing single 
instances of a recurrence set and if so, what sections?

Third - in the following quote:

At 02:36 AM 8/22/03 -0700, Michael Fair wrote:
>They both have the same UID on their calendar.
>The UID's do not refer to the same event.
>The CUAs must do the wrong thing no matter how they process it.

I need some clarification of the term "event" here. I don't see how the 
first two statements can be true under iCal/iTIP UNLESS you say that an 
updated UID  with a recurrence rule that has had changes to the instances 
is a new event - in that case, the version (SEQUENCE) of the UID would be 
different - so the two CUAs have representation of the same event at 
different version levels in my opinion. This is something which is going to 
happen all the time give time delays in the various mappings of iTIP to 
communication protocols.

Fourth - non-delegated forwarding of events:  While I see that this can 
happen,  I don't see how or why the iTIP protocol should worry about 
breaking a CUA's representation of an event when that CUA was never invited 
to the event. In my opinion it can also be a security/privacy concern to 
keep that CUA updated:  say for example that I want to keep track of the 
executives in some organization. I co-opt an employee to forward executive 
meeting REQUESTs to me, and I send REPLY methods for all of those VEVENTS. 
 From that point on, under some of the scenarios discussed, I would 
constantly be updated about what's going on.  Of course, the access 
controls might prevent that, if there are any - but wouldn't they, 
shouldn't they, also prevent the event from being replied to by 
non-authorized CUAs?  My bottom line here is that I think unless the event 
is delegated via an iTIP process and not merely forwarded.

Tim Hare




From owner-ietf-calendar@mail.imc.org  Fri Aug 22 22: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 WAA03459
	for ; Fri, 22 Aug 2003 22:17:29 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1pvqt065931
	for ; Fri, 22 Aug 2003 18:51:57 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7N1pvGo065930
	for ietf-calendar-bks; Fri, 22 Aug 2003 18:51:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1ptqt065925
	for ; Fri, 22 Aug 2003 18:51:55 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7N1ptS5023480
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Fri, 22 Aug 2003 18:51:57 -0700
Message-ID: <3F46C8B0.7050107@Royer.com>
Date: Fri, 22 Aug 2003 19:51:44 -0600
From: Doug Royer 
Reply-To: IETF Calendaring and Scheduling Working Group 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF Calendaring and Scheduling Working Group 
Subject: Re: Some things to help the discussion and some  clarifications I
  need
References:  <200308202101.15756.mark@WebServiceSolutions.com> <3F44F62F.7020006@Royer.com> <200308212320.34374.mark@ScheduleWorld.com> <5.2.1.1.0.20030822193937.00a1bd80@mail.comcast.net>
In-Reply-To: <5.2.1.1.0.20030822193937.00a1bd80@mail.comcast.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060104010804070701060408"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms060104010804070701060408
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Tim Hare wrote:

> 
> Second - does iTIP explicitly describe protocols for changing single 
> instances of a recurrence set and if so, what sections?

iTIP - 4.4.2 Modify A Recurring Instance

The example changes a single instance.

> 
>> They both have the same UID on their calendar.
>> The UID's do not refer to the same event.
>> The CUAs must do the wrong thing no matter how they process it.
> 
> 
> I need some clarification of the term "event" here. I don't see how the 
> first two statements can be true under iCal/iTIP UNLESS you say that an 
> updated UID  with a recurrence rule that has had changes to the 
> instances is a new event - in that case, the version (SEQUENCE) of the 
> UID would be different - so the two CUAs have representation of the same 
> event at different version levels in my opinion. This is something which 
> is going to happen all the time give time delays in the various mappings 
> of iTIP to communication protocols.

Agreed - if it is the same UID, then it is the same iCAL object
and then the SEQUENCE and DTSTAMP must be used to compare the objects.

Conclusions reached based on the false assumption that they are
different iCAL objects and not just versions of the same object
are going to lead to all sorts of ghost chasing debates.

> Fourth - non-delegated forwarding of events:  While I see that this can 
> happen,  I don't see how or why the iTIP protocol should worry about 
> breaking a CUA's representation of an event when that CUA was never 
> invited to the event.

In fact iTIP says "3.2.2.6 Forwarding to An Uninvited CU"

    ...   An "Attendee" invited to an event may invite another uninvited CU to
    the event. The invited "Attendee" accomplishes this by forwarding the
    original "REQUEST" method to the uninvited CU. The "Organizer"
    decides whether or not the uninvited CU is added to the attendee
    list. ...

So it is covered. The organizer may toss the object.

-- 

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

                 We Do Standards - You Need Standards

--------------ms060104010804070701060408
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyMzAxNTE0NFowIwYJKoZIhvcNAQkEMRYEFFtmJCvg
QiQ/fKo6ORnsOuEOtuFNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBACyGy94XzmIXvYAmiGc2weO3vDvAlptNMWHjzeMfpSZa3EMCwShN
+DPx5PmybcEeLZa575oqGJB/r4XOo61Q3pFwBTSGQ5H5w/VKjty8Az1sezDIpU/Rodw8RUjl
zhD6QvxX2EvJUAW9bC/Ne8qd3DN51HDSzVlN/oLuWGmG/2mhzs4lI5Agi6zRge85m3FvxqoW
6GB6FFh9qRC1hKHFxsrmhmvLPXHPS0smAKTrAY7qXx+GDV5pPxPmmAQD0Ewcivy3lS2cNE0x
0oUVtUz+M9CRFaWsPMyeCTrrD9kdhAGaJOKfSViOMSWh44XOzbpd4NgV6MEJ8T1GU7uSzuvH
sU0AAAAAAAA=
--------------ms060104010804070701060408--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 15:26: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 PAA00626
	for ; Wed, 27 Aug 2003 15:26:02 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RJ3Wgc080451
	for ; Wed, 27 Aug 2003 12:03:32 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RJ3Wlw080450
	for ietf-calendar-bks; Wed, 27 Aug 2003 12:03:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RJ3Vgc080442
	for ; Wed, 27 Aug 2003 12:03:31 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7RJ3PS5021404
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 27 Aug 2003 12:03:29 -0700
Message-ID: <3F4D0078.5050006@Royer.com>
Date: Wed, 27 Aug 2003 13:03:20 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Does anyone still think that RECURRENCE-ID's do NOT change?
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040704030209000904040002"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms040704030209000904040002
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


I know that there may be more screams that this issues will not
go away. But it really needs to be settled.

Despite the claims on this list, it appears that almost everyone
agrees that the RECURRECE-ID's do change and must change.

I think that proof is:

	So your first invitation is to:

  	   UID:100
  	   SEQUENCE:0
   	  DATE:...sep-1...10am...

	Then you get:

  	   UID:100
  	   SEQUENCE:1
  	   RRULE;FREQ=DAILY;COUNT=10
  	   DTSTART:...sep-2...3pm

	What is the RECURRENCE-ID for the 1st object?
	  ...sep-1...10am... Correct?

	So which of the 10 instances has its RECURRENCE-ID fixed to the 1st
	object?

	What are the 10 RECURRENCE-ID's for the 2nd object?

Does anyone still think that RECURRENCE-ID's do NOT change?

-- 

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

                 We Do Standards - You Need Standards

--------------ms040704030209000904040002
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyNzE5MDMyMFowIwYJKoZIhvcNAQkEMRYEFDFrIKqC
zyLIBuwDSRfO3KrQ4+ByMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAKe9IVDxCTd+R9+NT/1iMIDtnSFYk+rI+f/kBiWac2gqLt7KxxZw
ZOGutQ3bVfYLti7X4QQnwp95jiXXD/60PAdGSUWL5fHYAq2LprmZWlwKXuRbDf2D16pyb0UE
0R/K3Xu5UKwPyMvBo/3x6bAV44aj4pj4BzX/gKdm9yvDnnAlpCfUMT9OY+t+YhK/YlEj7jUy
yqxWqT2dlOWziHkpVe0hyLXngTnHSWXoweW1NGLbzq6044OWpmqHPEW7vGwOXrQ9VXBigsQ2
1ANSKtSyu4NaeDRmXix/5Vmgb07llYcjfzoFwiweWml1wR1PGTHbe/GydbAZPtrfyrPmh4p6
oEAAAAAAAAA=
--------------ms040704030209000904040002--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 16:01: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 QAA03738
	for ; Wed, 27 Aug 2003 16:01:24 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RJjMgc082284
	for ; Wed, 27 Aug 2003 12:45:22 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RJjM7P082283
	for ietf-calendar-bks; Wed, 27 Aug 2003 12:45:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RJjLgc082277
	for ; Wed, 27 Aug 2003 12:45:21 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4D0078.5050006@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Wed, 27 Aug 2003 15:28:41 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/27/2003
 03:45:16 PM,
	Serialize complete at 08/27/2003 03:45:16 PM
Content-Type: multipart/alternative; boundary="=_alternative 006A934685256D8F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 006A934685256D8F_=
Content-Type: text/plain; charset="US-ASCII"

Only when you send a new RULE
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/27/2003 03:03 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Does anyone still think that RECURRENCE-ID's do NOT change?







I know that there may be more screams that this issues will not
go away. But it really needs to be settled.

Despite the claims on this list, it appears that almost everyone
agrees that the RECURRECE-ID's do change and must change.

I think that proof is:

                 So your first invitation is to:

                    UID:100
                    SEQUENCE:0
                   DATE:...sep-1...10am...

                 Then you get:

                    UID:100
                    SEQUENCE:1
                    RRULE;FREQ=DAILY;COUNT=10
                    DTSTART:...sep-2...3pm

                 What is the RECURRENCE-ID for the 1st object?
                   ...sep-1...10am... Correct?

                 So which of the 10 instances has its RECURRENCE-ID fixed 
to the 1st
                 object?

                 What are the 10 RECURRENCE-ID's for the 2nd object?

Does anyone still think that RECURRENCE-ID's do NOT change?

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 006A934685256D8F_=
Content-Type: text/html; charset="US-ASCII"



Only when you send a new RULE

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/27/2003 03:03 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Does anyone still think that
RECURRENCE-ID's do NOT change?



















I know that there may be more screams that this issues will not

go away. But it really needs to be settled.



Despite the claims on this list, it appears that almost everyone

agrees that the RECURRECE-ID's do change and must change.



I think that proof is:



                
So your first invitation is to:



                  
   UID:100

                  
   SEQUENCE:0

                  
   DATE:...sep-1...10am...



                
Then you get:



                  
   UID:100

                  
   SEQUENCE:1

                  
   RRULE;FREQ=DAILY;COUNT=10

                  
   DTSTART:...sep-2...3pm



                
What is the RECURRENCE-ID for the 1st object?

                
  ...sep-1...10am... Correct?



                
So which of the 10 instances has its RECURRENCE-ID fixed to the 1st

                
object?



                
What are the 10 RECURRENCE-ID's for the 2nd object?



Does anyone still think that RECURRENCE-ID's do NOT change?



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 006A934685256D8F_=--


From owner-ietf-calendar@mail.imc.org  Wed Aug 27 16:30: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 QAA06004
	for ; Wed, 27 Aug 2003 16:30:17 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RKECgc083477
	for ; Wed, 27 Aug 2003 13:14:12 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RKECrO083476
	for ietf-calendar-bks; Wed, 27 Aug 2003 13:14:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RKEBgc083471
	for ; Wed, 27 Aug 2003 13:14:11 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4D0078.5050006@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Wed, 27 Aug 2003 16:11:37 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/27/2003
 04:14:05 PM,
	Serialize complete at 08/27/2003 04:14:05 PM
Content-Type: multipart/alternative; boundary="=_alternative 006E81BD85256D8F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 006E81BD85256D8F_=
Content-Type: text/plain; charset="US-ASCII"

You are sending invalid instance invitations to start with.
If you send an Instance invitation you MUST include the RECURRENCE-ID

When you send a REQUEST with a new RULE.  You are telling the receiving 
Calendar Store ...NUKE ALL ENTRIES   in your calendar store.   Nothing in 
your store is valid, I AM RESETTING THE RULE AND RECURRENCE-IDs and 
sending all new information.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/27/2003 03:03 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Does anyone still think that RECURRENCE-ID's do NOT change?







I know that there may be more screams that this issues will not
go away. But it really needs to be settled.

Despite the claims on this list, it appears that almost everyone
agrees that the RECURRECE-ID's do change and must change.

I think that proof is:

                 So your first invitation is to:

                    UID:100
                    SEQUENCE:0
                   DATE:...sep-1...10am...

                 Then you get:

                    UID:100
                    SEQUENCE:1
                    RRULE;FREQ=DAILY;COUNT=10
                    DTSTART:...sep-2...3pm

                 What is the RECURRENCE-ID for the 1st object?
                   ...sep-1...10am... Correct?

                 So which of the 10 instances has its RECURRENCE-ID fixed 
to the 1st
                 object?

                 What are the 10 RECURRENCE-ID's for the 2nd object?

Does anyone still think that RECURRENCE-ID's do NOT change?

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 006E81BD85256D8F_=
Content-Type: text/html; charset="US-ASCII"



You are sending invalid instance invitations
to start with.

If you send an Instance invitation you
MUST include the RECURRENCE-ID



When you send a REQUEST with a new RULE.
 You are telling the receiving Calendar Store ...NUKE ALL ENTRIES
  in your calendar store.   Nothing in your store is valid, I
AM RESETTING THE RULE AND RECURRENCE-IDs and sending all new information.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/27/2003 03:03 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Does anyone still think that
RECURRENCE-ID's do NOT change?



















I know that there may be more screams that this issues will not

go away. But it really needs to be settled.



Despite the claims on this list, it appears that almost everyone

agrees that the RECURRECE-ID's do change and must change.



I think that proof is:



                
So your first invitation is to:



                  
   UID:100

                  
   SEQUENCE:0

                  
   DATE:...sep-1...10am...



                
Then you get:



                  
   UID:100

                  
   SEQUENCE:1

                  
   RRULE;FREQ=DAILY;COUNT=10

                  
   DTSTART:...sep-2...3pm



                
What is the RECURRENCE-ID for the 1st object?

                
  ...sep-1...10am... Correct?



                
So which of the 10 instances has its RECURRENCE-ID fixed to the 1st

                
object?



                
What are the 10 RECURRENCE-ID's for the 2nd object?



Does anyone still think that RECURRENCE-ID's do NOT change?



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 006E81BD85256D8F_=--


From owner-ietf-calendar@mail.imc.org  Wed Aug 27 16:43: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 QAA07094
	for ; Wed, 27 Aug 2003 16:43:02 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RKTWgc084045
	for ; Wed, 27 Aug 2003 13:29:32 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RKTWWC084044
	for ietf-calendar-bks; Wed, 27 Aug 2003 13:29:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from office2.jigzaw.com (adsl-68-20-84-161.dsl.chcgil.ameritech.net [68.20.84.161])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RKTSgc084003
	for ; Wed, 27 Aug 2003 13:29:29 -0700 (PDT)
	(envelope-from shannon@jigzaw.com)
Received: from colatz ([10.0.0.10])
	by office2.jigzaw.com (8.9.3/8.9.3) with SMTP id PAA03008
	for ; Wed, 27 Aug 2003 15:00:10 -0500
Reply-To: 
From: "Shannon J. Clark" 
To: 
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Wed, 27 Aug 2003 15:28:40 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_005D_01C36CAF.E492AC00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: 
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_005D_01C36CAF.E492AC00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

It occurs to me to wonder, mostly as a user, what a change in RULE does to
events IN THE PAST?

In at least some calendars, I have seen "past" events deleted or otherwise
modified when rules have been modified.

Perhaps this is not specifically a question for the standards, but it
appears to me to be something fairly important in general.

1. Is there a built in assumption to the calendaring standards that there is
a "past" "present" and "future", perhaps with the possibility that no
changes should modify the past?

2. If not, should the standards at least make a clear suggestion of a
standardized way to handle reoccurring events which change how they reoccur,
where the "past" events MUST remain on the times on which they occurred?

Shannon
  -----Original Message-----
  From: owner-ietf-calendar@mail.imc.org
[mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of
Robert_Ransdell@notesdev.ibm.com
  Sent: Wednesday, August 27, 2003 3:12 PM
  To: ietf-calendar@imc.org
  Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?



  You are sending invalid instance invitations to start with.
  If you send an Instance invitation you MUST include the RECURRENCE-ID

  When you send a REQUEST with a new RULE.  You are telling the receiving
Calendar Store ...NUKE ALL ENTRIES   in your calendar store.   Nothing in
your store is valid, I AM RESETTING THE RULE AND RECURRENCE-IDs and sending
all new information.
  _____________________
  Note: new email address

  tom_ransdell@notesdev.ibm.com


        Doug Royer 
        Sent by: owner-ietf-calendar@mail.imc.org
        08/27/2003 03:03 PM Please respond to
              "ietf-calendar@imc.org" 


       To "ietf-calendar@imc.org" 
              cc
              Subject Does anyone still think that RECURRENCE-ID's do NOT
change?








  I know that there may be more screams that this issues will not
  go away. But it really needs to be settled.

  Despite the claims on this list, it appears that almost everyone
  agrees that the RECURRECE-ID's do change and must change.

  I think that proof is:

                  So your first invitation is to:

                       UID:100
                       SEQUENCE:0
                       DATE:...sep-1...10am...

                  Then you get:

                       UID:100
                       SEQUENCE:1
                       RRULE;FREQ=DAILY;COUNT=10
                       DTSTART:...sep-2...3pm

                  What is the RECURRENCE-ID for the 1st object?
                    ...sep-1...10am... Correct?

                  So which of the 10 instances has its RECURRENCE-ID fixed
to the 1st
                  object?

                  What are the 10 RECURRENCE-ID's for the 2nd object?

  Does anyone still think that RECURRENCE-ID's do NOT change?

  --

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

                  We Do Standards - You Need Standards


------=_NextPart_000_005D_01C36CAF.E492AC00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







It =
occurs to me to=20
wonder, mostly as a user, what a change in RULE does to events IN THE=20
PAST?


 


In at =
least some=20
calendars, I have seen "past" events deleted or otherwise modified when =
rules=20
have been modified.


 


Perhaps this is not=20
specifically a question for the standards, but it appears to me to be =
something=20
fairly important in general.


 


1. Is =
there a built=20
in assumption to the calendaring standards that there is a "past" =
"present" and=20
"future", perhaps with the possibility that no changes should modify the =

past?


 


2. If =
not, should=20
the standards at least make a clear suggestion of a standardized way to =
handle=20
reoccurring events which change how they reoccur, where the "past" =
events MUST=20
remain on the times on which they occurred?


 


Shannon



  
-----Original Message-----
From:=20
  owner-ietf-calendar@mail.imc.org=20
  [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of=20
  Robert_Ransdell@notesdev.ibm.com
Sent: Wednesday, August =
27,=20
  2003 3:12 PM
To: ietf-calendar@imc.org
Subject: =
Re: Does=20
  anyone still think that RECURRENCE-ID's do NOT=20
  change?


You =
are sending=20
  invalid instance invitations to start with. 
If you send an Instance invitation you MUST include the=20
  RECURRENCE-ID 

When you =
send a=20
  REQUEST with a new RULE.  You are telling the receiving Calendar =
Store=20
  ...NUKE ALL ENTRIES   in your calendar store.   Nothing in =
your=20
  store is valid, I AM RESETTING THE RULE AND RECURRENCE-IDs and sending =
all new=20
  information. 
_____________________
Note: new email=20
  address

tom_ransdell@notesdev.ibm.com 



  

    
    

      Doug Royer=20
        <Doug@royer.com> 
Sent=20
        by: owner-ietf-calendar@mail.imc.org=20
        
08/27/2003 03:03 PM=20
        

          
          

            
              
Please respond=20
              to
"ietf-calendar@imc.org"=20
              =
<ietf-calendar@imc.org>


      		
        

          
          

            
              
To

            		"ietf-calendar@imc.org"=20
              <ietf-calendar@imc.org>=20
          

            
              
cc

            		
          

            
              
Subject

            		Does =
anyone still=20
              think that RECURRENCE-ID's do NOT=20
change?


        

          
          

            
            =






I know that there may be more screams that this =
issues will=20
  not
go away. But it really needs to be settled.

Despite the =
claims=20
  on this list, it appears that almost everyone
agrees that the=20
  RECURRECE-ID's do change and must change.

I think that proof=20
  is:

                So =
your=20
  first invitation is to:

          =
 =20
           UID:100
      =
 =20
               SEQUENCE:0
  =
 =20
                 =20
   DATE:...sep-1...10am...

        =
   =20
      Then you get:

          =
 =20
           UID:100
      =
 =20
               SEQUENCE:1
  =
 =20
                 =20
   RRULE;FREQ=3DDAILY;COUNT=3D10
        =
   =20
           DTSTART:...sep-2...3pm

  =
 =20
              What is the RECURRENCE-ID =
for the=20
  1st object?
                =
 =20
  ...sep-1...10am... Correct?

          =
 =20
      So which of the 10 instances has its RECURRENCE-ID fixed =
to the=20
  1st
               =20
  object?

                =
What=20
  are the 10 RECURRENCE-ID's for the 2nd object?

Does anyone =
still think=20
  that RECURRENCE-ID's do NOT change?

-- 

 Doug Royer =
 =20
                    | =
 =20
  =
http://INET-Consulting.com
 -------------------------------|-----=
------------------------
 Doug@Royer.com=20
                  | Office:=20
  (208)612-INET
 http://Royer.com/People/Doug   |   =
 Fax:=20
  (866)594-8574
              =
 =20
                  |   Cell: =

  (208)520-4044

              =
 =20
  We Do Standards - You Need=20
Standards



------=_NextPart_000_005D_01C36CAF.E492AC00--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 16:51: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 QAA07654
	for ; Wed, 27 Aug 2003 16:51:37 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RKYHgc084264
	for ; Wed, 27 Aug 2003 13:34:17 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RKYHMA084263
	for ietf-calendar-bks; Wed, 27 Aug 2003 13:34:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RKYFgc084257
	for ; Wed, 27 Aug 2003 13:34:15 -0700 (PDT)
	(envelope-from satyanarayana.vempati@Sun.COM)
Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42])
	by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7RKYHvG000814;
	Wed, 27 Aug 2003 14:34:17 -0600 (MDT)
Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91])
	by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7RKYGaJ000209;
	Wed, 27 Aug 2003 13:34:16 -0700 (PDT)
Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109])
 by ha13sca-mail1.sfbay.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct  1 2002))
 with ESMTP id <0HKA002VFP54PN@ha13sca-mail1.sfbay.sun.com>; Wed,
 27 Aug 2003 13:34:16 -0700 (PDT)
Date: Wed, 27 Aug 2003 13:34:19 -0700
From: Satya Vempati 
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
To: "Robert_Ransdell@notesdev.ibm.com" ,
        "ietf-calendar@imc.org" 
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-language: en-USA
Content-transfer-encoding: 7BIT
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7BIT


I think everyone agrees that the RECURRENCE-IDs change when the recurrence
set is changed (e.g. a new RRULE/EXRULE). There should be no change to the
RECURRENCE-ID if one instance gets rescheduled.
 
The next interesting challenge is to find a scheme for updating SEQUENCE
numbers on the master and exception events while conforming to iTIP.

-----Original Message-----
From: Robert_Ransdell@notesdev.ibm.com
[mailto:Robert_Ransdell@notesdev.ibm.com]
Sent: Wednesday, August 27, 2003 12:29 PM
To: ietf-calendar@imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?



Only when you send a new RULE 
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com 



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org 

08/27/2003 03:03 PM 
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org"  
cc
Subject
Does anyone still think that RECURRENCE-ID's do NOT change?

	





I know that there may be more screams that this issues will not
go away. But it really needs to be settled.

Despite the claims on this list, it appears that almost everyone
agrees that the RECURRECE-ID's do change and must change.

I think that proof is:

                So your first invitation is to:

                     UID:100
                     SEQUENCE:0
                     DATE:...sep-1...10am...

                Then you get:

                     UID:100
                     SEQUENCE:1
                     RRULE;FREQ=DAILY;COUNT=10
                     DTSTART:...sep-2...3pm

                What is the RECURRENCE-ID for the 1st object?
                  ...sep-1...10am... Correct?

                So which of the 10 instances has its RECURRENCE-ID fixed
to the 1st
                object?

                What are the 10 RECURRENCE-ID's for the 2nd object?

Does anyone still think that RECURRENCE-ID's do NOT change?

-- 

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

                We Do Standards - You Need Standards






From owner-ietf-calendar@mail.imc.org  Wed Aug 27 17:16: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 RAA09179
	for ; Wed, 27 Aug 2003 17:16:00 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RL1Fgc085179
	for ; Wed, 27 Aug 2003 14:01:15 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RL1FHx085178
	for ietf-calendar-bks; Wed, 27 Aug 2003 14:01:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RL1Egc085168
	for ; Wed, 27 Aug 2003 14:01:14 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7RL1DS5022631
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 27 Aug 2003 14:01:15 -0700
Message-ID: <3F4D1C14.1090804@Royer.com>
Date: Wed, 27 Aug 2003 15:01:08 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050504090507080101010302"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms050504090507080101010302
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> Only when you send a new RULE

I assume you also mean change any of:

	DTSTART
	RDATE
	RRULE
	EXDATE
	EXRULE

> _____________________
> Note: new email address
> 
> tom_ransdell@notesdev.ibm.com
> 
> 
> Doug Royer 
> Sent by: owner-ietf-calendar@mail.imc.org
> 
> 08/27/2003 03:03 PM
> Please respond to
> "ietf-calendar@imc.org" 
> 
> 
> 	
> To
> 	"ietf-calendar@imc.org" 
> cc
> 	
> Subject
> 	Does anyone still think that RECURRENCE-ID's do NOT change?
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> I know that there may be more screams that this issues will not
> go away. But it really needs to be settled.
> 
> Despite the claims on this list, it appears that almost everyone
> agrees that the RECURRECE-ID's do change and must change.
> 
> I think that proof is:
> 
>                 So your first invitation is to:
> 
>                      UID:100
>                      SEQUENCE:0
>                      DATE:...sep-1...10am...
> 
>                 Then you get:
> 
>                      UID:100
>                      SEQUENCE:1
>                      RRULE;FREQ=DAILY;COUNT=10
>                      DTSTART:...sep-2...3pm
> 
>                 What is the RECURRENCE-ID for the 1st object?
>                   ...sep-1...10am... Correct?
> 
>                 So which of the 10 instances has its RECURRENCE-ID fixed 
> to the 1st
>                 object?
> 
>                 What are the 10 RECURRENCE-ID's for the 2nd object?
> 
> Does anyone still think that RECURRENCE-ID's do NOT change?
> 
> -- 
> 
>  Doug Royer                     |   http://INET-Consulting.com
>  -------------------------------|-----------------------------
>  Doug@Royer.com                 | Office: (208)612-INET
>  http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                 |   Cell: (208)520-4044
> 
>                 We Do Standards - You Need Standards
> 

-- 

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

                 We Do Standards - You Need Standards

--------------ms050504090507080101010302
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyNzIxMDEwOFowIwYJKoZIhvcNAQkEMRYEFElDi0eD
rvmyUYlHvICSsX0yWhoHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBABxYO8HseSnp6n6aRLwRkp8xiPFmWYkVBCYG745zzcdmH3mG04Rq
uYUYcl7M3uQOCbVgBINmMAhGDj1NLUZd3WPStWoVq4PJtp5fQHHYh0oWxzX2+/jo6DO21zPj
qIeBLGXfuuGzGnGoGL6pDQ6rQdvZR0jBduMl67Obcp5FxSVG0XvozHSbWYtPK0VQh1imGDj6
2lmDvBEi+WpYBgXZRjICIIQH0LOsIOUAmZfyJLrrmqNGbHFq2znU9vqV4XffrxdsmvNt2P81
OeRDfLNtBYhlp++VO5Q6qYCAyEpOOAMpKkWC9vNgsZUpilMNMlWODh1xhervaQs3qSu4jdHX
bdIAAAAAAAA=
--------------ms050504090507080101010302--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 17:35: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 RAA10434
	for ; Wed, 27 Aug 2003 17:35:38 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RLIQgc086134
	for ; Wed, 27 Aug 2003 14:18:26 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RLIQUE086133
	for ietf-calendar-bks; Wed, 27 Aug 2003 14:18:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RLIOgc086128
	for ; Wed, 27 Aug 2003 14:18:24 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7RLIOS5022859
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 27 Aug 2003 14:18:25 -0700
Message-ID: <3F4D201A.3040200@Royer.com>
Date: Wed, 27 Aug 2003 15:18:18 -0600
From: Doug Royer 
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020109020701060206090602"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms020109020701060206090602
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Shannon J. Clark wrote:
> It occurs to me to wonder, mostly as a user, what a change in RULE does 
> to events IN THE PAST?
>  
> In at least some calendars, I have seen "past" events deleted or 
> otherwise modified when rules have been modified.
>  
> Perhaps this is not specifically a question for the standards, but it 
> appears to me to be something fairly important in general.
>  
> 1. Is there a built in assumption to the calendaring standards that 
> there is a "past" "present" and "future", perhaps with the possibility 
> that no changes should modify the past?

No. iCAL and iTIP specify how to transfer information. It is up
to the CUA to care about the CU's view of the history of a UID.


> 2. If not, should the standards at least make a clear suggestion of a 
> standardized way to handle reoccurring events which change how they 
> reoccur, where the "past" events MUST remain on the times on which they 
> occurred?


There is a 'RANGE' parameter that is used with the RECURRENCE-ID
property to specify changes relative to a time, but NOT the same purpose.

So when the ORGANIZER changes a VEVENT for example, they can
change the instances 'this' (by RANGE's omission), THISANDPRIOR,
and THISANDFUTURE.

However as the usage of calendaring information may vary, it is
a CUA implementation detail as to the memory of any obsolete objects
or instances. I do not think that it could be standardized without
very specific and constrained usage definitions. What would work
for 'a history of events' might not apply to 'motel reservations'.

If a CUA needs to remember history it could save the objects in
its CS with a modified UID that it could use to tell were related
to the originals, or kept for history, or ....

-- 

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

                 We Do Standards - You Need Standards

--------------ms020109020701060206090602
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyNzIxMTgxOFowIwYJKoZIhvcNAQkEMRYEFA18i5pb
+WOZXKAkvWv1TjMTF7n4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAGKkyB/SMrdTDhoKVy6MAuEjodBzl1ZxG/mQYly5nCk8qMn6w9ap
Dwe00R/MOOfv80Q3n+LdEFSHESEjbYRplwtJvoxXEiBjhKig5s4wtZ4Q0LnwJVLmixxGPIs4
RWterL+vd06kpOYX4PlKRfdyF0WFEKdH+UYE7uCnrTa4dfMauoSUhtD44agWbR0oQv88nJ68
WCP+RA/keqf4lNq+TVulaI0zUvDewgeiKZRDIvC5Xsr8YArMSGCZd9NpaviVSrhU5R6F6OmH
H/Fhb63qtky6k7M7RxHimbDzYF2OBFGJLeYbI0MIA6uq79Z1fjh4x6HWAixYpL8HlBkAbVC+
Y10AAAAAAAA=
--------------ms020109020701060206090602--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 17:41: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 RAB10929
	for ; Wed, 27 Aug 2003 17:41:53 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RLQCgc086405
	for ; Wed, 27 Aug 2003 14:26:13 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RLQC02086404
	for ietf-calendar-bks; Wed, 27 Aug 2003 14:26:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RLQBgc086399
	for ; Wed, 27 Aug 2003 14:26:11 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7RLQAS5022932
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 27 Aug 2003 14:26:12 -0700
Message-ID: <3F4D21ED.4030707@Royer.com>
Date: Wed, 27 Aug 2003 15:26:05 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020003070701090004040206"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms020003070701090004040206
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> You are sending invalid instance invitations to start with.
> If you send an Instance invitation you MUST include the RECURRENCE-ID
 >
> When you send a REQUEST with a new RULE.  You are telling the receiving 
> Calendar Store ...NUKE ALL ENTRIES   in your calendar store.   Nothing 
> in your store is valid, I AM RESETTING THE RULE AND RECURRENCE-IDs and 
> sending all new information.

It goes further than that as iTIP says that when the SEQUENCE changes
then all older objects are obsolete. And SEQUENCE can be incremented
for more than instance changes.

And as all changes to any instance (single or all) require that the
SEQUENCE must be incremented, then yes the old instances are obsolete
and must be nuked. So according to iTIP it is the fact that the SEQUENCE
number got bumped that causes the old obsolete objects (instances
and all) to get nuked. However if no instance is changed and for other
reasons the SEQUENCE is incremented, then it is just a coincidence
that the RECURRENCE-IDs in the old nuked objects just happen to be
the same as the ones in the new object.


> _____________________
> Note: new email address
> 
> tom_ransdell@notesdev.ibm.com
> 
> 
> Doug Royer 
> Sent by: owner-ietf-calendar@mail.imc.org
> 
> 08/27/2003 03:03 PM
> Please respond to
> "ietf-calendar@imc.org" 
> 
> 
> 	
> To
> 	"ietf-calendar@imc.org" 
> cc
> 	
> Subject
> 	Does anyone still think that RECURRENCE-ID's do NOT change?
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> I know that there may be more screams that this issues will not
> go away. But it really needs to be settled.
> 
> Despite the claims on this list, it appears that almost everyone
> agrees that the RECURRECE-ID's do change and must change.
> 
> I think that proof is:
> 
>                 So your first invitation is to:
> 
>                      UID:100
>                      SEQUENCE:0
>                      DATE:...sep-1...10am...
> 
>                 Then you get:
> 
>                      UID:100
>                      SEQUENCE:1
>                      RRULE;FREQ=DAILY;COUNT=10
>                      DTSTART:...sep-2...3pm
> 
>                 What is the RECURRENCE-ID for the 1st object?
>                   ...sep-1...10am... Correct?
> 
>                 So which of the 10 instances has its RECURRENCE-ID fixed 
> to the 1st
>                 object?
> 
>                 What are the 10 RECURRENCE-ID's for the 2nd object?
> 
> Does anyone still think that RECURRENCE-ID's do NOT change?
> 
> -- 
> 
>  Doug Royer                     |   http://INET-Consulting.com
>  -------------------------------|-----------------------------
>  Doug@Royer.com                 | Office: (208)612-INET
>  http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                 |   Cell: (208)520-4044
> 
>                 We Do Standards - You Need Standards
> 

-- 

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

                 We Do Standards - You Need Standards

--------------ms020003070701090004040206
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyNzIxMjYwNVowIwYJKoZIhvcNAQkEMRYEFGcIgrKj
JDK9CN4bQ9dtZViA6FGvMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBADzB/UP2VOWi+6fUt4cntsx97Gaq0HEqR7b8ddFYXkYTLGTYwW/M
vqJSF3WXGxEpVGBxelFDmfrh4jml413qVfaEx0I6mO4avFTCT+PqzySHaojlbdmlRk+YmViJ
dlyfYQ27cdKhdwNJpDRSMLX4XUZxrV0Gj9AqM6w+vuzg+1r4dD7AcrhqhUWqC61CHRTgztT+
5XDlfPwqfVpNVW+A5XbUEZlRQ5bVvC8abI/4+si3nSTNNC2vwXJATgi85umoibAtYZRlPJOU
Y6KqjfMdPHcbYAAeggHCNDlevIy0Rau0NAFzEtnsOB+uSRrK7q/E1w3QgpR5uPh5DNYuj12C
MsIAAAAAAAA=
--------------ms020003070701090004040206--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 17:43: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 RAA11043
	for ; Wed, 27 Aug 2003 17:43:40 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RLUEgc086590
	for ; Wed, 27 Aug 2003 14:30:14 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RLUEE8086589
	for ietf-calendar-bks; Wed, 27 Aug 2003 14:30:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RLUDgc086584
	for ; Wed, 27 Aug 2003 14:30:13 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7RLUDS5022964
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 27 Aug 2003 14:30:14 -0700
Message-ID: <3F4D22DF.9010907@Royer.com>
Date: Wed, 27 Aug 2003 15:30:07 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000304090402030201010508"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms000304090402030201010508
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Satya Vempati wrote:
> I think everyone agrees that the RECURRENCE-IDs change when the recurrence
> set is changed (e.g. a new RRULE/EXRULE). There should be no change to the
> RECURRENCE-ID if one instance gets rescheduled.

False because there is NO way to reschedule one instance without bumping
the SEQUENCE number. Thus the set changes. Thus the RECURRENCE-IDs
always change on one OR all instance rescheduling changes.


> The next interesting challenge is to find a scheme for updating SEQUENCE
> numbers on the master and exception events while conforming to iTIP.

I do not follow. Do you mean that you want to update instances and not
change the SEQUENCE? If so, why?

-- 

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

                 We Do Standards - You Need Standards

--------------ms000304090402030201010508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyNzIxMzAwN1owIwYJKoZIhvcNAQkEMRYEFJUVPbeT
iElPeUUdDCNrTS4LUPAUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBALtAO8itLMqCO/Qhmr2yMUv20xH1ms4zdhMncJktw8hxBoLpXvjH
346APZc7M7zCuQjS63UABgYbhsHP5GwzhEzGkNffOpdjHHw8WmPePzrWum8m2Tn4r+oT3xqf
Zb3G00hQfnKb7zxaagLzNHaCs4e6PAz/TS2EwE4o24gsxkciEqH0pCGxyTp9rFPXVwcinqF5
fECxSKP+W6B6uegHKSkJGm9S8VsD6egv92ji3Df1noLGyb3MdCjUpOn/17I23QKqGVuaD67J
QVO4EElUjFJl6LA3TBAc3aIadQwm/arFMz57T9vwd226eYdy6oA8g2rzB2JEMDrp6RLEMd2A
RbgAAAAAAAA=
--------------ms000304090402030201010508--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 18:17: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 SAA13941
	for ; Wed, 27 Aug 2003 18:17:53 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RM66gc088148
	for ; Wed, 27 Aug 2003 15:06:06 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RM66cB088143
	for ietf-calendar-bks; Wed, 27 Aug 2003 15:06:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RM65gc088128
	for ; Wed, 27 Aug 2003 15:06:05 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4D1C14.1090804@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Wed, 27 Aug 2003 17:58:32 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/27/2003
 06:05:53 PM,
	Serialize complete at 08/27/2003 06:05:53 PM
Content-Type: multipart/alternative; boundary="=_alternative 00784BAF85256D8F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 00784BAF85256D8F_=
Content-Type: text/plain; charset="US-ASCII"

No I do not.


I do mean 
                 RDATE
                 RRULE
                 EXDATE
                 EXRULE

DTSTART is not part of RULE
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/27/2003 05:01 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Robert_Ransdell@notesdev.ibm.com wrote:
> 
> Only when you send a new RULE

I assume you also mean change any of:

                 DTSTART
                 RDATE
                 RRULE
                 EXDATE
                 EXRULE

> _____________________
> Note: new email address
> 
> tom_ransdell@notesdev.ibm.com
> 
> 
> Doug Royer 
> Sent by: owner-ietf-calendar@mail.imc.org
> 
> 08/27/2003 03:03 PM
> Please respond to
> "ietf-calendar@imc.org" 
> 
> 
> 
> To
>                "ietf-calendar@imc.org" 
> cc
> 
> Subject
>                Does anyone still think that RECURRENCE-ID's do NOT 
change?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I know that there may be more screams that this issues will not
> go away. But it really needs to be settled.
> 
> Despite the claims on this list, it appears that almost everyone
> agrees that the RECURRECE-ID's do change and must change.
> 
> I think that proof is:
> 
>                 So your first invitation is to:
> 
>                      UID:100
>                      SEQUENCE:0
>                      DATE:...sep-1...10am...
> 
>                 Then you get:
> 
>                      UID:100
>                      SEQUENCE:1
>                      RRULE;FREQ=DAILY;COUNT=10
>                      DTSTART:...sep-2...3pm
> 
>                 What is the RECURRENCE-ID for the 1st object?
>                   ...sep-1...10am... Correct?
> 
>                 So which of the 10 instances has its RECURRENCE-ID fixed 

> to the 1st
>                 object?
> 
>                 What are the 10 RECURRENCE-ID's for the 2nd object?
> 
> Does anyone still think that RECURRENCE-ID's do NOT change?
> 
> -- 
> 
>  Doug Royer                     |   http://INET-Consulting.com
>  -------------------------------|-----------------------------
>  Doug@Royer.com                 | Office: (208)612-INET
>  http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                 |   Cell: (208)520-4044
> 
>                 We Do Standards - You Need Standards
> 

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 00784BAF85256D8F_=
Content-Type: text/html; charset="US-ASCII"



No I do not.





I do mean 

           
     RDATE

                
RRULE

                
EXDATE

                
EXRULE



DTSTART is not part of RULE

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/27/2003 05:01 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

> Only when you send a new RULE



I assume you also mean change any of:



                
DTSTART

                
RDATE

                
RRULE

                
EXDATE

                
EXRULE



> _____________________

> Note: new email address

> 

> tom_ransdell@notesdev.ibm.com

> 

> 

> Doug Royer <Doug@royer.com>

> Sent by: owner-ietf-calendar@mail.imc.org

> 

> 08/27/2003 03:03 PM

> Please respond to

> "ietf-calendar@imc.org" <ietf-calendar@imc.org>

> 

> 

>                  

> To

>                  "ietf-calendar@imc.org"
<ietf-calendar@imc.org>

> cc

>                  

> Subject

>                  Does
anyone still think that RECURRENCE-ID's do NOT change?

> 

> 

>                  

> 

> 

> 

> 

> 

> 

> I know that there may be more screams that this issues will not

> go away. But it really needs to be settled.

> 

> Despite the claims on this list, it appears that almost everyone

> agrees that the RECURRECE-ID's do change and must change.

> 

> I think that proof is:

> 

>                 So your first
invitation is to:

> 

>                    
 UID:100

>                    
 SEQUENCE:0

>                    
 DATE:...sep-1...10am...

> 

>                 Then you get:

> 

>                    
 UID:100

>                    
 SEQUENCE:1

>                    
 RRULE;FREQ=DAILY;COUNT=10

>                    
 DTSTART:...sep-2...3pm

> 

>                 What is the
RECURRENCE-ID for the 1st object?

>                   ...sep-1...10am...
Correct?

> 

>                 So which of
the 10 instances has its RECURRENCE-ID fixed 

> to the 1st

>                 object?

> 

>                 What are the
10 RECURRENCE-ID's for the 2nd object?

> 

> Does anyone still think that RECURRENCE-ID's do NOT change?

> 

> -- 

> 

>  Doug Royer              
      |   http://INET-Consulting.com

>  -------------------------------|-----------------------------

>  Doug@Royer.com              
  | Office: (208)612-INET

>  http://Royer.com/People/Doug   |    Fax: (866)594-8574

>                    
            |   Cell: (208)520-4044

> 

>                 We Do Standards
- You Need Standards

> 



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 00784BAF85256D8F_=--


From owner-ietf-calendar@mail.imc.org  Wed Aug 27 18: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 SAA13978
	for ; Wed, 27 Aug 2003 18:18:15 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RM66gc088146
	for ; Wed, 27 Aug 2003 15:06:06 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RM66pj088144
	for ietf-calendar-bks; Wed, 27 Aug 2003 15:06:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RM65gc088127
	for ; Wed, 27 Aug 2003 15:06:05 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4D21ED.4030707@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Wed, 27 Aug 2003 18:00:12 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/27/2003
 06:05:53 PM,
	Serialize complete at 08/27/2003 06:05:53 PM
Content-Type: multipart/alternative; boundary="=_alternative 007872DC85256D8F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 007872DC85256D8F_=
Content-Type: text/plain; charset="US-ASCII"

The reschedule  to an instance only changes the SEQUENCE on that 
instance... NOT ON THE ENTIRE SET.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/27/2003 05:26 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Robert_Ransdell@notesdev.ibm.com wrote:
> 
> You are sending invalid instance invitations to start with.
> If you send an Instance invitation you MUST include the RECURRENCE-ID
 >
> When you send a REQUEST with a new RULE.  You are telling the receiving 
> Calendar Store ...NUKE ALL ENTRIES   in your calendar store.   Nothing 
> in your store is valid, I AM RESETTING THE RULE AND RECURRENCE-IDs and 
> sending all new information.

It goes further than that as iTIP says that when the SEQUENCE changes
then all older objects are obsolete. And SEQUENCE can be incremented
for more than instance changes.

And as all changes to any instance (single or all) require that the
SEQUENCE must be incremented, then yes the old instances are obsolete
and must be nuked. So according to iTIP it is the fact that the SEQUENCE
number got bumped that causes the old obsolete objects (instances
and all) to get nuked. However if no instance is changed and for other
reasons the SEQUENCE is incremented, then it is just a coincidence
that the RECURRENCE-IDs in the old nuked objects just happen to be
the same as the ones in the new object.


> _____________________
> Note: new email address
> 
> tom_ransdell@notesdev.ibm.com
> 
> 
> Doug Royer 
> Sent by: owner-ietf-calendar@mail.imc.org
> 
> 08/27/2003 03:03 PM
> Please respond to
> "ietf-calendar@imc.org" 
> 
> 
> 
> To
>                "ietf-calendar@imc.org" 
> cc
> 
> Subject
>                Does anyone still think that RECURRENCE-ID's do NOT 
change?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I know that there may be more screams that this issues will not
> go away. But it really needs to be settled.
> 
> Despite the claims on this list, it appears that almost everyone
> agrees that the RECURRECE-ID's do change and must change.
> 
> I think that proof is:
> 
>                 So your first invitation is to:
> 
>                      UID:100
>                      SEQUENCE:0
>                      DATE:...sep-1...10am...
> 
>                 Then you get:
> 
>                      UID:100
>                      SEQUENCE:1
>                      RRULE;FREQ=DAILY;COUNT=10
>                      DTSTART:...sep-2...3pm
> 
>                 What is the RECURRENCE-ID for the 1st object?
>                   ...sep-1...10am... Correct?
> 
>                 So which of the 10 instances has its RECURRENCE-ID fixed 

> to the 1st
>                 object?
> 
>                 What are the 10 RECURRENCE-ID's for the 2nd object?
> 
> Does anyone still think that RECURRENCE-ID's do NOT change?
> 
> -- 
> 
>  Doug Royer                     |   http://INET-Consulting.com
>  -------------------------------|-----------------------------
>  Doug@Royer.com                 | Office: (208)612-INET
>  http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                 |   Cell: (208)520-4044
> 
>                 We Do Standards - You Need Standards
> 

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 007872DC85256D8F_=
Content-Type: text/html; charset="US-ASCII"



The reschedule  to an instance
only changes the SEQUENCE on that instance... NOT ON THE ENTIRE SET.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/27/2003 05:26 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

> You are sending invalid instance invitations to start with.

> If you send an Instance invitation you MUST include the RECURRENCE-ID

 >

> When you send a REQUEST with a new RULE.  You are telling the
receiving 

> Calendar Store ...NUKE ALL ENTRIES   in your calendar store.
  Nothing 

> in your store is valid, I AM RESETTING THE RULE AND RECURRENCE-IDs
and 

> sending all new information.



It goes further than that as iTIP says that when the SEQUENCE changes

then all older objects are obsolete. And SEQUENCE can be incremented

for more than instance changes.



And as all changes to any instance (single or all) require that the

SEQUENCE must be incremented, then yes the old instances are obsolete

and must be nuked. So according to iTIP it is the fact that the SEQUENCE

number got bumped that causes the old obsolete objects (instances

and all) to get nuked. However if no instance is changed and for other

reasons the SEQUENCE is incremented, then it is just a coincidence

that the RECURRENCE-IDs in the old nuked objects just happen to be

the same as the ones in the new object.





> _____________________

> Note: new email address

> 

> tom_ransdell@notesdev.ibm.com

> 

> 

> Doug Royer <Doug@royer.com>

> Sent by: owner-ietf-calendar@mail.imc.org

> 

> 08/27/2003 03:03 PM

> Please respond to

> "ietf-calendar@imc.org" <ietf-calendar@imc.org>

> 

> 

>                  

> To

>                  "ietf-calendar@imc.org"
<ietf-calendar@imc.org>

> cc

>                  

> Subject

>                  Does
anyone still think that RECURRENCE-ID's do NOT change?

> 

> 

>                  

> 

> 

> 

> 

> 

> 

> I know that there may be more screams that this issues will not

> go away. But it really needs to be settled.

> 

> Despite the claims on this list, it appears that almost everyone

> agrees that the RECURRECE-ID's do change and must change.

> 

> I think that proof is:

> 

>                 So your first
invitation is to:

> 

>                    
 UID:100

>                    
 SEQUENCE:0

>                    
 DATE:...sep-1...10am...

> 

>                 Then you get:

> 

>                    
 UID:100

>                    
 SEQUENCE:1

>                    
 RRULE;FREQ=DAILY;COUNT=10

>                    
 DTSTART:...sep-2...3pm

> 

>                 What is the
RECURRENCE-ID for the 1st object?

>                   ...sep-1...10am...
Correct?

> 

>                 So which of
the 10 instances has its RECURRENCE-ID fixed 

> to the 1st

>                 object?

> 

>                 What are the
10 RECURRENCE-ID's for the 2nd object?

> 

> Does anyone still think that RECURRENCE-ID's do NOT change?

> 

> -- 

> 

>  Doug Royer              
      |   http://INET-Consulting.com

>  -------------------------------|-----------------------------

>  Doug@Royer.com              
  | Office: (208)612-INET

>  http://Royer.com/People/Doug   |    Fax: (866)594-8574

>                    
            |   Cell: (208)520-4044

> 

>                 We Do Standards
- You Need Standards

> 



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 007872DC85256D8F_=--


From owner-ietf-calendar@mail.imc.org  Wed Aug 27 18: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 SAA13980
	for ; Wed, 27 Aug 2003 18:18:16 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RM66gc088147
	for ; Wed, 27 Aug 2003 15:06:06 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RM66fE088145
	for ietf-calendar-bks; Wed, 27 Aug 2003 15:06:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RM65gd088128
	for ; Wed, 27 Aug 2003 15:06:06 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4D22DF.9010907@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Wed, 27 Aug 2003 18:02:27 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/27/2003
 06:05:54 PM,
	Serialize complete at 08/27/2003 06:05:54 PM
Content-Type: multipart/alternative; boundary="=_alternative 0078A76185256D8F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0078A76185256D8F_=
Content-Type: text/plain; charset="US-ASCII"

This is WRONG Doug.  Rescheduling an instance only changes the SEQUENCE on 
that instance.  IT DOES NOT reset the RECURRENCE-ID of that instance, and 
it DOES NOT reset the PATTERN (RULE) of the meeting.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/27/2003 05:30 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Satya Vempati wrote:
> I think everyone agrees that the RECURRENCE-IDs change when the 
recurrence
> set is changed (e.g. a new RRULE/EXRULE). There should be no change to 
the
> RECURRENCE-ID if one instance gets rescheduled.

False because there is NO way to reschedule one instance without bumping
the SEQUENCE number. Thus the set changes. Thus the RECURRENCE-IDs
always change on one OR all instance rescheduling changes.


> The next interesting challenge is to find a scheme for updating SEQUENCE
> numbers on the master and exception events while conforming to iTIP.

I do not follow. Do you mean that you want to update instances and not
change the SEQUENCE? If so, why?

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 0078A76185256D8F_=
Content-Type: text/html; charset="US-ASCII"



This is WRONG Doug.  Rescheduling
an instance only changes the SEQUENCE on that instance.  IT DOES NOT
reset the RECURRENCE-ID of that instance, and it DOES NOT reset the PATTERN
(RULE) of the meeting.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/27/2003 05:30 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Satya Vempati wrote:

> I think everyone agrees that the RECURRENCE-IDs change when the recurrence

> set is changed (e.g. a new RRULE/EXRULE). There should be no change
to the

> RECURRENCE-ID if one instance gets rescheduled.



False because there is NO way to reschedule one instance without bumping

the SEQUENCE number. Thus the set changes. Thus the RECURRENCE-IDs

always change on one OR all instance rescheduling changes.





> The next interesting challenge is to find a scheme for updating SEQUENCE

> numbers on the master and exception events while conforming to iTIP.



I do not follow. Do you mean that you want to update instances and not

change the SEQUENCE? If so, why?



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 0078A76185256D8F_=--


From owner-ietf-calendar@mail.imc.org  Wed Aug 27 19:13: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 TAA17452
	for ; Wed, 27 Aug 2003 19:13:57 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMw8gc090089
	for ; Wed, 27 Aug 2003 15:58:08 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RMw8NB090088
	for ietf-calendar-bks; Wed, 27 Aug 2003 15:58:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMw6gc090083
	for ; Wed, 27 Aug 2003 15:58:06 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7RMw6S5023882
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 27 Aug 2003 15:58:08 -0700
Message-ID: <3F4D3779.5060503@Royer.com>
Date: Wed, 27 Aug 2003 16:58:01 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080206030509050603020703"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms080206030509050603020703
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


If you change the DTSTART - *only*, as in:

	SEQUENCE:X
	DTSTART:...monday..
	RRULE:FREQ=WEEKLY

To:

	SEQUENCE:X+Y
	DTSTART:...tuesday...
	RRULE:FREQ=WEEKLY.

The instances and RECURRECE-ID's change.
So DTSTART *is* included even when; RRULE,
RDATE, EXDATE, and EXRULE do not change.


Robert_Ransdell@notesdev.ibm.com wrote:
> 
> No I do not.
> 
> 
> I do mean
>                  RDATE
>                 RRULE
>                 EXDATE
>                 EXRULE
> 
> DTSTART is not part of RULE
> _____________________
> Note: new email address
> 
> tom_ransdell@notesdev.ibm.com
> 
> 
> Doug Royer 
> Sent by: owner-ietf-calendar@mail.imc.org
> 
> 08/27/2003 05:01 PM
> Please respond to
> "ietf-calendar@imc.org" 
> 
> 
> 	
> To
> 	"ietf-calendar@imc.org" 
> cc
> 	
> Subject
> 	Re: Does anyone still think that RECURRENCE-ID's do NOT change?
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> 
> Robert_Ransdell@notesdev.ibm.com wrote:
>  >
>  > Only when you send a new RULE
> 
> I assume you also mean change any of:
> 
>                 DTSTART
>                 RDATE
>                 RRULE
>                 EXDATE
>                 EXRULE
> 
>  > _____________________
>  > Note: new email address
>  >
>  > tom_ransdell@notesdev.ibm.com
>  >
>  >
>  > Doug Royer 
>  > Sent by: owner-ietf-calendar@mail.imc.org
>  >
>  > 08/27/2003 03:03 PM
>  > Please respond to
>  > "ietf-calendar@imc.org" 
>  >
>  >
>  >                  
>  > To
>  >                  "ietf-calendar@imc.org" 
>  > cc
>  >                  
>  > Subject
>  >                  Does anyone still think that RECURRENCE-ID's do NOT 
> change?
>  >
>  >
>  >                  
>  >
>  >
>  >
>  >
>  >
>  >
>  > I know that there may be more screams that this issues will not
>  > go away. But it really needs to be settled.
>  >
>  > Despite the claims on this list, it appears that almost everyone
>  > agrees that the RECURRECE-ID's do change and must change.
>  >
>  > I think that proof is:
>  >
>  >                 So your first invitation is to:
>  >
>  >                      UID:100
>  >                      SEQUENCE:0
>  >                      DATE:...sep-1...10am...
>  >
>  >                 Then you get:
>  >
>  >                      UID:100
>  >                      SEQUENCE:1
>  >                      RRULE;FREQ=DAILY;COUNT=10
>  >                      DTSTART:...sep-2...3pm
>  >
>  >                 What is the RECURRENCE-ID for the 1st object?
>  >                   ...sep-1...10am... Correct?
>  >
>  >                 So which of the 10 instances has its RECURRENCE-ID fixed
>  > to the 1st
>  >                 object?
>  >
>  >                 What are the 10 RECURRENCE-ID's for the 2nd object?
>  >
>  > Does anyone still think that RECURRENCE-ID's do NOT change?
>  >
>  > --
>  >
>  >  Doug Royer                     |   http://INET-Consulting.com
>  >  -------------------------------|-----------------------------
>  >  Doug@Royer.com                 | Office: (208)612-INET
>  >  http://Royer.com/People/Doug   |    Fax: (866)594-8574
>  >                                 |   Cell: (208)520-4044
>  >
>  >                 We Do Standards - You Need Standards
>  >
> 
> -- 
> 
>  Doug Royer                     |   http://INET-Consulting.com
>  -------------------------------|-----------------------------
>  Doug@Royer.com                 | Office: (208)612-INET
>  http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                 |   Cell: (208)520-4044
> 
>                 We Do Standards - You Need Standards
> 

-- 

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

                 We Do Standards - You Need Standards

--------------ms080206030509050603020703
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyNzIyNTgwMVowIwYJKoZIhvcNAQkEMRYEFJN4zS1w
QbEYcwDqmrEuDITNsWTbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAJQZOK9K8UkJr5GZ6IxwpYR/6taGCpbJBu/6MGdtEm/3VpRfl+D/
Vhksf4Qj5nreGwoHEU6g2/n+usmG+2sT3HMq304/lX9KYGWaveo8G94l4a6ywIwHksd+kPVG
0E0qi7/4LPgBzfeJKzmySDn151tQwQrAuJN/XVQLqCzIN21TL4SkzeilibZVZbBKE2O3z7MU
AwDnoa6t5EfSOzl5es//seTwtM5wW4fxvhlEk8FqzGqX8rZ7CTdFOuxFFk52exPf1mbyJ0R1
gYtzoqycwxYCI96MIIOmFGtfBVbRr7NjKaVdkdsy2c32NFM6V1mc2vawI3vV+GwI5B8cpig/
FrwAAAAAAAA=
--------------ms080206030509050603020703--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 19:16: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 TAA17662
	for ; Wed, 27 Aug 2003 19:16:39 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RN2sgc090510
	for ; Wed, 27 Aug 2003 16:02:54 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RN2sUK090509
	for ietf-calendar-bks; Wed, 27 Aug 2003 16:02:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RN2pgc090499
	for ; Wed, 27 Aug 2003 16:02:51 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19s9KA-0006h1-00
	for ; Thu, 28 Aug 2003 01:03:34 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19s9K9-0006gt-00
	for ; Thu, 28 Aug 2003 01:03:33 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19s9JP-0005Du-00
	for ; Thu, 28 Aug 2003 01:02:47 +0200
From: "Michael Fair" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Wed, 27 Aug 2003 16:02:50 -0700
Lines: 81
Message-ID: 
References:  <3F4D22DF.9010907@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 know that Doug won't see this, but for the sake of
just having another voice weigh in on the issue for
the archives here goes:

> > I think everyone agrees that the RECURRENCE-IDs change
> > when the recurrence
> > set is changed (e.g. a new RRULE/EXRULE). There should
> > be no change to the
> > RECURRENCE-ID if one instance gets rescheduled.
>
> False because there is NO way to reschedule one instance without bumping
> the SEQUENCE number. Thus the set changes. Thus the RECURRENCE-IDs
> always change on one OR all instance rescheduling changes.

False because Doug Royer and Chris Olds do not agree and they
are part of "everyone".

Otherwise, excluding those two people, this seems true.

The instances themselves have their own SEQUENCE which
is always equal or greater than that of the base recurring
event description itself.  This is what is meant when
iTIP says that each instances "may be both referenced
and versioned".

Each instance of a recurring event has a RECURRENCE-ID
that remains fixed for as long as the SEQEUNCE of the
base recurring event remains the same.  This is what
iCal means when it says "for each UID/SEQUENCE pair
the RECURRENCE-ID remains fixed".

As a consequence, the only time you impact the RECURRENCE-ID
set is when you change the recurrence rules.  This always
causes a SEQUENCE bump on the base recurring event.

Doug is a 2-bit fool who can't stand 1-bit of being wrong.
His model is flawed.  His model is not iCal nor iTIP.
His model cannot be implemented sanely given iTIP's goals.
He puts you on his ignore list when you press him to prove
anything to the contrary - especially on the implementation side.

The SEQUENCE for the entire set does not bump whenever you
reschedule an instance and only two people I know of try to
do it this way, one is Doug Royer and the other is Chris Olds.


> > The next interesting challenge is to find a scheme for updating SEQUENCE
> > numbers on the master and exception events while conforming to iTIP.

This doesn't make any sense to me.  The only time you want to bump
the SEQUENCE value is when you've changed something that invalidates
the ATTENDENCE status of an ATTENDEE.  iTIP defines how to do this
for an entire recurring series, or for instances quite plainly.

When you bump the SEQUENCE on the base event it's as if you are telling
the recipient CUAs to completely throw out any of the existing data
they have for that event and you are providing all new data.  Both
the base event and all isntances are updated to the new SEQUENCE.

If you wanted to also keep any instance reschedules in tact, you
would simply send objects with a SEQUENCE larger than that of the
base object and include that in the update as well.

If the base was SEQ:1 and if the largest instance was at SEQ:5
then the reschedule of the base event would be SEQ:6.  This
would gaurantee that it will override any other prior instance
modifications.

If you simply wanted to attach more - non SEQUENCE affecting data -
to the base event or instances, no SEQUENCE bump is required and
iTIP clearly spells out how to do this too.


This is all totally valid within iTIP already.
I don't see the interesting challenge.

-- Michael --







From owner-ietf-calendar@mail.imc.org  Wed Aug 27 19:18:42 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17797
	for ; Wed, 27 Aug 2003 19:18:41 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RN5fgc090566
	for ; Wed, 27 Aug 2003 16:05:41 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RN5fgM090565
	for ietf-calendar-bks; Wed, 27 Aug 2003 16:05:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RN5dgc090560
	for ; Wed, 27 Aug 2003 16:05:40 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7RN5dS5023951
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 27 Aug 2003 16:05:41 -0700
Message-ID: <3F4D393E.7040905@Royer.com>
Date: Wed, 27 Aug 2003 17:05:34 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090709000800050604090307"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms090709000800050604090307
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> The reschedule  to an instance only changes the SEQUENCE on that 
> instance... NOT ON THE ENTIRE SET.

Whether this is done with RRULEs, ADD's or what ever, if the result
is equivalent to:

	SEQUENCE:0
	RDATE:...monday...
	RDATE:...tuesday..

And then the Monday meeting is chagned to Friday with
a single instance modificaiton:

	SEQUENCE:1
	RECURRENCE-ID:...monday
	RDATE:...friday...

The RECURRENCE-ID for Monday is void because I could have
choosen to send the following and not the previous example:

	SEQUENCE:1
	RDATE:...friday...
	RDATE:...tuesday..

And the results must be equivelent to the ATTENDEE.

So in all cases the 'set' of RECURRECNE-ID's is not the same
and SEQUENCE:0


-- 

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

                 We Do Standards - You Need Standards

--------------ms090709000800050604090307
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyNzIzMDUzNFowIwYJKoZIhvcNAQkEMRYEFABOp9+y
F41VQVFg8hR6uSeUBgHMMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBADh8Iv3CZakOMPkmWU01SQNKiAMkFiT5Pn55MYpaLijEfusDTnG1
83zrmzrBlE3YFIW6rVtAv0dXazcl7rS2cDOgPZlU9DyeTQ8MN9oBEukbRarU4uBvSAMYH3KZ
ZI3Pr9AMv2TFF6MbjnAWVWjuCsIL5lEjyfF+bYVcu3Tq8bUhwQMaXox0diQlUy8VH8xEqKZf
7yFXsmnEoDQFqDRUdoducaGqzuEUi7dU8ax86eB2FhVmE7AWxHRYwZfjhynJ044Hetct/YDA
gyYcwgk2v1+YD9oA38ChBqZMY1IJ8sdKsPtsVzK9+B7+5TB44GxoOMpwtVls2VhTnHpbdwET
HyMAAAAAAAA=
--------------ms090709000800050604090307--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 19:22: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 TAA18089
	for ; Wed, 27 Aug 2003 19:22:03 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RN7Wgc090633
	for ; Wed, 27 Aug 2003 16:07:32 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RN7WBE090632
	for ietf-calendar-bks; Wed, 27 Aug 2003 16:07:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RN7Vgc090627
	for ; Wed, 27 Aug 2003 16:07:31 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7RN7SS5023961
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Wed, 27 Aug 2003 16:07:32 -0700
Message-ID: <3F4D39AA.3020205@Royer.com>
Date: Wed, 27 Aug 2003 17:07:22 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040808090006080508050805"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms040808090006080508050805
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> This is WRONG Doug.  Rescheduling an instance only changes the SEQUENCE 
> on that instance.  IT DOES NOT reset the RECURRENCE-ID of that instance, 
> and it DOES NOT reset the PATTERN (RULE) of the meeting.

WRONG - If you change a MONDAY to a FRIDAY - please explain
how the pattern has not been altered? Or please show
an example of a rescheduling of an instance that has
the same pattern before and after the reschedule.


-- 

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

                 We Do Standards - You Need Standards

--------------ms040808090006080508050805
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyNzIzMDcyMlowIwYJKoZIhvcNAQkEMRYEFO601+IP
ucL1kRgFSZlfgoXI7fkSMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBABPGD5DiK0NrDnWVF1teJvfqPv4WtOs1azhr1Pk6KuVVIwyTHHHI
ki9ZaeDZcAWcwmBdwwnVIgSMfB//ZNiSdHwC3twCnIZ5TXVToiTMFvvPgPOUVnIM4JBjIw/3
rcJu8iENNGePbYytPNcVCll4yU2+GWJ553NWxE1ZTuHZ8StHZRMIN/L3ukXPIiKow13OiwJ7
fnbluzKhe9DMmkuF9ACwXi1xBzFOtcvqn0qWGA7RFtv/lQl9hAhu8qC87+D89Wr+RDFyJVp2
5O4FjsJ2Oku6EAlkZI9u4+MTGJONSSSu43bTCB5h7MMlZ5gJwuhsDOV3ZVjtlbgpBtnLvpv4
nloAAAAAAAA=
--------------ms040808090006080508050805--



From owner-ietf-calendar@mail.imc.org  Wed Aug 27 19:24:43 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18217
	for ; Wed, 27 Aug 2003 19:24:43 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RNBbgc090804
	for ; Wed, 27 Aug 2003 16:11:37 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RNBbOH090801
	for ietf-calendar-bks; Wed, 27 Aug 2003 16:11:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RNBZgc090796
	for ; Wed, 27 Aug 2003 16:11:35 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19s9Sh-0006nf-00
	for ; Thu, 28 Aug 2003 01:12:23 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19s9Sg-0006nX-00
	for ; Thu, 28 Aug 2003 01:12:22 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19s9Rw-0005Sz-00
	for ; Thu, 28 Aug 2003 01:11:36 +0200
From: "Michael Fair" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Wed, 27 Aug 2003 16:11:39 -0700
Lines: 166
Message-ID: 
References: <3F4D1C14.1090804@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: 



If I change "DTSTART" on the base object, it says that
I am redefining all instances to start at that new time.

Since RECURRENCE-IDs are both date and time based, and
they are calculated off of the RULEs plus the DTSTART,
this would be a redefinition of the set and would redefine
the RECURRENCE-IDs since every single instance now starts
at that new time.


Since we are forced to bump the SEQUENCE number when changing
DTSTART there is no violation of iCal nor iTIP here.  It
just means something other than an instance reschedule. It
means a reschedule of the entire set and as is appropriate
to such an act it redefines the set of RECURRENCE-IDs.


Again, it does not mean an instance reschedule.  It has nothing
to do with an instance reschedule.  It is not true that changing
the DTSTART of any particular instance redefines the entire
set and therefore no RECURRENCE-IDs change in the event of an
instance reschedule.

-- Michael --

 wrote in message
news:OFBC1666DC.9DBFA4B1-ON85256D8F.007898BA-85256D8F.00784BB9@notesdev.ibm.com...
> No I do not.
>
>
> I do mean
>                  RDATE
>                  RRULE
>                  EXDATE
>                  EXRULE
>
> DTSTART is not part of RULE
> _____________________
> Note: new email address
>
> tom_ransdell@notesdev.ibm.com
>
>
>
> Doug Royer 
> Sent by: owner-ietf-calendar@mail.imc.org
> 08/27/2003 05:01 PM
> Please respond to
> "ietf-calendar@imc.org" 
>
>
> To
> "ietf-calendar@imc.org" 
> cc
>
> Subject
> Re: Does anyone still think that RECURRENCE-ID's do NOT change?
>
>
>
>
>
>
>
>
> Robert_Ransdell@notesdev.ibm.com wrote:
> >
> > Only when you send a new RULE
>
> I assume you also mean change any of:
>
>                  DTSTART
>                  RDATE
>                  RRULE
>                  EXDATE
>                  EXRULE
>
> > _____________________
> > Note: new email address
> >
> > tom_ransdell@notesdev.ibm.com
> >
> >
> > Doug Royer 
> > Sent by: owner-ietf-calendar@mail.imc.org
> >
> > 08/27/2003 03:03 PM
> > Please respond to
> > "ietf-calendar@imc.org" 
> >
> >
> >
> > To
> >                "ietf-calendar@imc.org" 
> > cc
> >
> > Subject
> >                Does anyone still think that RECURRENCE-ID's do NOT
> change?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I know that there may be more screams that this issues will not
> > go away. But it really needs to be settled.
> >
> > Despite the claims on this list, it appears that almost everyone
> > agrees that the RECURRECE-ID's do change and must change.
> >
> > I think that proof is:
> >
> >                 So your first invitation is to:
> >
> >                      UID:100
> >                      SEQUENCE:0
> >                      DATE:...sep-1...10am...
> >
> >                 Then you get:
> >
> >                      UID:100
> >                      SEQUENCE:1
> >                      RRULE;FREQ=DAILY;COUNT=10
> >                      DTSTART:...sep-2...3pm
> >
> >                 What is the RECURRENCE-ID for the 1st object?
> >                   ...sep-1...10am... Correct?
> >
> >                 So which of the 10 instances has its RECURRENCE-ID fixed
>
> > to the 1st
> >                 object?
> >
> >                 What are the 10 RECURRENCE-ID's for the 2nd object?
> >
> > Does anyone still think that RECURRENCE-ID's do NOT change?
> >
> > -- 
> >
> >  Doug Royer                     |   http://INET-Consulting.com
> >  -------------------------------|-----------------------------
> >  Doug@Royer.com                 | Office: (208)612-INET
> >  http://Royer.com/People/Doug   |    Fax: (866)594-8574
> >                                 |   Cell: (208)520-4044
> >
> >                 We Do Standards - You Need Standards
> >
>
> -- 
>
>   Doug Royer                     |   http://INET-Consulting.com
>   -------------------------------|-----------------------------
>   Doug@Royer.com                 | Office: (208)612-INET
>   http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                  |   Cell: (208)520-4044
>
>                  We Do Standards - You Need Standards
>
>





From owner-ietf-calendar@mail.imc.org  Wed Aug 27 20:06: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 UAA21126
	for ; Wed, 27 Aug 2003 20:06:29 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RNpggc092519
	for ; Wed, 27 Aug 2003 16:51:42 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7RNpgfK092518
	for ietf-calendar-bks; Wed, 27 Aug 2003 16:51:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RNpegc092512
	for ; Wed, 27 Aug 2003 16:51:41 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sA5U-000779-00
	for ; Thu, 28 Aug 2003 01:52:28 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19sA5U-000771-00
	for ; Thu, 28 Aug 2003 01:52:28 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sA4j-0006b6-00
	for ; Thu, 28 Aug 2003 01:51:41 +0200
From: "Michael Fair" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Wed, 27 Aug 2003 16:51:45 -0700
Lines: 75
Message-ID: 
References:  <3F4D393E.7040905@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: 



Updates to DTSTART, EX/RRULE, EX/RDATE or submitting
an ADD all update the SEQUENCE of the base event.
They all redefine the set of RECURRENCE-IDs.

None of these however are instance reschedules.
Instance reschedules only bump the SEQUENCE of that
individual instance not the base object and therefore
do not redefine any RECURRENCE-IDs.

We have presented on several occasions the problems
that ensue if one did try and do this and he has not
addressed them.  Further, even for arguments sake,
he has not even accurately represented the SEQUENCE
per instance behavior when he talks about the
fixed-id model.

Doug has not addressed what he thinks that each instance
"may be both referenced and versioned" means, but his
other supporter Chris Olds acknowledged that it *could*
mean that each instance had its own SEQUENCE value.

Meaning that even a proponent of Doug's model says
that per instance SEQUENCE values can not be disputed
as invalid.  Though, because of the "may", he does not
go so far as to say that iTIP says that each instance
definitely has its own SEQUENCE value and contends that
their one-SEQUENCE-for-all model is still valid within
that wording.

While I don't disagree with him on that point, other
wording from both iCal and iTIP becomes more meaningful
when each instance MUST track a SEQUENCE independently.

-- Michael --




"Doug Royer"  wrote in message
news:3F4D393E.7040905@Royer.com...
>
>
> Robert_Ransdell@notesdev.ibm.com wrote:
> >
> > The reschedule  to an instance only changes the SEQUENCE on that
> > instance... NOT ON THE ENTIRE SET.
>
> Whether this is done with RRULEs, ADD's or what ever, if the result
> is equivalent to:
>
> SEQUENCE:0
> RDATE:...monday...
> RDATE:...tuesday..
>
> And then the Monday meeting is chagned to Friday with
> a single instance modificaiton:
>
> SEQUENCE:1
> RECURRENCE-ID:...monday
> RDATE:...friday...
>
> The RECURRENCE-ID for Monday is void because I could have
> choosen to send the following and not the previous example:
>
> SEQUENCE:1
> RDATE:...friday...
> RDATE:...tuesday..
>
> And the results must be equivelent to the ATTENDEE.
>
> So in all cases the 'set' of RECURRECNE-ID's is not the same
> and SEQUENCE:0





From owner-ietf-calendar@mail.imc.org  Wed Aug 27 20:18: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 UAA21782
	for ; Wed, 27 Aug 2003 20:18:08 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S04Egc092918
	for ; Wed, 27 Aug 2003 17:04:14 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7S04EDa092916
	for ietf-calendar-bks; Wed, 27 Aug 2003 17:04:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S04Dgc092905
	for ; Wed, 27 Aug 2003 17:04:13 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4D39AA.3020205@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Wed, 27 Aug 2003 19:58:20 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/27/2003
 08:04:46 PM,
	Serialize complete at 08/27/2003 08:04:46 PM
Content-Type: multipart/alternative; boundary="=_alternative 0083437685256D8F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0083437685256D8F_=
Content-Type: text/plain; charset="US-ASCII"

Since you never listen to any arguments that you did not start, why should 
I bother sending you anything.
This has been explained many time in the past, including the document from 
the original author Derik Stenerson.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/27/2003 07:07 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Robert_Ransdell@notesdev.ibm.com wrote:
> 
> This is WRONG Doug.  Rescheduling an instance only changes the SEQUENCE 
> on that instance.  IT DOES NOT reset the RECURRENCE-ID of that instance, 

> and it DOES NOT reset the PATTERN (RULE) of the meeting.

WRONG - If you change a MONDAY to a FRIDAY - please explain
how the pattern has not been altered? Or please show
an example of a rescheduling of an instance that has
the same pattern before and after the reschedule.


-- 

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

                 We Do Standards - You Need Standards


--=_alternative 0083437685256D8F_=
Content-Type: text/html; charset="US-ASCII"



Since you never listen to any arguments
that you did not start, why should I bother sending you anything.

This has been explained many time in
the past, including the document from the original author Derik
Stenerson.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/27/2003 07:07 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

> This is WRONG Doug.  Rescheduling an instance only changes the
SEQUENCE 

> on that instance.  IT DOES NOT reset the RECURRENCE-ID of that
instance, 

> and it DOES NOT reset the PATTERN (RULE) of the meeting.



WRONG - If you change a MONDAY to a FRIDAY - please explain

how the pattern has not been altered? Or please show

an example of a rescheduling of an instance that has

the same pattern before and after the reschedule.





-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 0083437685256D8F_=--


From owner-ietf-calendar@mail.imc.org  Wed Aug 27 20: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 UAA21925
	for ; Wed, 27 Aug 2003 20:21:01 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S04Egc092917
	for ; Wed, 27 Aug 2003 17:04:14 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7S04En5092915
	for ietf-calendar-bks; Wed, 27 Aug 2003 17:04:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S04Dgc092906
	for ; Wed, 27 Aug 2003 17:04:13 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4D393E.7040905@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Wed, 27 Aug 2003 19:55:28 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/27/2003
 08:04:46 PM,
	Serialize complete at 08/27/2003 08:04:46 PM
Content-Type: multipart/alternative; boundary="=_alternative 0083005485256D8F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0083005485256D8F_=
Content-Type: text/plain; charset="US-ASCII"

We are not doing your CRAZY model.
You do not send an RDATE in and instance REQUEST





_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/27/2003 07:05 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Robert_Ransdell@notesdev.ibm.com wrote:
> 
> The reschedule  to an instance only changes the SEQUENCE on that 
> instance... NOT ON THE ENTIRE SET.

Whether this is done with RRULEs, ADD's or what ever, if the result
is equivalent to:

                 SEQUENCE:0
                 RDATE:...monday...
                 RDATE:...tuesday..

And then the Monday meeting is chagned to Friday with
a single instance modificaiton:

                 SEQUENCE:1
                 RECURRENCE-ID:...monday
                 RDATE:...friday...

The RECURRENCE-ID for Monday is void because I could have
choosen to send the following and not the previous example:

                 SEQUENCE:1
                 RDATE:...friday...
                 RDATE:...tuesday..

And the results must be equivelent to the ATTENDEE.

So in all cases the 'set' of RECURRECNE-ID's is not the same
and SEQUENCE:0


-- 

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

                 We Do Standards - You Need Standards


--=_alternative 0083005485256D8F_=
Content-Type: text/html; charset="US-ASCII"



We are not doing your CRAZY model.

You do not send an RDATE in and instance
REQUEST











_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/27/2003 07:05 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

> The reschedule  to an instance only changes the SEQUENCE on that


> instance... NOT ON THE ENTIRE SET.



Whether this is done with RRULEs, ADD's or what ever, if the result

is equivalent to:



                
SEQUENCE:0

                
RDATE:...monday...

                
RDATE:...tuesday..



And then the Monday meeting is chagned to Friday with

a single instance modificaiton:



                
SEQUENCE:1

                
RECURRENCE-ID:...monday

                
RDATE:...friday...



The RECURRENCE-ID for Monday is void because I could have

choosen to send the following and not the previous example:



                
SEQUENCE:1

                
RDATE:...friday...

                
RDATE:...tuesday..



And the results must be equivelent to the ATTENDEE.



So in all cases the 'set' of RECURRECNE-ID's is not the same

and SEQUENCE:0





-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 0083005485256D8F_=--


From owner-ietf-calendar@mail.imc.org  Wed Aug 27 20:29: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 UAA22510
	for ; Wed, 27 Aug 2003 20:29:35 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S0F1gc093258
	for ; Wed, 27 Aug 2003 17:15:01 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7S0ExQ2093253
	for ietf-calendar-bks; Wed, 27 Aug 2003 17:14:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S0Eugc093242
	for ; Wed, 27 Aug 2003 17:14:56 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sAS0-0007Ha-00
	for ; Thu, 28 Aug 2003 02:15:44 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19sARz-0007HS-00
	for ; Thu, 28 Aug 2003 02:15:43 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sARF-0007ED-00
	for ; Thu, 28 Aug 2003 02:14:57 +0200
From: "Michael Fair" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Wed, 27 Aug 2003 17:15:01 -0700
Lines: 74
Message-ID: 
References:  <3F4D39AA.3020205@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: 


Would someone please say this to Doug on my behalf.
A simple empty reply post should be enough.

Step 1 the initial recurring event:
UID:1
SEQ:0
RRULE:All Monday's

Step 2 move the "1st Monday" instance's DTSTART time
to "That Friday":
UID:1
RID:1st Monday
SEQ:1
DTSTART:That Friday


Now let's say someone issues a REFRESH on UID:1,
here's what they would get in response (without
the separator lines of course):

BEGIN:VCALENDAR
-----------------------------------
BEGIN:VEVENT
UID:1
SEQ:0
RRULE:All Monday's
END:VEVENT
-----------------------------------
BEGIN:VEVENT
UID:1
RID:1st Monday
SEQ:1
DTSTART:That Friday
END:VEVENT
-----------------------------------
END:VCALENDAR


They would not get some concocted variation of
EXDATE and RDATE with an RRULE to try and describe
every Monday except the first Monday but include
that Friday with whole base object at SEQUENCE 1.

-- Michael --


"Doug Royer"  wrote in message
news:3F4D39AA.3020205@Royer.com...
>
>
> Robert_Ransdell@notesdev.ibm.com wrote:
> >
> > This is WRONG Doug.  Rescheduling an instance only changes the SEQUENCE
> > on that instance.  IT DOES NOT reset the RECURRENCE-ID of that instance,
> > and it DOES NOT reset the PATTERN (RULE) of the meeting.
>
> WRONG - If you change a MONDAY to a FRIDAY - please explain
> how the pattern has not been altered? Or please show
> an example of a rescheduling of an instance that has
> the same pattern before and after the reschedule.
>
>
> -- 
>
>   Doug Royer                     |   http://INET-Consulting.com
>   -------------------------------|-----------------------------
>   Doug@Royer.com                 | Office: (208)612-INET
>   http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                  |   Cell: (208)520-4044
>
>                  We Do Standards - You Need Standards
>





From owner-ietf-calendar@mail.imc.org  Wed Aug 27 20:54: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 UAA24578
	for ; Wed, 27 Aug 2003 20:54:32 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S0emgc094127
	for ; Wed, 27 Aug 2003 17:40:48 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7S0emHE094126
	for ietf-calendar-bks; Wed, 27 Aug 2003 17:40:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S0elgc094121
	for ; Wed, 27 Aug 2003 17:40:47 -0700 (PDT)
	(envelope-from satyanarayana.vempati@Sun.COM)
Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42])
	by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7S0emvG020916;
	Wed, 27 Aug 2003 18:40:48 -0600 (MDT)
Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91])
	by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7S0emaJ006581;
	Wed, 27 Aug 2003 17:40:48 -0700 (PDT)
Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109])
 by ha13sca-mail1.sfbay.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct  1 2002))
 with ESMTP id <0HKB000S10K0DR@ha13sca-mail1.sfbay.sun.com>; Wed,
 27 Aug 2003 17:40:48 -0700 (PDT)
Date: Wed, 27 Aug 2003 17:40:50 -0700
From: Satya Vempati 
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
To: Michael Fair ,
        "ietf-calendar@imc.org" 
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-language: en-USA
Content-transfer-encoding: 7BIT
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7BIT


Surely, Doug & Chris also agree that the RECURRENCE-ID changes when the
base recurrence set changes. They may not agree that RECURRENCE-ID stays
put if an instance is changed. Well, after the post from the original
authors, I hoped that this issue would be laid to rest. But ...

The SEQUENCE numbering scheme I am talking about is the following issue:

Suppose the base set is UID:1, SEQ:0
We reschedule an instance: UID:1, RID:x, SEQ:1
We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50 (attendee
A is invited to this instance alone)
Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51 OR
UID:1, SEQ:1?

If the SEQ:0 changes to SEQ:51

All CUAs sees a jump from UID:1, SEQ:0 to UID:1, SEQ:51 and assume they
have missed some intermediate updates (and based on your earlier posts)
would do a REFRESH. I believe the iTIP spirit to use REFRESH only when the
CUA realizes that something has gone wrong and not as a routine part of
the workflow. I see such a frequent requirement for REFRESH as an issue.

If the SEQ:0 changes to SEQ:1, and you regenerate the instances, UID:1,
RID:x will have SEQ:0 and attendee A's CUA may discard the change.

Or it could even be UID:1, SEQ:1 and UID:1, RID:x, SEQ:51.

We need to settle on the following:
  1) what changes (RRULES/EXRULES etc.) constitute changing the base set? 
  2) what is the best way to assign sequence numbers (without creating a
REFRESH storm)?
  3) under what circumstances to discard all existing exceptions to a
recurring event (If a Monday meeting is changed to Monday, Wednesday
meeting, do we really need to lose the all the old instances and
associated exception data?)

My point is that we should focus on moving on to other issues and not flog
the dead horse ("Will recurrence-id change for an instance reschedule?")
for ever.

-----Original Message-----
From: Michael Fair [mailto:michael@daclubhouse.net]
Sent: Wednesday, August 27, 2003 4:03 PM
To: ietf-calendar@imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?



I know that Doug won't see this, but for the sake of
just having another voice weigh in on the issue for
the archives here goes:

> > I think everyone agrees that the RECURRENCE-IDs change
> > when the recurrence
> > set is changed (e.g. a new RRULE/EXRULE). There should
> > be no change to the
> > RECURRENCE-ID if one instance gets rescheduled.
>
> False because there is NO way to reschedule one instance without bumping
> the SEQUENCE number. Thus the set changes. Thus the RECURRENCE-IDs
> always change on one OR all instance rescheduling changes.

False because Doug Royer and Chris Olds do not agree and they
are part of "everyone".

Otherwise, excluding those two people, this seems true.

The instances themselves have their own SEQUENCE which
is always equal or greater than that of the base recurring
event description itself.  This is what is meant when
iTIP says that each instances "may be both referenced
and versioned".

Each instance of a recurring event has a RECURRENCE-ID
that remains fixed for as long as the SEQEUNCE of the
base recurring event remains the same.  This is what
iCal means when it says "for each UID/SEQUENCE pair
the RECURRENCE-ID remains fixed".

As a consequence, the only time you impact the RECURRENCE-ID
set is when you change the recurrence rules.  This always
causes a SEQUENCE bump on the base recurring event.

Doug is a 2-bit fool who can't stand 1-bit of being wrong.
His model is flawed.  His model is not iCal nor iTIP.
His model cannot be implemented sanely given iTIP's goals.
He puts you on his ignore list when you press him to prove
anything to the contrary - especially on the implementation side.

The SEQUENCE for the entire set does not bump whenever you
reschedule an instance and only two people I know of try to
do it this way, one is Doug Royer and the other is Chris Olds.


> > The next interesting challenge is to find a scheme for updating
SEQUENCE
> > numbers on the master and exception events while conforming to iTIP.

This doesn't make any sense to me.  The only time you want to bump
the SEQUENCE value is when you've changed something that invalidates
the ATTENDENCE status of an ATTENDEE.  iTIP defines how to do this
for an entire recurring series, or for instances quite plainly.

When you bump the SEQUENCE on the base event it's as if you are telling
the recipient CUAs to completely throw out any of the existing data
they have for that event and you are providing all new data.  Both
the base event and all isntances are updated to the new SEQUENCE.

If you wanted to also keep any instance reschedules in tact, you
would simply send objects with a SEQUENCE larger than that of the
base object and include that in the update as well.

If the base was SEQ:1 and if the largest instance was at SEQ:5
then the reschedule of the base event would be SEQ:6.  This
would gaurantee that it will override any other prior instance
modifications.

If you simply wanted to attach more - non SEQUENCE affecting data -
to the base event or instances, no SEQUENCE bump is required and
iTIP clearly spells out how to do this too.


This is all totally valid within iTIP already.
I don't see the interesting challenge.

-- Michael --








From owner-ietf-calendar@mail.imc.org  Wed Aug 27 21:27: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 VAA27614
	for ; Wed, 27 Aug 2003 21:27:02 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S1Bqgc095304
	for ; Wed, 27 Aug 2003 18:11:52 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7S1BqqQ095303
	for ietf-calendar-bks; Wed, 27 Aug 2003 18:11:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S1Bogc095297
	for ; Wed, 27 Aug 2003 18:11:50 -0700 (PDT)
	(envelope-from TimHare@comcast.net)
Received: from thare.comcast.net (pcp01313897pcs.micske01.fl.comcast.net[68.35.251.175](misconfigured sender))
          by comcast.net (sccrmhc12) with SMTP
          id <2003082801114601200i405ee>
          (Authid: TimHare);
          Thu, 28 Aug 2003 01:11:46 +0000
Message-Id: <5.2.1.1.0.20030827204809.00a0d510@mail.comcast.net>
X-Sender: TimHare@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Wed, 27 Aug 2003 21:08:31 -0400
To: IETF Calendaring and Scheduling Working Group 
From: Tim Hare 
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: 


Would someone please send me (or post) where in this discussion we've 
discussed the following paragraph from 3.7.1 in iTIP? As I read this 
paragraph, this says that RECURRENCE-ID changes when some substantive 
change to the entire VEVENT changes, certainly, but the last sentence 
definitely says that RECURRENCE-ID changes, and the wording and order is 
such that it implies that this happens for an instance change.

------------------------------------------------ BEGIN  BLOCK QUOTE 
--------------------------------------------------------------
    An instance of a recurring event is assigned a unique identification,
    "RECURRENCE-ID" property, when that instance is renegotiated.
    Negotiation may be necessary when a substantive change to the event
    or to-do has be made (such as changing the start time, end time, due
    date or location). The "Organizer" can identify a specific recurrence
    instance using the "RECURRENCE-ID" property. The property value is
    equal to the date/time of the instance. If the "Organizer" wishes to
    change the "DTSTART", the original "DTSTART" value is used for
    "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
    reflect the change.  Note that after the change has occurred, the
    "RECURRENCE-ID" has changed to the new "DTSTART" value.
------------------------- END BLOCK QUOTE --------------------------------

I also would like to know, if the RECURRENCE-ID _is_ fixed, then why wasn't 
an arbitrary sequence number used for RECURRENCE-ID rather than the 
date-oriented one (in my view the enumeration method of identifying 
recurrence instances would have eliminated a lot of semantic confusion in 
our discussions!)?

The one answer I come up with is "So Calendar Stores which don't 
automatically expand recurrence sets can easily determine the RECURRENCE-ID 
of one instance". If that is so, then at the moment when one instance is 
changed, it must be stored in the CS as though it were a complete VEVENT, 
correct? If the CS doesn't want to store that one instance, then it must 
modify the VEVENT to have recurrence rules that reflect the original set 
PLUS the change - which is a modification to the pattern, and thus 
_requires_ SEQUENCE to be updated. I'm not completely convinced that 
SEQUENCE is has to be updated for _all_ changes to individual instances, 
because that would require every instance to be stored as a VEVENT 
(SEQUENCE being a property of VEVENT as near as I can tell from RFC2445. If 
SEQUENCE is a property of each instance, then every instance must be 
expanded whenever it is updated, which in a sense "promotes" it from one 
instance of a recurrence set to a VEVENT in its own right.

Notice, I'm not arguing right or wrong here, I'm trying to understand what 
iCal says about these as objects versus what the communication protocols 
say about it.

I still think we need to come up with one set of objects and users so we 
can all talk about the same items with the same identifiers. At a minimum, 
this should include one VEVENT that doesn't have recurrence rules, one set 
that does, and ORGANIZER, some ATTENDEEs, some official delegates, AND some 
users that get forwarded the information unofficially. We can then also 
define a set of actions to be performed on these objects. If we can do 
this, then we can all discuss things from the "same page".  I will try to 
work this up over the next couple of days and then find a place to post it. 
Maybe it will help, maybe not, but I believe it's worth a shot.

Tim Hare 




From owner-ietf-calendar@mail.imc.org  Wed Aug 27 23:01: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 XAA06735
	for ; Wed, 27 Aug 2003 23:01:16 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S2iVgc098389
	for ; Wed, 27 Aug 2003 19:44:31 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7S2iVii098388
	for ietf-calendar-bks; Wed, 27 Aug 2003 19:44:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from DrPepper (adsl-67-119-131-54.dsl.lsan03.pacbell.net [67.119.131.54])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S2iTgc098383
	for ; Wed, 27 Aug 2003 19:44:30 -0700 (PDT)
	(envelope-from michael@daclubhouse.net)
Received: by DrPepper (Postfix, from userid 65534)
	id 07436881799; Wed, 27 Aug 2003 19:44:31 -0700 (PDT)
Received: from cocacola (unknown [192.168.1.102])
	by DrPepper (Postfix) with ESMTP
	id 211F78113E3; Wed, 27 Aug 2003 19:44:30 -0700 (PDT)
Message-ID: <016301c36d0e$4e0c3b20$6601a8c0@daclubhouse.net>
From: "Michael Fair" 
To: "Satya Vempati" , 
References: 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Wed, 27 Aug 2003 19:44:29 -0700
Organization: DaClubhouse
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=-1.0 required=5.0
	tests=QUOTED_EMAIL_TEXT,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


> Surely, Doug & Chris also agree that the RECURRENCE-ID changes when the
> base recurrence set changes. They may not agree that RECURRENCE-ID stays
> put if an instance is changed. Well, after the post from the original
> authors, I hoped that this issue would be laid to rest. But ...

So did I, and as you say, but ...
 
...
> If the SEQ:0 changes to SEQ:51
...

If a CUA has any local instance that has SEQ:50, and the base 
increases to 51, then it can assume that it has seen everything.

If however, the base nor any instance is at 50, and it receives a
base at 51, then it actually has missed something (assuming the 
value has always increased by 1).

As for the "massive REFRESH requirement" you spoke of, the difference
between this model and the 'current-value' model is that for this case
and in this model it doesn't matter if the REFRESH actually makes it 
to the ORGANIZER and back.  The CUA already has the latest info and
adds it to the calendar without waiting for the REFRESH response.


Also, anyone who did not have an instance at 50, and was not invited 
to the base event will receive instance updates with SEQUENCE jump >1.
This may or may not cause a REFRESH depending on how paranoid the
programmer was.  The CUA would have already sent one REFRESH at the
time it received the first instance REQUEST.  It may consider that
request sufficient and not send another one.  In that case, it would
not send another REFRESH as it would just apply the latest copy of
the instance it knows about to the calendar.

However, it might also take the opportunity to send a REFRESH in case
it missed an update to the base object (which it actually didn't).
When dealing with recurring events and missed messages REFRESHes are
unavoidable, however as you saw above, if a CUA has indeed seen every
message, then it can detect that and not request the REFRESH.
The only exception to this is when a CU is only being invited to
individual instances.  But that's being addressed in other threads.

-- Michael --
 
-- Michael --


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 12:35: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 MAA28499
	for ; Thu, 28 Aug 2003 12:35:29 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SGM4gc077649
	for ; Thu, 28 Aug 2003 09:22:04 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SGM4Bs077647
	for ietf-calendar-bks; Thu, 28 Aug 2003 09:22:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SGM2gc077639
	for ; Thu, 28 Aug 2003 09:22:02 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SGM1S5002252
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 09:22:03 -0700
Message-ID: <3F4E2C24.2070400@Royer.com>
Date: Thu, 28 Aug 2003 10:21:56 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010005020202000400050903"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms010005020202000400050903
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Satya Vempati wrote:
> Surely, Doug & Chris also agree that the RECURRENCE-ID changes when the
> base recurrence set changes. They may not agree that RECURRENCE-ID stays
> put if an instance is changed. Well, after the post from the original
> authors, I hoped that this issue would be laid to rest. But ...

They clearly said it changes when the pattern changes.
Do you disagree that it changes when the pattern changes?


-- 

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

                 We Do Standards - You Need Standards

--------------ms010005020202000400050903
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODE2MjE1NlowIwYJKoZIhvcNAQkEMRYEFD619CAX
dqYi1lmdEPY7ngQ/oL/xMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAASkmk4KWA7CB1T2L3ehTH0JqQoyMZ3Cuk8gtGHhsUXFBg7rkjLi
FdCQU8CK7MAe4aaHYOc+rQ+KfqS23tWSzLMRVPxGVjAII/DWWTvODq6225joEL2kDCYghn1a
6F4OmpRBI8Go6hfqCCpVIH/DpyKQ340ZI7mX8cld+qvanTJhRLRfOencuPe7b+pCVZ3eVSjn
lWbeJGH8ivKZgXyakpB2lIxAA7OhQzc1paOk/Lxj+8KWzpNI+bTIPjXyG0+CNZuv+HdMqyxk
c/uk+I0o/BAJObLcuOs6Ef40n1q4BzjtIB/lKTG9abYnoJTs5lrEIfwMR6u3ZRDv9wtPSbvB
PVMAAAAAAAA=
--------------ms010005020202000400050903--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 12:36: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 MAA28539
	for ; Thu, 28 Aug 2003 12:36:01 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SGG8gc076534
	for ; Thu, 28 Aug 2003 09:16:08 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SGG8r3076533
	for ietf-calendar-bks; Thu, 28 Aug 2003 09:16:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SGG7gc076524
	for ; Thu, 28 Aug 2003 09:16:07 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SGFeS5002161
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 09:15:41 -0700
Message-ID: <3F4E2AA6.3030308@Royer.com>
Date: Thu, 28 Aug 2003 10:15:34 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030304050902000007010504"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms030304050902000007010504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> Since you never listen to any arguments that you did not start, why 
> should I bother sending you anything.

Your technical point being what?

> This has been explained many time in the past, including the document 
> from the original author Derik Stenerson.

In that email signed by Derik and Frank they said that it
moves when the pattern moves. Do you dispute that?

So rather than respond to what I see and gaping holes in your
position, you avoid the technical debate by self proclaimed
declarations of rightness and not a technical response.


-- 

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

                 We Do Standards - You Need Standards

--------------ms030304050902000007010504
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODE2MTUzNFowIwYJKoZIhvcNAQkEMRYEFLzl+cqe
3w/zLYiWjG3WHy7sTyEtMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAK28IMeVkOxduHO1RuCq8P9DnmOu7jLQsXknQVPwimdzmJLaCGem
7wTHF8nJCnelLS7TSghyvqzs/2Z2PgDIAX2OHqBOTnko3JZd9vTgYAZi7jSEXDCyN3Onos8Y
EyxyBOjADDAd849EA/8b50+2UEwrCliVVWDERz/08vx3aUlE/r2ML/2nwgD1eT/SylPkxYRb
CA1huK19w35waXZG5NGj96FGyxtSvaj8AGP9BeRz/pkGO6DCnnJSx70mg5VUn22yyaz8gyrd
rKRCMAwatjfU8smSW+V2/swennf5CTiBJvB0/HmNleu2Hf9kRpVH+spAjtg2EY/eK4GpPeDs
sVkAAAAAAAA=
--------------ms030304050902000007010504--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 13:11: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 NAA01104
	for ; Thu, 28 Aug 2003 13:11:36 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SGuDgc080184
	for ; Thu, 28 Aug 2003 09:56:13 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SGuDXv080183
	for ietf-calendar-bks; Thu, 28 Aug 2003 09:56:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SGuCgc080175
	for ; Thu, 28 Aug 2003 09:56:12 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SGuBS5002630
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 09:56:13 -0700
Message-ID: <3F4E3426.1000408@Royer.com>
Date: Thu, 28 Aug 2003 10:56:06 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060603010006050001040602"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms060603010006050001040602
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Satya Vempati wrote:

> The SEQUENCE numbering scheme I am talking about is the following issue:
> 
> Suppose the base set is UID:1, SEQ:0
> We reschedule an instance: UID:1, RID:x, SEQ:1
> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50 (attendee
> A is invited to this instance alone)
> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51 OR
> UID:1, SEQ:1?

iTIP says that when you send an instance update you increment
the SEQUENCE number each time. Do you disagree?

-- 

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

                 We Do Standards - You Need Standards

--------------ms060603010006050001040602
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODE2NTYwNlowIwYJKoZIhvcNAQkEMRYEFDhx8z6R
yzLQ1MVXqr7k1GHj8NC5MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAFGA4XeChMmKBroDhKpoKgeJ77VqKviOjCEodlO3eKCFNOg3DQ9L
emchvuRza2dws8LnEfBdxOlw0UthzKH0yyRMlKRRVh7tMtHZVDBb0niadW7uzdyBta0BJuxU
EgkhkFtHT977iVB6IaaQn5vGl+VDipD9g6Phtv5qlk4C8ZrEQVZ3x1pin9XaO81rJ77akjlr
DvxYF5ATdwQwKXukFs+jWHlxnmRUr4JwBQKoW4/LMeytsxWvawU38+93N1PX5SpW/stIYYZn
6LwiVOyYGyy/9rBBA+g63nHBSfCGWZ73Hwpjt4DAeUMAfTeGZRy4vxbqh6Dcc/1bcfzWD8W6
dvIAAAAAAAA=
--------------ms060603010006050001040602--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 13:14: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 NAA01313
	for ; Thu, 28 Aug 2003 13:14:13 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SH2Mgc081338
	for ; Thu, 28 Aug 2003 10:02:22 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SH2MCx081337
	for ietf-calendar-bks; Thu, 28 Aug 2003 10:02:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from DrPepper (adsl-67-119-131-54.dsl.lsan03.pacbell.net [67.119.131.54])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SH2Kgc081329
	for ; Thu, 28 Aug 2003 10:02:20 -0700 (PDT)
	(envelope-from michael@daclubhouse.net)
Received: by DrPepper (Postfix, from userid 65534)
	id 08C368113E3; Thu, 28 Aug 2003 10:02:18 -0700 (PDT)
Received: from cocacola (unknown [192.168.1.102])
	by DrPepper (Postfix) with ESMTP
	id DB48081079E; Thu, 28 Aug 2003 10:02:17 -0700 (PDT)
Message-ID: <024d01c36d86$23b7d000$6601a8c0@daclubhouse.net>
From: "Michael Fair" 
To: "Satya Vempati" , 
References: 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Thu, 28 Aug 2003 10:02:18 -0700
Organization: DaClubhouse
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=-0.5 required=5.0
	tests=REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


Doh!

I'm totally wrong about the CUAs needing to know if they missed
something.  I got distracted by all the talk prior about instances
and realized that this is actually in reference to the base event.

Since this is about the base event and not an instance, SEQUENCE
jumps don't matter as the most recent information is always the
most up to date.  It's only when the CUA receives information
about an instance which indicates that it might have missed
something about the base event that it sends a REFRESH..

> Suppose the base set is UID:1, SEQ:0
> We reschedule an instance: UID:1, RID:x, SEQ:1
> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50 (attendee
> A is invited to this instance alone)
...
> If the SEQ:0 changes to SEQ:51

Then the CUA updates to 51, uses the info contained
within and goes on its merry way regardless of what other
prior SEQUENCE numbers it may or may not have seen.
No REFRESH is needed at all because it has seen the latest
and greatest info.

-- Michael --



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 14:07: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 OAA05635
	for ; Thu, 28 Aug 2003 14:07:00 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SHregc085730
	for ; Thu, 28 Aug 2003 10:53:40 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SHreYh085729
	for ietf-calendar-bks; Thu, 28 Aug 2003 10:53:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SHrdgc085724
	for ; Thu, 28 Aug 2003 10:53:39 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4E3426.1000408@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Thu, 28 Aug 2003 13:32:31 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 01:54:15 PM,
	Serialize complete at 08/28/2003 01:54:15 PM
Content-Type: multipart/alternative; boundary="=_alternative 005FF0BC85256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 005FF0BC85256D90_=
Content-Type: text/plain; charset="US-ASCII"

There is nothing saying that invitee can not get SEQUENCE 20 and than 
SEQUENCE 30.
If chair reschedules several instances their individual SEQUENCE number 
will bump (NOT THE WHOLE SET).
If chair than reschedules over a range, the new sequence number for 
reschedule will be one greater than the highest sequence number on 
instances within range before reschedule.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/28/2003 12:56 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Satya Vempati wrote:

> The SEQUENCE numbering scheme I am talking about is the following issue:
> 
> Suppose the base set is UID:1, SEQ:0
> We reschedule an instance: UID:1, RID:x, SEQ:1
> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50 
(attendee
> A is invited to this instance alone)
> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51 OR
> UID:1, SEQ:1?

iTIP says that when you send an instance update you increment
the SEQUENCE number each time. Do you disagree?

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 005FF0BC85256D90_=
Content-Type: text/html; charset="US-ASCII"



There is nothing saying that invitee
can not get SEQUENCE 20 and than SEQUENCE 30.

If chair reschedules several instances
their individual SEQUENCE number will bump (NOT THE WHOLE SET).

If chair than reschedules over a range,
the new sequence number for reschedule will be one greater than the highest
sequence number on instances within range before reschedule.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/28/2003 12:56 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Satya Vempati wrote:



> The SEQUENCE numbering scheme I am talking about is the following
issue:

> 

> Suppose the base set is UID:1, SEQ:0

> We reschedule an instance: UID:1, RID:x, SEQ:1

> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50 (attendee

> A is invited to this instance alone)

> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51
OR

> UID:1, SEQ:1?



iTIP says that when you send an instance update you increment

the SEQUENCE number each time. Do you disagree?



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 005FF0BC85256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 14:30: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 OAA07226
	for ; Thu, 28 Aug 2003 14:30:53 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SIEYgc086781
	for ; Thu, 28 Aug 2003 11:14:34 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SIEY35086780
	for ietf-calendar-bks; Thu, 28 Aug 2003 11:14:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SIEWgc086772
	for ; Thu, 28 Aug 2003 11:14:32 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sRIj-0004a4-00
	for ; Thu, 28 Aug 2003 20:15:17 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19sRIi-0004Zw-00
	for ; Thu, 28 Aug 2003 20:15:16 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sRHz-0006mn-00
	for ; Thu, 28 Aug 2003 20:14:31 +0200
From: "Michael Fair" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Thu, 28 Aug 2003 11:14:30 -0700
Lines: 12
Message-ID: 
References:  <3F4E2AA6.3030308@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: 


> So rather than respond to what I see and gaping holes in your
> position, you avoid the technical debate by self proclaimed
> declarations of rightness and not a technical response.

If this ain't the pot calling the kettle black I don't
know what is.

The irony in Doug's accusation here is so bold it's painful. :)

-- Michael --





From owner-ietf-calendar@mail.imc.org  Thu Aug 28 14:52:45 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08455
	for ; Thu, 28 Aug 2003 14:52:45 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SIZVgc089146
	for ; Thu, 28 Aug 2003 11:35:31 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SIZVkb089145
	for ietf-calendar-bks; Thu, 28 Aug 2003 11:35:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SIZUgc089136
	for ; Thu, 28 Aug 2003 11:35:30 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SIZTS5003806
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 11:35:31 -0700
Message-ID: <3F4E4B6C.1030304@Royer.com>
Date: Thu, 28 Aug 2003 12:35:24 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050802040704040702070407"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms050802040704040702070407
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:


> 
(your childish rude comment removed)

> You do not send an RDATE in and instance REQUEST
 >
 > The reschedule  to an instance only changes the SEQUENCE on that
 > instance... NOT ON THE ENTIRE SET.

I should have sent:

Whether this is done with RRULEs, ADD's or what ever, if the result
is equivalent to:

                 SEQUENCE:0
		DTSTART:...monday...
                 RDATE:...tuesday..

And then the Monday meeting is changed to Friday with
a single instance modification:

                 SEQUENCE:1
                 RECURRENCE-ID:...monday
                 DTSTART:...friday...

The RECURRENCE-ID for Monday is void because I could have
chosen to send the following and not the previous example:

                 SEQUENCE:1
                 DTSTART:...friday...
                 RDATE:...tuesday..

So in all cases the 'set' of RECURRECNE-ID's is not the same
as SEQUENCE:0

-- 

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

                 We Do Standards - You Need Standards

--------------ms050802040704040702070407
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq
MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MjgxODM1MjRaMCMGCSqGSIb3DQEJBDEWBBQj
B/bLh6IgAhPyKjP8efTJ01M2sDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ
KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv
c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy
aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs
aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8
oTANBgkqhkiG9w0BAQEFAASCAQAGZDGKc1NHOJ9EdpOG1d34mzjO1pXpz+Py+KBbNsvQRJ1C
xpunWpukzm+DFkEKIU2ux51nxQhGBDneTc7HswYRnc8VN2V375ERgeckhv95J8PzqCwBX39I
nNSXjpesjMLco9sM7zgXpBlChudlDHJmTqVGkHp5Pc240Om/ao5JAcGPJxMjbjUFoxvg2iP6
ui95Ek5qoZpnOEzI/QxkHiRLwHH7JWk9y9ISM77N2mMXqhhEKQEqG6JPv8hwtm1ZYWO+4j7t
H08ihCbrMlZ67SF+7vmdFTWTJQXlPPq8OxCVhw9JVPUKd3vvLU815OnoX/EaTP04L11BLmZB
x6GFtFkOAAAAAAAA
--------------ms050802040704040702070407--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 14:57:45 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08728
	for ; Thu, 28 Aug 2003 14:57:44 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SIh3gc089867
	for ; Thu, 28 Aug 2003 11:43:03 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SIh3WO089866
	for ietf-calendar-bks; Thu, 28 Aug 2003 11:43:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SIh2gc089861
	for ; Thu, 28 Aug 2003 11:43:02 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SIh1S5003876
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 11:43:03 -0700
Message-ID: <3F4E4D30.2020900@Royer.com>
Date: Thu, 28 Aug 2003 12:42:56 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030400060203030001020005"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms030400060203030001020005
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> There is nothing saying that invitee can not get SEQUENCE 20 and than 
> SEQUENCE 30.

I agree.

> If chair reschedules several instances their individual SEQUENCE number 
> will bump (NOT THE WHOLE SET).

What do you mean by 'THE WHOLE SET' ? What will the ORGANIZERs
SEQUENCE number be? If you are saying that not all ATTENDEEs
need see all updates - we agree. If not, I did not understand
your point.

> If chair than reschedules over a range, the new sequence number for 
> reschedule will be one greater than the highest sequence number on 
> instances within range before reschedule.

In the iTIP packet sent to the effected ATTENDEEs, assuming they
were at newest-sequence-1, else as you point out above if
they were last at '20' and you send '30' then it will not be
'1' off, it will be '10' off. So then there set changes to
the set they were sent in sequence '30'. Correct? So in all
cases the RECURRECE-ID set changes for the effected ATTENDEES.
And as the ORGANIZER had to bump the sequence number because
they made one or more instance updates, the ORGANIZER set changes. Thus
the pattern changes, thus the RECURRECE-IDs change in all cases for
the ORGANIZER and all effected ATTENDEEs.




-- 

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

                 We Do Standards - You Need Standards

--------------ms030400060203030001020005
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODE4NDI1NlowIwYJKoZIhvcNAQkEMRYEFOygXnY2
HFFEAenDc54XY5cOMp6+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAKAL9nzW+yuuik6Gpchf4Kx7Eso7Src8l2Ksi6K+7KmaOuhZpY8L
udCnIIzRMF9cMAzK7QJnhMMoA3U2kC0jqOf9yhDiKqGWTQgayh2u1jbjWP9cvakwHqYBIMm8
U2GpxfOFCd/d0VUvaAvDTskjjUIpLjnXazzrRxfwC7H75rEnSrpDD0a8vrEK9TYEjJ/BxAWy
pzjPdW9aeurtkbrTOkV/MhM4AU+KMB5ZjrFszXxGk0CFPsUNmGtZHhmfTtzSBMyy/M/tYEhH
iIO+aIq+b9RfeMDtMBnI9C6A566FIj8L9lfPacyjVrPQS3yw+sxkcQvh1oIE2bSB9PsN9X9z
h/IAAAAAAAA=
--------------ms030400060203030001020005--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 15:27: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 PAA11344
	for ; Thu, 28 Aug 2003 15:27:38 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJDqgc093324
	for ; Thu, 28 Aug 2003 12:13:52 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SJDqN2093323
	for ietf-calendar-bks; Thu, 28 Aug 2003 12:13:52 -0700 (PDT)
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.9/8.12.8) with ESMTP id h7SJDpgc093302
	for ; Thu, 28 Aug 2003 12:13:51 -0700 (PDT)
	(envelope-from satyanarayana.vempati@Sun.COM)
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35])
	by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7SJDmXY026439
	for ; Thu, 28 Aug 2003 12:13:48 -0700 (PDT)
Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91])
	by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7SJDlhD006178
	for ; Thu, 28 Aug 2003 12:13:47 -0700 (PDT)
Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109])
 by ha13sca-mail1.sfbay.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct  1 2002))
 with ESMTP id <0HKC00723G2ZMU@ha13sca-mail1.sfbay.sun.com> for
 ietf-calendar@imc.org; Thu, 28 Aug 2003 12:13:47 -0700 (PDT)
Date: Thu, 28 Aug 2003 12:13:50 -0700
From: Satya Vempati 
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
To: "ietf-calendar@imc.org" 
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-language: en-USA
Content-transfer-encoding: 7BIT
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7BIT


That depends. Do you think that the pattern has changed if a single
instance gets rescheduled?

-----Original Message-----
From: Doug Royer [mailto:Doug@royer.com]
Sent: Thursday, August 28, 2003 9:22 AM
To: ietf-calendar@imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?




Satya Vempati wrote:
> Surely, Doug & Chris also agree that the RECURRENCE-ID changes when the
> base recurrence set changes. They may not agree that RECURRENCE-ID stays
> put if an instance is changed. Well, after the post from the original
> authors, I hoped that this issue would be laid to rest. But ...

They clearly said it changes when the pattern changes.
Do you disagree that it changes when the pattern changes?


-- 

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

                 We Do Standards - You Need Standards



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 15: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 PAA11513
	for ; Thu, 28 Aug 2003 15:31:35 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJHngc093432
	for ; Thu, 28 Aug 2003 12:17:49 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SJHnKN093431
	for ietf-calendar-bks; Thu, 28 Aug 2003 12:17:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJHlgc093425
	for ; Thu, 28 Aug 2003 12:17:48 -0700 (PDT)
	(envelope-from satyanarayana.vempati@Sun.COM)
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35])
	by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7SJHmwC024138;
	Thu, 28 Aug 2003 13:17:48 -0600 (MDT)
Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91])
	by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7SJHmhD008210;
	Thu, 28 Aug 2003 12:17:48 -0700 (PDT)
Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109])
 by ha13sca-mail1.sfbay.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct  1 2002))
 with ESMTP id <0HKC007PRG9NMU@ha13sca-mail1.sfbay.sun.com>; Thu,
 28 Aug 2003 12:17:48 -0700 (PDT)
Date: Thu, 28 Aug 2003 12:17:50 -0700
From: Satya Vempati 
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
To: Michael Fair ,
        "ietf-calendar@imc.org" 
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-language: en-USA
Content-transfer-encoding: 7BIT
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7BIT


That is what Bruce Kahn had said all along. But somewhere along the thread
you were also saying (along with Doug) that if there is jump in SEQUENCE
numbers (by more than one), CUA is expected to do a REFRESH.

It still would be beneficial to settle on sequence numbering scheme for
recurring events (master and individual instances).

-----Original Message-----
From: Michael Fair [mailto:michael@daclubhouse.net]
Sent: Thursday, August 28, 2003 10:02 AM
To: Satya Vempati; ietf-calendar@imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?



Doh!

I'm totally wrong about the CUAs needing to know if they missed
something.  I got distracted by all the talk prior about instances
and realized that this is actually in reference to the base event.

Since this is about the base event and not an instance, SEQUENCE
jumps don't matter as the most recent information is always the
most up to date.  It's only when the CUA receives information
about an instance which indicates that it might have missed
something about the base event that it sends a REFRESH..

> Suppose the base set is UID:1, SEQ:0
> We reschedule an instance: UID:1, RID:x, SEQ:1
> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50
(attendee
> A is invited to this instance alone)
...
> If the SEQ:0 changes to SEQ:51

Then the CUA updates to 51, uses the info contained
within and goes on its merry way regardless of what other
prior SEQUENCE numbers it may or may not have seen.
No REFRESH is needed at all because it has seen the latest
and greatest info.

-- Michael --




From owner-ietf-calendar@mail.imc.org  Thu Aug 28 15:52: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 PAA13053
	for ; Thu, 28 Aug 2003 15:52:16 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJUfgc093902
	for ; Thu, 28 Aug 2003 12:30:41 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SJUfkr093901
	for ietf-calendar-bks; Thu, 28 Aug 2003 12:30:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJUdgc093896
	for ; Thu, 28 Aug 2003 12:30:39 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sSUO-0005I1-00
	for ; Thu, 28 Aug 2003 21:31:24 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19sSUN-0005Ht-00
	for ; Thu, 28 Aug 2003 21:31:23 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sSTf-000269-00
	for ; Thu, 28 Aug 2003 21:30:39 +0200
From: "Michael Fair" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Thu, 28 Aug 2003 12:30:38 -0700
Lines: 85
Message-ID: 
References:  <3F4E4B6C.1030304@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:3F4E4B6C.1030304@Royer.com...
>
>
> Robert_Ransdell@notesdev.ibm.com wrote:
>
>  > You do not send an RDATE in and instance REQUEST
>  >
>  > The reschedule  to an instance only changes the SEQUENCE on that
>  > instance... NOT ON THE ENTIRE SET.
>
> I should have sent:
>
> Whether this is done with RRULEs, ADD's or what ever, if the result
> is equivalent to:
>
>                  SEQUENCE:0
> DTSTART:...monday...
>                  RDATE:...tuesday..

Rescheduling an instance is never equivalent to an RRULE or ADD update.
Rescheduling an instance changes solely the DTSTART of that instance
and the SEQUENCE.  The RECURRENCE-ID remains as it is defined by
the latest recurrence set description set forth in the base object.

Rescheduling an instance has influence only over that instance.
Changing an RRULE or doing an ADD has influence over the base
object, thereby having influence over the entire set.


> And then the Monday meeting is changed to Friday with
> a single instance modification:
>
>                  SEQUENCE:1
>                  RECURRENCE-ID:...monday
>                  DTSTART:...friday...
>
> The RECURRENCE-ID for Monday is void because I could have
> chosen to send the following and not the previous example:
>
>                  SEQUENCE:1
>                  DTSTART:...friday...
>                  RDATE:...tuesday..
>

Your examples are hard to follow because you don't tell us
what's going on.  In the first case you talk about Mondays,
and you move one of them to Friday, and in the second case
(supposedly the base event for the first case) you are now
seemingly talking about Fridays and adding a Tuesday.
What was the base case?
What change are you trying to make?

There are two ways to get the same result as a rescheduling of
an instance.  In one, you simply reschedule the instance, in
the other you redefine the whole set to exclude the original
date and add the new date.

In the first case, the RECURRENCE-ID for Monday is not void
because you have not changed the SEQUENCE for the base event.
The SEQUENCE for only that Monday instance has increased.
When the recurrence rule for the base event is expanded it
still contains a Monday RECURRENCE-ID.  The "reschedule" is
treated as an update to that Monday instance.  When a REFRESH
happens the bsae event is still SEQUENCE 0 and that Monday
instance is now SEQUENCE 1.  If you rescheduled that instance
50 more times, the SEQUENCE for the base event would still be
0, and the SEQUENCE for that Monday would be 51.

In the second instance you have rescheduled the entire series
and redefined the entire set of instances, coincidently the
Monday instance is no longer there and there also happens to
be a new Friday instance.  The two are not related as far as
the CUA's are concerned.  So in the second case, you have not
"rescheduled an instance" you have "redefined the set to
exclude one instance and add a different instance".


While an ORGANIZER's CUA can make this look like a reschedule,
it's not, it's a set redefinition.

-- Michael --





From owner-ietf-calendar@mail.imc.org  Thu Aug 28 15:56: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 PAA13310
	for ; Thu, 28 Aug 2003 15:55:59 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJf8gc094253
	for ; Thu, 28 Aug 2003 12:41:08 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SJf85H094252
	for ietf-calendar-bks; Thu, 28 Aug 2003 12:41:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJf7gc094247
	for ; Thu, 28 Aug 2003 12:41:07 -0700 (PDT)
	(envelope-from Bruce_Kahn@notesdev.ibm.com)
In-Reply-To: <3F4D0078.5050006@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003
Message-ID: 
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 28 Aug 2003 15:33:02 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 03:41:38 PM,
	Serialize complete at 08/28/2003 03:41:38 PM
Content-Type: multipart/alternative; boundary="=_alternative 006B581585256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 006B581585256D90_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Doug wrote on 08/27/2003 03:03:20 PM:
> I know that there may be more screams that this issues will not
> go away. But it really needs to be settled.

We went thru this before we RFCd.  We went over this a lot recently.  We=20
even got the original authors to clarify it.  Yet it seems that its a hard =

concept for some to accept for some reason...=20

> Despite the claims on this list, it appears that almost everyone
> agrees that the RECURRECE-ID's do change and must change.

Not quite.  Ive not kept up with the last spurt of messages but when I=20
last checked I sensed no such feeling by the WG.

Unless you ignore how poorly the workflow process performs when a delta=20
model is used with missequenced or lost messages then I dont see how that=20
anyone can think the RECURRENCE-IDs "must" change.=20

Ive repeatdly shown how poorly a changing ID model is, especially with=20
missequenced or lost messages.  To date, no one has been able to dispute=20
it; at least not technically.=20

So Im a bit weary with this topic and the repeated attempts to change=20
whats WRITTEN in the RFCs and whats been technically analyzed and even=20
commented on by the original authors.  How many times do we need to rehash =

this??

> I think that proof is:
>=20
>    So your first invitation is to:
>=20
>         UID:100
>         SEQUENCE:0
>         DATE:...sep-1...10am...
>=20
>    Then you get:
>=20
>         UID:100
>         SEQUENCE:1
>         RRULE;FREQ=3DDAILY;COUNT=3D10
>         DTSTART:...sep-2...3pm


Ugh!  THIS IS A TOTALLY DIFFERENT FISH THAN THE NORMAL INSTANACE=20
RESCHEDULE EXAMPLE!  The former snippet is a singleton instance reference=20
(NO RECURRENCE-ID).  The latter snipper is a (re)creating of a repeating=20
set of instnaces.  They are 2 totally different fish!  You cannot use them =

both to justify the delta model; the 1st one isnt repeating!


The first example is NOT a legit message when referencing an instance of a =

repeating set; it has no RECURRENCE-ID.  The only thing I can infer from=20
these 2 snippets is that you took a non-repeating entry and made it=20
repeat.=20

This is totally unrelevant to WHY a RECURRENCE-ID "must change" when an=20
instance is rescheduled!

>    What is the RECURRENCE-ID for the 1st object?
>      ...sep-1...10am... Correct?

If by "the 1st object" you are referring to the 1st fragment then it has=20
NONE!  Its NOT repeating.

If by "the 1st object" you are referring to the 1st instance generated by=20
the 2nd fragment then its Sep02@3PM; the DTSTART value defines the first=20
instance of the repeat set, as defined in iCalendar by:

                                              The recurrence set is
   generated by considering the initial "DTSTART" property along with
   the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
   within the iCalendar object.

Do not try to confuse the issue by mixing non-repeating and repeating=20
defintions; a non-repeating entry is not the same as an entry that repeats =

only once (unless you have a different defintion of the word repeating or=20
repeat than the rest of us).=20

> Does anyone still think that RECURRENCE-ID's do NOT change?

You are using an invalid example to justify why RECURRENCE-ID must change=20
for all cases.=20

You have pointedly ignored the objective analysis of where the changing=20
model fails without changing the instance set; where we just reschedule a=20
single instance and have missequenced or lost messages.  The delta model=20
can become unrecoverable for this common case as the analysis has shown.=20

We even got a posting from the original authors on this issue but that=20
didnt seem to help some.  Perhaps you didnt actually see all of the text=20
in Deriks/Franks posting.  Let me cut out the relevant bits that you=20
seemed to have missed:

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=20
the base recurrence set (or pattern) exists. A rescheduling of an=20
individual recurrence instance did not cause creation of new base=20
recurrence set, but only moved the start/end of the specified recurrence=20
instance.  [Emphasis added -BK]

b) An addition of a new recurrence instance to the set would be an example =

of an action that would create a new recurrence set ? e.g. changing a=20
Monday weekly meeting to a Monday and Tuesday weekly meeting. This latter=20
action is an example of an action that *might* also cause the values of=20
the RECURRENCE-ID properties for each member of the recurrence set to get=20
redefined

I have said all along that adding new instances could be cause for=20
RECURRENCE-ID to change (part 'b') but since the example in question was=20
rescheduling a single instance I maintain (in agreement with the RFCs=20
[except for the =5F1=5F erroneous line in iTIP] and the authors) that=20
RECURRENCE-ID stays fixed (part 'a').  Doing so makes dealing with=20
missequenced or lost messages much simpler and easier.  If the model were=20
a delta model then workflow recovery would require LOTS more work and=20
would still not be guaranteed.

In talking w/some folks I think I see why there is such tenacity regarding =

"How do I send the same rule" to a new invitee after the fact or after=20
something changed.  I suspect that some folks are relying too heavily=20
repeating rules and do not quite understand their role/use.   Perhaps a=20
few cycles should be spent on this now to clear up some possibly=20
misunderstood or overlooked ideas.

We added a repeating grammar for repeating (and exception) rules for 2=20
reasons: it provided a shorthand way to send large sets of repeat instance =

dates and it was the only way to represent "the infinitely repeating=20
entry" (that only Outlook had at the time).  In order for repeating rules=20
to be applicable for use, all instances generated must by defintion have=20
the exact same set of properties (except their effective DTSTART/DTEND).=20

The =5Fonly=5F place where a repeating rule is really necessary is for the =

infinite case.  For a non-infinite set, the RRULE only saves some octets=20
in the iTIP message compared to sending RDATEs.  So, for large repeating=20
sets using a recurrence rule is an easy way to save space in the iCalendar =

stream sent.   So the fragment:

     DTSTART:20030902T140000Z
     RRULE:FREQ=3DDAILY;COUNT=3D10

is an alternative to this fragment:

     DTSTART:20030902T140000Z
     RDATE:20030903T140000Z
     RDATE:20030904T140000Z
     RDATE:20030905T140000Z
     RDATE:20030906T140000Z
     RDATE:20030907T140000Z
     RDATE:20030908T140000Z
     RDATE:20030909T140000Z
     RDATE:20030910T140000Z
     RDATE:20030911T140000Z

It should be clear that once you reschedule a single instance then the use =

of a recurrence rule becomes MUCH harder if not impossible (at least=20
solely).  For example, if I reschedule the 6th instance to a different=20
time then you cannot expect the RRULE:FREQ=3DDAILY;COUNT=3D10 to still be=20
usable when adding any new invitees!  You have a few possible ways of=20
sending this new set to a new invitee but using just a single RRULE is NOT =

possible any more.

If I opt'd to send the REQUEST with RDATEs instead of an RRULE and then I=20
want to reschedule an instance, I would send nearly the same iCalendar=20
stream but the 6th instance would be different (reflecting the new time).=20
If I didnt use an RRULE then there is no "pattern" to change.  I'm=20
guessing that some folks are focusing on that particular word (to the=20
exclusion of all the other author reponse) since only the recurrence=20
grammar is designed to express patterns in a compact way.=20

People should not get hung up on the use of a pattern in the iTIP=20
messages; the pattern is simply what the recurrence grammar is designed to =

encode.  As such, it cannot be used for entries that do not repeat on some =

form of regular pattern. To do that you have to use RDATEs (or ugly=20
combinations of RRULEs/EXRULEs/EXDATEs).  Once you reschedule any single=20
instance, you no longer have a pattern to follow.

Another thing that I think some folks do not grok fully is that in order=20
for an RRULE to be used to generate a set of entry instances, there can be =

NO differences between each instance apart from its start/end date/times.=20
Every single property is =5Fexactly=5F the same: the same ATTENDEE list, th=
e=20
same DESCRIPTION, the same ATTACHments, etc.  This most commonly occurs=20
only when the instances are first created.  After that things typically=20
change: ATTENDEE PARTSTATs vary, ATTACHments change, DESCRIPTIONs=20
(typically the Agendas) change, COMMENTS about the instances vary, etc. As =

such, its not possible to rely on a RRULE (or group of RRULEs) in a single =

message to be usable when adding a new invitee; the individual instances=20
have different data.  They no longer are near exact clones of each other.=20

If you do not focus just on the idea of a particular pattern and treat the =

instances as a set that can move around then it should be clear why the=20
RECURRENCE-IDs do not change on a reschedule.  By keeping them fixed=20
missed changes (ie: lower SEQUENCE valued messages) are NOT a concern=20
since they are obsolete anyway.  ONLY with fixed RECURRENCE-IDs is it=20
possible to detect a missequenced iTIP message and deal with it properly.=20

Some folks seem to think that there is some mystical need to distinguish=20
an invitation from a reschedule from an update and are seemingly deriving=20
this from the presence of repeating information (or lack of=20
RECURRNECE-IDs).  This is an unnecessary distinction AND its NOT described =

at all in the iTIP RFC.  The distinction is clearly described in reference =

to the recipients calendar and NOT to the senders or the iTIP message=20
itself.   There is NO need to draw any distinctions; if the entry is new=20
to the recipient then its an Invitation, otherwise its a reschedule or an=20
update.=20

So you may ask why does Doug try to draw a distiction?  The answer is=20
simple: The need for a distinction derives from the delta models inability =

to deal with lost or missequenced messages.  The recipient has no way to=20
differentiate a missed reschedule from a new instance invitation.  Thus=20
the only solution for the delta model is to stop all workflow on ALL=20
instances and ask the Organizer for a REFRESH of all instances in=20
question.  There are a couple notable problems w/this design:=20

1: Until the Organizers 'nuke' REQUEST gets there the recipient can=20
perform NO workflow on ANY instance.  That means NO accepting, declining,=20
counter proposing or delegating; they can safely perform NO action until=20
they recreate all instances w/the correct current RECURRENCE-IDs.=20

2: Because iTIP cannot guarantee delivery its possible that the Organizers =

REQUEST never arrives thus the invitee can be indefinitely stuck=20
w/calendar entries that they cannot be sure are still real or not.  Or its =

possible that the "full REFRESH" never gets to the Organzier so they never =

have a clue that some invitee needs help...

3: Its possible that the recipient was only invited to a particular=20
instance.  As such the Organizer would only send a REQUEST with that=20
RECURRENCE-ID in it; not one with an RRULE or other repeating info in it.=20
Sending a REQUEST without a RECURRENCE-ID is not semantically the same as=20
a REQUEST for a single instance;  the recipient will treat it as a=20
non-repeating entry when in fact its an instnace of a repeat set.  As such =

adding the invitee to other instances means destroying what they think the =

UID is and having them recreate a new set of now repeating instances. This =

means that even though nothing may have changed about the initial instnace =

they were invited to, the Organizer MUST resend all the data for the=20
unchanged instance just so the recipient can destroy and recreate it in=20
their calendar as a repeating instance now.  What a waste of bandwidth and =

cycles!  Plus, iTIP clearly says that RECURRENCE-ID MUST be on the REQUEST =

when it refers to an instance of a repeat set (check the restriction table =

if in doubt).

If you consider the correct usages for recurrence rules, the analysis of=20
the delta models shortcomings and the response from Derik/Frank I would=20
hope that it should be clear now exactly why the model is fixed and not=20
changing.  But Im not holding my breath just yet...

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                                INet:=20
Bruce=5FKahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 006B581585256D90_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable



Doug wrote on 08/27/2003 03:03:20 PM:

> I know that there may be more screams that this issues will not

> go away. But it really needs to be settled.



We went thru this before we RFCd. &n=
bsp;We
went over this a lot recently.  We even got the original authors to
clarify it.  Yet it seems that its a hard concept for some to accept
for some reason...  



> Despite the claims on this list, it appears that
almost everyone

> agrees that the RECURRECE-ID's do change and must change.



Not quite.  Ive not kept up with
the last spurt of messages but when I last checked I sensed no such feeling
by the WG.



Unless you ignore how poorly the wor=
kflow
process performs when a delta model is used with missequenced or lost messa=
ges
then I dont see how that anyone can think the RECURRENCE-IDs "must&quo=
t;
change.  



Ive repeatdly shown how poorly a cha=
nging
ID model is, especially with missequenced or lost messages.  To date,
no one has been able to dispute it; at least not technically.  



So Im a bit weary with this topic and
the repeated attempts to change whats WRITTEN in the RFCs and whats been
technically analyzed and even commented on by the original authors.  H=
ow
many times do we need to rehash this??



> I think that proof is:

> 

>    So your first invitation is to:

> 

>         UID:100

>         SEQUENCE:0

>         DATE:...sep-1...10am...

> 

>    Then you get:

> 

>         UID:100

>         SEQUENCE:1

>         RRULE;FREQ=3DDAILY;COUNT=3D10

>         DTSTART:...sep-2...3pm



<FRUSTRATION /SHOW=3DON>

Ugh!  THIS IS A TOTALLY DIFFERE=
NT
FISH THAN THE NORMAL INSTANACE RESCHEDULE EXAMPLE!  The former snippet
is a singleton instance reference (NO RECURRENCE-ID).  The latter
snipper is a (re)creating of a repeating set of instnaces.  They are
2 totally different fish!  You cannot use them both to justify the
delta model; the 1st one isnt repeating!

</FRUSTRATION>



The first example is NOT a legit mes=
sage
when referencing an instance of a repeating set; it has no RECURRENCE-ID.
 The only thing I can infer from these 2 snippets is that you took
a non-repeating entry and made it repeat.  



This is totally unrelevant to WHY a
RECURRENCE-ID "must change" when an instance is rescheduled!



>    What is the RECURRENCE-ID for the
1st object?

>      ...sep-1...10am... Correct?



If by "the 1st object" you
are referring to the 1st fragment then it has NONE!  Its NOT repeating=
.



If by "the 1st object" you
are referring to the 1st instance generated by the 2nd fragment then its
Sep02@3PM; the DTSTART value defines the first instance of the repeat set,
as defined in iCalendar by:



              &nb=
sp;
                     
        The recurrence set is

   generated by considering the initial
"DTSTART" property along with

   the "RRULE", "RDATE", "EXDATE" and
"EXRULE" properties contained

   within the iCalendar object.



Do not try to confuse the issue by m=
ixing
non-repeating and repeating defintions; a non-repeating entry is not the
same as an entry that repeats only once (unless you have a different defint=
ion
of the word repeating or repeat than the rest of us).  



> Does anyone still think that RECURRENCE-ID's
do NOT change?



You are using an invalid example to
justify why RECURRENCE-ID must change for all cases.  



You have pointedly ignored the objec=
tive
analysis of where the changing model fails without changing the instance
set; where we just reschedule a single instance and have missequenced or
lost messages.  The delta model can become unrecoverable for this
common case as the analysis has shown.  



We even got a posting from the origi=
nal
authors on this issue but that didnt seem to help some.  Perhaps you
didnt actually see all of the text in Deriks/Franks posting.  Let
me cut out the relevant bits that you seemed to have missed:



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 resche=
duling
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.  [Emphasis added -BK]



b) An addition of a new recurrence
instance to the set would be an example of an action that would create
a new recurrence set – e.g. changing a Monday weekly meeting to a Mon=
day
and Tuesday weekly meeting. This latter action is an example of an action
that *might* also cause the values of the RECURRENCE-ID properties for
each member of the recurrence set to get redefined



I have said all along that adding new
instances could be cause for RECURRENCE-ID to change (part 'b') but since
the example in question was rescheduling a single instance I maintain (in
agreement with the RFCs [except for the =5F1=5F erroneous line in iTIP] and
the authors) that RECURRENCE-ID stays fixed (part 'a').  Doing so
makes dealing with missequenced or lost messages much simpler and easier.
 If the model were a delta model then workflow recovery would require
LOTS more work and would still not be guaranteed.



In talking w/some folks I think I see
why there is such tenacity regarding "How do I send the same rule"
to a new invitee after the fact or after something changed.  I suspect
that some folks are relying too heavily repeating rules and do not quite
understand their role/use.   Perhaps a few cycles should be spent
on this now to clear up some possibly misunderstood or overlooked ideas.



We added a repeating grammar for rep=
eating
(and exception) rules for 2 reasons: it provided a shorthand way to send
large sets of repeat instance dates and it was the only way to represent
"the infinitely repeating entry" (that only Outlook had at the
time).  In order for repeating rules to be applicable for use, all
instances generated must by defintion have the exact same set of properties
(except their effective DTSTART/DTEND).  



The =5Fonly=5F place where a repeati=
ng rule
is really necessary is for the infinite case.  For a non-infinite
set, the RRULE only saves some octets in the iTIP message compared to sendi=
ng
RDATEs.  So, for large repeating sets using a recurrence rule is an
easy way to save space in the iCalendar stream sent.   So the fragment=
:



     DTSTART:20030902T140000Z

     RRULE:FREQ=3DDAILY;COUNT=3D10



is an alternative to this fragment:<=
/font>



     DTSTART:20030902T140000Z

     RDATE:20030903T140000Z

     RDATE:20030904T140000Z

     RDATE:20030905T140000Z

     RDATE:20030906T140000Z

     RDATE:20030907T140000Z

     RDATE:20030908T140000Z

     RDATE:20030909T140000Z

     RDATE:20030910T140000Z

     RDATE:20030911T140000Z



It should be clear that once you res=
chedule
a single instance then the use of a recurrence rule becomes MUCH harder
if not impossible (at least solely).  For example, if I reschedule
the 6th instance to a different time then you cannot expect the RRULE:FREQ=
=3DDAILY;COUNT=3D10
to still be usable when adding any new invitees!  You have a few possi=
ble
ways of sending this new set to a new invitee but using just a single RRULE
is NOT possible any more.



If I opt'd to send the REQUEST with
RDATEs instead of an RRULE and then I want to reschedule an instance, I
would send nearly the same iCalendar stream but the 6th instance would
be different (reflecting the new time).  If I didnt use an RRULE then
there is no "pattern" to change.  I'm guessing that some
folks are focusing on that particular word (to the exclusion of all the
other author reponse) since only the recurrence grammar is designed to
express patterns in a compact way.   



People should not get hung up on the
use of a pattern in the iTIP messages; the pattern is simply what the recur=
rence
grammar is designed to encode.  As such, it cannot be used for entries
that do not repeat on some form of regular pattern. To do that you have
to use RDATEs (or ugly combinations of RRULEs/EXRULEs/EXDATEs).  Once
you reschedule any single instance, you no longer have a pattern to follow.=




Another thing that I think some folks
do not grok fully is that in order for an RRULE to be used to generate
a set of entry instances, there can be NO differences between each instance
apart from its start/end date/times.  Every single property is =5Fexac=
tly=5F
the same: the same ATTENDEE list, the same DESCRIPTION, the same ATTACHment=
s,
etc.  This most commonly occurs only when the instances are first
created.  After that things typically change: ATTENDEE PARTSTATs vary,
ATTACHments change, DESCRIPTIONs (typically the Agendas) change, COMMENTS
about the instances vary, etc.  As such, its not possible to rely
on a RRULE (or group of RRULEs) in a single message to be usable when adding
a new invitee; the individual instances have different data.  They
no longer are near exact clones of each other.  



If you do not focus just on the idea
of a particular pattern and treat the instances as a set that can move
around then it should be clear why the RECURRENCE-IDs do not change on
a reschedule.  By keeping them fixed missed changes (ie: lower SEQUENCE
valued messages) are NOT a concern since they are obsolete anyway.  ON=
LY
with fixed RECURRENCE-IDs is it possible to detect a missequenced iTIP
message and deal with it properly.  



Some folks seem to think that there
is some mystical need to distinguish an invitation from a reschedule from
an update and are seemingly deriving this from the presence of repeating
information (or lack of RECURRNECE-IDs).  This is an unnecessary disti=
nction
AND its NOT described at all in the iTIP RFC.  The distinction is
clearly described in reference to the recipients calendar and NOT to the
senders or the iTIP message itself.   There is NO need to draw any
distinctions; if the entry is new to the recipient then its an Invitation,
otherwise its a reschedule or an update.  



So you may ask why does Doug try to
draw a distiction?  The answer is simple: The need for a distinction
derives from the delta models inability to deal with lost or missequenced
messages.  The recipient has no way to differentiate a missed reschedu=
le
from a new instance invitation.  Thus the only solution for the delta
model is to stop all workflow on ALL instances and ask the Organizer for
a REFRESH of all instances in question.  There are a couple notable
problems w/this design:  



1: Until the Organizers 'nuke' REQUE=
ST
gets there the recipient can perform NO workflow on ANY instance.  That
means NO accepting, declining, counter proposing or delegating; they can
safely perform NO action until they recreate all instances w/the correct
current RECURRENCE-IDs.  



2: Because iTIP cannot guarantee del=
ivery
its possible that the Organizers REQUEST never arrives thus the invitee
can be indefinitely stuck w/calendar entries that they cannot be sure are
still real or not.  Or its possible that the "full REFRESH"
never gets to the Organzier so they never have a clue that some invitee
needs help...



3: Its possible that the recipient w=
as
only invited to a particular instance.  As such the Organizer would
only send a REQUEST with that RECURRENCE-ID in it; not one with an RRULE
or other repeating info in it.  Sending a REQUEST without a RECURRENCE=
-ID
is not semantically the same as a REQUEST for a single instance;  the
recipient will treat it as a non-repeating entry when in fact its an instna=
ce
of a repeat set.  As such adding the invitee to other instances means
destroying what they think the UID is and having them recreate a new set
of now repeating instances.  This means that even though nothing may
have changed about the initial instnace they were invited to, the Organizer
MUST resend all the data for the unchanged instance just so the recipient
can destroy and recreate it in their calendar as a repeating instance now.
 What a waste of bandwidth and cycles!  Plus, iTIP clearly says
that RECURRENCE-ID MUST be on the REQUEST when it refers to an instance
of a repeat set (check the restriction table if in doubt).



If you consider the correct usages f=
or
recurrence rules, the analysis of the delta models shortcomings and the
response from Derik/Frank I would hope that it should be clear now exactly
why the model is fixed and not changing.  But Im not holding my breath
just yet...



Bruce

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Bruce Kahn                  
             INet: Bruce=5FKahn@notesdev=
.ibm.com

Messaging & Collaboration            
    Phone: 978.399.6496

IBM Software Group                
        FAX: and nothing but the FAX...

Standard disclaimers apply, even where prohibited by law...
--=_alternative 006B581585256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:09: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 QAA14427
	for ; Thu, 28 Aug 2003 16:09:19 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJtYgc094904
	for ; Thu, 28 Aug 2003 12:55:34 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SJtYHt094903
	for ietf-calendar-bks; Thu, 28 Aug 2003 12:55:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJtWgc094898
	for ; Thu, 28 Aug 2003 12:55:33 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SJtWS5004647
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 12:55:33 -0700
Message-ID: <3F4E5E2F.8000201@Royer.com>
Date: Thu, 28 Aug 2003 13:55:27 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000402000809070008040008"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms000402000809070008040008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Satya Vempati wrote:
> That is what Bruce Kahn had said all along. But somewhere along the thread
> you were also saying (along with Doug) that if there is jump in SEQUENCE
> numbers (by more than one), CUA is expected to do a REFRESH.

Well - only for instances updates. For full objects it is not needed
as they are self contained instance patterns. For instance updates the
ATTENDEE CUA would not know what was being updated unless they knew for sure
they had the instance that was being updated. And the only way
to be sure if they get an instance update that is 2 or more
newer than what they have - is to ask the ORGANIZER via a REFRESH.

So I think we agree.

> It still would be beneficial to settle on sequence numbering scheme for
> recurring events (master and individual instances).

The SEQUENCE number is bumped in by the ORGANIZER when any of the mandatory
objects defended in iCAL/iTIP change. Plus when ever the ORGANIZER deems a
change will jeopardize the validity of the participation status of the
effected ATTENDEEs.

Then the ORGANIZER sends that information to the effected ATTENDEEs.
What's missing?

-- 

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

                 We Do Standards - You Need Standards

--------------ms000402000809070008040008
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODE5NTUyN1owIwYJKoZIhvcNAQkEMRYEFJH1Is+7
Et2pL0qtKte7ZQluZqtHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAEZtOaaWj+U3hO6nGurRuqwJmfVuadTiM2iElMKb+f1P/Vtf7IB5
iacB93KMCiwq+Tncc/JoYKGu69RW58jns3FrBH6w3HOT8dAmFYak1X7PoJKYOOTUQEltkPFt
fKCd5fnHdamptcsRfSqRx3ABWkqLQz41OrrpSUv2GYpK52BMytfNYlNnDmXjyfXfibevs8Us
/ds7EPtTAM6k9HggzKQ4B6soLbMoylvcgIRM96CIg8FpjzE71qIXBcQ0EXGR1x9mltj7QJKg
wJ6SGJ5KdqB8YdNFIYZTpRSW6MZy0XJ0eQabpwpNM8B2z37XlAdo/5BlI+bo/khrcnNnd9cz
vmEAAAAAAAA=
--------------ms000402000809070008040008--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:09:43 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14528
	for ; Thu, 28 Aug 2003 16:09:42 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJvIgc095107
	for ; Thu, 28 Aug 2003 12:57:18 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SJvIvb095106
	for ietf-calendar-bks; Thu, 28 Aug 2003 12:57:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJvHgc095100
	for ; Thu, 28 Aug 2003 12:57:17 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SJvGS5004671
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 12:57:18 -0700
Message-ID: <3F4E5E97.1010405@Royer.com>
Date: Thu, 28 Aug 2003 13:57:11 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000107030600030805050308"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms000107030600030805050308
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Satya Vempati wrote:
> That depends. Do you think that the pattern has changed if a single
> instance gets rescheduled?

Is that not the definition of 'rescheduled'? - a change?

So are you saying that you agree or disagree?

> -----Original Message-----
> From: Doug Royer [mailto:Doug@royer.com]
> Sent: Thursday, August 28, 2003 9:22 AM
> To: ietf-calendar@imc.org
> Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
> 
> 
> 
> 
> Satya Vempati wrote:
> 
>>Surely, Doug & Chris also agree that the RECURRENCE-ID changes when the
>>base recurrence set changes. They may not agree that RECURRENCE-ID stays
>>put if an instance is changed. Well, after the post from the original
>>authors, I hoped that this issue would be laid to rest. But ...
>
> They clearly said it changes when the pattern changes.
> Do you disagree that it changes when the pattern changes?

-- 

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

                 We Do Standards - You Need Standards

--------------ms000107030600030805050308
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODE5NTcxMVowIwYJKoZIhvcNAQkEMRYEFOOHyczy
vfrTkkbJVyWs2JmgAN9nMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAJBrSFdxCRAjYHXLktccoc1R/EZx9z+vKQVCPXJ+vQyKF2NTMCYT
OCE00wFLwBfWi2xvA7hjmy0p2PO+w/0lWl+4CCnqGNx+rfT2kksLYkkyBNBv/12c3GQ+w0Ca
FUiG0pClvyU84jvYKALKgUA3NI7pgAxkNqap7L+DEsPJT2JmBwKBjoteH44BE+Ewuuj9q1ie
8jsXmVy8RL/XnPH3O3KJA6NJHtn/ZG/ywdwTAAZYOQ6xARWqnqNEAqxsRcpZSTLprq9Z55kK
PLuWt4sgF4Z2MwwRcu0rxRis+ikAkjKlrq2oUjmyQRJHJ1nnuNFegwqCx1wuiF5yFGaJmIPt
kc8AAAAAAAA=
--------------ms000107030600030805050308--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:31: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 QAA16250
	for ; Thu, 28 Aug 2003 16:31:56 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKH3gc096485
	for ; Thu, 28 Aug 2003 13:17:03 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKH3kU096484
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:17:03 -0700 (PDT)
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.9/8.12.8) with ESMTP id h7SKH1gc096476
	for ; Thu, 28 Aug 2003 13:17:01 -0700 (PDT)
	(envelope-from satyanarayana.vempati@Sun.COM)
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35])
	by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7SKGwXY012547
	for ; Thu, 28 Aug 2003 13:16:58 -0700 (PDT)
Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91])
	by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7SKGwhD010971
	for ; Thu, 28 Aug 2003 13:16:58 -0700 (PDT)
Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109])
 by ha13sca-mail1.sfbay.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct  1 2002))
 with ESMTP id <0HKC007GLJ0AMU@ha13sca-mail1.sfbay.sun.com> for
 ietf-calendar@imc.org; Thu, 28 Aug 2003 13:16:58 -0700 (PDT)
Date: Thu, 28 Aug 2003 13:17:00 -0700
From: Satya Vempati 
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
To: "ietf-calendar@imc.org" 
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-language: en-USA
Content-transfer-encoding: 7BIT
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7BIT


To avoid confusion, we need to separate the master/base event and an
instance. I do not think that the sequence number on the master/base event
should change if an instance is rescheduled.

Yes, the sequence number must be updated but only on the instance. Not the
master.

My original question had to do with changing the base/master event: In
that situation, should the new sequence number on the master be (where
seq(n-1) is the sequence before, and seq(n) the sequence after, the change)

seq(n) = seq(n-1) + 1 or
seq(n) = max ((highest seq in all recurring instances), seq(n-1)) + 1

-----Original Message-----
From: Doug Royer [mailto:Doug@royer.com]
Sent: Thursday, August 28, 2003 9:56 AM
To: ietf-calendar@imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?




Satya Vempati wrote:

> The SEQUENCE numbering scheme I am talking about is the following issue:
> 
> Suppose the base set is UID:1, SEQ:0
> We reschedule an instance: UID:1, RID:x, SEQ:1
> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50
(attendee
> A is invited to this instance alone)
> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51 OR
> UID:1, SEQ:1?

iTIP says that when you send an instance update you increment
the SEQUENCE number each time. Do you disagree?

-- 

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

                 We Do Standards - You Need Standards



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:31:59 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16266
	for ; Thu, 28 Aug 2003 16:31:58 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKJVgc096572
	for ; Thu, 28 Aug 2003 13:19:32 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKJVg8096570
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:19:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKJTgc096561
	for ; Thu, 28 Aug 2003 13:19:30 -0700 (PDT)
	(envelope-from Bruce_Kahn@notesdev.ibm.com)
In-Reply-To: <3F4D22DF.9010907@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003
Message-ID: 
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 28 Aug 2003 15:42:04 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 04:20:00 PM,
	Serialize complete at 08/28/2003 04:20:00 PM
Content-Type: multipart/alternative; boundary="=_alternative 006C2BF385256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 006C2BF385256D90_=
Content-Type: text/plain; charset="US-ASCII"

Doug wrote on 08/27/2003 05:30:07 PM:
>                   Thus the set changes. Thus the RECURRENCE-IDs
> always change on one OR all instance rescheduling changes.

Sorry but thats false.  iCalendar clearly says:

   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.

and iTIP uses "original" in a few places that confirm this.  Even if you 
have a different understanding of the meaning of original, the rest of the 
text should provide some clues.  Plus Deriks/Franks recent note confirmed 
this and expressly rejected your assertion:

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.

They went on to describe _why_ and that also jives w/the analysis Ive done 
and the comments of several of us. 

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 006C2BF385256D90_=
Content-Type: text/html; charset="US-ASCII"



Doug wrote on 08/27/2003 05:30:07 PM:

>                   Thus
the set changes. Thus the RECURRENCE-IDs

> always change on one OR all instance rescheduling changes.



Sorry but thats false.  iCalendar
clearly says:



   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.



and iTIP uses "original" in
a few places that confirm this.  Even if you have a different understanding
of the meaning of original, the rest of the text should provide some clues.
 Plus Deriks/Franks recent note confirmed this and expressly rejected
your assertion:



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.



They went on to describe _why_ and that
also jives w/the analysis Ive done and the comments of several of us.  



Bruce

===========================================================================

Bruce Kahn                  
             INet: Bruce_Kahn@notesdev.ibm.com

Messaging & Collaboration            
    Phone: 978.399.6496

IBM Software Group                
        FAX: and nothing but the FAX...

Standard disclaimers apply, even where prohibited by law...
--=_alternative 006C2BF385256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:35: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 QAA16535
	for ; Thu, 28 Aug 2003 16:35:21 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKJXgc096579
	for ; Thu, 28 Aug 2003 13:19:33 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKJWZB096578
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:19:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKJUgc096565
	for ; Thu, 28 Aug 2003 13:19:31 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4E4D30.2020900@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Thu, 28 Aug 2003 15:41:54 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 04:20:01 PM,
	Serialize complete at 08/28/2003 04:20:01 PM
Content-Type: multipart/alternative; boundary="=_alternative 006BC96A85256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 006BC96A85256D90_=
Content-Type: text/plain; charset="US-ASCII"

THIS IS BOGUS AND YOU KNOW IT.
As per Derik Stenerson reponse changes to instances do not change pattern.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/28/2003 02:42 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Robert_Ransdell@notesdev.ibm.com wrote:
> 
> There is nothing saying that invitee can not get SEQUENCE 20 and than 
> SEQUENCE 30.

I agree.

> If chair reschedules several instances their individual SEQUENCE number 
> will bump (NOT THE WHOLE SET).

What do you mean by 'THE WHOLE SET' ? What will the ORGANIZERs
SEQUENCE number be? If you are saying that not all ATTENDEEs
need see all updates - we agree. If not, I did not understand
your point.

> If chair than reschedules over a range, the new sequence number for 
> reschedule will be one greater than the highest sequence number on 
> instances within range before reschedule.

In the iTIP packet sent to the effected ATTENDEEs, assuming they
were at newest-sequence-1, else as you point out above if
they were last at '20' and you send '30' then it will not be
'1' off, it will be '10' off. So then there set changes to
the set they were sent in sequence '30'. Correct? So in all
cases the RECURRECE-ID set changes for the effected ATTENDEES.
And as the ORGANIZER had to bump the sequence number because
they made one or more instance updates, the ORGANIZER set changes. Thus
the pattern changes, thus the RECURRECE-IDs change in all cases for
the ORGANIZER and all effected ATTENDEEs.




-- 

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

                 We Do Standards - You Need Standards


--=_alternative 006BC96A85256D90_=
Content-Type: text/html; charset="US-ASCII"



THIS IS BOGUS AND YOU KNOW IT.

As per Derik
Stenerson reponse changes to
instances do not change pattern.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/28/2003 02:42 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

> There is nothing saying that invitee can not get SEQUENCE 20 and than


> SEQUENCE 30.



I agree.



> If chair reschedules several instances their individual SEQUENCE number


> will bump (NOT THE WHOLE SET).



What do you mean by 'THE WHOLE SET' ? What will the ORGANIZERs

SEQUENCE number be? If you are saying that not all ATTENDEEs

need see all updates - we agree. If not, I did not understand

your point.



> If chair than reschedules over a range, the new sequence number for


> reschedule will be one greater than the highest sequence number on


> instances within range before reschedule.



In the iTIP packet sent to the effected ATTENDEEs, assuming they

were at newest-sequence-1, else as you point out above if

they were last at '20' and you send '30' then it will not be

'1' off, it will be '10' off. So then there set changes to

the set they were sent in sequence '30'. Correct? So in all

cases the RECURRECE-ID set changes for the effected ATTENDEES.

And as the ORGANIZER had to bump the sequence number because

they made one or more instance updates, the ORGANIZER set changes. Thus

the pattern changes, thus the RECURRECE-IDs change in all cases for

the ORGANIZER and all effected ATTENDEEs.









-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 006BC96A85256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:41: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 QAA17026
	for ; Thu, 28 Aug 2003 16:41:49 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKPrgc096923
	for ; Thu, 28 Aug 2003 13:25:53 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKPrgG096921
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:25:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKPqgc096915
	for ; Thu, 28 Aug 2003 13:25:52 -0700 (PDT)
	(envelope-from Bruce_Kahn@notesdev.ibm.com)
In-Reply-To: <3F4D3779.5060503@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003
Message-ID: 
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 28 Aug 2003 16:13:22 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 04:26:21 PM,
	Serialize complete at 08/28/2003 04:26:21 PM
Content-Type: multipart/alternative; boundary="=_alternative 006F098985256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 006F098985256D90_=
Content-Type: text/plain; charset="US-ASCII"

Doug maintained on 08/27/2003 06:58:01 PM:
> If you change the DTSTART - *only*, as in:
> 
>    SEQUENCE:X
>    DTSTART:...monday..
>    RRULE:FREQ=WEEKLY
> 
> To:
> 
>    SEQUENCE:X+Y
>    DTSTART:...tuesday...
>    RRULE:FREQ=WEEKLY.
> 
> The instances and RECURRECE-ID's change.
> So DTSTART *is* included even when; RRULE,
> RDATE, EXDATE, and EXRULE do not change.

This is NOT rescheduling an instance; its recreating the set!  iCalendar 
says that RECURRENCE-IDs "might also change" in this case and so far we 
all seem to agree on this case (and this is backed up by the 3.b text from 
the original authors).

If you want to discuss when RECURRENCE-IDs do change thats one thing but 
your example above is NOT a instance reschedule example.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 006F098985256D90_=
Content-Type: text/html; charset="US-ASCII"



Doug maintained on 08/27/2003 06:58:01 PM:

> If you change the DTSTART - *only*, as in:

> 

>    SEQUENCE:X

>    DTSTART:...monday..

>    RRULE:FREQ=WEEKLY

> 

> To:

> 

>    SEQUENCE:X+Y

>    DTSTART:...tuesday...

>    RRULE:FREQ=WEEKLY.

> 

> The instances and RECURRECE-ID's change.

> So DTSTART *is* included even when; RRULE,

> RDATE, EXDATE, and EXRULE do not change.



This is NOT rescheduling an instance;
its recreating the set!  iCalendar says that RECURRENCE-IDs "might
also change" in this case and so far we all seem to agree on this
case (and this is backed up by the 3.b text from the original authors).



If you want to discuss when RECURRENCE-IDs
do change thats one thing but your example above is NOT a instance reschedule
example.



Bruce

===========================================================================

Bruce Kahn                  
             INet: Bruce_Kahn@notesdev.ibm.com

Messaging & Collaboration            
    Phone: 978.399.6496

IBM Software Group                
        FAX: and nothing but the FAX...

Standard disclaimers apply, even where prohibited by law...
--=_alternative 006F098985256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:43:45 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17162
	for ; Thu, 28 Aug 2003 16:43:44 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKPrgc096929
	for ; Thu, 28 Aug 2003 13:25:53 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKPrr4096928
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:25:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKPqgc096916
	for ; Thu, 28 Aug 2003 13:25:52 -0700 (PDT)
	(envelope-from Bruce_Kahn@notesdev.ibm.com)
In-Reply-To: <3F4D393E.7040905@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003
Message-ID: 
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 28 Aug 2003 16:26:21 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 04:26:21 PM,
	Serialize complete at 08/28/2003 04:26:21 PM
Content-Type: multipart/alternative; boundary="=_alternative 007039E185256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 007039E185256D90_=
Content-Type: text/plain; charset="US-ASCII"

Doug claimed on 08/27/2003 07:05:34 PM:
> Whether this is done with RRULEs, ADD's or what ever, if the result
> is equivalent to:
> 
>    SEQUENCE:0
>    RDATE:...monday...
>    RDATE:...tuesday..
> 
> And then the Monday meeting is chagned to Friday with
> a single instance modificaiton:
> 
>    SEQUENCE:1
>    RECURRENCE-ID:...monday
>    RDATE:...friday...
> 
> The RECURRENCE-ID for Monday is void 

Not, its not void.  What you describe exactly matches the iCalendar text 
and what we've said been saying all along. 

>                                      because I could have
> choosen to send the following and not the previous example:
> 
>    SEQUENCE:1
>    RDATE:...friday...
>    RDATE:...tuesday..
> 
> And the results must be equivelent to the ATTENDEE.

The above is not equivalent to the attempted reschedule.  This fragment is 
one that causes the recipient to recreate the UID with the given 
RECURRENCE-IDs; it in effect is a recreating of all the instances for that 
UID on the recipients calendar. The first fragment was a single instance 
reschedule.  They are totally different.

PLUS its incorrect in that the Tuesday instance did NOT change so its 
SEQUENCE should still be 0.

> So in all cases the 'set' of RECURRECNE-ID's is not the same
> and SEQUENCE:0

Huh??  You must not have understood the text Derik/Frank put in their #3 
item.  It clearly says that RECURRENCE-IDs are fixed and do not change 
unless you recreate the set; a reschedule does NOT recreate the set, it 
merely moves an instance around.

Believe what you like but iCalendar was pretty clear on RECURRENCE-ID 
staying fixed when an instance is rescheduled.  Derik/Frank reiterated 
that with their recent reponse that expressly said this.

If you look at the analysis of how iTIP performs or fails when messages 
are lost or missequenced, how can you still think that a delta model 
works?  A delta model is error prone and hard to recover from.  The fixed 
model recovers quite easily and there is no need for extra back and forth 
iTIP messaging (which still does not guarantee workflow recovery and 
resyncing like a fixed model)

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 007039E185256D90_=
Content-Type: text/html; charset="US-ASCII"



Doug claimed on 08/27/2003 07:05:34 PM:

> Whether this is done with RRULEs, ADD's or what ever, if the result

> is equivalent to:

> 

>    SEQUENCE:0

>    RDATE:...monday...

>    RDATE:...tuesday..

> 

> And then the Monday meeting is chagned to Friday with

> a single instance modificaiton:

> 

>    SEQUENCE:1

>    RECURRENCE-ID:...monday

>    RDATE:...friday...

> 

> The RECURRENCE-ID for Monday is void 



Not, its not void.  What you describe
exactly matches the iCalendar text and what we've said been saying all
along.  



>              
                     
 because I could have

> choosen to send the following and not the previous example:

> 

>    SEQUENCE:1

>    RDATE:...friday...

>    RDATE:...tuesday..

> 

> And the results must be equivelent to the ATTENDEE.



The above is not equivalent to the attempted
reschedule.  This fragment is one that causes the recipient to recreate
the UID with the given RECURRENCE-IDs; it in effect is a recreating of
all the instances for that UID on the recipients calendar. The first fragment
was a single instance reschedule.  They are totally different.



PLUS its incorrect in that the Tuesday
instance did NOT change so its SEQUENCE should still be 0.



> So in all cases the 'set' of RECURRECNE-ID's
is not the same

> and SEQUENCE:0



Huh??  You must not have understood
the text Derik/Frank put in their #3 item.  It clearly says that RECURRENCE-IDs
are fixed and do not change unless you recreate the set; a reschedule does
NOT recreate the set, it merely moves an instance around.



Believe what you like but iCalendar
was pretty clear on RECURRENCE-ID staying fixed when an instance is rescheduled.
 Derik/Frank reiterated that with their recent reponse that expressly
said this.



If you look at the analysis of how iTIP
performs or fails when messages are lost or missequenced, how can you still
think that a delta model works?  A delta model is error prone and
hard to recover from.  The fixed model recovers quite easily and there
is no need for extra back and forth iTIP messaging (which still does not
guarantee workflow recovery and resyncing like a fixed model)



Bruce

===========================================================================

Bruce Kahn                  
             INet: Bruce_Kahn@notesdev.ibm.com

Messaging & Collaboration            
    Phone: 978.399.6496

IBM Software Group                
        FAX: and nothing but the FAX...

Standard disclaimers apply, even where prohibited by law...
--=_alternative 007039E185256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:49: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 QAA17714
	for ; Thu, 28 Aug 2003 16:49:30 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKa9gc097711
	for ; Thu, 28 Aug 2003 13:36:09 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKa9cZ097710
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:36:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKa7gc097703
	for ; Thu, 28 Aug 2003 13:36:07 -0700 (PDT)
	(envelope-from satyanarayana.vempati@Sun.COM)
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35])
	by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7SKXSbu014086
	for ; Thu, 28 Aug 2003 14:33:28 -0600 (MDT)
Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91])
	by sfbaymail1sca.SFBay.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7SKXRhD024264
	for ; Thu, 28 Aug 2003 13:33:27 -0700 (PDT)
Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109])
 by ha13sca-mail1.sfbay.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct  1 2002))
 with ESMTP id <0HKC007K6JRRMU@ha13sca-mail1.sfbay.sun.com> for
 ietf-calendar@imc.org; Thu, 28 Aug 2003 13:33:27 -0700 (PDT)
Date: Thu, 28 Aug 2003 13:33:30 -0700
From: Satya Vempati 
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
To: "ietf-calendar@imc.org" 
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-language: en-USA
Content-transfer-encoding: 7BIT
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7BIT


We disagree. I do not believe the recurring set changes when a single
instance gets rescheduled. The post from the original authors explicitly
says so.

-----Original Message-----
From: Doug Royer [mailto:Doug@royer.com]
Sent: Thursday, August 28, 2003 12:57 PM
To: ietf-calendar@imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?




Satya Vempati wrote:
> That depends. Do you think that the pattern has changed if a single
> instance gets rescheduled?

Is that not the definition of 'rescheduled'? - a change?

So are you saying that you agree or disagree?

> -----Original Message-----
> From: Doug Royer [mailto:Doug@royer.com]
> Sent: Thursday, August 28, 2003 9:22 AM
> To: ietf-calendar@imc.org
> Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
> 
> 
> 
> 
> Satya Vempati wrote:
> 
>>Surely, Doug & Chris also agree that the RECURRENCE-ID changes when the
>>base recurrence set changes. They may not agree that RECURRENCE-ID stays
>>put if an instance is changed. Well, after the post from the original
>>authors, I hoped that this issue would be laid to rest. But ...
>
> They clearly said it changes when the pattern changes.
> Do you disagree that it changes when the pattern changes?

-- 

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

                 We Do Standards - You Need Standards



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:51: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 QAA17870
	for ; Thu, 28 Aug 2003 16:51:05 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKWXgc097398
	for ; Thu, 28 Aug 2003 13:32:33 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKWXXq097396
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:32:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKWWgc097389
	for ; Thu, 28 Aug 2003 13:32:32 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SKWVS5005025
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 13:32:33 -0700
Message-ID: <3F4E66DA.80507@Royer.com>
Date: Thu, 28 Aug 2003 14:32:26 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090100080209000005020901"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms090100080209000005020901
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug wrote on 08/27/2003 03:03:20 PM:
>  > I know that there may be more screams that this issues will not
>  > go away. But it really needs to be settled.
> 
> We went thru this before we RFCd.  We went over this a lot recently.  We 
> even got the original authors to clarify it.  Yet it seems that its a 
> hard concept for some to accept for some reason...  


Yes. They said it changed. Yet some still insist that it does not.

Derik and Frank do think it changes, as they said when the pattern
changes - it changes.


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

   ...

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

  ...

  "In summary, the original intention of the iCalendar specification was that
  the value of the RECURRENCE-ID for a specific recurrence instance would
  remain unchanged for the duration of the existence of the recurrence set.
  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."

So if an ATTENDEE has SEQUENCE:X and you update SEQUENCE:X to SEQUENCE:Y
then it does not change the RECURRENCE-ID of SEQUENCE:X, it updates
the object from X to Y in the ATTENDEE's store. And the RECURRECE-ID in
Y (the one the ATTENDEE is now at) has a different pattern in Y than in X.
So the next update will be to the Y pattern and not the X pattern. This
allows invitation without the need for history.

If you disagree please explain what Frank and Derik mean when they
said '...This value remains unchanged for as long as  the base recurrence
set (or pattern) exists. ...' If you change the base (reschedule it)
it changes the pattern. When would a reschedule NOT change the pattern?

So when you change the pattern - it changes. If you only change
the LOCATION (for example)- it does not change the RECURRENCE-ID's.

They did not say it is fixed forever.

(your related other subject deleted from this email.)

-- 

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

                 We Do Standards - You Need Standards

--------------ms090100080209000005020901
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIwMzIyNlowIwYJKoZIhvcNAQkEMRYEFMW2c4X+
ccG0A5CAzNgG9KZrTlyBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBALzUjdckQ2e2DlcEazkJnuuCT1PzwluCDz4fyuSGR/NfPfmyToo4
llCBjcPCv06De8j7SCorxyJdVkVCqwVq8o3Wn9Zr2ubPYaVUb+5lgcJGO+0GmPzzsMfOAeKR
hybDhg8Tl7Xgz2KgpyYtDzZ/unsJwOQik4m7+4AGiiIbaXOPBpDu48A2/nCurI9NDR9e3r6k
HWCsHD0eXYVDh1G9e/AWYhc+VbkmASGFO5bxC5rgKopT0NqA5C6irglSGP/CGVTN86kBP9BI
4Q2jlURMjJdpi9FaL4hpkV2U5HqWx2akZGYeK0T1puajM5rkNFR3akzWs6P3AAoUw1nJgWnf
88sAAAAAAAA=
--------------ms090100080209000005020901--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:55: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 QAA18184
	for ; Thu, 28 Aug 2003 16:55:31 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKbpgc097863
	for ; Thu, 28 Aug 2003 13:37:51 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKbpfY097862
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:37:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKbogc097856
	for ; Thu, 28 Aug 2003 13:37:50 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SKboS5005076
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 13:37:51 -0700
Message-ID: <3F4E6818.20908@Royer.com>
Date: Thu, 28 Aug 2003 14:37:44 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020200040300040903030002"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms020200040300040903030002
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:

> 
>  > I think that proof is:
>  >
>  >    So your first invitation is to:
>  >
>  >         UID:100
>  >         SEQUENCE:0
>  >         DATE:...sep-1...10am...
>  >
>  >    Then you get:
>  >
>  >         UID:100
>  >         SEQUENCE:1
>  >         RRULE;FREQ=DAILY;COUNT=10
>  >         DTSTART:...sep-2...3pm
> 
> 
> Ugh!  THIS IS A TOTALLY DIFFERENT FISH THAN THE NORMAL INSTANACE 
> RESCHEDULE EXAMPLE!

I assume you have not read my corrected e-mail. So I'll reply
to any post you have to that correction - if any.

-- 

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

                 We Do Standards - You Need Standards

--------------ms020200040300040903030002
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIwMzc0NFowIwYJKoZIhvcNAQkEMRYEFGUFLztK
Ajpg6t6YAj1w3ydQXp2nMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBABtbAGQdNJK2CMMoOeYnjAkRx0PdhwKn1Z7EX+93RyaFfxqQy0Ae
rFaBkKvz+c6N1SJxSVjg+THtUwJO3RGli2CUbC6kVBlHzivRSvifhBKCqK9azdkHABxvs7YA
hPNtqnAFbfUvAGEuyVumJqkKVl5ftOyfxrEGJLYKtPqkkxRYN17bLQwzCLGiNnHhIq45k6vz
5Kom9VE0JaU58ylPqa7oDHcg2cq+Z3JxQDbH6Txim/kZoV3k55B1fhpq4fhOeS6pNbl7YPvf
5xEp/Ng3N70MG5I/3bxtZkBgvCQnm9zPRWOkU0gNu+HtAuFb2Wvd9i5RN7sHHwW0AxtNSYeQ
6VoAAAAAAAA=
--------------ms020200040300040903030002--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:59: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 QAA18482
	for ; Thu, 28 Aug 2003 16:59:29 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKkKgc098574
	for ; Thu, 28 Aug 2003 13:46:20 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKkK7S098573
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:46:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKkIgc098566
	for ; Thu, 28 Aug 2003 13:46:18 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sTfb-00062O-00
	for ; Thu, 28 Aug 2003 22:47:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19sTfa-00062G-00
	for ; Thu, 28 Aug 2003 22:47:02 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sTes-0005bp-00
	for ; Thu, 28 Aug 2003 22:46:18 +0200
From: "Michael Fair" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Thu, 28 Aug 2003 13:46:16 -0700
Lines: 37
Message-ID: 
References: 
X-Complaints-To: usenet@sea.gmane.org
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


> To avoid confusion, we need to separate the master/base event and an
> instance. I do not think that the sequence number on the master/base
> event should change if an instance is rescheduled.
>
> Yes, the sequence number must be updated but only on the instance.
> Not the master.
>
> My original question had to do with changing the base/master event: In
> that situation, should the new sequence number on the master be (where
> seq(n-1) is the sequence before, and seq(n) the sequence after, the
change)
>
> seq(n) = seq(n-1) + 1 or
> seq(n) = max ((highest seq in all recurring instances), seq(n-1)) + 1

It should be the "max" one.

Though I would simplify it as:
seq(n) = max(seq of all affected instances) + 1

This has the added bonus of applying to "THISANDPRIOR" and
"THISANDFUTURE" updates as well (even though strictly speaking
those are instance updates and not set redefinitions).

If there have been no reschedules or other such thing then all
instances will have the same SEQUENCE value and it will match
the value of the base event so the formula holds.

A an update to the base/master event affects all instances, and
therefore the max sequence from the entire series will be used
and the formula holds.

Kind of a trivial distinction, but it helps simplify it some more.

-- Michael --





From owner-ietf-calendar@mail.imc.org  Thu Aug 28 16:59: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 QAA18498
	for ; Thu, 28 Aug 2003 16:59:33 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKa2gc097697
	for ; Thu, 28 Aug 2003 13:36:02 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKa29Q097696
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:36:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKa0gc097690
	for ; Thu, 28 Aug 2003 13:36:01 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SKa0S5005058
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 13:36:02 -0700
Message-ID: <3F4E67AB.7020007@Royer.com>
Date: Thu, 28 Aug 2003 14:35:55 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030100090305070002030000"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms030100090305070002030000
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
>
> Ive repeatdly shown how poorly a changing ID model is, especially with 
> missequenced or lost messages.  To date, no one has been able to dispute 
> it; at least not technically.  

So far your assertion that it does not change has been disputed
by Frank and Derik, so what is the point of debating a conclusion
based on your disputed assumption?

> So Im a bit weary with this topic and the repeated attempts to change 
> whats WRITTEN in the RFCs and whats been technically analyzed and even 
> commented on by the original authors.  How many times do we need to 
> rehash this??

Explain how you change the pattern and still keep the RECURRECE-ID's
fixed. Or explain how your model is consistent with Frank and Deriks
assertion that it changes?

-- 

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

                 We Do Standards - You Need Standards

--------------ms030100090305070002030000
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIwMzU1NVowIwYJKoZIhvcNAQkEMRYEFCSNjMv2
2jjB11QcruXSXrbtttTeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBACdPkT2NXTxCWG48aUSfmU7Pc0C8XwUG5sNGboGvXUR2TXX+DRC3
0H4MW78tu6crXopUg7kR3ftyZCrsWyBvKE0oDrcpfpxPA0v4FRJ6UAqINhjrOMdjWYX7Fagn
A4G0IrYuRd4+uodhgJGjhRo4vkHDiWw/sCn8dXnuaWctu3mrhxR0msZxy5/cQJSO1l59pg2m
htLPt/w3Dc0qQ3LvhFJz8UYCBZdzjMhoiP5JE/Dka4VWeN2t70JiudzkFlLRqY2z8wdOMgxE
O6a+t7KWKY+B4cHkO2uw2qkDh3ZE7s6mlxW6wDrPqezLhCbBBLq63+2mCzQd4zzlAAeCoOzv
shYAAAAAAAA=
--------------ms030100090305070002030000--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:09: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 RAA19190
	for ; Thu, 28 Aug 2003 17:09:06 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKtwgc099118
	for ; Thu, 28 Aug 2003 13:55:58 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKtvMn099117
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:55:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKtvgc099112
	for ; Thu, 28 Aug 2003 13:55:57 -0700 (PDT)
	(envelope-from Bruce_Kahn@notesdev.ibm.com)
In-Reply-To: <3F4D39AA.3020205@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003
Message-ID: 
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 28 Aug 2003 16:44:21 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 04:56:24 PM,
	Serialize complete at 08/28/2003 04:56:24 PM
Content-Type: multipart/alternative; boundary="=_alternative 0071DFBA85256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0071DFBA85256D90_=
Content-Type: text/plain; charset="US-ASCII"

Doug fired back on 08/27/2003 07:07:22 PM:
> WRONG - If you change a MONDAY to a FRIDAY - please explain
> how the pattern has not been altered?

You are too fixated on the word "pattern" and thus are not seeing the 
concept for the word (to paraphrase a bit).  You have totally ignored the 
entire text of the response from Derik/Frank that expressly describes the 
single instance reschedule.   Much like you had a different defintion of 
the word "original" when reading iCalendar Section 4.8.4.4 I'm guessing.

Given that I tried to explain that RECURRENCE-ID is fixed based on RFC 
citations, that I provided an object analysis of both the fixed and delta 
models and showed exactly how the delta model fails to perform in error 
sitations and that the original authors provided a response that 
reconfirms the RFCs and what Ive been saying/showing I am at somewhat of a 
loss as to understanding why Doug (and 1 or 2 others) persists in saying 
that RECURRENCE-ID MUST change on each reschedule.

The only justification I have seen so far as to why Doug (and Chris and 
George?) think RECURRENCE-ID MUST change on each instance reschedule is 1 
line in iTIP.  A single sentence that contradicts ALL the other bits of 
iCalendar and iTIP.  A single sentece that the WG already considered in 
error back at least as far as 1999.

Can someone please explain why a delta model is still considered practical 
or functional given all the information to the contrary?  Perhaps if I can 
understand this I can better help to debunk it and we can move on to more 
pressing WG business.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0071DFBA85256D90_=
Content-Type: text/html; charset="US-ASCII"



Doug fired back on 08/27/2003 07:07:22 PM:

> WRONG - If you change a MONDAY to a FRIDAY - please explain

> how the pattern has not been altered?



You are too fixated on the word "pattern"
and thus are not seeing the concept for the word (to paraphrase a bit).
 You have totally ignored the entire text of the response from Derik/Frank
that expressly describes the single instance reschedule.   Much like
you had a different defintion of the word "original" when reading
iCalendar Section 4.8.4.4 I'm guessing.



Given that I tried to explain that RECURRENCE-ID
is fixed based on RFC citations, that I provided an object analysis of
both the fixed and delta models and showed exactly how the delta model
fails to perform in error sitations and that the original authors provided
a response that reconfirms the RFCs and what Ive been saying/showing I
am at somewhat of a loss as to understanding why Doug (and 1 or 2 others)
persists in saying that RECURRENCE-ID MUST change on each reschedule.



The only justification I have seen so
far as to why Doug (and Chris and George?) think RECURRENCE-ID MUST change
on each instance reschedule is 1 line in iTIP.  A single sentence
that contradicts ALL the other bits of iCalendar and iTIP.  A single
sentece that the WG already considered in error back at least as far as
1999.



Can someone please explain why a delta
model is still considered practical or functional given all the information
to the contrary?  Perhaps if I can understand this I can better help
to debunk it and we can move on to more pressing WG business.



Bruce

===========================================================================

Bruce Kahn                  
             INet: Bruce_Kahn@notesdev.ibm.com

Messaging & Collaboration            
    Phone: 978.399.6496

IBM Software Group                
        FAX: and nothing but the FAX...

Standard disclaimers apply, even where prohibited by law...
--=_alternative 0071DFBA85256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:14: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 RAA19623
	for ; Thu, 28 Aug 2003 17:14:55 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKwWgc099239
	for ; Thu, 28 Aug 2003 13:58:32 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKwW0O099238
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:58:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKwVgc099231
	for ; Thu, 28 Aug 2003 13:58:31 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SKwUS5005366
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 13:58:32 -0700
Message-ID: <3F4E6CF1.2050400@Royer.com>
Date: Thu, 28 Aug 2003 14:58:25 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080506030501020004040200"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms080506030501020004040200
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
(your rude and childish comment removed)

> As per Derik Stenerson reponse changes to instances do not change pattern.

They did however say that it remains fixed as long as the pattern does
not change. Please explain how to move a Monday meeting to Tuesday
without changing the pattern.


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

                 We Do Standards - You Need Standards

--------------ms080506030501020004040200
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIwNTgyNVowIwYJKoZIhvcNAQkEMRYEFIo9d/35
J1rmt7zeNtCjIZmoOVm6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAEqhq0152Aey1qD00sZf7v6JNqrCKhoXwX1Tg2gI9PwGMkAkyZbc
8nxClQ1l9DRUSeaoS/YVU5W2+Vtc7nXpkHfQyiT0JYIcBi3IjOeI4uFFE4qRFnh3MDHgSaNF
1A7vQdbC+mfbmCp1mC77HdKPIsC3lhjJl74LILV8daAVKjfdKHHcxZG94rC6b8IEiEu6AgV7
xWjzkLxyrrsvyip9gAauwQKeHr9eFpYvckc06k3G2jf5RKMeQx9UGSkqrwXxhNlA33pbnFy6
bDZMnXDdqeh/1XXmK+CXLaJEL783xSdufBYeAsuxbiQ3y2DTopo1vPZm+vEPx0P9A/D30h6T
GuoAAAAAAAA=
--------------ms080506030501020004040200--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:15: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 RAA19641
	for ; Thu, 28 Aug 2003 17:15:03 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKtUgc099086
	for ; Thu, 28 Aug 2003 13:55:30 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SKtU0k099085
	for ietf-calendar-bks; Thu, 28 Aug 2003 13:55:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKtSgc099079
	for ; Thu, 28 Aug 2003 13:55:28 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SKtSS5005342
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 13:55:29 -0700
Message-ID: <3F4E6C3B.8090405@Royer.com>
Date: Thu, 28 Aug 2003 14:55:23 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050000080709090002090203"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms050000080709090002090203
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Satya Vempati wrote:
> To avoid confusion, we need to separate the master/base event and an
> instance. I do not think that the sequence number on the master/base event
> should change if an instance is rescheduled.

Your talking implementation detail. I see no reason that the wire protocol
needs to care.

And iTIP says (in effect) when you change anything that effects the
instances, you have to bump the SEQUENCE. So why/when do you feel it does
apply?

> Yes, the sequence number must be updated but only on the instance. Not the
> master.

Why does it matter how the ORGANZIER-CUA stores objects?

If it is valid to send an instance update .OR. an entire object.
Then the net result must be that the two are equivalent.


> My original question had to do with changing the base/master event: In
> that situation, should the new sequence number on the master be (where
> seq(n-1) is the sequence before, and seq(n) the sequence after, the change)
> 
> seq(n) = seq(n-1) + 1 or
> seq(n) = max ((highest seq in all recurring instances), seq(n-1)) + 1

What you send the ATTENDEE must be incremented. What the ATTENDEE replies
to must match what was sent. If it is a single instance update or
a complete replacement - it must be true. I can not find a single
exception to that in iTIP or iCAL. The SEQUENCE number must be
bumped when the listed properties change (or the organizer deems
it needed). Each time they change.

-- 

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

                 We Do Standards - You Need Standards

--------------ms050000080709090002090203
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIwNTUyM1owIwYJKoZIhvcNAQkEMRYEFIBc8nRC
s7u/OuVOasVE1WV2spR1MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAIQXD7ZJxGt7IVgmGJqGQQb2+56k1QYv7GcS4X6FQbaIuTltsdOM
rCq7IN6RUj0bapke8tqZsPSaZk7WeqM3zbi5lGhpo7bW0SxkyukYJZMF2F+W7tkSU3Tdyz/3
6IaHwvKVg2rdV1VmekHCPge6p2j4zMn/ZognwZNMsCTj/Bafgb7zuWa4mRBhb4tBjz3XXKe/
/DciirbCBLdRHERVtBPOqFXtQrEoyXSBj415qfeumwFQcuVRZSfsFC7SIaCQSvRHzF/Qx037
h5aLn6MnI507VJu6PQesm1pERPaeJ4QXydo5Czk3OEnQbfvGPGSxQIv4K5hxpaPv/8zbV1GX
5QUAAAAAAAA=
--------------ms050000080709090002090203--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:21: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 RAA20152
	for ; Thu, 28 Aug 2003 17:21:34 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SL8tgc099916
	for ; Thu, 28 Aug 2003 14:08:55 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SL8tmx099915
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:08:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from webex.com (srv-mailgatesjc1.webex.com [64.68.123.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SL8sgc099907
	for ; Thu, 28 Aug 2003 14:08:54 -0700 (PDT)
	(envelope-from joerg.reichelt@webex.com)
Received: from ([192.168.253.55])
	by srv-mailgatesjc1.webex.com with ESMTP ;
	Thu, 28 Aug 2003 14:08:13 -0700 (PDT)
Received: by BASTION.webex.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Aug 2003 13:56:56 -0700
Message-ID: 
From: Joerg Reichelt 
To: "'ietf-calendar@imc.org'" 
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Thu, 28 Aug 2003 14:08:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


It appears that it would have been much easier - and a lot less 
controversial - to define the recurrence ID as an index into the 
set of instances.

Looking at it this way, it would be clear to most of us that
- this index DOES NOT change for simple changes to that instance
  it refers to
- this index DOES change when the instances of a set need to be 
  re-indexed, e.g. when the definition of what instances belong 
  to the set changes; when this happens, and you want to keep
  modifications to individual instances of the set, you need to
  update the index in each of the descriptions of the instance
  modifications (e.g. change that index to the new index of the
  modified instance)

Since the recurrence ID is currently defined to be constructed of 
the start date and time of the instance, it appears to imply that 
it always would be equivalent to that value, which seems to be the 
source of the disagreement. The argument is revolving around the 
question whether the recurrence ID should be the original or the 
current value for a given instance (and conflicting references to
RFC paragraphs about what is correct have been presented, and both
alternatives have been extensively discussed).

It appears to me that it would be easier to work with a constant 
reference as much as possible than with one that changes all the 
time, but that is just my personal opinion on this topic.

My 2 cents.

- Joerg


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17: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 RAA20217
	for ; Thu, 28 Aug 2003 17:22:18 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SL5Ngc099640
	for ; Thu, 28 Aug 2003 14:05:23 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SL5N1i099639
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:05:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SL5Lgc099633
	for ; Thu, 28 Aug 2003 14:05:21 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SL5LS5005453
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 14:05:22 -0700
Message-ID: <3F4E6E8C.3000208@Royer.com>
Date: Thu, 28 Aug 2003 15:05:16 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040004030205030604050105"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms040004030205030604050105
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug maintained on 08/27/2003 06:58:01 PM:
>  > If you change the DTSTART - *only*, as in:
>  >
>  >    SEQUENCE:X
>  >    DTSTART:...monday..
>  >    RRULE:FREQ=WEEKLY
>  >
>  > To:
>  >
>  >    SEQUENCE:X+Y
>  >    DTSTART:...tuesday...
>  >    RRULE:FREQ=WEEKLY.
>  >
>  > The instances and RECURRECE-ID's change.
>  > So DTSTART *is* included even when; RRULE,
>  > RDATE, EXDATE, and EXRULE do not change.
> 
> This is NOT rescheduling an instance; its recreating the set! 

Which was my point as Robert said that 'DTSTART' was not
in the set that effected the RECURRENCE-ID changing when he
replied to my example and he said:

     "No I do not.

      I do mean
                 RDATE
                 RRULE
                 EXDATE
                 EXRULE

     DTSTART is not part of RULE"

In responce to my email that said that moving the DTSTART effects
the pattern. And it does change the RECURRENCE-IDs. I said
noting about single instance update. And the example he responded
to was a full replacement showing that the RECURRECE-IDs change
when the pattern changes on a full replacement.


_____________________

-- 

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

                 We Do Standards - You Need Standards

--------------ms040004030205030604050105
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIxMDUxNlowIwYJKoZIhvcNAQkEMRYEFKsV+Nbw
57kzcLQt3VfGbJ2IcBQqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBALTKgUMEiCA57fVsS40jpmjCSd7mjMo1diYH2qKmW5lPRhQjSm/Y
FDE2AC/xVsW4cva0YvQnx9cI9TcEh8ZUVYmpzFQYyDsySO0BsgljKDB0lyl1mPoMsDXk7XOz
UUQifkOtkvq7CN4p525Hs2Hj7KytkUFbWvhL8ilZwJ3LhqALTn+9Ns37J93z2bGUgG/tcr3L
a21W6mNYFgwKlWXikCc/bnpwVYwpvRovl4YAamlxvVq3sTNX1BL+yKLg7a1UuZjO8XhMDEJ4
LM80WWPhKTD7jDWnZmKI/Sjla87kv3WRKRo0zNv9zgfb2LbEexWyDnR7tUG/qzIm8BHr32Ft
p5sAAAAAAAA=
--------------ms040004030205030604050105--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:30:45 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20778
	for ; Thu, 28 Aug 2003 17:30:44 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLGggc000571
	for ; Thu, 28 Aug 2003 14:16:42 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLGgsh000570
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:16:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLGfgc000564
	for ; Thu, 28 Aug 2003 14:16:41 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SLGeS5005564
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 14:16:42 -0700
Message-ID: <3F4E7132.1090601@Royer.com>
Date: Thu, 28 Aug 2003 15:16:34 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010605090707090304040302"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms010605090707090304040302
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
>
>  > Whether this is done with RRULEs, ADD's or what ever, if the result
>  > is equivalent to:
>  >
>  >    SEQUENCE:0
>  >    RDATE:...monday...
>  >    RDATE:...tuesday..
>  >
>  > And then the Monday meeting is chagned to Friday with
>  > a single instance modificaiton:
>  >
>  >    SEQUENCE:1
>  >    RECURRENCE-ID:...monday
>  >    RDATE:...friday...
>  >
>  > The RECURRENCE-ID for Monday is void
> 
> Not, its not void.  What you describe exactly matches the iCalendar text 
> and what we've said been saying all along.  

Well itip says it is 'obsolete'. That means void to me.

>  >                                      because I could have
>  > choosen to send the following and not the previous example:
>  >
>  >    SEQUENCE:1
>  >    RDATE:...friday...
>  >    RDATE:...tuesday..
>  >
>  > And the results must be equivelent to the ATTENDEE.
> 
> The above is not equivalent to the attempted reschedule.  This fragment 
> is one that causes the recipient to recreate the UID with the given 
> RECURRENCE-IDs; it in effect is a recreating of all the instances for 
> that UID on the recipients calendar. The first fragment was a single 
> instance reschedule.  They are totally different.

Yes that is my point. They are different and BOTH valid.
They both produce the exact same dates/times on the ATTENDEE's CUA.
So why does it matter which of the two methods were used?
They both changed the instance patterns. And the instance
patterns changed are exactly the same. So what?

> PLUS its incorrect in that the Tuesday instance did NOT change so its 
> SEQUENCE should still be 0.
 >
>  > So in all cases the 'set' of RECURRECNE-ID's is not the same
>  > and SEQUENCE:0
> 
> Huh??  You must not have understood the text Derik/Frank put in their #3 
> item.  It clearly says that RECURRENCE-IDs are fixed and do not change 
> unless you recreate the set; a reschedule does NOT recreate the set, it 
> merely moves an instance around.

Yes. They clearly say that if the pattern changes, the RECURRECE-IDs
change. The recurrece-id in SEQUENCE:1 does NOT have the same
RECURRECE-ID patterns that are in SEQUENEC:0, they changed. You also
noticed that above when you noted by exclusion that one of the two
did not change - (implying that the patterns are not the same - correct?)


-- 

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

                 We Do Standards - You Need Standards

--------------ms010605090707090304040302
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIxMTYzNFowIwYJKoZIhvcNAQkEMRYEFEnG1aAr
kJy2IERa5J+y5PaQyBi1MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBACm6Tu7XVX6HjTHsHMj8kovzG/4vht77zqYzIAZdhNIKlzvJ/Nsh
GXH1Vpmi7I69xbxiDqBGQq4t6fIR514E4fSoXicoJH8dMb1iNzMNwtRWfHLO3Uz1Dj9sU+nn
GJwLIZujbsW5+HgAcwkE28qWx/7/9VyDt8g+aqFinaN7PQz5NHcSFmkC7RwtSmHK2vBUn+qN
6KTozVCzelxHD9u0S/maonQcH2c3j7wmO/bXWMNU8lHl3DCtoPhkAo9I9JDRKs37pPAfJMfm
9KtxZ9+dRisn3RdQnC1cS35G9HWCFZk8/xDYNODMrCj73jH8h4V7BQpnfuM3Ejt0wM7lyeWL
0LAAAAAAAAA=
--------------ms010605090707090304040302--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:33: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 RAA20974
	for ; Thu, 28 Aug 2003 17:33:14 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLJGgc000669
	for ; Thu, 28 Aug 2003 14:19:16 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLJGxr000668
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:19:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLJFgc000661
	for ; Thu, 28 Aug 2003 14:19:15 -0700 (PDT)
	(envelope-from Bruce_Kahn@notesdev.ibm.com)
In-Reply-To: 
To: Satya Vempati 
Cc: ietf-calendar@imc.org
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003
Message-ID: 
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 28 Aug 2003 17:06:42 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 05:19:41 PM,
	Serialize complete at 08/28/2003 05:19:41 PM
Content-Type: multipart/alternative; boundary="=_alternative 0073EB9585256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0073EB9585256D90_=
Content-Type: text/plain; charset="US-ASCII"

Satya wrote on 08/27/2003 08:40:50 PM:
> Suppose the base set is UID:1, SEQ:0
> We reschedule an instance: UID:1, RID:x, SEQ:1
> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50 
(attendee
> A is invited to this instance alone)
> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51 OR
> UID:1, SEQ:1?

This is an example of misundertanding the role of a RRULE that I was 
talking about elsewhere.  If you are using an RRULE to invite someone then 
you are saying that all the instances created using the RRULE shorthand 
have _exactly_the_same_data_ with the only exception being the 
DTSTART/DTEND of each instance.  Other than than, ALL instances that are 
generated have the same data.

So if you move instances around or make any changes to them, you cannot 
expect an iTIP message with just the RRULE in it to accurately represent 
the instances anymore; you will have to rely on RDATEs or you will have to 
send the RRULE used and follow it with the individual different instances.

As such, for your example you have a couple choices on how to craft an 
invitation to someone new.  However Im not sure thats what you were 
intending.  What are you trying to do w/the set now?  Add a new invitee? 
Just recreate an iCalendar stream to represent it?  Something else?

In any case, the intent is not germane to Dougs contention that 
RECURRENCE-IDs change on an instance reschedule.

> My point is that we should focus on moving on to other issues and not 
flog
> the dead horse ("Will recurrence-id change for an instance reschedule?")
> for ever.

I agree.  By now it should be clear(er) that the iCalendar model is a 
fixed RECURRENCE-ID model.  Lets get on to other more pressing tasks 
before the ADs pull the plug on the WG.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0073EB9585256D90_=
Content-Type: text/html; charset="US-ASCII"



Satya wrote on 08/27/2003 08:40:50 PM:

> Suppose the base set is UID:1, SEQ:0

> We reschedule an instance: UID:1, RID:x, SEQ:1

> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50 (attendee

> A is invited to this instance alone)

> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51
OR

> UID:1, SEQ:1?



This is an example of misundertanding
the role of a RRULE that I was talking about elsewhere.  If you are
using an RRULE to invite someone then you are saying that all the instances
created using the RRULE shorthand have _exactly_the_same_data_ with the
only exception being the DTSTART/DTEND of each instance.  Other than
than, ALL instances that are generated have the same data.



So if you move instances around or make
any changes to them, you cannot expect an iTIP message with just the RRULE
in it to accurately represent the instances anymore; you will have to rely
on RDATEs or you will have to send the RRULE used and follow it with the
individual different instances.



As such, for your example you have a
couple choices on how to craft an invitation to someone new.  However
Im not sure thats what you were intending.  What are you trying to
do w/the set now?  Add a new invitee?  Just recreate an iCalendar
stream to represent it?  Something else?



In any case, the intent is not germane
to Dougs contention that RECURRENCE-IDs change on an instance reschedule.



> My point is that we should focus on moving on
to other issues and not flog

> the dead horse ("Will recurrence-id change for an instance reschedule?")

> for ever.



I agree.  By now it should be clear(er)
that the iCalendar model is a fixed RECURRENCE-ID model.  Lets get
on to other more pressing tasks before the ADs pull the plug on the WG.



Bruce

===========================================================================

Bruce Kahn                  
             INet: Bruce_Kahn@notesdev.ibm.com

Messaging & Collaboration            
    Phone: 978.399.6496

IBM Software Group                
        FAX: and nothing but the FAX...

Standard disclaimers apply, even where prohibited by law...
--=_alternative 0073EB9585256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:33: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 RAA21011
	for ; Thu, 28 Aug 2003 17:33:31 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLJMgc000696
	for ; Thu, 28 Aug 2003 14:19:22 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLJMUT000695
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:19:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLJFgc000663
	for ; Thu, 28 Aug 2003 14:19:15 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: 
To: satyanarayana.vempati@Sun.COM
Cc: "ietf-calendar@imc.org" ,
        owner-ietf-calendar@mail.imc.org
Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Thu, 28 Aug 2003 17:06:21 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 05:19:48 PM,
	Serialize complete at 08/28/2003 05:19:48 PM
Content-Type: multipart/alternative; boundary="=_alternative 0073848585256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0073848585256D90_=
Content-Type: text/plain; charset="US-ASCII"

If you are changing the base event the new SEQUENCE number is one more 
than the highest SEQUENCE number currently used by any of the instances in 
the set.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Satya Vempati  
Sent by: owner-ietf-calendar@mail.imc.org
08/28/2003 04:17 PM

To
"ietf-calendar@imc.org" 
cc

Subject
RE: Does anyone still think that RECURRENCE-ID's do NOT change?







To avoid confusion, we need to separate the master/base event and an
instance. I do not think that the sequence number on the master/base event
should change if an instance is rescheduled.

Yes, the sequence number must be updated but only on the instance. Not the
master.

My original question had to do with changing the base/master event: In
that situation, should the new sequence number on the master be (where
seq(n-1) is the sequence before, and seq(n) the sequence after, the 
change)

seq(n) = seq(n-1) + 1 or
seq(n) = max ((highest seq in all recurring instances), seq(n-1)) + 1

-----Original Message-----
From: Doug Royer [mailto:Doug@royer.com]
Sent: Thursday, August 28, 2003 9:56 AM
To: ietf-calendar@imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?




Satya Vempati wrote:

> The SEQUENCE numbering scheme I am talking about is the following issue:
> 
> Suppose the base set is UID:1, SEQ:0
> We reschedule an instance: UID:1, RID:x, SEQ:1
> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50
(attendee
> A is invited to this instance alone)
> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51 OR
> UID:1, SEQ:1?

iTIP says that when you send an instance update you increment
the SEQUENCE number each time. Do you disagree?

-- 

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

                 We Do Standards - You Need Standards



--=_alternative 0073848585256D90_=
Content-Type: text/html; charset="US-ASCII"



If you are changing the base event the
new SEQUENCE number is one more than the highest SEQUENCE number currently
used by any of the instances in the set.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Satya Vempati <satyanarayana.vempati@Sun.COM>


Sent by: owner-ietf-calendar@mail.imc.org

08/28/2003 04:17 PM








To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

RE: Does anyone still think
that RECURRENCE-ID's do NOT change?



















To avoid confusion, we need to separate the master/base event and an

instance. I do not think that the sequence number on the master/base event

should change if an instance is rescheduled.



Yes, the sequence number must be updated but only on the instance. Not
the

master.



My original question had to do with changing the base/master event: In

that situation, should the new sequence number on the master be (where

seq(n-1) is the sequence before, and seq(n) the sequence after, the change)



seq(n) = seq(n-1) + 1 or

seq(n) = max ((highest seq in all recurring instances), seq(n-1)) + 1



-----Original Message-----

From: Doug Royer [mailto:Doug@royer.com]

Sent: Thursday, August 28, 2003 9:56 AM

To: ietf-calendar@imc.org

Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?









Satya Vempati wrote:



> The SEQUENCE numbering scheme I am talking about is the following
issue:

> 

> Suppose the base set is UID:1, SEQ:0

> We reschedule an instance: UID:1, RID:x, SEQ:1

> We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50

(attendee

> A is invited to this instance alone)

> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51
OR

> UID:1, SEQ:1?



iTIP says that when you send an instance update you increment

the SEQUENCE number each time. Do you disagree?



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards






--=_alternative 0073848585256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:33: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 RAA21049
	for ; Thu, 28 Aug 2003 17:33:41 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLKFgc000740
	for ; Thu, 28 Aug 2003 14:20:15 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLKFbR000739
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:20:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLKEgc000734
	for ; Thu, 28 Aug 2003 14:20:14 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SLKDS5005613
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 14:20:15 -0700
Message-ID: <3F4E7208.2080606@Royer.com>
Date: Thu, 28 Aug 2003 15:20:08 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080405000909070506080200"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms080405000909070506080200
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug wrote on 08/27/2003 05:30:07 PM:
>  >                   Thus the set changes. Thus the RECURRENCE-IDs
>  > always change on one OR all instance rescheduling changes.
> 
> Sorry but thats false.  iCalendar clearly says:
> 
>    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.

Yes, to change the pattern (set), send an iTIP message that has
the RECURRECE-ID set to the one you are changing from. So what?
So you agree that you are telling the ATTENDEE to change the
set (pattern). Why do you feel that does not cause the pattern
of the set to change?

-- 

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

                 We Do Standards - You Need Standards

--------------ms080405000909070506080200
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIxMjAwOFowIwYJKoZIhvcNAQkEMRYEFHJvUOhF
ulxnQOgjms7+uNNst/f7MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBACl45Yfk53685CgCbQSpQ5jm/AIeQ6c43DlHwVv7QXcZ7tLOHpKT
DwlxKhB7lPsEXwWkwuI7bJrkYB4cTSmAp7Wp7ENQkJ6SBaaaCbmY5W4iMPk5hS8LKzavRm1b
hGZxsbCMVqxGjOJieSc9CWEpt2eD9QGmwzyfrcCUlOU0ZrfrTkQ7Vr2ERJh6TCZTk0A+rHOb
2lK2rvoOXZATPVf2C1CC5fsT+nTxkP9UfrwgDiBBjdnRqp3eAXwaUjkDXsDCxck5itls0FMM
TpSxFOK5Ek0q9z98JSEEUsNGXGKlPZGiZ2KMyz0UoRm7sKsgfAOi/fn6zg53SlYsVyOH3Yns
wDIAAAAAAAA=
--------------ms080405000909070506080200--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:33: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 RAA21087
	for ; Thu, 28 Aug 2003 17:33:47 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLJIgc000676
	for ; Thu, 28 Aug 2003 14:19:18 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLJItd000675
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:19:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLJFgd000661
	for ; Thu, 28 Aug 2003 14:19:16 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4E67AB.7020007@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Thu, 28 Aug 2003 17:14:20 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 05:19:42 PM,
	Serialize complete at 08/28/2003 05:19:42 PM
Content-Type: multipart/alternative; boundary="=_alternative 00743F8E85256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 00743F8E85256D90_=
Content-Type: text/plain; charset="US-ASCII"

That's is BOGUS Doug.

Derik Stenerson said
> 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. 

_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/28/2003 04:35 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Bruce_Kahn@notesdev.ibm.com wrote:
>
> Ive repeatdly shown how poorly a changing ID model is, especially with 
> missequenced or lost messages.  To date, no one has been able to dispute 

> it; at least not technically. 

So far your assertion that it does not change has been disputed
by Frank and Derik, so what is the point of debating a conclusion
based on your disputed assumption?

> So Im a bit weary with this topic and the repeated attempts to change 
> whats WRITTEN in the RFCs and whats been technically analyzed and even 
> commented on by the original authors.  How many times do we need to 
> rehash this??

Explain how you change the pattern and still keep the RECURRECE-ID's
fixed. Or explain how your model is consistent with Frank and Deriks
assertion that it changes?

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 00743F8E85256D90_=
Content-Type: text/html; charset="US-ASCII"



That's is BOGUS Doug.



Derik Stenerson
said

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



_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/28/2003 04:35 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Bruce_Kahn@notesdev.ibm.com wrote:

>

> Ive repeatdly shown how poorly a changing ID model is, especially
with 

> missequenced or lost messages.  To date, no one has been able
to dispute 

> it; at least not technically.  



So far your assertion that it does not change has been disputed

by Frank and Derik, so what is the point of debating a conclusion

based on your disputed assumption?



> So Im a bit weary with this topic and the repeated attempts to change


> whats WRITTEN in the RFCs and whats been technically analyzed and
even 

> commented on by the original authors.  How many times do we need
to 

> rehash this??



Explain how you change the pattern and still keep the RECURRECE-ID's

fixed. Or explain how your model is consistent with Frank and Deriks

assertion that it changes?



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 00743F8E85256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:34: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 RAA21173
	for ; Thu, 28 Aug 2003 17:34:51 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLJIgc000683
	for ; Thu, 28 Aug 2003 14:19:18 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLJIj6000682
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:19:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLJFge000661
	for ; Thu, 28 Aug 2003 14:19:17 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4E6CF1.2050400@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Thu, 28 Aug 2003 17:19:13 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 05:19:44 PM,
	Serialize complete at 08/28/2003 05:19:44 PM
Content-Type: multipart/alternative; boundary="=_alternative 0074B24A85256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0074B24A85256D90_=
Content-Type: text/plain; charset="US-ASCII"

Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/28/2003 04:58 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Robert_Ransdell@notesdev.ibm.com wrote:
> 
(your rude and childish comment removed)

> As per Derik Stenerson reponse changes to instances do not change 
pattern.

They did however say that it remains fixed as long as the pattern does
not change. Please explain how to move a Monday meeting to Tuesday
without changing the pattern.


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

                 We Do Standards - You Need Standards


--=_alternative 0074B24A85256D90_=
Content-Type: text/html; charset="US-ASCII"












Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/28/2003 04:58 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

(your rude and childish comment removed)



> As per Derik Stenerson reponse changes to instances do not change
pattern.



They did however say that it remains fixed as long as the pattern does

not change. Please explain how to move a Monday meeting to Tuesday

without changing the pattern.





  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 0074B24A85256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:35:15 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21247
	for ; Thu, 28 Aug 2003 17:35:15 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLMGgc000837
	for ; Thu, 28 Aug 2003 14:22:16 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLMGgx000836
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:22:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLMEgc000830
	for ; Thu, 28 Aug 2003 14:22:15 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SLMDS5005660
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 14:22:16 -0700
Message-ID: <3F4E7280.8010207@Royer.com>
Date: Thu, 28 Aug 2003 15:22:08 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080607050409080803040201"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms080607050409080803040201
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Satya Vempati wrote:
> We disagree. I do not believe the recurring set changes when a single
> instance gets rescheduled. The post from the original authors explicitly
> says so.

So what is the purpose of the iTIP message - to change nothing?

So please send a sequence of snipits from iTIP messages where
you can move (reschedule - or what ever you want to call it) one
instance from one date/time to another and NOT have the pattern change.

-- 

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

                 We Do Standards - You Need Standards

--------------ms080607050409080803040201
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIxMjIwOFowIwYJKoZIhvcNAQkEMRYEFPRtPH59
trwSn8Mj65MkNKne+HFPMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAKBE1X/CMaTGR5WXgDPtilRjS5CGsIdjxTRVfZ6tM0fDBMa+SVjP
hCOLWyihd8zVMcjPTmZtdfuGw//XYIzosb/0ItKiGWaX8yWBWHB+0CL/Yk7wvCyw1FA2r3mM
9UR06L2mn/9f1GQ6/EQzF7YH1fq6rDm5Xb+TBvwWaQEGe/tZKqeZV3v1VHFb8oLQH03ul/OD
ytZeg9TOGPNYuOTq4t55QB7KySsF2uRX8+jp/xPldLcOXyTS2mzPxJNkQqatjWeJuajidCng
fpcco6Mt4KSgtG2I5a/6fATW6t8tBtsYHeCgQGZVl8x9Jbxe1GZP50ZFDUR1RPSKKEZ0GiDW
GzkAAAAAAAA=
--------------ms080607050409080803040201--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:39: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 RAA21465
	for ; Thu, 28 Aug 2003 17:39:52 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLQ4gc001072
	for ; Thu, 28 Aug 2003 14:26:04 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLQ4qB001071
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:26:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLQ3gc001066
	for ; Thu, 28 Aug 2003 14:26:03 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SLQ3S5005742
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 14:26:04 -0700
Message-ID: <3F4E7365.30202@Royer.com>
Date: Thu, 28 Aug 2003 15:25:57 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060003050902030800050809"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms060003050902030800050809
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug fired back on 08/27/2003 07:07:22 PM:
>  > WRONG - If you change a MONDAY to a FRIDAY - please explain
>  > how the pattern has not been altered?
> 
> You are too fixated on the word "pattern" and thus are not seeing the 
> concept for the word (to paraphrase a bit).  You have totally ignored 
> the entire text of the response from Derik/Frank that expressly 
> describes the single instance reschedule.   Much like you had a 
> different defintion of the word "original" when reading iCalendar 
> Section 4.8.4.4 I'm guessing.

You are totally fixated on ignoring that words 'pattern' and 'changed'.
You ignore change in iTIP, iCAL, and now in Frank's and Derik's email.

Please send a sequence of iTIP updates that alter the date/time of
one or more instances that do not change the pattern (set).
The entire point of a iTIP instance reschedule is to change
the pattern. You could send an iTIP message that changes the
LOCATION and that does not change the pattern. Is that what
you mean?

-- 

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

                 We Do Standards - You Need Standards

--------------ms060003050902030800050809
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIxMjU1OFowIwYJKoZIhvcNAQkEMRYEFG4enCiR
JrF/BznyTdCO/1uNEzCBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAIkHBDKqGNRmI66U67my+cH4xBBps2aYNT2CAdZdiv1JjsBW9gy7
yItHtz06/lLcicwUrvra7zBXFXmXRFMtzaa9IC7A9l4tKja3+7OmZwS8LOAhKpD9Il1vi3yy
S+x81n8aq5hNUc+acKG60voWY27/ksAFeH6b7WCLttGd8UDE75LI1TkilUQhGgPGlyaHaBqm
KaoNAjC7rdCQIpxe4B0o591Nsegp5qoRFK3CxyyQbVI3OEAqcSZxALlESJq0ZW3uH4VFZ4mU
9m1YfNb5QqsiNlLAlBlAJ3FNz84g8eWf39Xqew0Xb2BcJ719mpfLb94pzZVzo9MOBANwfeCy
TpkAAAAAAAA=
--------------ms060003050902030800050809--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 17:54: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 RAA22295
	for ; Thu, 28 Aug 2003 17:54:09 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLcvgc001787
	for ; Thu, 28 Aug 2003 14:38:57 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLcv3K001786
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:38:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLcugc001780
	for ; Thu, 28 Aug 2003 14:38:56 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4E6E8C.3000208@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Thu, 28 Aug 2003 17:27:20 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 05:39:21 PM,
	Serialize complete at 08/28/2003 05:39:21 PM
Content-Type: multipart/alternative; boundary="=_alternative 0075703B85256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0075703B85256D90_=
Content-Type: text/plain; charset="US-ASCII"

I will admit I was wrong in that case.  Sorry
If you send a REQUEST with no RECURRENCE-ID than it applies to the entire 
set.
Thus changing the DTSTART does reset the pattern.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/28/2003 05:05 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug maintained on 08/27/2003 06:58:01 PM:
>  > If you change the DTSTART - *only*, as in:
>  >
>  >    SEQUENCE:X
>  >    DTSTART:...monday..
>  >    RRULE:FREQ=WEEKLY
>  >
>  > To:
>  >
>  >    SEQUENCE:X+Y
>  >    DTSTART:...tuesday...
>  >    RRULE:FREQ=WEEKLY.
>  >
>  > The instances and RECURRECE-ID's change.
>  > So DTSTART *is* included even when; RRULE,
>  > RDATE, EXDATE, and EXRULE do not change.
> 
> This is NOT rescheduling an instance; its recreating the set! 

Which was my point as Robert said that 'DTSTART' was not
in the set that effected the RECURRENCE-ID changing when he
replied to my example and he said:

     "No I do not.

      I do mean
                 RDATE
                 RRULE
                 EXDATE
                 EXRULE

     DTSTART is not part of RULE"

In responce to my email that said that moving the DTSTART effects
the pattern. And it does change the RECURRENCE-IDs. I said
noting about single instance update. And the example he responded
to was a full replacement showing that the RECURRECE-IDs change
when the pattern changes on a full replacement.


_____________________

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 0075703B85256D90_=
Content-Type: text/html; charset="US-ASCII"



I will admit I was wrong in that case.
 Sorry

If you send a REQUEST with no RECURRENCE-ID
than it applies to the entire set.

Thus changing the DTSTART does reset
the pattern.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/28/2003 05:05 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Bruce_Kahn@notesdev.ibm.com wrote:

> 

> Doug maintained on 08/27/2003 06:58:01 PM:

>  > If you change the DTSTART - *only*, as in:

>  >

>  >    SEQUENCE:X

>  >    DTSTART:...monday..

>  >    RRULE:FREQ=WEEKLY

>  >

>  > To:

>  >

>  >    SEQUENCE:X+Y

>  >    DTSTART:...tuesday...

>  >    RRULE:FREQ=WEEKLY.

>  >

>  > The instances and RECURRECE-ID's change.

>  > So DTSTART *is* included even when; RRULE,

>  > RDATE, EXDATE, and EXRULE do not change.

> 

> This is NOT rescheduling an instance; its recreating the set! 



Which was my point as Robert said that 'DTSTART' was not

in the set that effected the RECURRENCE-ID changing when he

replied to my example and he said:



     "No I do not.



      I do mean

                 RDATE

                 RRULE

                 EXDATE

                 EXRULE



     DTSTART is not part of RULE"



In responce to my email that said that moving the DTSTART effects

the pattern. And it does change the RECURRENCE-IDs. I said

noting about single instance update. And the example he responded

to was a full replacement showing that the RECURRECE-IDs change

when the pattern changes on a full replacement.





_____________________



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 0075703B85256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:09: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 SAA23817
	for ; Thu, 28 Aug 2003 18:09:41 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLsDgc002444
	for ; Thu, 28 Aug 2003 14:54:13 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLsDeb002443
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:54:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLsBgc002437
	for ; Thu, 28 Aug 2003 14:54:12 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SLsAS5006097
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 14:54:13 -0700
Message-ID: <3F4E79FD.7080907@Royer.com>
Date: Thu, 28 Aug 2003 15:54:05 -0600
From: Doug Royer 
Reply-To: "'ietf-calendar@imc.org'" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'ietf-calendar@imc.org'" 
Subject: Resolving the RECURRENE-ID issue. (was Does anyone...)
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080704040605040109060203"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms080704040605040109060203
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Thanks Joerg.

I feel that a definition needs to be worked out that can
ether overlap or overhaul the idea so that everyone's code
can work or minimum changes.

I think another source of confusion is the 'I want' vs. 'it is'.

'I want' may be achievable, but without knowing if the
sender thinks it is a 'want or 'it is', it makes
communication a bit heated.

I am slowly compiling a list of opinions when technical
content is included. I do feel that we can develop an
iTIP-next or an iTIP-add-on draft that will solve the problems.

I also have noted that the 'fixed and never changes' camp
moved to 'fixed and changes under some circumstances'. Or perhaps
they have thought that is what they were saying from day one.

This has been a heated and debated point for years as Frank
and Derik pointed out in their email. I do feel that I do
not fully understand the other model or their confusion. And I
do not think they understand the non-fixed model. Assertions seem
to be 'that will not work', when in fact they are saying 'I do not
know how to make that work'. That may be true for me also, but
I know of no other way than to keep pinging each point until
it is fully explained.

I also feel that many seem to project their implementation details
into the wire protocol and view iCAL objects as a complete state
of the object and not a interoperability protocol to transfer information.
For example the recent assertions that we resolve the 'master' copy
of object issues makes me think the sender is equating
the wire objects with the stored objects. Or perhaps they are asking
"how to you make it work?". I am not sure yet.

Another very important point - heated debates ARE part of the
process. The only time that I take it personally is when
personal remarks are thrown into the debate. They are not
needed.

I have the highest respect for those that I have meet at
the IETF meetings - all of them. If you can not participate
in a debate and keep from throwing personal insults into
the debate - then I tend to think that you are admitting
that you do not have a clue how to communicate.
For example I consider Bruce a friend - we are both capable
of strongly disagreeing and still send each other jokes
on the side from time to time.

Joerg Reichelt wrote:
> It appears that it would have been much easier - and a lot less 
> controversial - to define the recurrence ID as an index into the 
> set of instances.
> 
> Looking at it this way, it would be clear to most of us that
> - this index DOES NOT change for simple changes to that instance
>   it refers to
> - this index DOES change when the instances of a set need to be 
>   re-indexed, e.g. when the definition of what instances belong 
>   to the set changes; when this happens, and you want to keep
>   modifications to individual instances of the set, you need to
>   update the index in each of the descriptions of the instance
>   modifications (e.g. change that index to the new index of the
>   modified instance)
> 
> Since the recurrence ID is currently defined to be constructed of 
> the start date and time of the instance, it appears to imply that 
> it always would be equivalent to that value, which seems to be the 
> source of the disagreement. The argument is revolving around the 
> question whether the recurrence ID should be the original or the 
> current value for a given instance (and conflicting references to
> RFC paragraphs about what is correct have been presented, and both
> alternatives have been extensively discussed).
> 
> It appears to me that it would be easier to work with a constant 
> reference as much as possible than with one that changes all the 
> time, but that is just my personal opinion on this topic.
> 
> My 2 cents.
> 
> - Joerg

-- 

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

                 We Do Standards - You Need Standards

--------------ms080704040605040109060203
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIxNTQwNVowIwYJKoZIhvcNAQkEMRYEFKNKkqV5
vULGdKr4WCs4zs1PEWJTMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAALO56ygpetS69VWdc5l0U3LDrZr2QGkx3b9R4wWxvzpYQ3e4xbg
uKaFp9eX+Pmb15x4IN/DPbmg5J8SJGdjp/R8JWEIF/37Ypa8ljAWSjGtTDU5TDbc1bcGhTaZ
r75rKXOI9BL3BsHilnjo0E4U578rsiYlqUMBIsm+sIgaUdZCdziG99Unu9S5a7IzFQI0Gv68
XTCxvDCKm47O1jId6U9htpkH5eChKQnGD8reNBBOfqcbbf1BbmsMC3DYtf3C3EBa95RaaQwc
id0vXzLK6daq6iEZ2u+tflpdCXYuMGwEgQ5rDhs7n/fOMk6hAtEAnK/xRD3QDQhllze1fEpB
d7YAAAAAAAA=
--------------ms080704040605040109060203--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:09: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 SAA23871
	for ; Thu, 28 Aug 2003 18:09:55 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLwLgc002600
	for ; Thu, 28 Aug 2003 14:58:21 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLwLIR002599
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:58:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLwKgc002594
	for ; Thu, 28 Aug 2003 14:58:20 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SLwKS5006146
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 14:58:21 -0700
Message-ID: <3F4E7AF7.7000007@Royer.com>
Date: Thu, 28 Aug 2003 15:58:15 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000501060005080101000402"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms000501060005080101000402
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> That's is BOGUS Doug.

I'll place that on the list of points that one day will help
resolve the issue. But first could you explain your point
as it relates to CALSCH or resolving this debate?


-- 

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

                 We Do Standards - You Need Standards

--------------ms000501060005080101000402
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIxNTgxNVowIwYJKoZIhvcNAQkEMRYEFN8wKQyI
NWx0CBjGm9fWt7ik+cuyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAFJdY60IGLTLc1aBJDeDVa9vKXMtbVu0yU05haT+5Tzz4Gwk3jgq
PkVnvUvLkac5ipL+MlDb7UVDyxg2cm+VmKRrAwibS7eGC80PlVCd6Mh5zaAhbEgwc9pUQp/L
C8ao+QRVek50qCKufy0/Uvd297zfiASPeEstQwjISlj2Bo8ySiLWPjLDXmbRsF1oqDPkLYSD
wRlxYQjUSuve+XpIYpLqwgoACDa2ggo6CNiImiFDErqgH2RD4Yev3wjdeqT5MSS/3jV9lSPT
ZBBG6+NP7HVxWeAVtb7CwL4xNdKgtnfsv9904bpUpGB+PHZahgmcALSQbhTns0e3wwz1Cd3n
3E0AAAAAAAA=
--------------ms000501060005080101000402--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:10: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 SAA23893
	for ; Thu, 28 Aug 2003 18:09:59 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLw5gc002589
	for ; Thu, 28 Aug 2003 14:58:05 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SLw5lg002588
	for ietf-calendar-bks; Thu, 28 Aug 2003 14:58:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SLw4gc002583
	for ; Thu, 28 Aug 2003 14:58:04 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SLw4S5006141
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 14:58:05 -0700
Message-ID: <3F4E7AE6.7030509@Royer.com>
Date: Thu, 28 Aug 2003 15:57:58 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060605070808070105070003"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms060605070808070105070003
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> That's is BOGUS Doug.

I'll place that on the list of points that one day will help
resolve the issue. But first could you explain your point
as it relates to CALSCH or resolvint this debate?


-- 

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

                 We Do Standards - You Need Standards

--------------ms060605070808070105070003
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIxNTc1OFowIwYJKoZIhvcNAQkEMRYEFBkEENdv
nbUxFj5fNCpjlzZ7eg7lMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAE+a3B8N1u8Lk3UeBFG1+sk85IMGhfCMyTb9kwePdEvv6NwfseqU
YbgHhjAQnTpDqCSHFLKDHikqQicMjss8ncIkMe2Ns7r44w+E8fiF1rRaa53VSyG+a+X4pTuy
pEktIa7DO2O5lYppcd4wobr96iaZZVMbPK/AmreCnKC2CpDswOZl7mw2tRbcgwG0jyUHKz26
kV6f40DJTpiaclW3XYtHXN8U9Pyb/QabrcEMRMrsFxYPnBKt2r3f2mK9cbh6d3z0zscdBHMh
WnIMLbh6DTJzq0UetGn1iSDB3SZnfFX2edNQ7ui5aneeWX0kcDvy9LFuevx7xdXI4wdKwRLC
JKcAAAAAAAA=
--------------ms060605070808070105070003--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:18: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 SAA25037
	for ; Thu, 28 Aug 2003 18:18:22 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SM4Sgc002769
	for ; Thu, 28 Aug 2003 15:04:28 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SM4SKH002768
	for ietf-calendar-bks; Thu, 28 Aug 2003 15:04:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SM4Qgc002763
	for ; Thu, 28 Aug 2003 15:04:26 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SM4PS5006240
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 15:04:28 -0700
Message-ID: <3F4E7C64.6020908@Royer.com>
Date: Thu, 28 Aug 2003 16:04:20 -0600
From: Doug Royer 
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080703080703010200040709"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms080703080703010200040709
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> In any case, the intent is not germane to Dougs contention that RECURRENCE-IDs
 > change on an instance reschedule.
> 
> I agree.  By now it should be clear(er) that the iCalendar model is a 
> fixed RECURRENCE-ID model.  Lets get on to other more pressing tasks 
> before the ADs pull the plug on the WG.

I have noted that in your recent responses you fail to explain
how to change an instance without changing the pattern. Perhaps
that will clear it up. If sequence:0 has dates/times

	A
	B
	C

and SEQUENCE:1 has

	A
	B
	D

How is not not a change to the pattern?

And by the way, my email was not about 'single instance' updates.
It was about the fact that RECURENCE-IDs are not fixed forever.


-- 

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

                 We Do Standards - You Need Standards

--------------ms080703080703010200040709
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIyMDQyMFowIwYJKoZIhvcNAQkEMRYEFJunQi9C
Q5iHHBe5jIRbN73PG0ovMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAFx9pxWCJ+th/KdZly8XdsUuTIlnjiyGCxL5T+EF7ZwDZdEh+qgC
bp/+Ka7WJPBaC/a+V4U4ixL9vqbqtOs5r5xTrHR3aajmzO/n45qaXaGYGJQVr7CIaVPHkM9O
+MGAlS7mY3bhtFbtf4w+1d0tpLS2NEygsHFLE2dmWgD7mlF1oI+rIYqn1f00e3IF9rXkp+uX
/R8deT0eOQGGbhEhXoXbSCO1LQfBIl26jGVp8KK6w1uwvqtjwR05HD8gq68NoOy9HWShvcKz
L/EoRUhxywO47YJzTJlQGviNa2kSkhaeMES4ivpcddj7H9dU6qzWHRwzpmaDu1lWdD8zcTmS
5YwAAAAAAAA=
--------------ms080703080703010200040709--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:27: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 SAA25845
	for ; Thu, 28 Aug 2003 18:27:27 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SM9lgc002970
	for ; Thu, 28 Aug 2003 15:09:47 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SM9lnk002969
	for ietf-calendar-bks; Thu, 28 Aug 2003 15:09:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SM9igc002963
	for ; Thu, 28 Aug 2003 15:09:45 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sUyL-0006rK-00
	for ; Fri, 29 Aug 2003 00:10:29 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19sUyJ-0006rC-00
	for ; Fri, 29 Aug 2003 00:10:27 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sUxb-0002rK-00
	for ; Fri, 29 Aug 2003 00:09:43 +0200
From: "Michael Fair" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Thu, 28 Aug 2003 15:09:42 -0700
Lines: 74
Message-ID: 
References: 
X-Complaints-To: usenet@sea.gmane.org
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


Thanks for the input.
We've been hashing this out with Doug for about 8 weeks now.

If you go through the archives over the past 2 months
almost every message has been on this topic.

Your arguments are very reasonable, and unfortunately
reason has not been very useful here.  Doug clings to
his ideas like they were his saving grace and ignores
any issues raised against his idealogy that he can't
disprove.  He also twists it said to mean what he wants
it to mean rather than the its intent and focuses on
stupid irrelevant arguments without addressing the
core issues.

Your "2 cents gut feel" is actually very demonstratable
to be the only sane way and there have been megabytes
of posts to this list cementing how not doing it the
"fixed-id" way is extremely fragile.

At the moment Doug Royer is the only proponent of his
model and he has placed me on his ignore list because
I demanded he prove his model didn't break.

If you do want to participate, your best bet is to talk to
Doug directly, the rest of us already agree on what we're
saying though we say it in very different ways sometimes.

8 weeks and probably some 300 messages is an eye opening
eperience in how rigomortized some people can be.  We
even sought the opinion of the original authors who
unfortunately didn't do a crystal clear enough job to
convince Doug that he's still mistaken.

-- Michael --


"Joerg Reichelt"  wrote in message
news:CA8D7A11C649284AA163D951DA56533001305477@srv-mailsjc2...
>
> It appears that it would have been much easier - and a lot less
> controversial - to define the recurrence ID as an index into the
> set of instances.
>
> Looking at it this way, it would be clear to most of us that
> - this index DOES NOT change for simple changes to that instance
>   it refers to
> - this index DOES change when the instances of a set need to be
>   re-indexed, e.g. when the definition of what instances belong
>   to the set changes; when this happens, and you want to keep
>   modifications to individual instances of the set, you need to
>   update the index in each of the descriptions of the instance
>   modifications (e.g. change that index to the new index of the
>   modified instance)
>
> Since the recurrence ID is currently defined to be constructed of
> the start date and time of the instance, it appears to imply that
> it always would be equivalent to that value, which seems to be the
> source of the disagreement. The argument is revolving around the
> question whether the recurrence ID should be the original or the
> current value for a given instance (and conflicting references to
> RFC paragraphs about what is correct have been presented, and both
> alternatives have been extensively discussed).
>
> It appears to me that it would be easier to work with a constant
> reference as much as possible than with one that changes all the
> time, but that is just my personal opinion on this topic.
>
> My 2 cents.
>
> - Joerg
>





From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:27: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 SAA25847
	for ; Thu, 28 Aug 2003 18:27:27 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SM9Qgc002941
	for ; Thu, 28 Aug 2003 15:09:26 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SM9QqU002940
	for ietf-calendar-bks; Thu, 28 Aug 2003 15:09:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SM9Pgc002929
	for ; Thu, 28 Aug 2003 15:09:25 -0700 (PDT)
	(envelope-from Bruce_Kahn@notesdev.ibm.com)
In-Reply-To: <5.2.1.1.0.20030827204809.00a0d510@mail.comcast.net>
To: Tim Hare 
Cc: ietf-calendar@imc.org
Subject: Re: 
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_07142003NP July 14, 2003
Message-ID: 
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 28 Aug 2003 17:49:17 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 06:09:49 PM,
	Serialize complete at 08/28/2003 06:09:49 PM
Content-Type: multipart/alternative; boundary="=_alternative 0077D15485256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 0077D15485256D90_=
Content-Type: text/plain; charset="US-ASCII"

Tim wrote on 08/27/2003 09:08:31 PM:
> Would someone please send me (or post) where in this discussion we've 
> discussed the following paragraph from 3.7.1 in iTIP? 

I believe that Satya recently posted a summary of that thread already. You 
can also check the official archives and search for the subject "
Recurrence ID changes?" dated 07/21/99 01:26:47 PM by Dan Hickman.

As has been previously noted and confirmed by the recent posting by 
Derik/Frank there are some known errors in iTIP and thats one of them. 

>                                                    but the last sentence 

> definitely says that RECURRENCE-ID changes, and the wording and order is 

> such that it implies that this happens for an instance change.

This last sentence is the only text in iCalendar or iTIP that says 
RECURRENCE-ID changes.  Its contrary to the text immediately above it, to 
the text in iCalendar and to all the logic in elsewhere in iTIP describing 
workflow sequencing and recovery.

It should be noted that iTIPs role is not to define (or redefine in this 
case) the behaviour of iCalendar properties; its job is to provide 
semantics to the properties.  iCalendar is the RFC that defines properties 
and their behaviour so it should be considered the definitive source for 
RECURRENCE-ID and its behaviour.

> I also would like to know, if the RECURRENCE-ID _is_ fixed, then why 
wasn't 
> an arbitrary sequence number used for RECURRENCE-ID rather than the 
> date-oriented one (in my view the enumeration method of identifying 
> recurrence instances would have eliminated a lot of semantic confusion 
in 
> our discussions!)?

We chose to use a date/time value for the RECURRENCE-ID instead of a 
different enmerated data type like an integer or something else because:

A) we already had a frame of reference when discussing instances and that 
was the date/time of the instance ("The second Monday instance got moved 
to the next Tuesday at 3PM", etc) 
B) it seemed the most logical data type to choose because its a useful 
part of the instance that can be reused (ie: When you create the instances 
in the set, you can calculate the RECURRENCE-ID value w/o the Organzier 
having to send them all plus you can use that when putting the entries on 
the calendar) and 
C) since we had the ability to have infinite repeating set (joy oh joy!) 
there was NO way for both the Organzier to send the RECURRENCE-ID values; 
each recipient had to be able to correctly generate them to match the same 
values the Organzier has/uses.

The reason we opt'd for a fixed design was because of sequencing issue and 
the poor performance of iTIP in those situations.  Its all in the side by 
side analysis I posted a couple weeks ago in response to your first 
posting.

> Notice, I'm not arguing right or wrong here, I'm trying to understand 
what 
> iCal says about these as objects versus what the communication protocols 

> say about it.

I did not see any followup from Tim regaring my analysis of both the delta 
and fixed RECURRENCE-ID models nor do I see any in the archive.  I am 
interested to know if you saw them and any response or thoughts you have 
in response to 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 0077D15485256D90_=
Content-Type: text/html; charset="US-ASCII"



Tim wrote on 08/27/2003 09:08:31 PM:

> Would someone please send me (or post) where in this discussion we've


> discussed the following paragraph from 3.7.1 in iTIP? 



I believe that Satya recently posted
a summary of that thread already.  You can also check the official
archives and search for the subject "Recurrence ID changes?"
dated 07/21/99 01:26:47 PM by Dan Hickman.



As has been previously noted and confirmed
by the recent posting by Derik/Frank there are some known errors in iTIP
and thats one of them.  



>              
                     
               but the last sentence


> definitely says that RECURRENCE-ID changes, and the wording and order
is 

> such that it implies that this happens for an instance change.



This last sentence is the only text
in iCalendar or iTIP that says RECURRENCE-ID changes.  Its contrary
to the text immediately above it, to the text in iCalendar and to all the
logic in elsewhere in iTIP describing workflow sequencing and recovery.



It should be noted that iTIPs role is
not to define (or redefine in this case) the behaviour of iCalendar properties;
its job is to provide semantics to the properties.  iCalendar is the
RFC that defines properties and their behaviour so it should be considered
the definitive source for RECURRENCE-ID and its behaviour.



> I also would like to know, if the RECURRENCE-ID
_is_ fixed, then why wasn't 

> an arbitrary sequence number used for RECURRENCE-ID rather than the


> date-oriented one (in my view the enumeration method of identifying


> recurrence instances would have eliminated a lot of semantic confusion
in 

> our discussions!)?



We chose to use a date/time value for
the RECURRENCE-ID instead of a different enmerated data type like an integer
or something else because:



A) we already had a frame of reference
when discussing instances and that was the date/time of the instance ("The
second Monday instance got moved to the next Tuesday at 3PM", etc)


B) it seemed the most logical data type
to choose because its a useful part of the instance that can be reused
(ie: When you create the instances in the set, you can calculate the RECURRENCE-ID
value w/o the Organzier having to send them all plus you can use that when
putting the entries on the calendar) and 

C) since we had the ability to have
infinite repeating set (joy oh joy!) there was NO way for both the Organzier
to send the RECURRENCE-ID values; each recipient had to be able to correctly
generate them to match the same values the Organzier has/uses.



The reason we opt'd for a fixed design
was because of sequencing issue and the poor performance of iTIP in those
situations.  Its all in the side by side analysis I posted a couple
weeks ago in response to your first posting.



> Notice, I'm not arguing right or wrong here,
I'm trying to understand what 

> iCal says about these as objects versus what the communication protocols


> say about it.



I did not see any followup from Tim
regaring my analysis of both the delta and fixed RECURRENCE-ID models nor
do I see any in the archive.  I am interested to know if you saw them
and any response or thoughts you have in response to 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 0077D15485256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:35: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 SAA26299
	for ; Thu, 28 Aug 2003 18:35:41 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SMN9gc003581
	for ; Thu, 28 Aug 2003 15:23:09 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SMN9nZ003580
	for ietf-calendar-bks; Thu, 28 Aug 2003 15:23:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SMN7gc003575
	for ; Thu, 28 Aug 2003 15:23:08 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sVBK-0006y8-00
	for ; Fri, 29 Aug 2003 00:23:54 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19sVBI-0006xy-00
	for ; Fri, 29 Aug 2003 00:23:52 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sVAa-00047j-00
	for ; Fri, 29 Aug 2003 00:23:08 +0200
From: "Michael Fair" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
Date: Thu, 28 Aug 2003 15:23:07 -0700
Lines: 48
Message-ID: 
References:  <3F4E6CF1.2050400@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: 



Would someone please reply to this post so that Doug will
actually see it.  I think we've explained it enough that
he's finally ready to listen to what we've been saying all along.

> They did however say that it remains fixed as long as the pattern does
> not change. Please explain how to move a Monday meeting to Tuesday
> without changing the pattern.

Here goes:
I define the set of recurring Mondays at SEQ:0
I move one of those Mondays to start on Tuesday at SEQ:1.
That instance, and only that instance are at SEQUENCE 1.

If I was to do a "REFRESH" on the UID I would get back
to VEVENT objects in the same REQUEST.

The first event component says:

SEQ:0
RRULE: Every Monday

The second says:

SEQ:1
RID: Some Monday
DTSTART Some Tuesday


The "set" of every Monday is still intact and has not been changed.
It just so happens that the instance created by "Some Monday" now
starts at "Some Tuesday".

I'll repeat:
The recurrence set still describes every Monday.
The recurrence set is still defined by SEQUENCE:0
The instance of "Some Monday" starts "Some Tuesday" and is
defined by SEQUENCE:1 of RID:"Some Monday".

Again, the repeat set defined by SEQUENCE:0 has not changed.
The only thing that has changed is that one of the instances
calculated by the repeat set actually starts on on a Tuesday.
It is important to note that the RECURRENCE-ID and DTSTART
for that instance DO NOT MATCH.

-- Michael --





From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:35: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 SAA26319
	for ; Thu, 28 Aug 2003 18:35:43 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SMMkgc003552
	for ; Thu, 28 Aug 2003 15:22:46 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SMMkcI003551
	for ietf-calendar-bks; Thu, 28 Aug 2003 15:22:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SMMjgc003545
	for ; Thu, 28 Aug 2003 15:22:45 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SMMjS5006486
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 15:22:46 -0700
Message-ID: <3F4E80AF.4060004@Royer.com>
Date: Thu, 28 Aug 2003 16:22:39 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070703070203000605060003"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms070703070203000605060003
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> I will admit I was wrong in that case.  Sorry
> If you send a REQUEST with no RECURRENCE-ID than it applies to the 
> entire set.
> Thus changing the DTSTART does reset the pattern.

Okay - my quesitons now are:

  When does the pattern NOT change on a reschedule as seen
  by the ATTENDEE?

  When does the pattern NOT change on a reschedule as seen
  by the ORGANIZER?


And I do not care  if it is a single or full update example(s).


-- 

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

                 We Do Standards - You Need Standards

--------------ms070703070203000605060003
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIyMjIzOVowIwYJKoZIhvcNAQkEMRYEFCo8W/uR
nXAivyPDDmt1AuT7dNIYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBADqYzU5qWbpdLhU8WuTh1uFlBU0t7/oz1qY2K/aHiPCATYTZVRCx
BlmMhxA6HW8uz4cidzBDFggOqb58VYXKoRECDoW5ZByJMBRL8Ti+aSTUK14sYtZklVkMAPoy
uocwrmGdmvU6YxQ55hIoNY23Vc/jEEC9zJHh8xSfbZ64oVE/gjGTe82L0uOVIC/0uWE8KZQP
KFwYeBkssm8WQ697omrFkJU6PTHPUnyXHPHBWB+rY/OfSh489pQZKdvZUSlX92gtDxNzuPbt
BVa5CzzrBTKtLuSFAzwTLq0XH6K+7Sq2vgX+BOdVlsdYcAYw8F3Bvln94OlM22WVGo64Dlv5
cvQAAAAAAAA=
--------------ms070703070203000605060003--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:55:13 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27595
	for ; Thu, 28 Aug 2003 18:55:12 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SMdbgc004187
	for ; Thu, 28 Aug 2003 15:39:37 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SMdb9e004186
	for ietf-calendar-bks; Thu, 28 Aug 2003 15:39:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SMdagc004181
	for ; Thu, 28 Aug 2003 15:39:36 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F4E7AF7.7000007@Royer.com>
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Thu, 28 Aug 2003 18:19:40 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/28/2003
 06:39:59 PM,
	Serialize complete at 08/28/2003 06:39:59 PM
Content-Type: multipart/alternative; boundary="=_alternative 007A3AF385256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 007A3AF385256D90_=
Content-Type: text/plain; charset="US-ASCII"

I sent the supporting  text.. You ignored it.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com



Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/28/2003 05:58 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?








Robert_Ransdell@notesdev.ibm.com wrote:
> 
> That's is BOGUS Doug.

I'll place that on the list of points that one day will help
resolve the issue. But first could you explain your point
as it relates to CALSCH or resolving this debate?


-- 

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

                 We Do Standards - You Need Standards


--=_alternative 007A3AF385256D90_=
Content-Type: text/html; charset="US-ASCII"



I sent the supporting  text.. You
ignored it.

_____________________

Note: new email address



tom_ransdell@notesdev.ibm.com










Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/28/2003 05:58 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: Does anyone still think
that RECURRENCE-ID's do NOT change?





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

> That's is BOGUS Doug.



I'll place that on the list of points that one day will help

resolve the issue. But first could you explain your point

as it relates to CALSCH or resolving this debate?





-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 007A3AF385256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 18:57: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 SAA27744
	for ; Thu, 28 Aug 2003 18:57:04 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SMekgc004219
	for ; Thu, 28 Aug 2003 15:40:46 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SMek3X004218
	for ietf-calendar-bks; Thu, 28 Aug 2003 15:40:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SMeigc004213
	for ; Thu, 28 Aug 2003 15:40:45 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SMehS5006665
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 15:40:46 -0700
Message-ID: <3F4E84E5.5090207@Royer.com>
Date: Thu, 28 Aug 2003 16:40:37 -0600
From: Doug Royer 
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: 
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010506080807030801000008"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms010506080807030801000008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Tim wrote on 08/27/2003 09:08:31 PM:
>  > Would someone please send me (or post) where in this discussion we've
>  > discussed the following paragraph from 3.7.1 in iTIP?
> 
> I believe that Satya recently posted a summary of that thread already. 
>  You can also check the official archives and search for the subject 
> "Recurrence ID changes?" dated 07/21/99 01:26:47 PM by Dan Hickman.
> 
> As has been previously noted and confirmed by the recent posting by 
> Derik/Frank there are some known errors in iTIP and thats one of them.  
> 
>  >                                                    but the last sentence
>  > definitely says that RECURRENCE-ID changes, and the wording and order is
>  > such that it implies that this happens for an instance change.
> 
> This last sentence is the only text in iCalendar or iTIP that says 
> RECURRENCE-ID changes.  Its contrary to the text immediately above it, 
> to the text in iCalendar and to all the logic in elsewhere in iTIP 
> describing workflow sequencing and recovery.

So do you also claim that Derik's and Frank's recient post also
is in error when it says they change? Where they in error again?


-- 

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

                 We Do Standards - You Need Standards

--------------ms010506080807030801000008
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIyNDAzN1owIwYJKoZIhvcNAQkEMRYEFASBQO8l
tPaBFhb4tgc1NGetH0pjMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAHbh+PZZ7ZJW3gNqHyF/n/nygRoZsLwYtJ1Roq5eBB7suAsGtlkq
b6xybyFX6a+HrqQdwKJV74M1D6ny4R/5L9bUzwOW4Y1328+cawoYXmSdkLJfTqn1cSZreJWE
qK/DO8iWW5grdYMV7lON2tRN3ASegaULhO7ANQNcJuVd+l3b5gyhtrfgCahreFbzzDo7Hgu6
3jztP8AbgXReEtdN3/SttWJ1HfxbPvJpumuSuPUeWC90APLd+gKhVdlmMmHrsCE1FmeeAEqP
vhDa1pwBYzUAHCMQ54hXHURYPMPt4qUP5hG73SpOcecM2BTsi5LPMohdkEmoRxphSCjRdgax
td4AAAAAAAA=
--------------ms010506080807030801000008--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 19:26: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 TAA29504
	for ; Thu, 28 Aug 2003 19:26:16 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SN92gc005509
	for ; Thu, 28 Aug 2003 16:09:02 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SN92Ai005508
	for ietf-calendar-bks; Thu, 28 Aug 2003 16:09:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SN90gc005503
	for ; Thu, 28 Aug 2003 16:09:01 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7SN90S5006995
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 16:09:02 -0700
Message-ID: <3F4E8B86.7050005@Royer.com>
Date: Thu, 28 Aug 2003 17:08:54 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020502010309030504090409"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms020502010309030504090409
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> I sent the supporting  text.. You ignored it.

Please explain how posting the word BOGUS helps anything.

And I am still waiting to see examples of how to
reschedule one or more instances and not change
the recurrence pattern (set).

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

                 We Do Standards - You Need Standards

--------------ms020502010309030504090409
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyODIzMDg1NVowIwYJKoZIhvcNAQkEMRYEFNIyxeqC
3XJcHHnRTryK/glLuehZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBADqBGDlxKMQMK1EirDVk6SoOLVC6reHnpbeApBTpWOugYFMzNypP
TBOlLrrma6h3DVNo5cjxXel1K5AYMgUl+q4RSCFG730Ay2Rvc9d/u2SN/KXkymujskGVFYHv
j2MlC/bTVT0adOMSx/raoLmHSXQnlkL5m1g5JO1+4WAMpyv9tavR4N0KbM3w3ieTF6QQ5ffa
zQtlCke1yqH4i6dql+VQhGa3cd0JJrn2+TmTBHcCiXTrX0Vr6+Xad8VI3UukJC9eS3r0mon6
39dXSK/rp3j6aniMpdDO4w7yauMDxaxKc2ImKlx+hyWCEZlHkZwJz+idn31aN8wDec+aOrup
OHUAAAAAAAA=
--------------ms020502010309030504090409--



From owner-ietf-calendar@mail.imc.org  Thu Aug 28 20:05:42 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02233
	for ; Thu, 28 Aug 2003 20:05:41 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SNpxgc006830
	for ; Thu, 28 Aug 2003 16:51:59 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7SNpxA1006829
	for ietf-calendar-bks; Thu, 28 Aug 2003 16:51:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SNpvgc006818
	for ; Thu, 28 Aug 2003 16:51:58 -0700 (PDT)
	(envelope-from pregen@egenconsulting.com)
To: "Michael Fair" 
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.12   February 13, 2003
Message-ID: 
From: pregen@egenconsulting.com
Date: Thu, 28 Aug 2003 19:51:59 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.2CF2|July 23, 2003) at
 08/28/2003 07:52:00 PM,
	Serialize complete at 08/28/2003 07:52:00 PM
Content-Type: multipart/alternative; boundary="=_alternative 00831A8E85256D90_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 00831A8E85256D90_=
Content-Type: text/plain; charset="us-ascii"

Ok, I've sat back and watched, with interest, my inbasket fill up and 
people come out of the woodwork to present their 
thoughts on this issue.  And, I seem to see it moving pretty strongly in a 
specific direction.  What I'm going to do over the 
Labor day weekend is go back over all the comments - yes, all of them. I'm 
going to put them into some semblance of order 
either in a spreadsheet or simply with tick marks on paper.  Then, I'm 
going to come up with what I see is the overall, final, opinion of the 
group 
on this issue.  I believe we have concensus.  I just want to make sure 
what I put on the list is as correct as it can be based on some 
of the epic-length notes that have been on this list.  When I put on the 
list what I and Bob feel is the final decision - that is what it will 
be and that is what we will work to fix or let be, depending on the final 
decision., 

I know we have two people who are set firmly in their respective corners. 
But the rest of us of have sort of come to a conclusion, 
and have heard from the original authors, and that's what I am going to 
confirm, quietly, in a nice comfey chair, after killing a tree printing 
out all the notes.   

So, we will have an answer next week and that will be the final decision. 
Hopefully EVERYONE will agree on the final ruling 
and we can move forward again.  Thanks for your support and it's nice to 
see some new names out there!

--=_alternative 00831A8E85256D90_=
Content-Type: text/html; charset="us-ascii"





Ok, I've sat back and watched, with interest, my inbasket fill up and people come out of the woodwork to present their 

thoughts on this issue.  And, I seem to see it moving pretty strongly in a specific direction.  What I'm going to do over the 

Labor day weekend is go back over all the comments - yes, all of them.  I'm going to put them into some semblance of order 

either in a spreadsheet or simply with tick marks on paper.  Then, I'm going to come up with what I see is the overall, final, opinion of the group 

on this issue.  I believe we have concensus.  I just want to make sure what I put on the list is as correct as it can be based on some 

of the epic-length notes that have been on this list.  When I put on the list what I and Bob feel is the final decision - that is what it will 

be and that is what we will work to fix or let be, depending on the final decision., 



I know we have two people who are set firmly in their respective corners.  But the rest of us of have sort of come to a conclusion, 

and have heard from the original authors, and that's what I am going to confirm, quietly, in a nice comfey chair, after killing a tree printing 

out all the notes.   



So, we will have an answer next week and that will be the final decision.  Hopefully EVERYONE will agree on the final ruling 

and we can move forward again.  Thanks for your support and it's nice to see some new names out there!


--=_alternative 00831A8E85256D90_=--


From owner-ietf-calendar@mail.imc.org  Thu Aug 28 22:36:24 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14039
	for ; Thu, 28 Aug 2003 22:36:23 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7T25pgc011241
	for ; Thu, 28 Aug 2003 19:05:51 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7T25onb011240
	for ietf-calendar-bks; Thu, 28 Aug 2003 19:05:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7T25mgc011235
	for ; Thu, 28 Aug 2003 19:05:48 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7T25mS5008614
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Thu, 28 Aug 2003 19:05:49 -0700
Message-ID: <3F4EB4F7.10508@Royer.com>
Date: Thu, 28 Aug 2003 20:05:43 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010708070906010100090304"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms010708070906010100090304
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:

> 
> The _only_ place where a repeating rule is really necessary is for the 
> infinite case.  For a non-infinite set, the RRULE only saves some octets 
> in the iTIP message compared to sending RDATEs.  So, for large repeating 
> sets using a recurrence rule is an easy way to save space in the 
> iCalendar stream sent.   So the fragment:
> 
>      DTSTART:20030902T140000Z
>     RRULE:FREQ=DAILY;COUNT=10
> 
> is an alternative to this fragment:
> 
>     DTSTART:20030902T140000Z
>     RDATE:20030903T140000Z
>     RDATE:20030904T140000Z
>     RDATE:20030905T140000Z
>     RDATE:20030906T140000Z
>     RDATE:20030907T140000Z
>     RDATE:20030908T140000Z
>     RDATE:20030909T140000Z
>     RDATE:20030910T140000Z
>     RDATE:20030911T140000Z
> 
> It should be clear that once you reschedule a single instance then the 
> use of a recurrence rule becomes MUCH harder if not impossible (at least 
> solely).  For example, if I reschedule the 6th instance to a different 
> time then you cannot expect the RRULE:FREQ=DAILY;COUNT=10 to still be 
> usable when adding any new invitees!  You have a few possible ways of 
> sending this new set to a new invitee but using just a single RRULE is 
> NOT possible any more.

If the RRUE is easy or hard does not seem to be a qualification for
the definition of RECURRENCE-ID. Your point above is not relevant
to the point of whether the effective DTSTARTs you have above are
the same in the SEQUENCE:0 object as they are for the SEQUENEC:1 object.

> If I opt'd to send the REQUEST with RDATEs instead of an RRULE and then 
> I want to reschedule an instance, I would send nearly the same iCalendar 
> stream but the 6th instance would be different (reflecting the new 
> time).  If I didnt use an RRULE then there is no "pattern" to change. 
>  I'm guessing that some folks are focusing on that particular word (to 
> the exclusion of all the other author reponse) since only the recurrence 
> grammar is designed to express patterns in a compact way.  

Bruce - I find it hard to believe that you really believe that you
can exclude 'pattern' and 'change' in Derik's and Frank's email and
keep a straight face.

> People should not get hung up on the use of a pattern in the iTIP 
> messages; the pattern is simply what the recurrence grammar is designed 
> to encode.  As such, it cannot be used for entries that do not repeat on 
> some form of regular pattern. To do that you have to use RDATEs (or ugly 
> combinations of RRULEs/EXRULEs/EXDATEs).  Once you reschedule any single 
> instance, you no longer have a pattern to follow.

Pattern is the pattern of instances. No where in Frank's or Derik's email
do they define pattern to be the RRULE grammar. It is however used
in the paragraph that describes the 'instances'. And for that I read
that the RECURRENE-ID's are the effective start dates of the object.

> Another thing that I think some folks do not grok fully is that in order 
> for an RRULE to be used to generate a set of entry instances, there can 
> be NO differences between each instance apart from its start/end 
> date/times.  Every single property is _exactly_ the same: the same 
> ATTENDEE list, the same DESCRIPTION, the same ATTACHments, etc.  This 
> most commonly occurs only when the instances are first created.  After 
> that things typically change: ATTENDEE PARTSTATs vary, ATTACHments 
> change, DESCRIPTIONs (typically the Agendas) change, COMMENTS about the 
> instances vary, etc.  As such, its not possible to rely on a RRULE (or 
> group of RRULEs) in a single message to be usable when adding a new 
> invitee; the individual instances have different data.  They no longer 
> are near exact clones of each other.  

When you use the word 'instances' above in the last sentence you do not
mean the effective start date instance - Correct? You mean the copy
that one ATTENDEE sees with respect to another ATTENDEE may differ-
Correct? If so, I think we agree.

You are also not saying that all ATTENDEES need see the exact (byte
for byte) same object correct?

> If you do not focus just on the idea of a particular pattern and treat 
> the instances as a set that can move around then it should be clear why 
> the RECURRENCE-IDs do not change on a reschedule.  By keeping them fixed 
> missed changes (ie: lower SEQUENCE valued messages) are NOT a concern 
> since they are obsolete anyway.  ONLY with fixed RECURRENCE-IDs is it 
> possible to detect a missequenced iTIP message and deal with it properly.  


> Some folks seem to think that there is some mystical need to distinguish 
> an invitation from a reschedule from an update and are seemingly 
> deriving this from the presence of repeating information (or lack of 
> RECURRNECE-IDs). 

You do seem to get initial invitations crossed referenced with the
RECURRENCE-ID issue. I suspect it is for the same reason. Because
you have a legacy problem and not because it says so in ITIP (and
despite the 300-400 emails sent on this subject - there has not
been ONE that explains where in iTIP or iCAL or iMIP that says you
can send an instance update and call it an initial invitation.)

The myth as you call it is a section or two in iTIP. The real myth
is that you can selectively ignore parts of iTIP to satisfy your CUA
legacy requirements.

> This is an unnecessary distinction AND its NOT 
> described at all in the iTIP RFC.

What about the specific text in: "4.4.2 Modify A Recurring Instance" ?

>  The distinction is clearly described 
> in reference to the recipients calendar and NOT to the senders or the 
> iTIP message itself.   There is NO need to draw any distinctions; if the 
> entry is new to the recipient then its an Invitation, otherwise its a 
> reschedule or an update.  

Then why has EVERYONE  that thinks that you can invite someone
by sending them an instance update guessed incorrectly as to the
example I sent was an update or not? I copied the text verbatim
from iTIP itself. Its not a debate, it is not my opinion,
it was 'verbatim' from iTIP and yet you got the wrong answer.

The only response was when someone called it 'fishy' and somehow
the CUA would know that it is 'fishy' and do a REFRESH. Yet
you and they can not seem to reply or explain how the CUA would know
to do that REFRESH or how to know that it was 'fishy'.

> So you may ask why does Doug try to draw a distiction?  The answer is 
> simple: The need for a distinction derives from the delta models 
> inability to deal with lost or missequenced messages.  The recipient has 
> no way to differentiate a missed reschedule from a new instance 
> invitation.  Thus the only solution for the delta model is to stop all 
> workflow on ALL instances and ask the Organizer for a REFRESH of all 
> instances in question.  There are a couple notable problems w/this 
> design:  

No and please stop mis-quoting me.  The real answer is I copied
the example from ITIP and you guessed the wrong answer because
you could not tell by looking at the object. And you guessed
the wrong answer because you thought it was an initial invitation
to a single instance (Now that is something NOT described in iTIP
at all - that *is* a Bruce invention).

Your CUA and all persons that called the example I sent an initial
invitation to this day would have incorrect data in their CUA because
they did a REPLY to a INSTANCE update and never knew to do the REFRESH.
The objects did not look 'fishy' as someone called it because it
was byte for byte what you called an initial invitation, yet it was
not, it was an instance update copied straight from iTIP. You have been 
misleading people about this and I suspect it is again a legacy problem
you have in your implementation.

> 1: Until the Organizers 'nuke' REQUEST gets there the recipient can 
> perform NO workflow on ANY instance.  That means NO accepting, 
> declining, counter proposing or delegating; they can safely perform NO 
> action until they recreate all instances w/the correct current 
> RECURRENCE-IDs.  

False - as you can not confuse an initial invitation from an update
in the iTIP model, no such problem exists. Simply not true and
outrageous for your to make that up on the fly.

If you get an update you know you missed something. If you
get an update and you have not got a non-update object, do a REFRESH.

If you get a full object - nothing to miss as you are up to date.

In your model if you get an update you called it an initial invitation
and would have no way to know that it is an update so your
CUA would not know to do a REFRESH - your CU going to miss
meetings. You keep making assertions that that is not true, yet
you can not explain how your CUA would know it is 'fishy'.

Your assertions about workflow have not been posted about using
the iTIP model with distinct update and invitation, it mixed the
fixed model with the non-mixed model and declared that broken.
And yes that example sent was broken.

> 2: Because iTIP cannot guarantee delivery its possible that the 
> Organizers REQUEST never arrives thus the invitee can be indefinitely 
> stuck w/calendar entries that they cannot be sure are still real or not. 
>  Or its possible that the "full REFRESH" never gets to the Organzier so 
> they never have a clue that some invitee needs help...

Simply false and for the same reasons as above. Because the objects
are distinctly updates or distinctly new invitations, then 100% of the time
you can distinctly tell the difference the first object you get.

With your model you have still failed to explain how to tell if
it is 'fishy'.

> 3: Its possible that the recipient was only invited to a particular 
> instance.  As such the Organizer would only send a REQUEST with that 
> RECURRENCE-ID in it; not one with an RRULE or other repeating info in 
> it.

Again falsely representing the email that was sent.
Simply not what was said at all.

(1) Send them the object as they need to see it. Done.
(2) There is NO requirement and it HAS been discussed and IS in ITIP
     that you can send distinct objects to unique ATTENDEEs.

>  Sending a REQUEST without a RECURRENCE-ID is not semantically the 
> same as a REQUEST for a single instance;

Yet BYTE for BYTE they are 100% identical in your proposal.
Explain by what magic they are they not semantically the same
and how you your CUA can tell them apart, but on the WG list
you can not and did not know how to tell them apart when sent
samples.


? the recipient will treat it as
> a non-repeating entry when in fact its an instnace of a repeat set.   As
> such adding the invitee to other instances means destroying what they 
> think the UID is and having them recreate a new set of now repeating 
> instances.  This means that even though nothing may have changed about 
> the initial instnace they were invited to, the Organizer MUST resend all 
> the data for the unchanged instance just so the recipient can destroy 
> and recreate it in their calendar as a repeating instance now.  What a 
> waste of bandwidth and cycles!  Plus, iTIP clearly says that 
> RECURRENCE-ID MUST be on the REQUEST when it refers to an instance of a 
> repeat set (check the restriction table if in doubt).

(please submit a real draft so it can be debated)

So in your proposal you can only invite an ATTENDEE to ONE instance
at a time to an existing series? Why not just send them ONE object with all 
the instances they are requested to attend, tailored to that ATTENDEE?


> If you consider the correct usages for recurrence rules, the analysis of 
> the delta models shortcomings and the response from Derik/Frank I would 
> hope that it should be clear now exactly why the model is fixed and not 
> changing.  But Im not holding my breath just yet...

Bruce - you ether did not read the email that was sent, did not understand
it, or you are intentionally misrepresenting it. No matter what iTIP-next
concludes, there is NO way that a serious evaluation of what was sent
came from you in this email.

-- 

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

                 We Do Standards - You Need Standards

--------------ms010708070906010100090304
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgyOTAyMDU0M1owIwYJKoZIhvcNAQkEMRYEFFcahpp/
IM4pV6lhNIfWOzgo6n5MMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBAChGfNF/xWTNOPwkFmkQ/MlSvhodMR7K7xaRm1OeZEXEOpyzzpMw
RK02JteJqeX+Gkw5yhJVvC7uyW1KnG7CaefDTp7Jojfo+boFbhpE9KyIvWrSlFlqJYV2IZ3D
R/xCWJZ63+X6yjDxy41m96xLjDYtOQpXIoATc2APRcjvk3fTNcC8/zssFOdwAUSPiuVuybf9
zWzP2pRxGe7Fz80Nv5SLrWizlbSwq65VAy0u0stY8kXkqia443clAIhetc+BRAN1G6ULclJH
cokKb4Pc0Tcil0Fjtp9MiFgggwX0pN7nBueSoMNM1pnG0Kbg+5tAHQvYbLglDhvHKQesYggB
v9EAAAAAAAA=
--------------ms010708070906010100090304--



From owner-ietf-calendar@mail.imc.org  Fri Aug 29 16:11: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 QAA00927
	for ; Fri, 29 Aug 2003 16:11:00 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TJtAgc006958
	for ; Fri, 29 Aug 2003 12:55:10 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7TJtAiu006957
	for ietf-calendar-bks; Fri, 29 Aug 2003 12:55:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TJt9gc006952
	for ; Fri, 29 Aug 2003 12:55:10 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
To: "ietf-calendar@imc.org" 
Subject: ADD does not INVALIDATE current PATTERN
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Fri, 29 Aug 2003 15:53:16 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/29/2003
 03:55:49 PM,
	Serialize complete at 08/29/2003 03:55:49 PM
Content-Type: multipart/alternative; boundary="=_alternative 006CC37C85256D91_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 006CC37C85256D91_=
Content-Type: text/plain; charset="US-ASCII"

An ADD does not INVALIDATE any RECURRENCE-ID in current set.  Thus it does 
not change the pattern of existing set.
If an ADD INVALIDATED the existing set, than you would be forced to send a 
new RRULE/RDATES/EXRULE/EXDATES with ADD.
In that case the ADD would be pointless, just include the new DATE in the 
new rules.

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

The CHAIR does not really care either.  He is in control and just adds it 
to his set. 
--=_alternative 006CC37C85256D91_=
Content-Type: text/html; charset="US-ASCII"



An ADD does not INVALIDATE any RECURRENCE-ID
in current set.  Thus it does not change the pattern of existing set.

If an ADD INVALIDATED the existing set,
than you would be forced to send a new RRULE/RDATES/EXRULE/EXDATES with
ADD.

In that case the ADD would be pointless,
just include the new DATE in the new rules.



An ADD is equivalent to sending the
invitee an REQUEST with a RECURRENCE-ID that he does not currently have.

The invitee WOULD take CHAIRS word for
RECURRENCE-ID and add it to his calendar, storing off RECURRENCE-ID that
CHAIR supplied.



The CHAIR does not really care either.
 He is in control and just adds it to his set. 
--=_alternative 006CC37C85256D91_=--


From owner-ietf-calendar@mail.imc.org  Fri Aug 29 17:29:59 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06930
	for ; Fri, 29 Aug 2003 17:29:59 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TLBNgc012046
	for ; Fri, 29 Aug 2003 14:11:23 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7TLBN5N012045
	for ietf-calendar-bks; Fri, 29 Aug 2003 14:11:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TLBIgc012007
	for ; Fri, 29 Aug 2003 14:11:20 -0700 (PDT)
	(envelope-from gic-ietf-calendar-597@gmane.org)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sqX5-0006wP-00
	for ; Fri, 29 Aug 2003 23:11:47 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-calendar@imc.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19sqX4-0006wH-00
	for ; Fri, 29 Aug 2003 23:11:46 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19sqWO-0001on-00
	for ; Fri, 29 Aug 2003 23:11:04 +0200
From: "Michael Fair" 
Subject: Re: ADD does not INVALIDATE current PATTERN
Date: Fri, 29 Aug 2003 14:11:02 -0700
Lines: 89
Message-ID: 
References: 
X-Complaints-To: usenet@sea.gmane.org
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


I totally agree that an ADD does not invalidate any preexisting
RECCURENCE-ID.

I completely disagree that ADD does not change the current pattern.

ADD does change it only in a non-destructive manner though.

If I have an every Monday event and then ADD every Tuesday,
I have a new set.

This new set is every Monday and Tuesday.

I communicate this by telling existing ATTENDEEs to ADD every Tuesday.

If I invited a new CU post-ADD they would recveive a single UID
with recurrence rules describing every Monday and Tuesday.

The SEQUENCE value for the base event has increased.  The UID/SEQ
pair value has therefore changed and if ADD could ever be a
destructive change to the pattern then it could invalidate RIDs
according to the rules.

If we said that ADD did not change the recurrence pattern then it
would be impossible for ATTENDEEs to verify the set of possible
RECURRENCE-IDs through the response to a REFRESH.

If it didn't alter the recurrence rules, then the response object
would only contain the description of "every Monday". The "every
Tuesday" that had been added would be removed from the Calendar.

Since ADD can never be a destructive act it is only necessary to
send a description for the new set of instances.  The rules
described in the "ADD" message can be safely merged with the
existing rules of the base object while increasing the
SEQUENCE number.

This process is shown in example 4.4.7 of iTIP.
However where I expected the fourth "RDATE" to be in the REFRESH
response object was an "Error! Bookmark not defined" statement.
However looking closely, you can see that the "4th instance" is
indeed listed there.


Example 4.4.7 also covers "ADD".
This one however reveals a really strange case for preexisting
modifications to instances prior to the ADD.  In the example,
the new SEQUENCE update is going to be 7 and therefore by
design all the existing instance modifications will be <7.

The ADD is going to set the base object to be SEQ:7 which would
trump all instance specific data and force them to be removed
from the calendar.

However, from the text and examples, while it doesn't explicitly
address it, there is an implication that using an ADD will
preserve all existing instance specific modifications.

So is the right move to implicitly update all instances with
updates to 7+1 so that the instance data gets preserved?

The main problem I'm thinking of is CUs are going to want to
update their status info for those instances.  Their responses
should be at least SEQ:7, but preferably SEQ:>7.  Otherwise,
even though nothing about those instance has changed, the
ORGANIZER's CUA will think that it has not seen a response
for the latest version of those instances yet.

Or am I missing something simple?

-- Michael --

 wrote in message
news:OFE7C28BE3.25A92664-ON85256D91.006CD53E-85256D91.006CC38F@notesdev.ibm.com...
> An ADD does not INVALIDATE any RECURRENCE-ID in current set.  Thus it does
> not change the pattern of existing set.
> If an ADD INVALIDATED the existing set, than you would be forced to send a
> new RRULE/RDATES/EXRULE/EXDATES with ADD.
> In that case the ADD would be pointless, just include the new DATE in the
> new rules.
>
> An ADD is equivalent to sending the invitee an REQUEST with a
> RECURRENCE-ID that he does not currently have.
> The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his
> calendar, storing off RECURRENCE-ID that CHAIR supplied.
>
> The CHAIR does not really care either.  He is in control and just adds it
> to his set.





From owner-ietf-calendar@mail.imc.org  Fri Aug 29 21:34: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 VAA26081
	for ; Fri, 29 Aug 2003 21:34:15 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U1ITgc020980
	for ; Fri, 29 Aug 2003 18:18:29 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7U1ITdt020979
	for ietf-calendar-bks; Fri, 29 Aug 2003 18:18:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from DrPepper (adsl-67-119-131-54.dsl.lsan03.pacbell.net [67.119.131.54])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U1ISgc020973
	for ; Fri, 29 Aug 2003 18:18:28 -0700 (PDT)
	(envelope-from michael@daclubhouse.net)
Received: by DrPepper (Postfix, from userid 65534)
	id 3B4E28908CC; Fri, 29 Aug 2003 18:18:30 -0700 (PDT)
Received: from cocacola (unknown [192.168.1.102])
	by DrPepper (Postfix) with ESMTP
	id D70358908CB; Fri, 29 Aug 2003 18:18:27 -0700 (PDT)
Message-ID: <022b01c36e94$9e0be260$6601a8c0@daclubhouse.net>
From: "Michael Fair" 
To: "Robert Ransdell/Westford/IBM" ,
        
References: 
Subject: Re: ADD does not INVALIDATE current PATTERN
Date: Fri, 29 Aug 2003 18:18:27 -0700
Organization: DaClubhouse
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=-1.0 required=5.0
	tests=QUOTED_EMAIL_TEXT,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


> I agrees that it changes the set,  does not change any RECURRENCE-ID on
> existing set.  I am trying to avoid the word CHANGE PATTERN, because it
> has been said that any change in PATTERN would cause all RECURRENCE-IDs to
> be invalid.  If you can word smith this better please do so... Thanks

I'd have to say that in many respects I agree with the assement.
In the same way a new SEQUENCE value always obsoletes/invalidates
the old values every pattern change will also cause a SEQUENCE bump.

Now most often there will be many RECURRENCE-IDs that exist in both
the old and the new sets.  Existence in both sets is really meaningless
because the SEQUENCE increase invalidates the attendence STATUS.

However, assuming that the instance hasn't changed (e.g. if there
were any instance updates those updates were propogated), then
it's safe to just automatically transfer the old STATUS to the
new SEQUENCE version of the object.


Perhaps something along the lines of:
"ADD can only add to the number of instances in the current pattern."

Or, if you're looking for something about the pattern change:

Any pattern change that results in the exclusion of any prior
RECURRENCE-ID value implicitly cancels any instances referenced
by the now excluded values.  This implies that a CUA discovering
that it has now invalid instances should remove those and only
those instances whose RECURRENCE-ID is now excluded.

-- Michael --



From owner-ietf-calendar@mail.imc.org  Sat Aug 30 14:00: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 OAA23016
	for ; Sat, 30 Aug 2003 14:00:48 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7UHhjgc021144
	for ; Sat, 30 Aug 2003 10:43:45 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7UHhj4X021143
	for ietf-calendar-bks; Sat, 30 Aug 2003 10:43:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7UHhigc021137
	for ; Sat, 30 Aug 2003 10:43:44 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7UHhgS5000543
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Sat, 30 Aug 2003 10:43:44 -0700
Message-ID: <3F50E249.20008@Royer.com>
Date: Sat, 30 Aug 2003 11:43:37 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: Re: ADD does not INVALIDATE current PATTERN
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080208080102040104080603"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms080208080102040104080603
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert_Ransdell@notesdev.ibm.com wrote:
> 
> An ADD does not INVALIDATE any RECURRENCE-ID in current set.  Thus it 
> does not change the pattern of existing set.
> If an ADD INVALIDATED the existing set, than you would be forced to send 
> a new RRULE/RDATES/EXRULE/EXDATES with ADD.
> In that case the ADD would be pointless, just include the new DATE in 
> the new rules.

The ADD method was added after a discussion on how to add instances
to an existing set that had something such as LOCATION different.

For example a series of meetings that take place around the world
(The IETF meetings for example). As each meeting may have a unique
LOCATION there is no way to describe the next few meetings in one
object. With the ADD method you can add to the instances of an
existing UID. So if the original object sent is a multipart/realted
MIME object. With one REQUEST and five ADD objects, then that is
describing the meeting set (pattern) for that UID. There are also
other valid reasons that a set of meetings could not be described
in on object.

So how could an iMIP CUA that can not do multipart differentiate
between the one multipart/related object that contained two MIME
objects (1 REQUEST + (5 ADD)) and a series of single MIME objects
(1 REQUEST + 1 ADD + 1 ADD + 1 ADD + 1 ADD + 1 ADD) if they are not
equivalent? It could not. So the net result has to be that the ADD
method also adds to the pattern exactly the same as if ADD was used
in the initial REQUEST multipart/mime object - it changes the pattern.

> An ADD is equivalent to sending the invitee an REQUEST with a 
> RECURRENCE-ID that he does not currently have.

The ADD method is the only iTIP way described to add an instance
(RECURRENCE-ID) to an ATTENDEEs view that does not already exist in an
object known to the ATTENDEE. And RECURRENCE-ID is disallowed from
the ADD method in the iTIP restriction tables because it would limit
ADD to adding one instance at a time to the set.

I can not find any text or example that says you can invite someone
to a new instance by sending REQUEST and RECURRENCE-ID. I can find
text that says you can modify an existing instance with REQUEST
and RECURRENCE-ID. I can also find text that describes how to invite
an attendee. So equivalent to what?

> The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his 
> calendar, storing off RECURRENCE-ID that CHAIR supplied.

iTIP specifically disallows RECURRENCE-ID in ADD methods. Or do
you mean it would store the additional patterns described in the
DTSTART, RRULE, RDATE, EXRULE and EXDATE?

> The CHAIR does not really care either.  He is in control and just adds 
> it to his set.

-- 

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

                 We Do Standards - You Need Standards

--------------ms080208080102040104080603
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggSq
MIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MzAxNzQzMzdaMCMGCSqGSIb3DQEJBDEWBBQ7
RCUVtMHAyG8KNiymNOyR+d9+zzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJ
KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv
c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy
aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs
aWRhdGVkAhAejFNQR/pY9ailMryViTyhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQHoxTUEf6WPWopTK8lYk8
oTANBgkqhkiG9w0BAQEFAASCAQBbqpWhwbtWziqRFpp7zcKBKzNfEEVK16uj6p3dMravZcpp
UI2882eqRISu/1IDqXDXsy+EBuI7L1aoWH5HrS312ss+oy1gJcPaK28kyByTSP4ByKu+nNTc
bSX0NuVuTrGV7jE7PkeuTCWyjB47EcGThWav2mxaglDnVRvI6Sypq7G0wXlJu/4IMVdkXPSs
8Qwt0yZ+k36D5IgrDoHGsNMeo7gawNQnfNWuVfGHSjjAFMYeAq87GRULd8tzPU/ClfR7yps1
cUhy4/2Ry8EJrldMeNFbWXIgJg4i46z7ob0w522yMhk4KjRQfQPij5m3HEmNmGSKzmSunLMa
qD+waIO4AAAAAAAA
--------------ms080208080102040104080603--



From owner-ietf-calendar@mail.imc.org  Sat Aug 30 16:02: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 QAA29397
	for ; Sat, 30 Aug 2003 16:02:02 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7UJmxgc026955
	for ; Sat, 30 Aug 2003 12:48:59 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7UJmxx1026953
	for ietf-calendar-bks; Sat, 30 Aug 2003 12:48:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7UJmwgc026948
	for ; Sat, 30 Aug 2003 12:48:58 -0700 (PDT)
	(envelope-from Doug@Royer.com)
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h7UJmwS5001945
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for ; Sat, 30 Aug 2003 12:48:59 -0700
Message-ID: <3F50FFA4.9050107@Royer.com>
Date: Sat, 30 Aug 2003 13:48:52 -0600
From: Doug Royer 
Reply-To: "ietf-calendar@imc.org" 
Organization: http://INET-Consulting.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" 
Subject: CAP-12 - interm version 'A'
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050908020905030701050103"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a cryptographically signed message in MIME format.

--------------ms050908020905030701050103
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


I have placed the latest edit of CAP for your review at:

	http://inet-consulting.com/draft-ietf-calsch-cap-12-a.txt

	http://inet-consulting.com/draft-ietf-calsch-cap-12-a.html

	http://inet-consulting.com/draft-ietf-calsch-cap-12-a.xml

THANK YOU VERY MUCH Greg Barnes for your detailed feedback that obviously
took MUCH time to compile!

--

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

                 We Do Standards - You Need Standards

--------------ms050908020905030701050103
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCBKowggSm
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgzMDE5NDg1MlowIwYJKoZIhvcNAQkEMRYEFOstkp6H
E6mPfyxzxUIIl8f+52CIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEE
AYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEB6MU1BH+lj1qKUyvJWJPKEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAejFNQR/pY9ailMryViTyhMA0G
CSqGSIb3DQEBAQUABIIBADa23+ZfaR6DJKui5bS/13baE8ZeBb+plvbmA6Sm2X4TGO2O+Y6c
A0EP05sALC9RxcXaeIevlMA/6e+4VDP1V4H1qKz4S4Of2OzgtSqMZtZTARqKKQWuuU5gXnXm
Mrw8B8i9DQ1+hbU6XKLNZcICspML4hFx5d9MFuSje6JeiJrqq8hPd3xqhhC04EQYZ+trofRa
DmGdQGbIizZRTbFlnFSpPeVfL/AI0MVG1HP6R4MsXqn9DvH1Ajikm/FQteZWMx+yYALujnSP
ACVTlhs5NXQ4QQjKj8z/vpSgfmos45j7cmd9HFpRyXxdUoI93c65vyPmkXF7Xd5knUZzoudt
oH0AAAAAAAA=
--------------ms050908020905030701050103--



From owner-ietf-calendar@mail.imc.org  Sun Aug 31 12:17: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 MAA09271
	for ; Sun, 31 Aug 2003 12:17:56 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7VFxNgc007280
	for ; Sun, 31 Aug 2003 08:59:23 -0700 (PDT)
	(envelope-from owner-ietf-calendar@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h7VFxNos007279
	for ietf-calendar-bks; Sun, 31 Aug 2003 08:59:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f
Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h7VFxMgc007268
	for ; Sun, 31 Aug 2003 08:59:22 -0700 (PDT)
	(envelope-from Robert_Ransdell@notesdev.ibm.com)
In-Reply-To: <3F50E249.20008@Royer.com>
To: "ietf-calendar@imc.org" 
Cc: "ietf-calendar@imc.org" ,
        owner-ietf-calendar@mail.imc.org
Subject: Re: ADD does not INVALIDATE current PATTERN
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V65_08192003NP August 19, 2003
Message-ID: 
From: Robert_Ransdell@notesdev.ibm.com
Date: Sun, 31 Aug 2003 12:00:10 -0400
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 08/31/2003
 11:59:14 AM,
	Serialize complete at 08/31/2003 11:59:14 AM
Content-Type: multipart/alternative; boundary="=_alternative 005765BA85256D93_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


This is a multipart message in MIME format.
--=_alternative 005765BA85256D93_=
Content-Type: text/plain; charset="US-ASCII"

Doug wrote:
> I can not find any text or example that says you can invite someone
> to a new instance by sending REQUEST and RECURRENCE-ID. I can find
> text that says you can modify an existing instance with REQUEST
> and RECURRENCE-ID. I can also find text that describes how to invite
> an attendee. So equivalent to what?


See ITIP REQUEST METHOD 3.2.2 REQUEST


    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.


The text does not say "This does not apply to new request" so it is valid 
for all METHOD REQUEST.




Doug Royer  
Sent by: owner-ietf-calendar@mail.imc.org
08/30/2003 01:43 PM
Please respond to
"ietf-calendar@imc.org" 


To
"ietf-calendar@imc.org" 
cc

Subject
Re: ADD does not INVALIDATE current PATTERN








Robert_Ransdell@notesdev.ibm.com wrote:
> 
> An ADD does not INVALIDATE any RECURRENCE-ID in current set.  Thus it 
> does not change the pattern of existing set.
> If an ADD INVALIDATED the existing set, than you would be forced to send 

> a new RRULE/RDATES/EXRULE/EXDATES with ADD.
> In that case the ADD would be pointless, just include the new DATE in 
> the new rules.

The ADD method was added after a discussion on how to add instances
to an existing set that had something such as LOCATION different.

For example a series of meetings that take place around the world
(The IETF meetings for example). As each meeting may have a unique
LOCATION there is no way to describe the next few meetings in one
object. With the ADD method you can add to the instances of an
existing UID. So if the original object sent is a multipart/realted
MIME object. With one REQUEST and five ADD objects, then that is
describing the meeting set (pattern) for that UID. There are also
other valid reasons that a set of meetings could not be described
in on object.

So how could an iMIP CUA that can not do multipart differentiate
between the one multipart/related object that contained two MIME
objects (1 REQUEST + (5 ADD)) and a series of single MIME objects
(1 REQUEST + 1 ADD + 1 ADD + 1 ADD + 1 ADD + 1 ADD) if they are not
equivalent? It could not. So the net result has to be that the ADD
method also adds to the pattern exactly the same as if ADD was used
in the initial REQUEST multipart/mime object - it changes the pattern.

> An ADD is equivalent to sending the invitee an REQUEST with a 
> RECURRENCE-ID that he does not currently have.

The ADD method is the only iTIP way described to add an instance
(RECURRENCE-ID) to an ATTENDEEs view that does not already exist in an
object known to the ATTENDEE. And RECURRENCE-ID is disallowed from
the ADD method in the iTIP restriction tables because it would limit
ADD to adding one instance at a time to the set.

I can not find any text or example that says you can invite someone
to a new instance by sending REQUEST and RECURRENCE-ID. I can find
text that says you can modify an existing instance with REQUEST
and RECURRENCE-ID. I can also find text that describes how to invite
an attendee. So equivalent to what?

> The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his 
> calendar, storing off RECURRENCE-ID that CHAIR supplied.

iTIP specifically disallows RECURRENCE-ID in ADD methods. Or do
you mean it would store the additional patterns described in the
DTSTART, RRULE, RDATE, EXRULE and EXDATE?

> The CHAIR does not really care either.  He is in control and just adds 
> it to his set.

-- 

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

                 We Do Standards - You Need Standards


--=_alternative 005765BA85256D93_=
Content-Type: text/html; charset="US-ASCII"



Doug wrote:

> I can not find any text or example
that says you can invite someone

> to a new instance by sending REQUEST and RECURRENCE-ID. I can find

> text that says you can modify an existing instance with REQUEST

> and RECURRENCE-ID. I can also find text that describes how to invite

> an attendee. So equivalent to what?





See ITIP REQUEST METHOD 3.2.2 REQUEST





    RECURRENCE-ID   0 or 1  only if referring to an
instance of a

                    
       recurring calendar component.  Otherwise
it

                    
       MUST NOT be present.





The text does not say "This does
not apply to new request" so it is valid for all METHOD REQUEST.












Doug Royer <Doug@royer.com>


Sent by: owner-ietf-calendar@mail.imc.org

08/30/2003 01:43 PM






Please respond to

"ietf-calendar@imc.org" <ietf-calendar@imc.org>











To

"ietf-calendar@imc.org"
<ietf-calendar@imc.org>




cc






Subject

Re: ADD does not INVALIDATE
current PATTERN





















Robert_Ransdell@notesdev.ibm.com wrote:

> 

> An ADD does not INVALIDATE any RECURRENCE-ID in current set.  Thus
it 

> does not change the pattern of existing set.

> If an ADD INVALIDATED the existing set, than you would be forced to
send 

> a new RRULE/RDATES/EXRULE/EXDATES with ADD.

> In that case the ADD would be pointless, just include the new DATE
in 

> the new rules.



The ADD method was added after a discussion on how to add instances

to an existing set that had something such as LOCATION different.



For example a series of meetings that take place around the world

(The IETF meetings for example). As each meeting may have a unique

LOCATION there is no way to describe the next few meetings in one

object. With the ADD method you can add to the instances of an

existing UID. So if the original object sent is a multipart/realted

MIME object. With one REQUEST and five ADD objects, then that is

describing the meeting set (pattern) for that UID. There are also

other valid reasons that a set of meetings could not be described

in on object.



So how could an iMIP CUA that can not do multipart differentiate

between the one multipart/related object that contained two MIME

objects (1 REQUEST + (5 ADD)) and a series of single MIME objects

(1 REQUEST + 1 ADD + 1 ADD + 1 ADD + 1 ADD + 1 ADD) if they are not

equivalent? It could not. So the net result has to be that the ADD

method also adds to the pattern exactly the same as if ADD was used

in the initial REQUEST multipart/mime object - it changes the pattern.



> An ADD is equivalent to sending the invitee an REQUEST with a 

> RECURRENCE-ID that he does not currently have.



The ADD method is the only iTIP way described to add an instance

(RECURRENCE-ID) to an ATTENDEEs view that does not already exist in an

object known to the ATTENDEE. And RECURRENCE-ID is disallowed from

the ADD method in the iTIP restriction tables because it would limit

ADD to adding one instance at a time to the set.



I can not find any text or example that says you can invite someone

to a new instance by sending REQUEST and RECURRENCE-ID. I can find

text that says you can modify an existing instance with REQUEST

and RECURRENCE-ID. I can also find text that describes how to invite

an attendee. So equivalent to what?



> The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to
his 

> calendar, storing off RECURRENCE-ID that CHAIR supplied.



iTIP specifically disallows RECURRENCE-ID in ADD methods. Or do

you mean it would store the additional patterns described in the

DTSTART, RRULE, RDATE, EXRULE and EXDATE?



> The CHAIR does not really care either.  He is in control and
just adds 

> it to his set.



-- 



  Doug Royer                
    |   http://INET-Consulting.com

  -------------------------------|-----------------------------

  Doug@Royer.com              
  | Office: (208)612-INET

  http://Royer.com/People/Doug   |    Fax: (866)594-8574

                    
            |   Cell: (208)520-4044



                 We Do Standards
- You Need Standards




--=_alternative 005765BA85256D93_=--