From owner-ietf-calendar@mail.imc.org Tue May 6 02:51:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09973 for ; Tue, 6 May 2003 02:51:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h466fci2031333 for ; Mon, 5 May 2003 23:41:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h466fbOK031332 for ietf-calendar-bks; Mon, 5 May 2003 23:41:37 -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.8p1/8.12.8) with ESMTP id h466fai2031322 for ; Mon, 5 May 2003 23:41:37 -0700 (PDT) (envelope-from jparker@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Tue, 06 May 2003 00:27:40 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Tue, 06 May 2003 00:38:29 -0600 From: "Jay Parker" To: Subject: Re: iTIP REPLY question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm still having difficulty understanding the VCAR rights as they pertain to iTIP over CAP verses iTIP via iMIP. Could I get additional clarification on my comments below? Thanks! Jay >>> Doug@royer.com 4/25/2003 10:59:53 AM >>> > > >Jay Parker wrote: >> Could someone please provide clarification in the following areas: >> >> 1. Can both an email address and a CAP uri be specified for the >> organizer so that if rights haven't been granted for opening a >> connection then the CUA can fall back to the email address? If so how >> is it done? If not, and both a CAP uri and an email address are >> available - which should be preferred when creating an iTIP request? > >RFC 2445 limits one URI value to ORGANIZER >RFC 2446 limits one ORGANIZER to a VEVENT. > >So currently no, you can not have both for the same ORGANIZER. > >As to which is preferred: > > If you can let then REPLY via CAP, you cap if you wish. > If not, e-mail them and give them an e-mail reply. > I'm asking from the perspective of a store provider (Novell GroupWise). If the calendar item was sent by a non-CAP (GroupWise) client, but accessed by a CAP client, then the store (GroupWise agent) must decide whether to use a CAP uri or an email address for the organizer. As a store provider we have access to both the CAP uri and the email address. Does anyone know of a reason that we should choose to use the CAP uri instead of the email address or vice-versa. >> 2. It's not clear to me which pre-defined rights are checked when >> depositing an iTIP reply object. > >Nothing is specified. So, (1) try it or (2) query for the VCARs >and figure it out. I would think that (1) would be faster and >require less round trips. > Again, I am asking from the perspective of an administration utility that creates the VCAR rights, and from the perspective of a store that verifies the user rights before allowing access to calendar items. We need to map our built-in rights to VCARs. Several of our built-in rights are not covered by the pre-defined rights. For instance, what pre-defined VCAR deals with rights to return VFREEBUSY components as a result of a busy search? Is a CS required to return all granted rights via VCAR or can it choose to enforce certain built-in rights even though VCARs associated with those rights are never returned to the client as a result of a query for VCARs?. > > I.E. Is CARID:UPDATEPARTSTATUS VCAR checked? > >I an not sure what you mean by 'checked'. It applies (per CAP) >to booked components, not unscheduled entries. OK. We can use the word apply. > >> Does this right cover both VEVENT and VFREEBUSY components? > >The text in CAP says "... in any components ..." if this question >applies to UPDATEPARTSTATUS. > So the pre-defined CARID:UPDATEPARTSTATUS VCAR does not 'apply' to VFREEBUSY components in an iTIP free busy reply because the VFREEBUSY request did not create a 'booked' VFREEBUSY item in the originators calendar? > >> Or does each store need to implement additional VCARs such as a >> hypothetical CARID:UPDATEBUSYTIMEINFO. Do I need to create a VCAR to >> handle the email address AND a VCAR to handle the CAP uri? > >vVCARs apply to UPNs, not CAP or e-mail URI's. > >In cap-10: > > Calendar Access Rights (VCAR) - The mechanism for specifying the CAP > operations ("PERMISSION") that a particular calendar user ("UPN") > is granted or denied permission to perform on a given calendar > object ("SCOPE"). The calendar access rights are specified with a > "VCAR" component. (Section 9.3. > If the iTIP object arrived via email (iMIP) then the UPN associated with the CAP session will belong to the user processing the received iMIP message - not the one who sent it and signed it. But the permissions should be checked against the sender's email address. How would the user's MUA/CUA that is processing the iMIP message get the VCARs to 'apply' to the sender's email address? And how would the CS prevent the MUA/CUA from spoofing someone's email address. >> 3. A CUA that is ready to process an iTIP reply that was delivered via >> iMIP is expected to check the VCARs in the same manner as if it was >> transported via CAP, correct? > >A 'CS' would check the VCARs if the 'CUA' attempts any operation. >However the CUA is free to query for the VCARs and decide before >the operation. The CUA UPN identity is established through the CAP session authentication. How is the UPN identity established when a CUA is processing iTIP objects sent via iMIP? Or is the calendar store the component that must validate the signature on the MIME? It seems like the entire signed MIME rather than just the iTIP object should be passed to the CS when an iTIP request was delivered via email. Or from another perspective... how does the CS know that the CUA/MUA has validated the signature before passing the iTIP object to the calendar store? > >-- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.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 May 6 11:49:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26824 for ; Tue, 6 May 2003 11:49:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FSWi2082478 for ; Tue, 6 May 2003 08:28:32 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46FSWxt082477 for ietf-calendar-bks; Tue, 6 May 2003 08:28: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 (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FSVi2082469 for ; Tue, 6 May 2003 08:28:32 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 6 May 2003 11:26:49 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/06/2003 11:24:35 AM, Serialize complete at 05/06/2003 11:24:35 AM Content-Type: multipart/alternative; boundary="=_alternative 0054B02C85256D1E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054B02C85256D1E_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 04/24/2003 01:32:32 PM CST: > > In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST > > objects in another CUA's CS. > > There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT > > information. > > > > How do I get the rights to place METHOD:REPLY objects in another CUA's > > CS? > > They must give it to you in advance. If they have not given you the > rights to deposit a REPLY into their CS, then they broke iTIP - ignore them > and throw away the REQUEST. Ahem, its not breaking iTIP if the CU1 did not grant CU2 the proper rights to return a response; its a user/configuration issue in CAP. The REQUEST/REPLY bits are perfectly fine; its the VCARs the CU set that are at fault. > It is possible that they want you to connect anonymously. Are you suggesting that a CUA SHOULD try to connect and CREATE the REPLY and if that fails that the CUA change their identity to 'anonymous' and retry the command? I would think that allowing 'anonymous' authenticated users to CREATE documents in a calendar would be less than desirable because there is no way to authenticate the identity against the contents of the message. If I intercepted or guessed that you and John were having a meeting I could anonymously DECLINE on Johns behalf even though really ACCEPTed previously. Hmm, sounds like potential for lots of hacker fun... Anonymous access _is_ useful for public calendars or for "announcement" kinds of calendars but not for any serious C&S workflow because of the potential for hacking and disruption. > > How do I access the other CS? > > If the ORGANIZER property is a CAP uri, then open a connection > to that uri. Will this work for the case where CS's are behind firewalls and thus not necessarily exposed to external DNS servers? Can you at INET-consulting.com resolve my alice.iris.com CAP server? You'll probably get "Unknown host" from your DNS server. So what should your CUA do at that point? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0054B02C85256D1E_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 04/24/2003 01:32:32 PM CST:
> > In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST
> > objects in another CUA's CS.
> > There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT
> > information.
> >
> > How do I get the rights to place METHOD:REPLY objects in another CUA's
> > CS?
>
> They must give it to you in advance. If they have not given you the
> rights to deposit a REPLY into their CS, then they broke iTIP - ignore them
> and throw away the REQUEST.
Ahem, its not breaking iTIP if the CU1 did not grant CU2 the proper rights to return a response; its a user/configuration issue in CAP.  The REQUEST/REPLY bits are perfectly fine; its the VCARs the CU set that are at fault.

> It is possible that they want you to connect anonymously.
Are you suggesting that a CUA SHOULD try to connect and CREATE the REPLY and if that fails that the CUA change their identity to 'anonymous' and retry the command?  I would think that allowing 'anonymous' authenticated users to CREATE documents in a calendar would be less than desirable because there is no way to authenticate the identity against the contents of the message.  If I intercepted or guessed that you and John were having a meeting I could anonymously DECLINE on Johns behalf even though really ACCEPTed previously.  Hmm, sounds like potential for lots of hacker fun...

Anonymous access _is_ useful for public calendars or for "announcement" kinds of calendars but not for any serious C&S workflow because of the potential for hacking and disruption.

> > How do I access the other CS?
>
> If the ORGANIZER property is a CAP uri, then open a connection
> to that uri.
Will this work for the case where CS's are behind firewalls and thus not necessarily exposed to external DNS servers?  

Can you at INET-consulting.com resolve my alice.iris.com CAP server?  You'll probably get "Unknown host" from your DNS server.  So what should your CUA do at that point?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0054B02C85256D1E_=-- From owner-ietf-calendar@mail.imc.org Tue May 6 11:59:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27161 for ; Tue, 6 May 2003 11:59:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FfAi2082930 for ; Tue, 6 May 2003 08:41:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46Ff9ON082929 for ietf-calendar-bks; Tue, 6 May 2003 08:41: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.8p1/8.12.8) with ESMTP id h46Ff8i2082920 for ; Tue, 6 May 2003 08:41: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 h46Ff3G4011020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 6 May 2003 08:41:07 -0700 Message-ID: <3EB7D785.9070102@Royer.com> Date: Tue, 06 May 2003 09:40:53 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080709050606050501040307" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080709050606050501040307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jay Parker wrote: >>As to which is preferred: >> >> If you can let then REPLY via CAP, you cap if you wish. >> If not, e-mail them and give them an e-mail reply. >> > > > I'm asking from the perspective of a store provider (Novell GroupWise). > If the calendar item was sent by a non-CAP (GroupWise) client, but > accessed by a CAP client, then the store (GroupWise agent) must decide > whether to use a CAP uri or an email address for the organizer. As a > store provider we have access to both the CAP uri and the email address. > Does anyone know of a reason that we should choose to use the CAP uri > instead of the email address or vice-versa. As in iTIP you can not have both for the same property (ORGANIZER or ATTENDEE), your question will not have a definitive answer as it will not apply to iCalendar objects. So the answer is out of scope for RFC 244[567] or CAP. > >>>2. It's not clear to me which pre-defined rights are checked when >>>depositing an iTIP reply object. >> >>Nothing is specified. So, (1) try it or (2) query for the VCARs >>and figure it out. I would think that (1) would be faster and >>require less round trips. > > Again, I am asking from the perspective of an administration utility > that creates the VCAR rights, and from the perspective of a store that > verifies the user rights before allowing access to calendar items. We > need to map our built-in rights to VCARs. Several of our built-in > rights are not covered by the pre-defined rights. For instance, what > pre-defined VCAR deals with rights to return VFREEBUSY components as a > result of a busy search? Defined in 4.2.2 of draft-...-10.txt: READBUSYTIMEINFO > Is a CS required to return all granted rights > via VCAR or can it choose to enforce certain built-in rights even though > VCARs associated with those rights are never returned to the client as a > result of a query for VCARs?. The CUA never needs to ask for VCARs. So yes. > >>> I.E. Is CARID:UPDATEPARTSTATUS VCAR checked? >> >>I an not sure what you mean by 'checked'. It applies (per CAP) >>to booked components, not unscheduled entries. > > > OK. We can use the word apply. > >>>Does this right cover both VEVENT and VFREEBUSY components? >> >>The text in CAP says "... in any components ..." if this question >>applies to UPDATEPARTSTATUS. >> > > So the pre-defined CARID:UPDATEPARTSTATUS VCAR does not 'apply' to > VFREEBUSY components in an iTIP free busy reply because the VFREEBUSY > request did not create a 'booked' VFREEBUSY item in the originators > calendar? No, because that is not how it is defined in section 4.2.2. And because VFREEBUSY does not have an ATTENDEE property as described in 4.2.2 / UPDATEPARTSTATUS. > >>>Or does each store need to implement additional VCARs such as a >>>hypothetical CARID:UPDATEBUSYTIMEINFO. Do I need to create a VCAR >> > to > >>>handle the email address AND a VCAR to handle the CAP uri? >> >>vVCARs apply to UPNs, not CAP or e-mail URI's. >> >>In cap-10: >> >> Calendar Access Rights (VCAR) - The mechanism for specifying the > > CAP > >> operations ("PERMISSION") that a particular calendar user > > ("UPN") > >> is granted or denied permission to perform on a given calendar >> object ("SCOPE"). The calendar access rights are specified > > with a > >> "VCAR" component. (Section 9.3. >> > > > If the iTIP object arrived via email (iMIP) then the UPN associated > with the CAP session will belong to the user processing the received > iMIP message - not the one who sent it and signed it. But the > permissions should be checked against the sender's email address. No VCARs are checked against the UPN of the currently connected CUA that successfully logged in. Othe VCAR rules may restrict the data however the CS will never see the senders email address. The CS will only see the ATTENDEE or ORGANIZER property values. > How > would the user's MUA/CUA that is processing the iMIP message get the > VCARs to 'apply' to the sender's email address? I do not understand you question. The CUA attempts an operation and the CS allows or disallows it because of the VCARs stored in the CS. > And how would the CS > prevent the MUA/CUA from spoofing someone's email address. No such claim has been made. The CS compares the VCARs to the currently connected and authenticated session. The CS never sees the 'From:' address of the object. >>>3. A CUA that is ready to process an iTIP reply that was delivered >> > via > >>>iMIP is expected to check the VCARs in the same manner as if it was >>>transported via CAP, correct? >> >>A 'CS' would check the VCARs if the 'CUA' attempts any operation. >>However the CUA is free to query for the VCARs and decide before >>the operation. > > > The CUA UPN identity is established through the CAP session > authentication. How is the UPN identity established when a CUA is > processing iTIP objects sent via iMIP? A CS does not accept iMIP objects directly, they always come from a CUA (automated or not). So it is up to the CUA to map e-mail addresses to/from UPNs for authentication. > Or is the calendar store the > component that must validate the signature on the MIME? The CS is not an MUA, so no. All iCalendar objects are MIME objects, iCalendar objects are not 822 messages. > It seems like > the entire signed MIME rather than just the iTIP object should be passed > to the CS when an iTIP request was delivered via email. Or from another > perspective... how does the CS know that the CUA/MUA has validated the > signature before passing the iTIP object to the calendar store? It does 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 --------------ms080709050606050501040307 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MDYxNTQwNTRaMCMGCSqGSIb3DQEJBDEWBBT4 FuVgyoUF1Pb5wwUsy9xfO/Nx6zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAOqCR7jCKVn5a wHrI3Q1jDvOXq21LP9of/8g9d7xTFbLXUANf5KpT5NXQtTHoAT0gr7fhompYuYgNfAAPfp9K CRRree2Ld/GrR7TYnmX9+2DLS9Ziq/s8a+Ir9lgcolNcPBf0zsXW3im9lMtIpyKnPVo3PFQf HSvaIVfzMmVxGNEwX9dO5gsVgGf4dZjTIt9c1siUpuhIkrJDZG0N0S0wWyeAcTJ4eXMlyN1I NVAK20l5QS9MS0XdM+Ak6diyXQU5VvbeRNYrOuaGf+sfL9xS8V3j8H6RkV17wz1d35VsZUFh v4Y+VBSf7GVqw6lgaljSgwviar6Iab5QG0doWCYpBAAAAAAAAA== --------------ms080709050606050501040307-- From owner-ietf-calendar@mail.imc.org Tue May 6 12:02:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27281 for ; Tue, 6 May 2003 12:02:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FiDi2083043 for ; Tue, 6 May 2003 08:44:13 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46FiDLZ083042 for ietf-calendar-bks; Tue, 6 May 2003 08:44:13 -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 (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FiCi2083035 for ; Tue, 6 May 2003 08:44:13 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: Re: iTIP REPLY question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 6 May 2003 11:31:27 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/06/2003 11:44:14 AM, Serialize complete at 05/06/2003 11:44:14 AM Content-Type: multipart/alternative; boundary="=_alternative 00551CCF85256D1E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00551CCF85256D1E_= Content-Type: text/plain; charset="US-ASCII" Preston replied on 04/24/2003 01:57:18 PM CST: > This model would also work for the VFREEBUSY REQUEST. > The reply VFREEBUSY REPLY is placed back in the Organizer's CS. I would hope that VFREEBUSY lookups in CAP would be 'realtime' and not 'store and forward'. That is, if I have sufficient rights to TARGET your calendar and to perform a VFREEBUSY REQUEST then your CS should return me the proper VFREEBUSY REPLY, not you or your CUA. This gets back to the removed text from Drafts 03-05 where we had the CS doing the VFREEBUSY maintenance and NOT any CUA. A thread that we never finished last month... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00551CCF85256D1E_= Content-Type: text/html; charset="US-ASCII"
Preston replied on 04/24/2003 01:57:18 PM CST:
> This model would also work for the VFREEBUSY REQUEST.
> The reply VFREEBUSY REPLY is placed back in the Organizer's CS.
I would hope that VFREEBUSY lookups in CAP would be 'realtime' and not 'store and forward'.  That is, if I have sufficient rights to TARGET your calendar and to perform a VFREEBUSY REQUEST then your CS should return me the proper VFREEBUSY REPLY, not you or your CUA.

This gets back to the removed text from Drafts 03-05 where we had the CS doing the VFREEBUSY maintenance and NOT any CUA.  A thread that we never finished last month...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00551CCF85256D1E_=-- From owner-ietf-calendar@mail.imc.org Tue May 6 12:34:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28638 for ; Tue, 6 May 2003 12:34:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GHmi2085227 for ; Tue, 6 May 2003 09:17:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46GHmns085226 for ietf-calendar-bks; Tue, 6 May 2003 09:17:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GHki2085219 for ; Tue, 6 May 2003 09:17:47 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id D32DE3FAC1 for ; Tue, 6 May 2003 18:08:30 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id 22F9C312; Tue, 6 May 2003 18:17:24 +0200 (MET DST) To: ietf-calendar@imc.org From: gustav.mango@safecareab.com Subject: Re: Re: iTIP REPLY question Message-Id: <20030506161724.22F9C312@nw-pop4.wineasy.se> Date: Tue, 6 May 2003 18:17:24 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Tue May 6 12:36:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28727 for ; Tue, 6 May 2003 12:36:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GI4i2085240 for ; Tue, 6 May 2003 09:18:04 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46GI41N085239 for ietf-calendar-bks; Tue, 6 May 2003 09:18: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.8p1/8.12.8) with ESMTP id h46GI3i2085234 for ; Tue, 6 May 2003 09:18: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 h46GHwG4011332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 6 May 2003 09:18:03 -0700 Message-ID: <3EB7E030.10506@Royer.com> Date: Tue, 06 May 2003 10:17:52 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070708040208000408040504" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070708040208000408040504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 04/24/2003 01:32:32 PM CST: > > > In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST > > > objects in another CUA's CS. > > > There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT > > > information. > > > > > > How do I get the rights to place METHOD:REPLY objects in another CUA's > > > CS? > > > > They must give it to you in advance. If they have not given you the > > rights to deposit a REPLY into their CS, then they broke iTIP - > ignore them > > and throw away the REQUEST. > > Ahem, its not breaking iTIP if the CU1 did not grant CU2 the proper > rights to return a response; its a user/configuration issue in CAP. The > REQUEST/REPLY bits are perfectly fine; its the VCARs the CU set that are > at fault. Your right. > > It is possible that they want you to connect anonymously. > > Are you suggesting that a CUA SHOULD try to connect and CREATE the REPLY > and if that fails that the CUA change their identity to 'anonymous' and > retry the command? I would think that allowing 'anonymous' > authenticated users to CREATE documents in a calendar would be less than > desirable because there is no way to authenticate the identity against > the contents of the message. If I intercepted or guessed that you and > John were having a meeting I could anonymously DECLINE on Johns behalf > even though really ACCEPTed previously. Hmm, sounds like potential for > lots of hacker fun... I am suggesting that it is an option. Within a company and inside a firewall - why not? > Anonymous access _is_ useful for public calendars or for "announcement" > kinds of calendars but not for any serious C&S workflow because of the > potential for hacking and disruption. On the outside of a firewall - YES. > > > How do I access the other CS? > > > > If the ORGANIZER property is a CAP uri, then open a connection > > to that uri. > > Will this work for the case where CS's are behind firewalls and thus not > necessarily exposed to external DNS servers? > > Can you at INET-consulting.com resolve my alice.iris.com CAP server? If you set your ORGANIZER property value to CAP:alice.iris.com, I would expect to be able to CAP reply to that address. > You'll probably get "Unknown host" from your DNS server. So what > should your CUA do at that point? I would call you on the phone and tell you you sent me a bogus CAP object. Then delete the object from my store. I do not see that it is any different than if you set your ORGANIZER property value to mailto:bruce@alice.iris.com. It would bounce or not be sent when the MUA/CUA tried to look up the MX record for alice.iris.com. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070708040208000408040504 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MDYxNjE3NTJaMCMGCSqGSIb3DQEJBDEWBBQI LyOLl8Bzp/SIwprwqMoMJ5uIYTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAd7wrd8yjLmMA pn6V7At7rdhdlMRm7NcxYXs/f4wiR2R8RGtT89WpoUFONngUsvGjpb/OixEzuKxMgxy5O5Ev 2204Dk0xRjWQYElXaDUei1oOl8qY4mKLjh+GGqddJUcjm+4v5+MPkzyGQbdeq8ozhZCi37S3 ZYqonaYz5oF+j4IC7wTxxN6Z0eb/vdBknvsiTQFd0/WtXpQ2FmsDA29AH+9CPppIk5lX+PPJ iIbg0XKoXqKhSUfkIbd9PXpAlfsFRAVxSv280luWxE8KKKT6QfDY7iaexm5GSU7CadIMJ60l QgAd588QpWmbZAGIglTS1Sx+GP6nFUz2wPLUTJUZlgAAAAAAAA== --------------ms070708040208000408040504-- From owner-ietf-calendar@mail.imc.org Tue May 6 13:16:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29997 for ; Tue, 6 May 2003 13:16:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Gr1i2090733 for ; Tue, 6 May 2003 09:53:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46Gr1it090732 for ietf-calendar-bks; Tue, 6 May 2003 09:53:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Gr0i2090706 for ; Tue, 6 May 2003 09:53:00 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id 7BCB03F907 for ; Tue, 6 May 2003 18:44:02 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id 1DEB8312; Tue, 6 May 2003 18:52:56 +0200 (MET DST) To: "ietf-calendar@imc.org" From: gustav.mango@safecareab.com Subject: Re: Re: iTIP REPLY question Message-Id: <20030506165256.1DEB8312@nw-pop4.wineasy.se> Date: Tue, 6 May 2003 18:52:56 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Thu May 15 02:37: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 CAA28654 for ; Thu, 15 May 2003 02:37: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 h4F6SQAF057199 for ; Wed, 14 May 2003 23:28: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 h4F6SQbf057197 for ietf-calendar-bks; Wed, 14 May 2003 23:28:26 -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 h4F6SPAF057156 for ; Wed, 14 May 2003 23:28:25 -0700 (PDT) (envelope-from jparker@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Thu, 15 May 2003 00:27:49 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 15 May 2003 00:27:56 -0600 From: "Jay Parker" To: Subject: Re: iTIP REPLY question Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_Boundary_0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_Boundary_0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >>>> Doug@royer.com 05/06 9:40 AM >>> > > >Jay Parker wrote: > >>>As to which is preferred: >>> >>> If you can let then REPLY via CAP, you cap if you wish. >>> If not, e-mail them and give them an e-mail reply. >>> >> >> >> I'm asking from the perspective of a store provider (Novell GroupWise). >> If the calendar item was sent by a non-CAP (GroupWise) client, but >> accessed by a CAP client, then the store (GroupWise agent) must decide >> whether to use a CAP uri or an email address for the organizer. As a >> store provider we have access to both the CAP uri and the email address. >> Does anyone know of a reason that we should choose to use the CAP uri >> instead of the email address or vice-versa. > >As in iTIP you can not have both for the same property (ORGANIZER >or ATTENDEE), your question will not have a definitive answer >as it will not apply to iCalendar objects. So the answer is >out of scope for RFC 244[567] or CAP. > >> >>>>2. It's not clear to me which pre-defined rights are checked when >>>>depositing an iTIP reply object. >>> >>>Nothing is specified. So, (1) try it or (2) query for the VCARs >>>and figure it out. I would think that (1) would be faster and >>>require less round trips. >> >> Again, I am asking from the perspective of an administration utility >> that creates the VCAR rights, and from the perspective of a store that >> verifies the user rights before allowing access to calendar items. We >> need to map our built-in rights to VCARs. Several of our built-in >> rights are not covered by the pre-defined rights. For instance, what >> pre-defined VCAR deals with rights to return VFREEBUSY components as a >> result of a busy search? > >Defined in 4.2.2 of draft-...-10.txt: READBUSYTIMEINFO > From 4.2.2... " CARID:READBUSYTIMEINFO - Specifies the "GRANT" and "DENY" rules that allow UPNs to search "VFREEBUSY" components." If I understand it correctly, the iTIP steps for UserA performing a busy search of UserB's calendar are as follows: 1. UserA creates an iTIP REQUEST for VFREEBUSY and stores it in UserB's calendar 2. UserB's CUA (or a bot) processes the request and creates an iTIP REPLY with VFREEBUSY information and stores it in UserA's calendar 3. UserA queries his calendar for VFREEBUSY replies to his request and processes them. Does READBUSYTIMEINFO apply to all 3 steps in the process? It seems to only apply to step 3 when UserA SEARCHES his calendar for the replies. What am I missing? I would have expected a CARID:UPDATEBUSYTIMEINFO or something similar. >> Is a CS required to return all granted rights >> via VCAR or can it choose to enforce certain built-in rights even though >> VCARs associated with those rights are never returned to the client as a >> result of a query for VCARs?. > >The CUA never needs to ask for VCARs. So yes. > >> >>>> I.E. Is CARID:UPDATEPARTSTATUS VCAR checked? >>> >>>I an not sure what you mean by 'checked'. It applies (per CAP) >>>to booked components, not unscheduled entries. True, the returned VFREEBUSY REPLY is not booked, but neither is the VEVENT REPLY that is created. Isn't it the CUA processing the REPLY that would need the UPDATEPARTSTATUS rights? The CAP draft does not specify which rights would apply for each iTIP step of a busy search or of an appointment request/Accept secquence. If someone would like to take a stab at it, I'd greatly appreciate the detailed response. >> >> >> OK. We can use the word apply. >> >>>>Does this right cover both VEVENT and VFREEBUSY components? >>> >>>The text in CAP says "... in any components ..." if this question >>>applies to UPDATEPARTSTATUS. >>> >> >> So the pre-defined CARID:UPDATEPARTSTATUS VCAR does not 'apply' to >> VFREEBUSY components in an iTIP free busy reply because the VFREEBUSY >> request did not create a 'booked' VFREEBUSY item in the originators >> calendar? > >No, because that is not how it is defined in section 4.2.2. >And because VFREEBUSY does not have an ATTENDEE property as >described in 4.2.2 / UPDATEPARTSTATUS. CARID:READBUSYTIMEINFO in 4.2.2 specifies the right to "search" VFREEBUSY components. Does that also imply the right to request them or create them in response to a request? If not what does? > >> >>>>Or does each store need to implement additional VCARs such as a >>>>hypothetical CARID:UPDATEBUSYTIMEINFO. Do I need to create a VCAR >>> >> to >> >>>>handle the email address AND a VCAR to handle the CAP uri? >>> >>>vVCARs apply to UPNs, not CAP or e-mail URI's. >>> >>>In cap-10: >>> >>> Calendar Access Rights (VCAR) - The mechanism for specifying the >> >> CAP >> >>> operations ("PERMISSION") that a particular calendar user >> >> ("UPN") >> >>> is granted or denied permission to perform on a given calendar >>> object ("SCOPE"). The calendar access rights are specified >> >> with a >> >>> "VCAR" component. (Section 9.3. >>> >> >> >> If the iTIP object arrived via email (iMIP) then the UPN associated >> with the CAP session will belong to the user processing the received >> iMIP message - not the one who sent it and signed it. But the >> permissions should be checked against the sender's email address. > >No VCARs are checked against the UPN of the currently connected >CUA that successfully logged in. Othe VCAR rules may restrict >the data however the CS will never see the senders email address. >The CS will only see the ATTENDEE or ORGANIZER property values. > >> How >> would the user's MUA/CUA that is processing the iMIP message get the >> VCARs to 'apply' to the sender's email address? > >I do not understand you question. The CUA attempts an operation >and the CS allows or disallows it because of the VCARs stored >in the CS. > >> And how would the CS >> prevent the MUA/CUA from spoofing someone's email address. > >No such claim has been made. The CS compares the VCARs to the >currently connected and authenticated session. The CS never >sees the 'From:' address of the object. > >>>>3. A CUA that is ready to process an iTIP reply that was delivered >>> >> via >> >>>>iMIP is expected to check the VCARs in the same manner as if it was >>>>transported via CAP, correct? >>> >>>A 'CS' would check the VCARs if the 'CUA' attempts any operation. >>>However the CUA is free to query for the VCARs and decide before >>>the operation. >> >> >> The CUA UPN identity is established through the CAP session >> authentication. How is the UPN identity established when a CUA is >> processing iTIP objects sent via iMIP? > >A CS does not accept iMIP objects directly, they always come >from a CUA (automated or not). So it is up to the CUA >to map e-mail addresses to/from UPNs for authentication. > Hmmm... Yet another requirement on the CAP client that could be implemented at the store.... Are there any efforts underway for a thin client version of CAP that pushes the calendaring logic to the store? Most collaboration products such as Notes, GroupWise and Exchange already implement calendaring logic that would facilitate a 'CAP Thin Client ' protocol with real-time transport. A thin cient busy search could request information and receive immediate results. A meeting could be scheduled in a single command that created the organizer's entry, created each local target's entry and converted external targets into an SMTP/iMIP message for external users. A single command could also be used to tell the store/agent to book a request and create the associated reply... Is there interest for a CAP thin client protocol or is everyone content with the thick client approach? >> Or is the calendar store the >> component that must validate the signature on the MIME? > >The CS is not an MUA, so no. All iCalendar objects are MIME >objects, iCalendar objects are not 822 messages. > >> It seems like >> the entire signed MIME rather than just the iTIP object should be passed >> to the CS when an iTIP request was delivered via email. Or from another >> perspective... how does the CS know that the CUA/MUA has validated the >> signature before passing the iTIP object to the calendar store? > >It does not. > That's unfortunate for administrators; instead of choosing a secure calendar store, they must now concern themselves with every possible CAP client that might run against the calendar store. >-- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > --=_Boundary_0 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: 8bit
>
>>>> Doug@royer.com 05/06 9:40 AM >>>
>
>
>Jay Parker wrote:
>
>>>As to which is preferred:
>>>
>>>    If you can let then REPLY via CAP, you cap if you wish.
>>>    If not, e-mail them and give them an e-mail reply.
>>>
>>
>>
>> I'm asking from the perspective of a store provider (Novell GroupWise).
>>  If the calendar item was sent by a non-CAP (GroupWise) client, but
>> accessed by a CAP client, then the store (GroupWise agent) must decide
>> whether to use a CAP uri or an email address for the organizer.  As a
>> store provider we have access to both the CAP uri and the email address.
>>  Does anyone know of a reason that we should choose to use the CAP uri
>> instead of the email address or vice-versa.
>
>As in iTIP you can not have both for the same property (ORGANIZER
>or ATTENDEE), your question will not have a definitive answer
>as it will not apply to iCalendar objects. So the answer is
>out of scope for RFC 244[567] or CAP.
>
>>
>>>>2. It's not clear to me which pre-defined rights are checked when
>>>>depositing an iTIP reply object.
>>>
>>>Nothing is specified. So, (1) try it or (2) query for the VCARs
>>>and figure it out. I would think that (1) would be faster and
>>>require less round trips.
>>
>> Again, I am asking from the perspective of an administration utility
>> that creates the VCAR rights, and from the perspective of a store that
>> verifies the user rights before allowing access to calendar items.  We
>> need to map our built-in rights to VCARs.  Several of our built-in
>> rights are not covered by the pre-defined rights.  For instance, what
>> pre-defined VCAR deals with rights to return VFREEBUSY components as a
>> result of a busy search?
>
>Defined in 4.2.2 of draft-...-10.txt: READBUSYTIMEINFO
>
From 4.2.2...
 
  " CARID:READBUSYTIMEINFO -  Specifies the "GRANT" and "DENY" rules that
      allow UPNs to search "VFREEBUSY" components."
 
If I understand it correctly, the iTIP steps for UserA performing a busy search of UserB's calendar are as follows:
1. UserA creates an iTIP REQUEST for VFREEBUSY and stores it in UserB's calendar
2. UserB's CUA (or a bot) processes the request and creates an iTIP REPLY with VFREEBUSY information and stores it in UserA's calendar
3. UserA queries his calendar for VFREEBUSY replies to his request and processes them.
 
Does READBUSYTIMEINFO apply to all 3 steps in the process?  It seems to only apply to step 3 when UserA SEARCHES his calendar for the replies.  What am I missing?  I would have expected a CARID:UPDATEBUSYTIMEINFO or something similar.

>> Is a CS required to return all granted rights
>> via VCAR or can it choose to enforce certain built-in rights even though
>> VCARs associated with those rights are never returned to the client as a
>> result of a query for VCARs?.
>
>The CUA never needs to ask for VCARs. So yes.
>
>>
>>>> I.E. Is CARID:UPDATEPARTSTATUS VCAR checked?
>>>
>>>I an not sure what you mean by 'checked'. It applies (per CAP)
>>>to booked components, not unscheduled entries.
 
True, the returned VFREEBUSY REPLY is not booked, but neither is the VEVENT REPLY that is created.  Isn't it the CUA processing the REPLY that would need the UPDATEPARTSTATUS rights? 
 
The CAP draft does not specify which rights would apply for each iTIP step of a busy search or of an appointment request/Accept secquence.  If someone would like to take a stab at it, I'd greatly appreciate the detailed response.

>>
>>
>> OK.  We can use the word apply.
>>
>>>>Does this right cover both VEVENT and VFREEBUSY components?
>>>
>>>The text in CAP says "... in any components ..." if this question
>>>applies to UPDATEPARTSTATUS.
>>>
>>
>> So the pre-defined CARID:UPDATEPARTSTATUS VCAR does not 'apply' to
>> VFREEBUSY components in an iTIP free busy reply because the VFREEBUSY
>> request did not create a 'booked' VFREEBUSY item in the originators
>> calendar?
>
>No, because that is not how it is defined in section 4.2.2.
>And because VFREEBUSY does not have an ATTENDEE property as
>described in 4.2.2 / UPDATEPARTSTATUS.
 
CARID:READBUSYTIMEINFO in 4.2.2 specifies the right to "search" VFREEBUSY components.  Does that also imply the right to request them or create them in response to a request?  If not what does?

>
>>
>>>>Or does each store need to implement additional VCARs such as a
>>>>hypothetical CARID:UPDATEBUSYTIMEINFO.  Do I need to create a VCAR
>>>
>> to
>>
>>>>handle the email address AND a VCAR to handle the CAP uri?
>>>
>>>vVCARs apply to UPNs, not CAP or e-mail URI's.
>>>
>>>In cap-10:
>>>
>>>   Calendar Access Rights (VCAR) -  The mechanism for specifying the
>>
>> CAP
>>
>>>      operations ("PERMISSION") that a particular calendar user
>>
>> ("UPN")
>>
>>>      is granted or denied permission to perform on a given calendar
>>>      object ("SCOPE").  The calendar access rights are specified
>>
>> with a
>>
>>>      "VCAR" component.  (Section 9.3.
>>>
>>
>>
>> If the iTIP object arrived via email (iMIP) then the UPN associated
>> with the CAP session will belong to the user processing the received
>> iMIP message - not the one who sent it and signed it.   But the
>> permissions should be checked against the sender's email address.
>
>No VCARs are checked against the UPN of the currently connected
>CUA that successfully logged in. Othe VCAR rules may restrict
>the data however the CS will never see the senders email address.
>The CS will only see the ATTENDEE or ORGANIZER property values.
>
>>   How
>> would the user's MUA/CUA that is processing the iMIP message get the
>> VCARs to 'apply' to the sender's email address?
>
>I do not understand you question. The CUA attempts an operation
>and the CS allows or disallows it because of the VCARs stored
>in the CS.
>
>> And how would the CS
>> prevent the MUA/CUA from spoofing someone's email address.
>
>No such claim has been made. The CS compares the VCARs to the
>currently connected and authenticated session. The CS never
>sees the 'From:' address of the object.
>
>>>>3. A CUA that is ready to process an iTIP reply that was delivered
>>>
>> via
>>
>>>>iMIP is expected to check the VCARs in the same manner as if it was
>>>>transported via CAP, correct?
>>>
>>>A 'CS' would check the VCARs if the 'CUA' attempts any operation.
>>>However the CUA is free to query for the VCARs and decide before
>>>the operation.
>>
>>
>> The CUA UPN identity is established through the CAP session
>> authentication.  How is the UPN identity established when a CUA is
>> processing iTIP objects sent via iMIP?
>
>A CS does not accept iMIP objects directly, they always come
>from a CUA (automated or not). So it is up to the CUA
>to map e-mail addresses to/from UPNs for authentication.
>
 
Hmmm...  Yet another requirement on the CAP client that could be implemented at the store....
 
Are there any efforts underway for a thin client version of CAP that pushes the calendaring logic to the store?  Most collaboration products such as Notes, GroupWise and Exchange already implement calendaring logic that would facilitate a 'CAP Thin Client ' protocol with real-time transport.  A thin cient busy search could request information and receive immediate results.  A meeting could be scheduled in a single command that created the organizer's entry, created each local target's entry and converted external targets into an SMTP/iMIP message for external users.  A single command could also be used to tell the store/agent to book a request and create the associated reply...  Is there interest for a CAP thin client protocol or is everyone content with the thick client approach?

>>  Or is the calendar store the
>> component that must validate the signature on the MIME?
>
>The CS is not an MUA, so no. All iCalendar objects are MIME
>objects, iCalendar objects are not 822 messages.
>
>> It seems like
>> the entire signed MIME rather than just the iTIP object should be passed
>> to the CS when an iTIP request was delivered via email.  Or from another
>> perspective... how does the CS know that the CUA/MUA has validated the
>> signature before passing the iTIP object to the calendar store?
>
>It does not.
>
That's unfortunate for administrators; instead of choosing a secure calendar store, they must now concern themselves with every possible CAP client that might run against the calendar store.
 
>--
>
>  Doug Royer                     |   http://INET-Consulting.com
>  -------------------------------|-----------------------------
>  Doug@Royer.com                 | Office: (208)612-INET
>  http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                 |   Cell: (208)520-4044
>
>                 We Do Standards - You Need Standards
>
--=_Boundary_0-- From owner-ietf-calendar@mail.imc.org Thu May 15 02:49: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 CAA28854 for ; Thu, 15 May 2003 02:49: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 h4F6hiAF061399 for ; Wed, 14 May 2003 23:43: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 h4F6hijG061398 for ietf-calendar-bks; Wed, 14 May 2003 23:43:44 -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 h4F6hhAF061366 for ; Wed, 14 May 2003 23:43:43 -0700 (PDT) (envelope-from jparker@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Thu, 15 May 2003 00:43:06 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 15 May 2003 00:43:20 -0600 From: "Jay Parker" To: , Subject: Re: iTIP REPLY question Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_Boundary_0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_Boundary_0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> Doug@royer.com 05/06 10:17 AM >>> >> > > How do I access the other CS? >> > >> > If the ORGANIZER property is a CAP uri, then open a connection >> > to that uri. >> >> Will this work for the case where CS's are behind firewalls and thus not >> necessarily exposed to external DNS servers? >> >> Can you at INET-consulting.com resolve my alice.iris.com CAP server? > >If you set your ORGANIZER property value to CAP:alice.iris.com, I would >expect to be able to CAP reply to that address. > >> You'll probably get "Unknown host" from your DNS server. So what >> should your CUA do at that point? > >I would call you on the phone and tell you you sent me a bogus >CAP object. Then delete the object from my store. > This is where it would be nice to be able to specify both an email address and a CAP uri for the organizer property. The CUA could try the CAP uri and then fall back to the email address after getting the "Unknown host error" >I do not see that it is any different than if you set your >ORGANIZER property value to mailto:bruce@alice.iris.com. It >would bounce or not be sent when the MUA/CUA tried to look up the >MX record for alice.iris.com. The difference is in the probability of seeing the error with each method. Our customers rarely expose their calendar stores outside the firewall, but all of them with whom I've communicated have a valid email 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 > --=_Boundary_0 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: 8bit
>>> Doug@royer.com 05/06 10:17 AM >>>


<SNIP>
>>  > > How do I access the other CS?
>>  >
>>  > If the ORGANIZER property is a CAP uri, then open a connection
>>  > to that uri.
>>
>> Will this work for the case where CS's are behind firewalls and thus not
>> necessarily exposed to external DNS servers? 
>>
>> Can you at INET-consulting.com resolve my alice.iris.com CAP server?
>
>If you set your ORGANIZER property value to CAP:alice.iris.com, I would
>expect to be able to CAP reply to that address.
>
>>  You'll probably get "Unknown host" from your DNS server.  So what
>> should your CUA do at that point?
>
>I would call you on the phone and tell you you sent me a bogus
>CAP object. Then delete the object from my store.
>
This is where it would be nice to be able to specify both an email address and a CAP uri for the organizer property.  The CUA could try the CAP uri and then fall back to the email address after getting the "Unknown host error"

>I do not see that it is any different than if you set your
>ORGANIZER property value to mailto:bruce@alice.iris.com. It
>would bounce or not be sent when the MUA/CUA tried to look up the
>MX record for alice.iris.com.
 
The difference is in the probability of seeing the error with each method.  Our customers rarely expose their calendar stores outside the firewall, but all of them with whom I've communicated have a valid email 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
>
--=_Boundary_0-- From owner-ietf-calendar@mail.imc.org Thu May 15 16:16: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 QAA21890 for ; Thu, 15 May 2003 16:16: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 h4FJwCAF025069 for ; Thu, 15 May 2003 12:58: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 h4FJwCWx025068 for ietf-calendar-bks; Thu, 15 May 2003 12:58: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 h4FJwAAF025060 for ; Thu, 15 May 2003 12:58: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 h4FJw82m000931 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 15 May 2003 12:58:11 -0700 Message-ID: <3EC3F147.6010706@Royer.com> Date: Thu, 15 May 2003 13:57:59 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050802060308000506010901" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050802060308000506010901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jay Parker wrote: > From 4.2.2... > > " CARID:READBUSYTIMEINFO - Specifies the "GRANT" and "DENY" rules that > allow UPNs to search "VFREEBUSY" components." > > If I understand it correctly, the iTIP steps for UserA performing a busy > search of UserB's calendar are as follows: > 1. UserA creates an iTIP REQUEST for VFREEBUSY and stores it in UserB's > calendar > 2. UserB's CUA (or a bot) processes the request and creates an iTIP > REPLY with VFREEBUSY information and stores it in UserA's calendar > 3. UserA queries his calendar for VFREEBUSY replies to his request and > processes them. > > Does READBUSYTIMEINFO apply to all 3 steps in the process? It applies to search. So if they VQUERY for VFREEBUSY the VCAR applies. > It seems to only apply to step 3 when UserA SEARCHES his calendar for > the replies. What am I missing? Nothing, you are correct. > I would have expected a CARID:UPDATEBUSYTIMEINFO or > something similar. There is a VCAR called REQUESTONLY which is would apply to your step (1) above. > True, the returned VFREEBUSY REPLY is not booked, but neither is the > VEVENT REPLY that is created. Isn't it the CUA processing the REPLY > that would need the UPDATEPARTSTATUS rights? Yes, the UPDATEPARTSTATUS rights would allow or block a CUA from just updating the currently authenticated UPN's entries PARTSTAT parameter value in the TARGET. > The CAP draft does not specify which rights would apply for each iTIP > step of a busy search or of an appointment request/Accept secquence. If > someone would like to take a stab at it, I'd greatly appreciate the > detailed response. So far no such proposal has been made. > >> > >> > >> OK. We can use the word apply. > >> > >>>>Does this right cover both VEVENT and VFREEBUSY components? > >>> > >>>The text in CAP says "... in any components ..." if this question > >>>applies to UPDATEPARTSTATUS. > >>> > >> > >> So the pre-defined CARID:UPDATEPARTSTATUS VCAR does not 'apply' to > >> VFREEBUSY components in an iTIP free busy reply because the VFREEBUSY > >> request did not create a 'booked' VFREEBUSY item in the originators > >> calendar? > > > >No, because that is not how it is defined in section 4.2.2. > >And because VFREEBUSY does not have an ATTENDEE property as > >described in 4.2.2 / UPDATEPARTSTATUS. > > CARID:READBUSYTIMEINFO in 4.2.2 specifies the right to "search" > VFREEBUSY components. Does that also imply the right to request them > or create them in response to a request? If not what does? It allows for search rights only. > > > >A CS does not accept iMIP objects directly, they always come > >from a CUA (automated or not). So it is up to the CUA > >to map e-mail addresses to/from UPNs for authentication. > > > > Hmmm... Yet another requirement on the CAP client that could be > implemented at the store.... > > Are there any efforts underway for a thin client version of CAP that > pushes the calendaring logic to the store? No, it would have to push is to a CUA that did the work for the thin client. The same as if you wanted a WEB calendar. You would need to implement a CUA that took HTTP requests and send them to the CS. The terms 'CUA' and 'CS' are conceptual things, there is nothing to keep them from being built into one binary program. > Most collaboration products > such as Notes, GroupWise and Exchange already implement calendaring > logic that would facilitate a 'CAP Thin Client ' protocol with real-time > transport. A thin cient busy search could request information and > receive immediate results. A meeting could be scheduled in a single > command that created the organizer's entry, created each local target's > entry and converted external targets into an SMTP/iMIP message for > external users. A single command could also be used to tell the > store/agent to book a request and create the associated reply... Is > there interest for a CAP thin client protocol or is everyone content > with the thick client approach? The same with an MUA. There is no reason that you could not combine a MUA + CUA, CUA + CS, MUA + CUA + CS into one binary program. However they are separate layers as far as the protocol and interoperability is concerned. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050802060308000506010901 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MTUxOTU3NTlaMCMGCSqGSIb3DQEJBDEWBBQG AodCFXnmi8YpK4IK/t2lmfQG0zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAhsCAvp+j1cFB FZX1oXveekMz+zax2TgLh1MWWPiifIEUwA+YLYSJIWDuZgcySasNZDEiRKCChiCd057hlxdL 9FUW+IpdipfPAy64aOPibogeRp9eRiUqpyePyUMPGs6NFpYBUV1SyQxYTo49bLa3fvCrUBsT etr6lQVSv0f3EyYdMacczWH/hQI+AIaOOolBZEEsaN7Mp+BLGfjXboiNWi9WTyiTRd4XJuJ8 0IwUMotKSFh0fVY0I/dlKyANxYWd7wkw/hRLmLF/yu8XvY1kwyxehRORfeSNwspkdD7XwxCN bcCaEe+0WwuxazE7zEgLZbke82ZFRJUkPafM2+B1TwAAAAAAAA== --------------ms050802060308000506010901-- From owner-ietf-calendar@mail.imc.org Thu May 15 16:31: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 QAA22287 for ; Thu, 15 May 2003 16:31: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 h4FK8IAF025485 for ; Thu, 15 May 2003 13:08: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 h4FK8IPY025484 for ietf-calendar-bks; Thu, 15 May 2003 13:08: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 h4FK8HAF025477 for ; Thu, 15 May 2003 13:08: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 h4FK8F2m000998 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 15 May 2003 13:08:18 -0700 Message-ID: <3EC3F3AA.2080402@Royer.com> Date: Thu, 15 May 2003 14:08:10 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020303050002020309070007" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020303050002020309070007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > > This is where it would be nice to be able to specify both an email > address and a CAP uri for the organizer property. The CUA could try the > CAP uri and then fall back to the email address after getting the > "Unknown host error" For any known UPN that can authenticate to your system, your calendar administrator would have created or allowed them to create an account. You could require their e-mail address at the time of registration, verified by an auto reply scripts. Now just map them to their registration information (I use their email address as their UPN). The same is true for their CAP url, ask for it and if they have one, test it at registration time. > >I do not see that it is any different than if you set your > >ORGANIZER property value to mailto:bruce@alice.iris.com. It > >would bounce or not be sent when the MUA/CUA tried to look up the > >MX record for alice.iris.com. > > The difference is in the probability of seeing the error with each > method. Our customers rarely expose their calendar stores outside the > firewall, but all of them with whom I've communicated have a valid email > address. True but the problem is the same. Ether the host is visable, not visable, known, or not known. In Bruces example he compared a visable and known MX host to an invisable and unknown CAP host. Not an apples to apples comparison. If I set my MX record to an invisable host or to a not known host, I would not get email replies - same problem - so don't do that. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020303050002020309070007 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MTUyMDA4MTBaMCMGCSqGSIb3DQEJBDEWBBTI wncuKGjalMbG8kQSxzMwbUoaNTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAJyB+DnsKO5m/ /fyNh+5D6B++7lPziSx63F6YG4kNizcdaaXxhCThjX3Z+JxHKWQqclwEKZdtl+MK0Coo4oXb FQs/9c8q8PumZklm2dCNwxj7fFG+b9Z3bVa3d8+bw3l2i9o4CcQOhnRmKMm3+JXFGfx64+CQ NuIPWHaXAC5fzDcT0CTuibumE710pOZJEzSDqqwTlzLSkG1dPBhpipTjKYjSgS4X9+tg3mYV 1Nj+YOI28JIR9JBkTVF7xAwZ4IpGXr0eRxL529kCVrNeOiGHU3UZZUj8yi/Tlsm4yjlhBKKJ 8Er8h7p8icTPQYornIBNsU7yBsNXhiyWtArVo8YzSQAAAAAAAA== --------------ms020303050002020309070007-- From owner-ietf-calendar@mail.imc.org Thu May 15 16: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 QAA22645 for ; Thu, 15 May 2003 16:43: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 h4FKQeAF026786 for ; Thu, 15 May 2003 13:26: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 h4FKQeQw026785 for ietf-calendar-bks; Thu, 15 May 2003 13:26:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FKQdAF026776 for ; Thu, 15 May 2003 13:26:39 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id 562A73F822 for ; Thu, 15 May 2003 22:17:18 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id 78BA02DC; Thu, 15 May 2003 22:26:33 +0200 (MET DST) To: ietf-calendar@imc.org From: gustav.mango@safecareab.com Subject: Re: Re: iTIP REPLY question Message-Id: <20030515202633.78BA02DC@nw-pop4.wineasy.se> Date: Thu, 15 May 2003 22:26:33 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Fri May 16 10:19: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 KAA27010 for ; Fri, 16 May 2003 10:19: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 h4GDsJAF094423 for ; Fri, 16 May 2003 06:54: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 h4GDsJdk094422 for ietf-calendar-bks; Fri, 16 May 2003 06:54: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GDsIAF094384 for ; Fri, 16 May 2003 06:54:18 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EB7E030.10506@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 16 May 2003 09:54:13 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/16/2003 09:54:07 AM, Serialize complete at 05/16/2003 09:54:07 AM Content-Type: multipart/alternative; boundary="=_alternative 004C2CDD85256D28_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004C2CDD85256D28_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 05/06/2003 12:17:52 PM: Pardon the lag, I only can use my personal spare time these days to stay involved... > > > It is possible that they want you to connect anonymously. > > > > Are you suggesting that a CUA SHOULD try to connect and CREATE the REPLY > > and if that fails that the CUA change their identity to 'anonymous' and > > retry the command? I would think that allowing 'anonymous' > > authenticated users to CREATE documents in a calendar would be less than > > desirable because there is no way to authenticate the identity against > > the contents of the message. If I intercepted or guessed that you and > > John were having a meeting I could anonymously DECLINE on Johns behalf > > even though really ACCEPTed previously. Hmm, sounds like potential for > > lots of hacker fun... > > I am suggesting that it is an option. Within a company and inside > a firewall - why not? Check the stats frequently cited in IT circles and the media: not all IT threats come from without, MOST come from within! You hear about external attacks because they cannot be covered up as easily; internal attacks are much much easier for a company to hush up. If we worked at the same company and I had a grudge against you I could mess w/your calendar anonymously just because I can and because I didnt like the color of your hair (not true but for demonstration purposes lets say it is). Or I decide to get some payback to those higher ups that got big bonuses this year while I got a pot luck lunch on the lawn. If I could _anonymously_ CREATE litterally hundreds or thousands of bogus DECLINEs I would eventually be able to get 'a hit' and easily cause you problems. Maybe recoverble, maybe not. The point is that there are no demonstratable cases where _anonymous_ users have the legit need to CREATE content in someone elses calendar. After all, why would I want you to _anonymously_ authenticate w/my CS and then CREATE the ACCEPTance message in my calendar for a meeting that you were invited to? You need to do this anonymously even though you were an ATTENDEE?... I got news for you I will NEVER EVER allow anonymous access to my calendar for ANY PURPOSE (reading or writing!). Wont happen and any sane user out there likely feels the same way. There may be a case out there where its useful but I cannot think of one and I doubt most here can either. If this is a case of 99.99 to .01 Id say "margin of error" and toss the ability. Then again we could probably say that an alternative means to this is to allow a CS to claim "its against CS policy to allow anonymous users to CREATE" and reject the command and assume CS developers think of this when they code 'em up... Yeah, that sounds secure.... > > Anonymous access _is_ useful for public calendars or for "announcement" > > kinds of calendars but not for any serious C&S workflow because of the > > potential for hacking and disruption. > > On the outside of a firewall - YES. Inside the firewall too! We have internal servers set up as "bulletin boards" where folks can anonymously browse all kinds of information including montly calendars of events at sites, etc. Reading from them can be done anonymously, putting content on them cannot. > > > > How do I access the other CS? > > > > > > If the ORGANIZER property is a CAP uri, then open a connection > > > to that uri. > > > > Will this work for the case where CS's are behind firewalls and thus not > > necessarily exposed to external DNS servers? > > > > Can you at INET-consulting.com resolve my alice.iris.com CAP server? > > If you set your ORGANIZER property value to CAP:alice.iris.com, I would > expect to be able to CAP reply to that address. You are assuming that because my CUA was able to get outside the firewall and reach your CS somehow that your CUA MUST be able to both find and contact my CS to return the REPLY. This is NOT necessarily true. Companys have few qualms about allowing outbound access by their people (ie: HTTP or SOCKS proxying) but they have cast in diamond (harder than stone!) rules against allowing external access to their internal networks let alone servers. As such I would be able to reach your CS (assuming you allow access to your servers from outside your firewall!) but you have a snowballs chance in a nuclear blast of even getting the IP of my CS and reaching it from your CUA. Unlike mail which has pretty well understood processes/needs and does not require exposing internal networks/servers directly to outsiders, CAP has an implic limitation that every CS involved must be directly reachable by the CUAs involved (remember, we took out 'fan out' and this is one side effect of that). As such CAP only works as intended if companies expose their networks/servers and thats going to be a hard sell, especially to larger companies. > > You'll probably get "Unknown host" from your DNS server. So what > > should your CUA do at that point? > > I would call you on the phone and tell you you sent me a bogus > CAP object. Then delete the object from my store. Its NOT bogus! It was perfectly formed and properly routed from my CUA to your CS. Just because you cannot get to my CS does not mean the CAP object is bad! If I had used a CS that is not valid (alice.iris.com is valid) or the data in the CAP object was bad then Id agree. However its 100% correct to EVERYONE ELSE who can reach my CS so how does that make the object bad? If your CUA can process the REQUEST just fine then how is it bad? Its not a problem w/the data; its a problem in the design/expectations. > I do not see that it is any different than if you set your > ORGANIZER property value to mailto:bruce@alice.iris.com. It > would bounce or not be sent when the MUA/CUA tried to look up the > MX record for alice.iris.com. Your mailer can lookup the MX record for iris.com and then send the REPLY to me there. When it arrived at that server it knows how to reach alice.iris.com and off the REPLY goes again to the next hop or to alice.iris.com itself. The comparison you use though is not that viable since mail is store/foreward and by defintiion CAP is point to point only. Mail systems have all kinds of routing rules they can be configured with to get the message to the proper address. CAP has nothing regarding this because all CAP is done CUA <-> CS and the CUA is responsible for contacting each CS in turn. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 004C2CDD85256D28_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 05/06/2003 12:17:52 PM:
Pardon the lag, I only can use my personal spare time these days to stay involved...

> >  > It is possible that they want you to connect anonymously.
> >
> > Are you suggesting that a CUA SHOULD try to connect and CREATE the REPLY
> > and if that fails that the CUA change their identity to 'anonymous' and
> > retry the command?  I would think that allowing 'anonymous'
> > authenticated users to CREATE documents in a calendar would be less than
> > desirable because there is no way to authenticate the identity against
> > the contents of the message.  If I intercepted or guessed that you and
> > John were having a meeting I could anonymously DECLINE on Johns behalf
> > even though really ACCEPTed previously.  Hmm, sounds like potential for
> > lots of hacker fun...
>
> I am suggesting that it is an option. Within a company and inside
> a firewall - why not?
Check the stats frequently cited in IT circles and the media:  not all IT threats come from without, MOST come from within!  You hear about external attacks because they cannot be covered up as easily; internal attacks are much much easier for a company to hush up.

If we worked at the same company and I had a grudge against you I could mess w/your calendar anonymously just because I can and because I didnt like the color of your hair (not true but for demonstration purposes lets say it is).  Or I decide to get some payback to those higher ups that got big bonuses this year while I got a pot luck lunch on the lawn.  

If I could _anonymously_ CREATE litterally hundreds or thousands of bogus DECLINEs I would eventually be able to get 'a hit' and easily cause you problems.  Maybe recoverble, maybe not.  The point is that there are no demonstratable cases where _anonymous_ users have the legit need to CREATE content in someone elses calendar.  After all, why would I want you to _anonymously_ authenticate w/my CS and then CREATE the ACCEPTance message in my calendar for a meeting that you were invited to?   You need to do this anonymously even though you were an ATTENDEE?...

I got news for you I will NEVER EVER allow anonymous access to my calendar for ANY PURPOSE (reading or writing!).  Wont happen and any sane user out there likely feels the same way.  There may be a case out there where its useful but I cannot think of one and I doubt most here can either.

If this is a case of 99.99 to .01 Id say "margin of error" and toss the ability.  Then again we could probably say that an alternative means to this is to allow a CS to claim "its against CS policy to allow anonymous users to CREATE" and reject the command and assume CS developers think of this when they code 'em up...  Yeah, that sounds secure....

> > Anonymous access _is_ useful for public calendars or for "announcement"
> > kinds of calendars but not for any serious C&S workflow because of the
> > potential for hacking and disruption.
>
> On the outside of a firewall - YES.
Inside the firewall too!  We have internal servers set up as "bulletin boards" where folks can anonymously browse all kinds of information including montly calendars of events at sites, etc.  Reading from them can be done anonymously, putting content on them cannot.

> >  > > How do I access the other CS?
> >  >
> >  > If the ORGANIZER property is a CAP uri, then open a connection
> >  > to that uri.
> >
> > Will this work for the case where CS's are behind firewalls and thus not
> > necessarily exposed to external DNS servers?  
> >
> > Can you at INET-consulting.com resolve my alice.iris.com CAP server?
>
> If you set your ORGANIZER property value to CAP:alice.iris.com, I would
> expect to be able to CAP reply to that address.
You are assuming that because my CUA was able to get outside the firewall and reach your CS somehow that your CUA MUST be able to both find and contact my CS to return the REPLY.  This is NOT necessarily true.  

Companys have few qualms about allowing outbound access by their people (ie: HTTP or SOCKS proxying) but they have cast in diamond (harder than stone!) rules against allowing external access to their internal networks let alone servers.  As such I would be able to reach your CS (assuming you allow access to your servers from outside your firewall!) but you have a snowballs chance in a nuclear blast of even getting the IP of my CS and reaching it from your CUA.

Unlike mail which has pretty well understood processes/needs and does not require exposing internal networks/servers directly to outsiders, CAP has an implic limitation that every CS involved must be directly reachable by the CUAs involved (remember, we took out 'fan out' and this is one side effect of that).  As such CAP only works as intended if companies expose their networks/servers and thats going to be a hard sell, especially to larger companies.

> >  You'll probably get "Unknown host" from your DNS server.  So what
> > should your CUA do at that point?
>
> I would call you on the phone and tell you you sent me a bogus
> CAP object. Then delete the object from my store.
Its NOT bogus!  It was perfectly formed and properly routed from my CUA to your CS.  Just because you cannot get to my CS does not mean the CAP object is bad!  If I had used a CS that is not valid (alice.iris.com is valid) or the data in the CAP object was bad then Id agree.  However its 100% correct to EVERYONE ELSE who can reach my CS so how does that make the object bad?  If your CUA can process the REQUEST just fine then how is it bad?  Its not a problem w/the data; its a problem in the design/expectations.

> I do not see that it is any different than if you set your
> ORGANIZER property value to mailto:bruce@alice.iris.com. It
> would bounce or not be sent when the MUA/CUA tried to look up the
> MX record for alice.iris.com.
Your mailer can lookup the MX record for iris.com and then send the REPLY to me there.  When it arrived at that server it knows how to reach alice.iris.com and off the REPLY goes again to the next hop or to alice.iris.com itself.

The comparison you use though is not that viable since mail is store/foreward and by defintiion CAP is point to point only.  Mail systems have all kinds of routing rules they can be configured with to get the message to the proper address.  CAP has nothing regarding this because all CAP is done CUA <-> CS and the CUA is responsible for contacting each CS in turn.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 004C2CDD85256D28_=-- From owner-ietf-calendar@mail.imc.org Fri May 16 12:43: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 MAA02314 for ; Fri, 16 May 2003 12:43: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 h4GGNRAF002409 for ; Fri, 16 May 2003 09:23: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 h4GGNRr1002408 for ietf-calendar-bks; Fri, 16 May 2003 09:23:27 -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 h4GGNPAF002403 for ; Fri, 16 May 2003 09:23: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 M2003051612291131298 for ; Fri, 16 May 2003 12:29:11 -0400 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 May 2003 12:20:54 -0400 Message-ID: <3EC50FE6.7020900@centive.com> Date: Fri, 16 May 2003 12:20:54 -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: iTIP REPLY question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2003 16:20:54.0475 (UTC) FILETIME=[1FEFB1B0:01C31BC7] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > I got news for you I will NEVER EVER allow anonymous access to my > calendar for ANY PURPOSE (reading or writing!). Agreed. > Unlike mail which has pretty well understood processes/needs and does > not require exposing internal networks/servers directly to outsiders, > CAP has an implic limitation that every CS involved must be directly > reachable by the CUAs involved (remember, we took out 'fan out' and > this is one side effect of that). Right. As I recall, we took out fan-out in part because we didn't want to cope with the complexities of proxying requests with authentication. So we've replaced the difficulties of domain-to-domain authentication with the much larger difficulties of user-to-foreign-domain authentication. Since this is a problem that's essentially unsolvable without a PKI, we've wound up with a mechanism that's unacceptable between domains, so people are going to have to drop back to email--where you still don't have any authentication, but at least your request has to look plausible to the user. Actually, if we *require* the CUA to use the CS to do fan-out, we can get a fairly simple interdomain authentication mechanism. If I get a message from a foreign CS, claiming to be from foo@example.com (never mind the syntax for now), I do the SRV lookup to verify that the source address is a CS for example.com. (For an extra level of protection, I can actually connect to the CS specified in the SRV, and do some sort of cookie exchange to verify that I'm talking to the same entity that contacted me, instead of J. Random Process on the same host.) Now, in theory, it is possible for someone to crack the CS for example.com and send messages masquerading as foo@example.com. But, if they crack the CS, then they can do that no matter *what* authentication system we come up with. This is an idea that came out of the IMPP discussions in 1999; the key point is that the owner of a domain is the ultimate authority on names allocated from that domain's namespace, and there is no point trying to gainsay that authority. If I get a message that I can verify as being from the designated CS for example.com, and that designated CS asserts that the message is from foo@example.com, that assertion is a tautology. Of course, if you want assurances that a message is from a specific *person*, then you need a PKI; but this simple proxy authentication is good enough to prevent most types of spoofing (e.g., sending an ACCEPT that purports to be from foo@example.com but isn't), and to ensure accountability for spamming. Better than iMIP, anyway. -- /==========================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==========================================| |You buttered your bread, now lie in it. | \==========================================/ From owner-ietf-calendar@mail.imc.org Fri May 16 13:33: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 NAA04463 for ; Fri, 16 May 2003 13:33: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 h4GHEEAF008811 for ; Fri, 16 May 2003 10:14: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 h4GHEEm3008810 for ietf-calendar-bks; Fri, 16 May 2003 10:14: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 h4GHEDAF008805 for ; Fri, 16 May 2003 10:14: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 h4GHE9Wf010175 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 16 May 2003 10:14:13 -0700 Message-ID: <3EC51C58.80502@Royer.com> Date: Fri, 16 May 2003 11:14:00 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070607030005040301050803" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070607030005040301050803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > I got news for you I will NEVER EVER allow anonymous access to my > calendar for ANY PURPOSE (reading or writing!). I think that is your point. Well CAP has anonymous UPS. So your are debating policy and not protocol. Which is fine. However your policy does not negate the issue. And they did imply policy with their question. So - yes you can do that. Many will not allow that. Many public read-only calendar will however allow anonymous access to view public calendars and many will 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 --------------ms070607030005040301050803 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MTYxNzE0MDBaMCMGCSqGSIb3DQEJBDEWBBQb ngTKeD0Ictq6skuXfzJpi8FLRDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAWhL8PE5u0GPW GIPETdbrKs9CRpEdN0FeUSH0LaH3NUUHAMHv7moeqqxCMs+afuncI0dH4NbHKN0QaSeCN2Aa FGspdFXHzR/x5f2hzFXeks4zcIk+iwbn48NYS1bJI0rDzVLIgRSV9YoYTyz/t3Mi7CBUQIXT RNKagIR5r9v/6eNyVQk0qsPTVaUIquLJjkFHjHwqMW/Jfsj+VVI5TbG8FTwV+Xw23NVCMLW5 cv5/p69l80P1UG7OSCc7iax4rHd8ka5eHjaSOZRqiUeGoFh3PnNZSwe55Ic0aHA2SdiP/fBt 1I2i227EQiUFUkOrevjCRLrU4JNqOPjmOJM3QRqOMwAAAAAAAA== --------------ms070607030005040301050803-- From owner-ietf-calendar@mail.imc.org Fri May 16 14:00: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 OAA05334 for ; Fri, 16 May 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 h4GHi0AF009677 for ; Fri, 16 May 2003 10:44: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 h4GHi0mO009676 for ietf-calendar-bks; Fri, 16 May 2003 10:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GHhxAF009668 for ; Fri, 16 May 2003 10:44:00 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id 7D8E73F8DB for ; Fri, 16 May 2003 19:34:38 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id C8C5F601; Fri, 16 May 2003 19:43:55 +0200 (MET DST) To: "ietf-calendar@imc.org" From: gustav.mango@safecareab.com Subject: Re: Re: iTIP REPLY question Message-Id: <20030516174355.C8C5F601@nw-pop4.wineasy.se> Date: Fri, 16 May 2003 19:43:55 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Mon May 19 12:24: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 MAA26212 for ; Mon, 19 May 2003 12:24: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 h4JFqOAF045192 for ; Mon, 19 May 2003 08:52: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 h4JFqOMg045191 for ietf-calendar-bks; Mon, 19 May 2003 08:52:24 -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 h4JFqIAF045185 for ; Mon, 19 May 2003 08:52:18 -0700 (PDT) (envelope-from PStephenson@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Mon, 19 May 2003 09:51:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Mon, 19 May 2003 09:51:34 -0600 From: "Preston Stephenson" To: Subject: Follow up to BEEP and CAP - one-to-many Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I just need a little clarification on some postings from last year. Section 10.1.4 CREATE Command The replies from the different targets. Is this an example of a BEEP MSG/ANS,ANS,NUL exchange? In the case of a BEEP MSG/RPY exchange, would the two VCALENDAR objects be in one text/calendar mime? S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR S: VERSION:2.0 S: PRODID:-//someone's prodid S: CMD;ID=creation02:REPLY S: TARGET:relcalz1 <- 1st TARGET listed. S: BEGIN:REPLY <- Reply for 1st VEVENT create in 1st TARGET. S: UID:FirstInThisExample-1 S: REQUEST-STATUS:2.0 S: END:VREPLY S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 1st TARGET. S: UID:SecondInThisExample-2 S: REQUEST-STATUS:2.0 S: END:VREPLY S: END:VCALENDAR S: BEGIN:VCALENDAR S: VERSION:2.0 S: PRODID:-//someone's prodid S: CMD;ID=creation02:REPLY S: TARGET:relcalz2 <- 2nd TARGET listed S: BEGIN:REPLY <- Reply for 1st VEVENT create in 2nd TARGET. S: UID:FirstInThisExample-1 S: REQUEST-STATUS:2.0 S: END:VREPLY S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 2nd TARGET. S: UID:SecondInThisExample-2 S: REQUEST-STATUS:2.0 S: END:VREPLY S: END:VCALENDAR Thanks. Preston From owner-ietf-calendar@mail.imc.org Mon May 19 13: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 NAA27353 for ; Mon, 19 May 2003 13: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 h4JGr3AF048028 for ; Mon, 19 May 2003 09: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 h4JGr3Jt048027 for ietf-calendar-bks; Mon, 19 May 2003 09:53: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 h4JGr2AF048021 for ; Mon, 19 May 2003 09:53:02 -0700 (PDT) (envelope-from vicky.oliver@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 h4JGqwHN023767 for ; Mon, 19 May 2003 09:52:58 -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 h4JGqr6f020042 for ; Mon, 19 May 2003 09:52:53 -0700 (PDT) Received: from sun.com (ajajin.red.iplanet.com [192.18.146.63]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HF500196885KK@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Mon, 19 May 2003 09:52:53 -0700 (PDT) Date: Mon, 19 May 2003 09:50:12 -0700 From: "V. Oliver" Subject: Correct handling of Recurrence-id To: ietf-calendar@imc.org Message-id: <3EC90B44.9020209@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Resending (I apologize if this ends up as a duplicate, but I didn't see the first submission come through). I am hoping that someone can clarify the correct use of Recurrence-id in recurring calendar components. Specifically, what is the correct value to use when setting the Recurrence-id? RFC 2445, Section 4.8.4.4 "Recurrence ID" seems to contain contradictory statements: "... The property value is the effective value of the "DTSTART" property of the recurrence instance." The meaning of "effective value" is not defined, but could be interpreted to mean the date/time when the instance will occur. However, several paragraphs later: "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 above seems very clear if I change the date/time of a recurring instance, the Recurrence-id is set to the date/time that the instance originally had. Finally, in RFC 2446 (iTIP), Section 3.7.1 "Working With Recurrence Instances" the following paragraph is found: "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." The last sentence in the above paragraph is the interesting one. It clearly states that Recurrence-id will change. But this seems to contradict the paragraph from RFC 2445 that says "... date/time is still set to the original Friday meeting". There is also an example in RFC 2446, Section 4.4.7 "Add A New Series of Instances To A Recurring Event" which would seem to adhere to the description in Section 3.7.1 above. Unfortunately, the example given does not work with an RRULE, but defines the recurring series entirely through a sequence of RDATEs. This may have no effect on the correct setting of Recurrence-id, but it is not entirely clear if that is the case. Here is an example of a sequence of changes to a recurring series. I am leaving out lots of associated fields since I am really interested only in the correct setting of Recurrence-id (and perhaps the EXDATEs and RDATEs) at the moment. The data represents a series of iTIP messages. - there is a "master" component which defines a recurring series through an RRULE. The event occurs weekly on Mondays, starting 5/5/2003 from 6 - 7 pm UTC, with no end date BEGIN:VEVENT UID:12345 SUMMARY:recurring event DTSTART:20030505T180000Z DTEND:20030505T190000Z SEQUENCE:0 RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO;WKST=SU END:VEVENT OPTION 1: recurrence-id never changes (always the very original DTSTART) - Change 1: create one exception to this event by changing the time on 5/12/2003 to 5pm UTC exception (5/12/2003 17:00) : BEGIN:VEVENT UID:12345 RECURRENCE-ID:20030512T180000Z SUMMARY:recurring event DTSTART:20030512T170000Z DTEND:20030512T180000Z SEQUENCE:1 END:VEVENT - Change 2: move the same instance to a different day exception (5/13/2003 17:00): BEGIN:VEVENT UID:12345 RECURRENCE-ID:20030512T180000Z SUMMARY:recurring event DTSTART:20030513T170000Z DTEND:20030513T180000Z SEQUENCE:2 END:VEVENT OPTION 2: the recurrence-id changes - Change 1: exception (5/12/2003 17:00) : BEGIN:VEVENT UID:12345 RECURRENCE-ID:20030512T180000Z SUMMARY:recurring event DTSTART:20030512T170000Z DTEND:20030512T180000Z SEQUENCE:1 END:VEVENT - Change 2: exception (5/13/2003 17:00): BEGIN:VEVENT UID:12345 RECURRENCE-ID:20030512T170000Z SUMMARY:recurring event DTSTART:20030513T170000Z DTEND:20030513T180000Z SEQUENCE:2 END:VEVENT And, finally, if I ask for a REFRESH of the entire component? What should that look like OPTION 1: BEGIN:VCALENDAR BEGIN:VEVENT UID:12345 SUMMARY:recurring event DTSTART:20030505T180000Z DTEND:20030505T190000Z SEQUENCE:1 RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO;WKST=SU EXDATE:20030512T180000Z RDATE;VALUE=DATE-TIME:20030513T170000Z END:VEVENT BEGIN:VEVENT UID:12345 RECURRENCE-ID:20030512T180000Z SUMMARY:recurring event DTSTART:20030513T170000Z DTEND:20030513T180000Z SEQUENCE:2 END:VEVENT END:VCALENDAR OPTION 2: BEGIN:VCALENDAR BEGIN:VEVENT UID:12345 SUMMARY:recurring event DTSTART:20030505T180000Z DTEND:20030505T190000Z SEQUENCE:1 RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO;WKST=SU EXDATE:20030512T180000Z RDATE;VALUE=DATE-TIME:20030513T170000Z END:VEVENT BEGIN:VEVENT UID:12345 RECURRENCE-ID:20030513T170000Z SUMMARY:recurring event DTSTART:20030513T170000Z DTEND:20030513T180000Z SEQUENCE:2 END:VEVENT END:VCALENDAR Which of the two options above is correct? Or is there some third way that is correct? Is there a distinction between recurrence sets whose instances are defined only by RDATEs as opposed to those sets which are defined (primarily) by RRULEs? I'd appreciate any clarification to this problem. From owner-ietf-calendar@mail.imc.org Mon May 19 13:27: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 NAA28008 for ; Mon, 19 May 2003 13:27: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 h4JHClAF050745 for ; Mon, 19 May 2003 10:12: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 h4JHClsn050744 for ietf-calendar-bks; Mon, 19 May 2003 10:12:47 -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 h4JHCjAF050700 for ; Mon, 19 May 2003 10:12:45 -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 M2003051913183124129 for ; Mon, 19 May 2003 13:18:31 -0400 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 May 2003 13:10:14 -0400 Message-ID: <3EC90FF6.1010300@centive.com> Date: Mon, 19 May 2003 13:10:14 -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: Correct handling of Recurrence-id References: <3EC90B44.9020209@sun.com> In-Reply-To: <3EC90B44.9020209@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2003 17:10:14.0132 (UTC) FILETIME=[8344C340:01C31E29] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit V. Oliver wrote: > Note that after the change has occurred, the "RECURRENCE-ID" has changed > to the new "DTSTART" value." > > The last sentence in the above paragraph is the interesting one. It > clearly states that Recurrence-id will change. But this seems to > contradict the paragraph from RFC 2445 that says "... date/time is still > set to the original Friday meeting". These two paragraphs are saying the same thing. They are both referring to changing a recurrence. In the message that describes the change, the old DTSTART is used; after that, the new DTSTART must be used. -- /==========================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==========================================| |What do you mean, *you're* a solipsist? | \==========================================/ From owner-ietf-calendar@mail.imc.org Mon May 19 14:13: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 OAA29294 for ; Mon, 19 May 2003 14:13: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 h4JI0uAF054228 for ; Mon, 19 May 2003 11:00: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 h4JI0ugP054227 for ietf-calendar-bks; Mon, 19 May 2003 11:00: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 h4JI0tAF054222 for ; Mon, 19 May 2003 11:00: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 h4JI0ov3029237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 May 2003 11:00:55 -0700 Message-ID: <3EC91BC8.5090505@Royer.com> Date: Mon, 19 May 2003 12:00:40 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: <3EC90B44.9020209@sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030909020502080404080209" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030909020502080404080209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit V. Oliver wrote: > > Resending (I apologize if this ends up as a duplicate, but I didn't see > the first submission come through). > > I am hoping that someone can clarify the correct use of Recurrence-id in > recurring calendar components. Specifically, what is the correct value > to use when setting the Recurrence-id? > > > RFC 2445, Section 4.8.4.4 "Recurrence ID" seems to contain contradictory > statements: > > "... The property value is the effective value of the "DTSTART" property > of the recurrence instance." > > The meaning of "effective value" is not defined, but could be > interpreted to mean the date/time when the instance will occur. That is what it means. If a repeating component has 10 instances in which it will occur. Then each has instance has a RECURRENCE-ID equivalent to its own start time. > > However, several paragraphs later: > > "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 above seems very clear if I change the date/time of a recurring > instance, the Recurrence-id is set to the date/time that the instance > originally had. That refers to a COUNTER or an new REQUEST or PUBLISH that is updating an instance. You have to give the OLD RECURRENCE-ID in order for the recipients to know the 'from' RECURRENCE-ID that you are changing. It is worded badly. > > Finally, in RFC 2446 (iTIP), Section 3.7.1 "Working With Recurrence > Instances" the following paragraph is found: > > ... > > The last sentence in the above paragraph is the interesting one. It > clearly states that Recurrence-id will change. But this seems to > contradict the paragraph from RFC 2445 that says "... date/time is still > set to the original Friday meeting". During an update to an instance RECURRENCE-ID is used to specify the 'was' instance. After the update RECURRENCE-ID refers to the 'is now' instance. > > There is also an example in RFC 2446, Section 4.4.7 "Add A New Series of > Instances To A Recurring Event" which would seem to adhere to the > description in Section 3.7.1 above. Unfortunately, the example given > does not work with an RRULE, but defines the recurring series entirely > through a sequence of RDATEs. This may have no effect on the correct > setting of Recurrence-id, but it is not entirely clear if that is the case. Given this component: BEGIN:VCALENDAR METHOD:REQUEST (or PUBLISH) ... RDATE: 1-jan... RDATE: 2-jan... UID: 1st SEQ:1 ... END:VCALENDAR Now to ADD one instance: BEGIN:VCALENDAR METHOD:ADD ... RDATE: 3-jan UID: 1st (same UID as original) ... END:VCALENDAR Now if you want to update just ONE instance, supply an RECURRENCE-ID a value that is equivalent to the start time of the one instance you wish to change (change 1-jan to 4-jan): BEGIN:VCALENDAR METHOD: REQUEST RDATE: 4-jan (the new date) SEQ:2 (must be a newer sequence number than recipient has) RECURRENCE-ID: 1-jan (the one you are changing) UID: 1st ... END:VCALENDAR Now to CANCEL an INSTANCE (4-jan): BEGIN:VCALENDAR METHOD:CANCEL ... RECURRENCE-ID: 4-jan (the instance to be canceled) UID: 1st SEQ:2 ... END:VCALENDAR RECURRENCE-ID is not really a part of the persistent object. It is a handle to refer to an instance within a context in time with a known sequence. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030909020502080404080209 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MTkxODAwNDFaMCMGCSqGSIb3DQEJBDEWBBRO Hoe31abzjlM2qSjd5W6EPm1HNjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEARFC00LChn9Rx RA/bWYRICJyUsDkM8jImH5BYetT8SBR5VTQhtJZ+4AP9btfZvsndAunyN2cql5gKNthkUO7l mVhH8Z5YVY5eH7Bn6br1fVKdIsOQHlzfGZe3AQGRP4fHITUIJX2+yn44ZiR+z5M+TxH+ycIh aLACTO7MQXanPOq9tQU4w60Jioy2fBkLdAqygGFwuZY9ZUnRbc8/awUAulRx2zP4z65R/vCW wmFEVaEpErQoWGA5qN+tWxTATfmLUdwN0D8fNOALDfsz/dzvXv/tcpS58Yrq7kxldbBpR4zk UpCox4+h6RgKMwHdqbHT0IP1TeHjLxuoik+DoFBOUwAAAAAAAA== --------------ms030909020502080404080209-- From owner-ietf-calendar@mail.imc.org Mon May 19 14:32:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29859 for ; Mon, 19 May 2003 14:32: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 h4JIBPAF054495 for ; Mon, 19 May 2003 11:11: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 h4JIBPYH054494 for ietf-calendar-bks; Mon, 19 May 2003 11:11: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 h4JIBOAF054489 for ; Mon, 19 May 2003 11:11: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 h4JIBJv3029334 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 May 2003 11:11:23 -0700 Message-ID: <3EC91E3E.6030503@Royer.com> Date: Mon, 19 May 2003 12:11:10 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Follow up to BEEP and CAP - one-to-many References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050901030007080007020902" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050901030007080007020902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: > I just need a little clarification on some postings from last year. > > Section 10.1.4 CREATE Command > The replies from the different targets. > > Is this an example of a BEEP MSG/ANS,ANS,NUL exchange? > > In the case of a BEEP MSG/RPY exchange, would the two VCALENDAR objects > be in one text/calendar mime? Yes it could be. You can have multiple VCALENDARS in each MIME object. You can have multiple MIME objects, each with any valid MIME object using MULTIPART/ and possibly nested. However as the topic is CAP, it is assumed that at least one of the MIME objects will be an iCalendar 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 --------------ms050901030007080007020902 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MTkxODExMTBaMCMGCSqGSIb3DQEJBDEWBBR/ wrCD8vO+LVJNC4F3ZckSJNKNsDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAbSD6Se+T9mrt ncMGhqwFjPJIvVlHuu34Nb4Jl6876LuyBF2LR0ijqDIg4VYBfugs22P0551gIU2CzIDIjzD7 j5emhWrqic91DmqkcwPFyubajFaq9vE6Q6lSoYU/BQ9aFtWd+XS5tE/Te/vlPPnifJOJllst ijH/sVor8tOARzkITq1Ld98G8sfK1FdJqd4U0VVWZcMqnEW18k/pkuxNWBoadyT/0E3gLN2g mC0H1EOPEC0/7nB19HeOvwdmrCdF9ebPFiCMpgjVqX3JnhR7MGrtTsYcdBHiOJRn7xZRAvNM iJ+wjICxD4mDFRS+iSkPQtnNha1xEEjFlQwz/sE6dwAAAAAAAA== --------------ms050901030007080007020902-- From owner-ietf-calendar@mail.imc.org Mon May 19 14:32:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29858 for ; Mon, 19 May 2003 14:32: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 h4JILPAF054983 for ; Mon, 19 May 2003 11:21: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 h4JILPIg054982 for ietf-calendar-bks; Mon, 19 May 2003 11:21:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JILOAF054977 for ; Mon, 19 May 2003 11:21:24 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id 63ADE3F9B4 for ; Mon, 19 May 2003 20:11:51 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id CBC96302; Mon, 19 May 2003 20:21:15 +0200 (MET DST) To: ietf-calendar@imc.org From: gustav.mango@safecareab.com Subject: Re: Re: Correct handling of Recurrence-id Message-Id: <20030519182115.CBC96302@nw-pop4.wineasy.se> Date: Mon, 19 May 2003 20:21:15 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Mon May 19 14:39: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 OAA00199 for ; Mon, 19 May 2003 14:39: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 h4JIIrAF054904 for ; Mon, 19 May 2003 11: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 h4JIIrGu054903 for ietf-calendar-bks; Mon, 19 May 2003 11:18:53 -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 h4JIInAF054897 for ; Mon, 19 May 2003 11:18:51 -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 M2003051914244307244 for ; Mon, 19 May 2003 14:24:43 -0400 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 May 2003 14:16:25 -0400 Message-ID: <3EC91F79.1070408@centive.com> Date: Mon, 19 May 2003 14:16:25 -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: Correct handling of Recurrence-id References: <3EC90B44.9020209@sun.com> <3EC91BC8.5090505@Royer.com> In-Reply-To: <3EC91BC8.5090505@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2003 18:16:25.0712 (UTC) FILETIME=[C283C700:01C31E32] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > V. Oliver wrote: > >> The meaning of "effective value" is not defined, but could be >> interpreted to mean the date/time when the instance will occur. > > That is what it means. If a repeating component has 10 instances > in which it will occur. Then each has instance has a RECURRENCE-ID > equivalent to its own start time. Basically, if you took the RECUR and rewrote it as a series of RDATEs, the RECURRENCE-ID of each instance would be equal to the corresponding RDATE. -- /===========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===========================================================| |We must be devious, cunning, inventive... too bad we're us.| \===========================================================/ From owner-ietf-calendar@mail.imc.org Mon May 19 14:49: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 OAA00619 for ; Mon, 19 May 2003 14:49: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 h4JIflAF055577 for ; Mon, 19 May 2003 11:41: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 h4JIflfo055576 for ietf-calendar-bks; Mon, 19 May 2003 11:41:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JIfkAF055561 for ; Mon, 19 May 2003 11:41:46 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EC91BC8.5090505@Royer.com> To: ietf-calendar@imc.org Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M1_03242003NP March 24, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Mon, 19 May 2003 14:36:13 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/19/2003 02:41:41 PM, Serialize complete at 05/19/2003 02:41:41 PM Content-Type: multipart/alternative; boundary="=_alternative 0065F1C385256D2B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065F1C385256D2B_= Content-Type: text/plain; charset="US-ASCII" I disagree, the recurrence-id must always refer to the original date. of the meeting. Lets say i had a 5 day repeating meeting. However I invited you to just Monday Tuesday to start with, but for some reason you have not received the mail yet. I now reschedule Thursday Friday to a later time in the day and add you to the invitee list. You now get a sequence 2 invite for Thursday Friday Later you finally receive the meeting for Monday Tuesday with sequence of 1. If I allow recurrence dates to reset on a reschedule, I can not tell if the Monday Tuesday invitee was rescheduled to Thursday Friday or if this is a separate invite. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com --=_alternative 0065F1C385256D2B_= Content-Type: text/html; charset="US-ASCII"
I disagree, the recurrence-id must always refer to the original date.
 
of the meeting.  Lets say i had a 5 day repeating meeting. However I invited you to just Monday Tuesday to start with, but for some reason you have not received the mail yet.
I now reschedule Thursday Friday to a later time in the day and add you to the invitee list.  
You now get a sequence 2 invite for Thursday Friday
Later you finally receive the meeting for Monday Tuesday with sequence of 1.
If I allow recurrence dates to reset on a reschedule, I can not tell if the Monday Tuesday invitee was rescheduled to Thursday Friday or if this is a separate invite.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com --=_alternative 0065F1C385256D2B_=-- From owner-ietf-calendar@mail.imc.org Mon May 19 14:53: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 OAA00718 for ; Mon, 19 May 2003 14:53: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 h4JIeQAF055525 for ; Mon, 19 May 2003 11: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 h4JIeQcR055524 for ietf-calendar-bks; Mon, 19 May 2003 11:40:26 -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 h4JIeOAF055518 for ; Mon, 19 May 2003 11:40:24 -0700 (PDT) (envelope-from PStephenson@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Mon, 19 May 2003 12:39:27 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Mon, 19 May 2003 12:39:34 -0600 From: "Preston Stephenson" To: Subject: Re: Follow up to BEEP and CAP - one-to-many Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I understand the multipart. I just wanted to verify that a single BEEP reply message can't have two mime entities at the outermost level. RPY 5 0 . 0 842 Content-Type: text/calendar BEGIN:VCALENDAR VERSION:2.0 PRODID:-//someone's prodid CMD;ID=creation02:REPLY TARGET:relcalz1 <- 1st TARGET listed. BEGIN:REPLY <- Reply for 1st VEVENT create in 1st TARGET. UID:FirstInThisExample-1 REQUEST-STATUS:2.0 END:VREPLY BEGIN:REPLY <- Reply for 2nd VEVENT crate in 1st TARGET. UID:SecondInThisExample-2 REQUEST-STATUS:2.0 END:VREPLY END:VCALENDAR Content-Type: text/calendar BEGIN:VCALENDAR VERSION:2.0 PRODID:-//someone's prodid CMD;ID=creation02:REPLY TARGET:relcalz2 <- 2nd TARGET listed BEGIN:REPLY <- Reply for 1st VEVENT create in 2nd TARGET. UID:FirstInThisExample-1 REQUEST-STATUS:2.0 END:VREPLY BEGIN:REPLY <- Reply for 2nd VEVENT crate in 2nd TARGET. UID:SecondInThisExample-2 REQUEST-STATUS:2.0 END:VREPLY END:VCALENDAR END The above should be invalid, but the following would be valid. RPY 5 0 . 0 811 Content-Type: text/calendar BEGIN:VCALENDAR VERSION:2.0 PRODID:-//someone's prodid CMD;ID=creation02:REPLY TARGET:relcalz1 <- 1st TARGET listed. BEGIN:REPLY <- Reply for 1st VEVENT create in 1st TARGET. UID:FirstInThisExample-1 REQUEST-STATUS:2.0 END:VREPLY BEGIN:REPLY <- Reply for 2nd VEVENT crate in 1st TARGET. UID:SecondInThisExample-2 REQUEST-STATUS:2.0 END:VREPLY END:VCALENDAR BEGIN:VCALENDAR VERSION:2.0 PRODID:-//someone's prodid CMD;ID=creation02:REPLY TARGET:relcalz2 <- 2nd TARGET listed BEGIN:REPLY <- Reply for 1st VEVENT create in 2nd TARGET. UID:FirstInThisExample-1 REQUEST-STATUS:2.0 END:VREPLY BEGIN:REPLY <- Reply for 2nd VEVENT crate in 2nd TARGET. UID:SecondInThisExample-2 REQUEST-STATUS:2.0 END:VREPLY END:VCALENDAR END Thanks. Preston >>> Doug@royer.com 5/19/2003 12:11:10 PM >>> Preston Stephenson wrote: > I just need a little clarification on some postings from last year. > > Section 10.1.4 CREATE Command > The replies from the different targets. > > Is this an example of a BEEP MSG/ANS,ANS,NUL exchange? > > In the case of a BEEP MSG/RPY exchange, would the two VCALENDAR objects > be in one text/calendar mime? Yes it could be. You can have multiple VCALENDARS in each MIME object. You can have multiple MIME objects, each with any valid MIME object using MULTIPART/ and possibly nested. However as the topic is CAP, it is assumed that at least one of the MIME objects will be an iCalendar 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 From owner-ietf-calendar@mail.imc.org Mon May 19 14: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 OAA00876 for ; Mon, 19 May 2003 14:57: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 h4JIktAF055791 for ; Mon, 19 May 2003 11:46: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 h4JIktQq055790 for ietf-calendar-bks; Mon, 19 May 2003 11:46:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JIksAF055784 for ; Mon, 19 May 2003 11:46:55 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id 9F0573FB1A for ; Mon, 19 May 2003 20:37:26 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id 45AE92DC; Mon, 19 May 2003 20:46:51 +0200 (MET DST) To: "ietf-calendar@imc.org" From: gustav.mango@safecareab.com Subject: Re: Re: Follow up to BEEP and CAP - one-to-many Message-Id: <20030519184651.45AE92DC@nw-pop4.wineasy.se> Date: Mon, 19 May 2003 20:46:51 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Mon May 19 16:04: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 QAA04549 for ; Mon, 19 May 2003 16:04: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 h4JJNZAF057414 for ; Mon, 19 May 2003 12:23: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 h4JJNZMb057413 for ietf-calendar-bks; Mon, 19 May 2003 12:23: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 h4JJNYAF057408 for ; Mon, 19 May 2003 12:23: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 h4JJNVv3029854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 May 2003 12:23:35 -0700 Message-ID: <3EC92F29.5010803@Royer.com> Date: Mon, 19 May 2003 13:23:21 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Follow up to BEEP and CAP - one-to-many References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070504090504010004020701" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070504090504010004020701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: > I understand the multipart. I just wanted to verify that a single BEEP > reply message can't have two mime entities at the outermost level. If MIME allows it, it can. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070504090504010004020701 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MTkxOTIzMjFaMCMGCSqGSIb3DQEJBDEWBBTZ 51QTcKYA11xxpWlXQxFDVyBW+TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAp10ebTN2cHG0 P3iN5UCLDwgCj3RB6F9ipJ32zYVKBtqoPlYaYnNRVQw2dF95DEzlP8TzzHsDJz8q9pDRnzqs Qwwb/64RfnrrVARukN6bPMQRVX+/ecyfT+0o134dwk/ijWiffqEX/LDOitJI6LaKQ7Hrd+Cy QpW5tpqZvzwxzMgUwNjAtaKdzYnmGcBeEo5vD6jy2xXssgKFcWVA18Ot54VBMNriNMIg/ARM lbbDp1rgeP6D9GSDPMVC3RqfZUKKnfPl/ybVkWLf58HKBQWb8cwxLdtmG1I8ExQWqXDWPWqK xxemJ6i0gGh5L+UwPGQT53QAZ8FTY98aAcIxot2EYwAAAAAAAA== --------------ms070504090504010004020701-- From owner-ietf-calendar@mail.imc.org Tue May 20 20:31: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 UAA07191 for ; Tue, 20 May 2003 20:31: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 h4L0ECAF064625 for ; Tue, 20 May 2003 17: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 h4L0ECY6064624 for ietf-calendar-bks; Tue, 20 May 2003 17:14:12 -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 h4L0EAAF064615; Tue, 20 May 2003 17:14:11 -0700 (PDT) (envelope-from ki.wong@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 h4L0ECY9025856; Tue, 20 May 2003 18:14:13 -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 h4L0EChD012988; Tue, 20 May 2003 17:14:12 -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 <0HF700G4WNBOIU@ha13sca-mail1.sfbay.sun.com>; Tue, 20 May 2003 17:14:12 -0700 (PDT) Date: Tue, 20 May 2003 17:17:51 -0700 From: kiwong Subject: RE: Correct handling of Recurrence-id To: "Robert_Ransdell@notesdev.ibm.com" , "ietf-calendar@imc.org" Cc: "owner-ietf-calendar@mail.imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BVHa03y+LFtFeDHFHT2pZQ)"; DIFFERENCES=Content-Language Content-language: en-USA Content-transfer-encoding: 8BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_BVHa03y+LFtFeDHFHT2pZQ) Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-language: en-USA Content-Transfer-Encoding: QUOTED-PRINTABLE I agree with Bob. I don=92t see how recurrence-id will work for =93out of band=94 iTIP messages if it doesn=92t have the original date. =20 I tested out the Outlook/Exchange and they use the original date as the RECURRENCE-ID. I assume Notes is using it the same way. For iTIP interoperability, is it more beneficial to have RECURRENCE-ID as the original date? =20 ki =20 -----Original Message----- From: Robert_Ransdell@notesdev.ibm.com [mailto:Robert_Ransdell@notesdev.ibm.com]=20 Sent: Monday, May 19, 2003 11:36 AM To: ietf-calendar@imc.org Cc: owner-ietf-calendar@mail.imc.org Subject: Re: Correct handling of Recurrence-id =20 I disagree, the recurrence-id must always refer to the original date.=20 =20 of the meeting. Lets say i had a 5 day repeating meeting. However I invited you to just Monday Tuesday to start with, but for some reason you have not received the mail yet.=20 I now reschedule Thursday Friday to a later time in the day and add you to the invitee list. =20 You now get a sequence 2 invite for Thursday Friday=20 Later you finally receive the meeting for Monday Tuesday with sequence of 1.=20 If I allow recurrence dates to reset on a reschedule, I can not tell if the Monday Tuesday invitee was rescheduled to Thursday Friday or if this is a separate invite.=20 _____________________ Note: new email address tom_ransdell@notesdev.ibm.com --Boundary_(ID_BVHa03y+LFtFeDHFHT2pZQ) Content-id: 0 Content-type: TEXT/html; CHARSET=iso-8859-1 Content-language: en-USA Content-Transfer-Encoding: QUOTED-PRINTABLE

I agree with Bob. I = don’t see how recurrence-id will work for “out of band” iTIP me= ssages if it doesn’t have the original date.

  =

I tested out t= he Outlook/Exchange and they use the original date as the RECURRENCE-ID. I = assume Notes is using it the same way. For iTIP interoperability, is it mor= e beneficial to have RECURRENCE-ID as the original date? <= /p>

  <= /font>

ki

&= nbsp;

-----Original Message-----
From: Robert_Ransdell@n= otesdev.ibm.com [mailto:Robert_Ransdell@notesdev.ibm.com]
Sent: Monday, May 19, 2= 003 11:36 AM
To: ietf-calendar@imc.o= rg
Cc: owner-ietf-calendar= @mail.imc.org
Subject: Re: Correct ha= ndling of Recurrence-id

&nbs= p;


I disagree, the recurrence-id must always refer to the or= iginal date.
 
of the meeting.  Lets say i had a 5= day repeating meeting. However I invited you to just Monday Tuesday to sta= rt with, but for some reason you have not received the mail yet.
I now reschedule Thursday Friday to a later time in the day and add you t= o the invitee list.  
You now get a sequence 2 invite for Thursday Friday =
Later you finally receive the meeting for Monday Tuesday with sequence of= 1.
If I allow recurrence dates to reset on a reschedule, I can not tell if t= he Monday Tuesday invitee was rescheduled to Thursday Friday or if this is = a separate invite.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com

= --Boundary_(ID_BVHa03y+LFtFeDHFHT2pZQ)-- From owner-ietf-calendar@mail.imc.org Wed May 21 14:24: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 OAA00648 for ; Wed, 21 May 2003 14:24: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 h4LI0TAF048289 for ; Wed, 21 May 2003 11:00: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 h4LI0TDG048288 for ietf-calendar-bks; Wed, 21 May 2003 11:00:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LI0PAF048282 for ; Wed, 21 May 2003 11:00:27 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h4LI0Jv3017252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 21 May 2003 11:00:25 -0700 Message-ID: <3ECBBEA7.4080203@Royer.com> Date: Wed, 21 May 2003 12:00:07 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050702090609080600090106" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050702090609080600090106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think the terms 'the same' and 'original' are the cause of the confusion. Two different question were asked. kiwong wrote: > > > I agree with Bob. I don?t see how recurrence-id will work for ?out of > band? iTIP messages if it doesn?t have the original date. The RECURRANCE-ID value is the same as the DTSTART value for that specific instance in the booked object. It is not always equal to the DTSTART value of the original object: A 1 hour meeting starts on monday at 1pm for 5 days: DTSTART: ...monday To specify a specific instance the RECURRANCE-ID value may be set to a value of ...tuesday. So they are NOT the same as the original instance except when the instance in the iTIP object refers to the 1st booked instance. And the DTSTART and RECURRANCE-ID values are not always the same in a specific iTIP object. It depends on the METHOD value. If you are METHOD:CANCEL-ing an instance - yes they must be the same in the iTIP object. If you are updating the DTSTART value of an existing (booked) object. And you are altering the DTSTART value of a specific instance of that booked object. And you are NOT updating the 1st instance of that booked object: Then the RECURRANCE-ID in an update iTIP object would have different values for the RECURRANCE-ID and its DTSTART value. The DTSTART value has the NEW instance value. The RECURRANCE-ID value has the OLD instance value. So it IS always the same as the 'booked' object instance. It is NOT always the same as the DTSTART value in the 'booked' object. It is NOT always the same in a specific iTIP object. > > I tested out the Outlook/Exchange and they use the original date as the > RECURRENCE-ID. Using what 'METHOD:' value? > I assume Notes is using it the same way. For iTIP > interoperability, is it more beneficial to have RECURRENCE-ID as the > original date? Only when referring to the 1st instance of a booked object or using specifc METHOD values. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050702090609080600090106 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjExODAwMDdaMCMGCSqGSIb3DQEJBDEWBBSx WMJTfMbqcyyNiyROvBJfc3opcDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAZOgnnOGeBLwc EbHjDnZU+wYcnP5Vgk5tOBcvEgmsL3JZqVmzbIHm5fnvLgP2w7I2ksJRb5sHbfnTjTOeyU2b /Vv/tUA7/M6pCWjLB4+JFAfQFP6P7/8YJptpVgEU+O/D7bjVa99quS0LBMSi9JwfF0O8aNYT 2hjxIHmMyK9zA8/3C6LuaaZrRJZRVRVgBihuA05+O4VCfMbgigRlM3qEY0CZ+6zphXAqA1YX VCuj0naGPOl01gypv9lX/1hO2VV85cObyD6HkdA2i9RSX2g815bavCUGtH9LB6Tm6iiX+t9n w4fdiHOALfr+G2rCdvj1Q13ncZBStw5AeyjvQ+S4DQAAAAAAAA== --------------ms050702090609080600090106-- From owner-ietf-calendar@mail.imc.org Wed May 21 14: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 OAA01896 for ; Wed, 21 May 2003 14: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 h4LIaNAF049219 for ; Wed, 21 May 2003 11:36: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 h4LIaNVV049218 for ietf-calendar-bks; Wed, 21 May 2003 11:36:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LIaLAF049210 for ; Wed, 21 May 2003 11:36:22 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id 7F8B63F8B0 for ; Wed, 21 May 2003 20:26:44 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id B1C55961; Wed, 21 May 2003 20:36:13 +0200 (MET DST) To: "ietf-calendar@imc.org" From: gustav.mango@safecareab.com Subject: Re: Re: Correct handling of Recurrence-id Message-Id: <20030521183613.B1C55961@nw-pop4.wineasy.se> Date: Wed, 21 May 2003 20:36:13 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Wed May 21 16:29: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 QAA07866 for ; Wed, 21 May 2003 16:29: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 h4LK93AF052098 for ; Wed, 21 May 2003 13: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 h4LK939r052097 for ietf-calendar-bks; Wed, 21 May 2003 13:09: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 (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LK92AF052075 for ; Wed, 21 May 2003 13:09:02 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3ECBBEA7.4080203@Royer.com> To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M1_03242003NP March 24, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Wed, 21 May 2003 16:01:59 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/21/2003 04:08:56 PM, Serialize complete at 05/21/2003 04:08:56 PM Content-Type: multipart/alternative; boundary="=_alternative 006DCBDD85256D2D_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006DCBDD85256D2D_= Content-Type: text/plain; charset="US-ASCII" Don't even reference DTSTART. The values for RECURRANCE-ID in any future reschedule/update or counter must be the dates rolled from the chairs Original meeting invitation RRULE/RDATE/EXRULE/EXDATE. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 05/21/2003 02:00 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: Correct handling of Recurrence-id I think the terms 'the same' and 'original' are the cause of the confusion. Two different question were asked. kiwong wrote: > > > I agree with Bob. I don?t see how recurrence-id will work for ?out of > band? iTIP messages if it doesn?t have the original date. The RECURRANCE-ID value is the same as the DTSTART value for that specific instance in the booked object. It is not always equal to the DTSTART value of the original object: A 1 hour meeting starts on monday at 1pm for 5 days: DTSTART: ...monday To specify a specific instance the RECURRANCE-ID value may be set to a value of ...tuesday. So they are NOT the same as the original instance except when the instance in the iTIP object refers to the 1st booked instance. And the DTSTART and RECURRANCE-ID values are not always the same in a specific iTIP object. It depends on the METHOD value. If you are METHOD:CANCEL-ing an instance - yes they must be the same in the iTIP object. If you are updating the DTSTART value of an existing (booked) object. And you are altering the DTSTART value of a specific instance of that booked object. And you are NOT updating the 1st instance of that booked object: Then the RECURRANCE-ID in an update iTIP object would have different values for the RECURRANCE-ID and its DTSTART value. The DTSTART value has the NEW instance value. The RECURRANCE-ID value has the OLD instance value. So it IS always the same as the 'booked' object instance. It is NOT always the same as the DTSTART value in the 'booked' object. It is NOT always the same in a specific iTIP object. > > I tested out the Outlook/Exchange and they use the original date as the > RECURRENCE-ID. Using what 'METHOD:' value? > I assume Notes is using it the same way. For iTIP > interoperability, is it more beneficial to have RECURRENCE-ID as the > original date? Only when referring to the 1st instance of a booked object or using specifc METHOD values. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.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 006DCBDD85256D2D_= Content-Type: text/html; charset="US-ASCII"
Don't even reference DTSTART.
The values for RECURRANCE-ID in any future reschedule/update or counter must be the dates rolled from the chairs Original meeting invitation RRULE/RDATE/EXRULE/EXDATE.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

05/21/2003 02: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: Correct handling of Recurrence-id






I think the terms 'the same' and 'original' are the cause of the
confusion. Two different question were asked.


kiwong wrote:
>
>
> I agree with Bob. I don?t see how recurrence-id will work for ?out of
> band? iTIP messages if it doesn?t have the original date.

The RECURRANCE-ID value is the same as the DTSTART value for that specific
instance in the booked object. It is not always equal to the DTSTART
value of the original object:

  A 1 hour meeting starts on monday at 1pm for 5 days:

    DTSTART: ...monday

  To specify a specific instance the RECURRANCE-ID value
  may be set to a value of ...tuesday.

  So they are NOT the same as the original instance except when
  the instance in the iTIP object refers to the 1st booked instance.

And the DTSTART and RECURRANCE-ID values are not always the same in a
specific iTIP object. It depends on the METHOD value. If you are
METHOD:CANCEL-ing an  instance - yes they must be the same in the
iTIP object.

If you are updating the DTSTART value of an existing (booked) object.
And you are altering the DTSTART value of a specific instance of that
booked object. And you are NOT updating the 1st instance of that
booked object:

   Then the RECURRANCE-ID in an update iTIP object would have
   different values for the RECURRANCE-ID and its DTSTART value.
   The DTSTART value has the NEW instance value.
   The RECURRANCE-ID value has the OLD instance value.

So it IS always the same as the 'booked' object instance.
It is NOT always the same as the DTSTART value in the 'booked' object.
It is NOT always the same in a specific iTIP object.

>
> I tested out the Outlook/Exchange and they use the original date as the
> RECURRENCE-ID.

Using what 'METHOD:' value?

> I assume Notes is using it the same way. For iTIP
> interoperability, is it more beneficial to have RECURRENCE-ID as the
> original date?

Only when referring to the 1st instance of a booked object or
using specifc METHOD values.

--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.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 006DCBDD85256D2D_=-- From owner-ietf-calendar@mail.imc.org Wed May 21 17:36: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 RAA09776 for ; Wed, 21 May 2003 17:36: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 h4LLBCAF055926 for ; Wed, 21 May 2003 14:11: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 h4LLBChQ055925 for ietf-calendar-bks; Wed, 21 May 2003 14:11: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 h4LLB8AF055914 for ; Wed, 21 May 2003 14:11: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 h4LLB6v3018856 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 21 May 2003 14:11:09 -0700 Message-ID: <3ECBEB5B.9090803@Royer.com> Date: Wed, 21 May 2003 15:10:51 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070100050009030208040802" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070100050009030208040802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Don't even reference DTSTART. > The values for RECURRANCE-ID in any future reschedule/update or counter > must be the dates rolled from the chairs Original meeting invitation > RRULE/RDATE/EXRULE/EXDATE. Yes, and I assume by 'original' you mean currently booked version of the object, as the 'original' may be of date (updated already). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070100050009030208040802 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjEyMTEwNTJaMCMGCSqGSIb3DQEJBDEWBBTw MKNgAP8I1UKVXI54fPCPQImL7zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAJL/gGIuGKIoF AgzsFmr6PqIwAN72vQd8qEc4zwEVFot82NKc7McMNmoRjWrggcGJiu8QER1Mf83Cnn+iEgSQ VnMK3bxK3CHIu6H24JY0jO+h1Rit/Iw5RNL5K6bM6FJ1P38D8JYHUv3+y+dj5EF9pB7bn48v eRl2Jli3YBrgQbrEZ/A6y5bO6rADkAFxOHoXgFtcxtQdq3tQf4/Gq4Od4DoMqzPzHk687rzM PoYHkGf8lgbmdmdWGYg8P+e24LU8hQ7Yx0Yegq85t+vhHa5zGFMDEyQM0P6NWtpfGUEPD+iM tR2BSTUdvRCVcTmYznxNq3vAUGRq1FiukNuIWMIR7gAAAAAAAA== --------------ms070100050009030208040802-- From owner-ietf-calendar@mail.imc.org Wed May 21 17: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 RAA09810 for ; Wed, 21 May 2003 17:37: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 h4LLM5AF056299 for ; Wed, 21 May 2003 14: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 h4LLM5LX056298 for ietf-calendar-bks; Wed, 21 May 2003 14:22:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LLM4AF056289 for ; Wed, 21 May 2003 14:22:04 -0700 (PDT) (envelope-from george.babics@oracle.com) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h4LLM0FD006035 for ; Wed, 21 May 2003 14:22:00 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail3.oracle.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h4LLM0FD006027 for ; Wed, 21 May 2003 14:22:00 -0700 (PDT) Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h4LLLxc05524 for ; Wed, 21 May 2003 15:21:59 -0600 (MDT) Received: from rgmum2.us.oracle.com (rgmum2.us.oracle.com [138.1.191.23]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h4LLLxE05509 for ; Wed, 21 May 2003 15:21:59 -0600 (MDT) Received: from c-0000.ca.oracle.com by rgmum2.us.oracle.com with ESMTP id 183229741053552110; Wed, 21 May 2003 15:21:50 -0600 Message-ID: <3ECBED88.1000605@oracle.com> Date: Wed, 21 May 2003 17:20:08 -0400 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: Robert_Ransdell@notesdev.ibm.com CC: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: Correct handling of Recurrence-id References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit According to RFC 2445 an event's current DTSTART is its recurrence id. Section 4.8.4.4: 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. And in RFC 2446, section 3.7.1: 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. George Robert_Ransdell@notesdev.ibm.com wrote: > > Don't even reference DTSTART. > The values for RECURRANCE-ID in any future reschedule/update or counter > must be the dates rolled from the chairs Original meeting invitation > RRULE/RDATE/EXRULE/EXDATE. > _____________________ > Note: new email address > > tom_ransdell@notesdev.ibm.com > > > *Doug Royer * > Sent by: owner-ietf-calendar@mail.imc.org > > 05/21/2003 02:00 PM > Please respond to > "ietf-calendar@imc.org" > > > To > "ietf-calendar@imc.org" > cc > Subject > Re: Correct handling of Recurrence-id > > > > > > > > I think the terms 'the same' and 'original' are the cause of the > confusion. Two different question were asked. > > > kiwong wrote: > > > > > > I agree with Bob. I don?t see how recurrence-id will work for ?out of > > band? iTIP messages if it doesn?t have the original date. > > The RECURRANCE-ID value is the same as the DTSTART value for that specific > instance in the booked object. It is not always equal to the DTSTART > value of the original object: > > A 1 hour meeting starts on monday at 1pm for 5 days: > > DTSTART: ...monday > > To specify a specific instance the RECURRANCE-ID value > may be set to a value of ...tuesday. > > So they are NOT the same as the original instance except when > the instance in the iTIP object refers to the 1st booked instance. > > And the DTSTART and RECURRANCE-ID values are not always the same in a > specific iTIP object. It depends on the METHOD value. If you are > METHOD:CANCEL-ing an instance - yes they must be the same in the > iTIP object. > > If you are updating the DTSTART value of an existing (booked) object. > And you are altering the DTSTART value of a specific instance of that > booked object. And you are NOT updating the 1st instance of that > booked object: > > Then the RECURRANCE-ID in an update iTIP object would have > different values for the RECURRANCE-ID and its DTSTART value. > The DTSTART value has the NEW instance value. > The RECURRANCE-ID value has the OLD instance value. > > So it IS always the same as the 'booked' object instance. > It is NOT always the same as the DTSTART value in the 'booked' object. > It is NOT always the same in a specific iTIP object. > > > > > I tested out the Outlook/Exchange and they use the original date as the > > RECURRENCE-ID. > > Using what 'METHOD:' value? > > > I assume Notes is using it the same way. For iTIP > > interoperability, is it more beneficial to have RECURRENCE-ID as the > > original date? > > Only when referring to the 1st instance of a booked object or > using specifc METHOD values. > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.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 May 21 18:18:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11658 for ; Wed, 21 May 2003 18:18: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 h4LM06AF057804 for ; Wed, 21 May 2003 15:00: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 h4LM06eu057803 for ietf-calendar-bks; Wed, 21 May 2003 15:00:06 -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 h4LM05AF057787; Wed, 21 May 2003 15:00:05 -0700 (PDT) (envelope-from ki.wong@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 h4LM024Z013766; Wed, 21 May 2003 15:00:02 -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 h4LM026f009259; Wed, 21 May 2003 15:00:02 -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 <0HF9006EEBS1QO@ha13sca-mail1.sfbay.sun.com>; Wed, 21 May 2003 15:00:02 -0700 (PDT) Date: Wed, 21 May 2003 15:03:41 -0700 From: kiwong Subject: RE: Correct handling of Recurrence-id To: George Babics , "Robert_Ransdell@notesdev.ibm.com" Cc: "ietf-calendar@imc.org" , "owner-ietf-calendar@mail.imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rbCFj6JRRY0s+yqy7UHS/w)"; DIFFERENCES=Content-Language Content-language: en-USA Content-transfer-encoding: 8BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_rbCFj6JRRY0s+yqy7UHS/w) Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-language: en-USA Content-Transfer-Encoding: QUOTED-PRINTABLE I just want to make sure we understand the problem of RECURRENCE-ID if we *DO NOT* use the original dtstart (the dtstart the recurring set is created at the time by the organizer). Let=92s say I send out an weekly invitation to you, which is 5/1, 5/8, 5/15= , 5/22, ... =20 You got your invitation and see the recurring event in your calendar=20 Now if I change the 5/8 to 5/9 and send out an update. Then I change it again from 5/9 to 5/10 and send another update.=20 The problem arises in the following cases:=20 1)If the 5/8- > 5/9 event got lost in email, but 5/9- >5/10 succeeds, then you cannot apply the 5/9- >5/10 because 5/9 is not in your recurring set.= =20 2)If both emails 5/8- >5/9 and 5/9- >5/10 are in your Inbox, and you open the latest one first, which is 5/9- >5/10, then it will generate an error as well. You must open the 5/8- >5/9 before you can open 5/9- >5/10=20 If RECURRENCE-ID is the original dtstart, then *out of sequence* iMIPs will not be a problem. Otherwise, how do CUA/CS resolve this kind of problems? ki > -----Original Message----- > From: George Babics [mailto:george.babics@oracle.com] > Sent: Wednesday, May 21, 2003 2:20 PM > To: Robert_Ransdell@notesdev.ibm.com > Cc: ietf-calendar@imc.org; owner-ietf-calendar@mail.imc.org > Subject: Re: Correct handling of Recurrence-id >=20 >=20 >=20 > According to RFC 2445 an event's current DTSTART is > its recurrence id. Section 4.8.4.4: >=20 > 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. >=20 > And in RFC 2446, section 3.7.1: >=20 > 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. >=20 > George >=20 > Robert_Ransdell@notesdev.ibm.com wrote: > > > > Don't even reference DTSTART. > > The values for RECURRANCE-ID in any future reschedule/update or counter > > must be the dates rolled from the chairs Original meeting invitation > > RRULE/RDATE/EXRULE/EXDATE. > > _____________________ > > Note: new email address > > > > tom_ransdell@notesdev.ibm.com > > > > > > *Doug Royer * > > Sent by: owner-ietf-calendar@mail.imc.org > > > > 05/21/2003 02:00 PM > > Please respond to > > "ietf-calendar@imc.org" > > > > > > To > > "ietf-calendar@imc.org" > > cc > > Subject > > Re: Correct handling of Recurrence-id > > > > > > > > > > > > > > > > I think the terms 'the same' and 'original' are the cause of the > > confusion. Two different question were asked. > > > > > > kiwong wrote: > > > > > > > > > I agree with Bob. I don?t see how recurrence-id will work for ?out of > > > band? iTIP messages if it doesn?t have the original date. > > > > The RECURRANCE-ID value is the same as the DTSTART value for that specific > > instance in the booked object. It is not always equal to the DTSTART > > value of the original object: > > > > A 1 hour meeting starts on monday at 1pm for 5 days: > > > > DTSTART: ...monday > > > > To specify a specific instance the RECURRANCE-ID value > > may be set to a value of ...tuesday. > > > > So they are NOT the same as the original instance except when > > the instance in the iTIP object refers to the 1st booked instance. > > > > And the DTSTART and RECURRANCE-ID values are not always the same in a > > specific iTIP object. It depends on the METHOD value. If you are > > METHOD:CANCEL-ing an instance - yes they must be the same in the > > iTIP object. > > > > If you are updating the DTSTART value of an existing (booked) object. > > And you are altering the DTSTART value of a specific instance of that > > booked object. And you are NOT updating the 1st instance of that > > booked object: > > > > Then the RECURRANCE-ID in an update iTIP object would have > > different values for the RECURRANCE-ID and its DTSTART value. > > The DTSTART value has the NEW instance value. > > The RECURRANCE-ID value has the OLD instance value. > > > > So it IS always the same as the 'booked' object instance. > > It is NOT always the same as the DTSTART value in the 'booked' object. > > It is NOT always the same in a specific iTIP object. > > > > > > > > I tested out the Outlook/Exchange and they use the original date as the > > > RECURRENCE-ID. > > > > Using what 'METHOD:' value? > > > > > I assume Notes is using it the same way. For iTIP > > > interoperability, is it more beneficial to have RECURRENCE-ID as the > > > original date? > > > > Only when referring to the 1st instance of a booked object or > > using specifc METHOD values. > > > > -- > > > > Doug Royer | http://INET-Consulting.com > > -------------------------------|----------------------------- > > Doug@Royer.com | Office: (208)612-INET > > http://Royer.com/People/Doug | Fax: (866)594-8574 > > | Cell: (208)520-4044 > > > > We Do Standards - You Need Standards > > >=20 --Boundary_(ID_rbCFj6JRRY0s+yqy7UHS/w) Content-id: 0 Content-type: TEXT/html; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT
I just want to make sure we understand the problem of RECURRENCE-ID if we *DO NOT* use the original dtstart (the dtstart the recurring set is created at the time by the organizer).
Let’s say I send out an weekly invitation to you, which is 5/1, 5/8, 5/15, 5/22, ...
You got your invitation and see the recurring event in your calendar
Now if I change the 5/8 to 5/9 and send out an update. Then I change it again from 5/9 to 5/10 and send another update.
The problem arises in the following cases:
1)If the 5/8- > 5/9 event got lost in email, but 5/9- >5/10 succeeds, then you cannot apply the 5/9- >5/10 because 5/9 is not in your recurring set.
2)If both emails 5/8- >5/9 and 5/9- >5/10 are in your Inbox, and you open the latest one first, which is 5/9- >5/10, then it will generate an error as well. You must open the 5/8- >5/9 before you can open 5/9- >5/10
If RECURRENCE-ID is the original dtstart, then *out of sequence* iMIPs will not be a problem. Otherwise, how do CUA/CS resolve this kind of problems?
ki
> -----Original Message-----
> From: George Babics [mailto:george.babics@oracle.com]
> Sent: Wednesday, May 21, 2003 2:20 PM
> To: Robert_Ransdell@notesdev.ibm.com
> Cc: ietf-calendar@imc.org; owner-ietf-calendar@mail.imc.org
> Subject: Re: Correct handling of Recurrence-id
>
>
>
> According to RFC 2445 an event's current DTSTART is
> its recurrence id. Section 4.8.4.4:
>
> 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.
>
> And in RFC 2446, section 3.7.1:
>
> 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.
>
> George
>
> Robert_Ransdell@notesdev.ibm.com wrote:
> >
> > Don't even reference DTSTART.
> > The values for RECURRANCE-ID in any future reschedule/update or counter
> > must be the dates rolled from the chairs Original meeting invitation
> > RRULE/RDATE/EXRULE/EXDATE.
> > _____________________
> > Note: new email address
> >
> > tom_ransdell@notesdev.ibm.com
> >
> >
> > *Doug Royer <Doug@Royer.com>*
> > Sent by: owner-ietf-calendar@mail.imc.org
> >
> > 05/21/2003 02: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: Correct handling of Recurrence-id
> >
> >
> >
> >
> >
> >
> >
> > I think the terms 'the same' and 'original' are the cause of the
> > confusion. Two different question were asked.
> >
> >
> > kiwong wrote:
> > >
> > >
> > > I agree with Bob. I don?t see how recurrence-id will work for ?out of
> > > band? iTIP messages if it doesn?t have the original date.
> >
> > The RECURRANCE-ID value is the same as the DTSTART value for that specific
> > instance in the booked object. It is not always equal to the DTSTART
> > value of the original object:
> >
> > A 1 hour meeting starts on monday at 1pm for 5 days:
> >
> > DTSTART: ...monday
> >
> > To specify a specific instance the RECURRANCE-ID value
> > may be set to a value of ...tuesday.
> >
> > So they are NOT the same as the original instance except when
> > the instance in the iTIP object refers to the 1st booked instance.
> >
> > And the DTSTART and RECURRANCE-ID values are not always the same in a
> > specific iTIP object. It depends on the METHOD value. If you are
> > METHOD:CANCEL-ing an instance - yes they must be the same in the
> > iTIP object.
> >
> > If you are updating the DTSTART value of an existing (booked) object.
> > And you are altering the DTSTART value of a specific instance of that
> > booked object. And you are NOT updating the 1st instance of that
> > booked object:
> >
> > Then the RECURRANCE-ID in an update iTIP object would have
> > different values for the RECURRANCE-ID and its DTSTART value.
> > The DTSTART value has the NEW instance value.
> > The RECURRANCE-ID value has the OLD instance value.
> >
> > So it IS always the same as the 'booked' object instance.
> > It is NOT always the same as the DTSTART value in the 'booked' object.
> > It is NOT always the same in a specific iTIP object.
> >
> > >
> > > I tested out the Outlook/Exchange and they use the original date as the
> > > RECURRENCE-ID.
> >
> > Using what 'METHOD:' value?
> >
> > > I assume Notes is using it the same way. For iTIP
> > > interoperability, is it more beneficial to have RECURRENCE-ID as the
> > > original date?
> >
> > Only when referring to the 1st instance of a booked object or
> > using specifc METHOD values.
> >
> > --
> >
> > Doug Royer | http://INET-Consulting.com
> > -------------------------------|-----------------------------
> > Doug@Royer.com | Office: (208)612-INET
> > http://Royer.com/People/Doug | Fax: (866)594-8574
> > | Cell: (208)520-4044
> >
> > We Do Standards - You Need Standards
> >
>
--Boundary_(ID_rbCFj6JRRY0s+yqy7UHS/w)-- From owner-ietf-calendar@mail.imc.org Thu May 22 11:17: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 LAA18183 for ; Thu, 22 May 2003 11:17: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 h4MEomAF028391 for ; Thu, 22 May 2003 07:50: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 h4MEomoF028390 for ietf-calendar-bks; Thu, 22 May 2003 07:50:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4MEokAF028385 for ; Thu, 22 May 2003 07:50: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 h4MEodv3026250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 22 May 2003 07:50:46 -0700 Message-ID: <3ECCE3B2.6010001@Royer.com> Date: Thu, 22 May 2003 08:50:26 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090009080208080606060107" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090009080208080606060107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit kiwong wrote: > I just want to make sure we understand the problem of RECURRENCE-ID if > we *DO NOT* use the original dtstart (the dtstart the recurring set is > created at the time by the organizer). > Let?s say I send out an weekly invitation to you, which is 5/1, 5/8, > 5/15, 5/22, ... > You got your invitation and see the recurring event in your calendar > Now if I change the 5/8 to 5/9 and send out an update. Then I change it > again from 5/9 to 5/10 and send another update. > The problem arises in the following cases: > 1)If the 5/8- > 5/9 event got lost in email, but 5/9- >5/10 succeeds, > then you cannot apply the 5/9- >5/10 because 5/9 is not in your > recurring set. Yes. > 2)If both emails 5/8- >5/9 and 5/9- >5/10 are in your Inbox, and you > open the latest one first, which is 5/9- >5/10, then it will generate an > error as well. When you say 'Inbox' I think of an MUA. Although iTIP can be sent through e-mail, iCalendar objects are not processed by an MUA. The are processed by a CUA. So your CUA should be smarter. > You must open the 5/8- >5/9 before you can open 5/9- >5/10 > If RECURRENCE-ID is the original dtstart, then *out of sequence* iMIPs > will not be a problem. Otherwise, how do CUA/CS resolve this kind of > problems? Your CUA must 'process' them in the correct order. The 5/9 -> 5/10 iTIP object would have a SEQUENCE number in it that does not match your current copy of the object. So your CUA would know to do a REFRESH and get a new copy before applying the update. This is described in RFC-2446. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090009080208080606060107 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjIxNDUwMjdaMCMGCSqGSIb3DQEJBDEWBBSH hjoxtgOOfTq5z5Evnw12pYx0dzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAA7KsdBlSzoja 49zYZQpaF5KQwffvvKYjZK3MC597Nrw3CMKWCmWc1tySQ19AbbPVQEhYkpW808mYrDrwWOmD xz/sdPFLgWtsEUNpFLHkAwurOc/gFwr9wzU6cd/S4J+1XxO0Ki6sA6xDjuDfThBF3TmHbEGW oV1zLnMK3cIeZrPUf0UJJqUq6QKpDCwODutysHXzV7U/tlmsYLAiYDarb4u4LS013VqDm1dZ wbC06kiZgQLnDTjMy5gXE+TcjlmB50tUUB7W9WjcHO2Psu4JeEc6JE6jlMZUilNUR9DBRa4M ed1UAHQzWT0D/Sp2cvEzUxbBXlijO74xw6pSB3vWegAAAAAAAA== --------------ms090009080208080606060107-- From owner-ietf-calendar@mail.imc.org Thu May 22 11:25: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 LAA18363 for ; Thu, 22 May 2003 11:25: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 h4MF4EAF028878 for ; Thu, 22 May 2003 08: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 h4MF4EtA028877 for ietf-calendar-bks; Thu, 22 May 2003 08: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 (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4MF4CAF028862 for ; Thu, 22 May 2003 08:04:13 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3ECBEB5B.9090803@Royer.com> To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M1_03242003NP March 24, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 22 May 2003 10:53:55 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/22/2003 11:04:05 AM, Serialize complete at 05/22/2003 11:04:05 AM Content-Type: multipart/alternative; boundary="=_alternative 005197AD85256D2E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005197AD85256D2E_= Content-Type: text/plain; charset="US-ASCII" NO. I mean the initial dates from the inital invitation. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 05/21/2003 05:10 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: Correct handling of Recurrence-id Robert_Ransdell@notesdev.ibm.com wrote: > > Don't even reference DTSTART. > The values for RECURRANCE-ID in any future reschedule/update or counter > must be the dates rolled from the chairs Original meeting invitation > RRULE/RDATE/EXRULE/EXDATE. Yes, and I assume by 'original' you mean currently booked version of the object, as the 'original' may be of date (updated already). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.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 005197AD85256D2E_= Content-Type: text/html; charset="US-ASCII"
NO.   I mean the initial dates from the inital invitation.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

05/21/2003 05:10 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: Correct handling of Recurrence-id







Robert_Ransdell@notesdev.ibm.com wrote:
>
> Don't even reference DTSTART.
> The values for RECURRANCE-ID in any future reschedule/update or counter
> must be the dates rolled from the chairs Original meeting invitation
> RRULE/RDATE/EXRULE/EXDATE.

Yes, and I assume by 'original' you mean currently booked version of
the object, as the 'original' may be of date (updated already).


--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.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 005197AD85256D2E_=-- From owner-ietf-calendar@mail.imc.org Thu May 22 11:57: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 LAA19112 for ; Thu, 22 May 2003 11:57: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 h4MFfDAF031376 for ; Thu, 22 May 2003 08:41: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 h4MFfCpq031375 for ietf-calendar-bks; Thu, 22 May 2003 08:41:12 -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 h4MFfBAF031368 for ; Thu, 22 May 2003 08:41:11 -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 M2003052211465606223 for ; Thu, 22 May 2003 11:46:56 -0400 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 11:38:39 -0400 Message-ID: <3ECCEEFF.1010304@centive.com> Date: Thu, 22 May 2003 11:38:39 -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: Correct handling of Recurrence-id References: <3ECCE3B2.6010001@Royer.com> In-Reply-To: <3ECCE3B2.6010001@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2003 15:38:39.0316 (UTC) FILETIME=[3757A140:01C32078] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Although iTIP can be sent through > e-mail, iCalendar objects are not processed by an MUA. The are > processed by > a CUA. So your CUA should be smarter. Except that, in the most common case, your CUA receives your incoming iTIP messages only when you open them in your MUA. I suppose it could say, "This message is out of sequence; I'll hold it until I get the missing message(s)". -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |McDonald's, which does not wait on your table, does not cook your| |food to order, and does not clear your table, came up with the | |slogan "We Do It All For You." -- Dave Barry | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu May 22 12:38: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 MAA20535 for ; Thu, 22 May 2003 12:38: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 h4MGJWAF034111 for ; Thu, 22 May 2003 09: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 h4MGJW0L034110 for ietf-calendar-bks; Thu, 22 May 2003 09: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 (bi01p1.nc.us.ibm.com [129.33.49.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4MGJUAF034105 for ; Thu, 22 May 2003 09:19:32 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECBEB5B.9090803@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 22 May 2003 12:14:15 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/22/2003 12:19:20 PM, Serialize complete at 05/22/2003 12:19:20 PM Content-Type: multipart/alternative; boundary="=_alternative 005910AD85256D2E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005910AD85256D2E_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 05/21/2003 05:10:51 PM: > > Don't even reference DTSTART. > > The values for RECURRANCE-ID in any future reschedule/update or counter > > must be the dates rolled from the chairs Original meeting invitation > > RRULE/RDATE/EXRULE/EXDATE. > > Yes, and I assume by 'original' you mean currently booked version of > the object, as the 'original' may be of date (updated already). NO NO NO! That wont work!! Doesnt anyone here think this stuff thru on paper or on a marker board anymore??!! Sheesh, I raised this issue over a year ago and so did someone else but I guess some folks have short memories. The RFCs are in conflict in some parts. ALL text that says that RECURRENCE-ID changes on reschedules, etc is WRONG! IT WONT WORK! IT 100% BREAKS WORKFLOW IN JUST 3 SIMPLE STEPS!!!! (Think Im mad, Im not. Im livid that some folks are NOT thinking a scenario thru and seeing that this is broken! All except Tom and Ki and maybe Andrea if hes lurking still... Ok, deep breath... Again... Continuing...) Lets see if I can demonstrate that _any_ reassigning of RECURRENCE-ID breaks workflow! I want to invite Doug, George, Tom and Ki to a repeating meeting that starts on 09-Jun-03 from 9AM EDT thru 10AM EDT and it repeats for 2 more Mondays (16-Jun-03 & 23-Jun-03). The relevant property values in the REQUEST are: M 09-Jun-03: DTSTART:20030609T140000Z DTEND:20030609T150000Z RECURRENCE-ID:20030609T140000Z SEQUENCE:0 M 16-Jun-03: DTSTART:20030616T140000Z DTEND:20030616T150000Z RECURRENCE-ID:20030616T140000Z SEQUENCE:0 M 23-Jun-03: DTSTART:20030623T140000Z DTEND:20030623T150000Z RECURRENCE-ID:20030623T140000Z SEQUENCE:0 I send the invitations to everyone and wait for responses. I then find out that Tom and George both have conflicts so I decide to move the set to Wednesdays (11-Jun-03, 18-Jun-03, 25-Jun-03) and send out a reschedule notice. The relevant property values in the reschedule REQUEST should be (in my own, Toms and Kis view): W 11-Jun-03: DTSTART:20030611T140000Z DTEND:20030611T150000Z RECURRENCE-ID:20030609T140000Z SEQUENCE:1 W 18-Jun-03: DTSTART:20030618T140000Z DTEND:20030618T150000Z RECURRENCE-ID:20030616T140000Z SEQUENCE:1 W 25-Jun-03: DTSTART:20030625T140000Z DTEND:20030625T150000Z RECURRENCE-ID:20030625T140000Z SEQUENCE:1 From what Ive read it sounds as if Doug and George would agree with this EXCEPT that once received by each ATTENDEE the RECURRENCE-ID value would be changed to match the DTSTART value. If thats the case then any further updates CANNOT BE MATCHED to the ATTENDEEs view of the meetings. That is, if Tom did not recieve the reschedule before accepting my initial request then his REPLY accepting just the first instance would look like: RECURRENCE-ID:20030609T140000Z SEQUENCE:0 How can I as the Organizer match this RECURRENCE-ID to any in my current set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z according to Doug/George)?? There is no match nor can I rely on the SEQUENCE values either since there is no match. Perhaps Doug/George think that the Organizer MUST keep track of ALL possible RECURRENCE-IDs as each instances gets rescheduled...?? Ugh!!) So just how can I correctly tell which instance Tom was accepting? The more reschedules that have occured the worse this 'reassign the RECURRENCE-ID to the new DTSTART' bit gets and makes iMIP workflow (and CAP workflow too) that much more impossible to keep in sync! BUT it gets WORSE! (Yes Virginia, its true...) If I had ADDed a new Monday instance to the repeat set after I rescheduled to Wednesdays (wait for it...) then I can easily mismatch Toms REPLY to an instance he may not have been invited to and may not even know about! The new Monday instance would by 2445 rules be: M 09-Jun-03: DTSTART:20030609T140000Z DTEND:20030609T150000Z RECURRENCE-ID:20030609T140000Z SEQUENCE:2 so I would mistakenly think that Tom accepted the ADDed entry and has not responded to the Wednesday instances at all although his SEQUENCE value was less than my current value and thus Id have to send a new REQUEST to him with the latest Monday info. This can be bad, very very bad! If however the RECURRENCE-ID NEVER EVER EVER changed once it was instanciated no matter where the instance got rescheduled to then I can easily match Toms reply to the proper intance (and know to send him the proper new snapshot of it in a new REQUEST). By now Im sure Doug is replying wth "Well do you have a proposal" and the answer is yes I do. Ive had one for some time but its not fully typed into MSWord and then reformatted into draft form for the WG (Pat just gave me the converter program a couple weeks ago). I am feverishly working on it to fully flesh it out so that it clearly details the problem with repeating meetings and then describes the solution. I expect to post it to the WG sometime next week (I hate MSWord but I dont have LaTEX on my Win2K box...) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.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 005910AD85256D2E_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 05/21/2003 05:10:51 PM:
> > Don't even reference DTSTART.
> > The values for RECURRANCE-ID in any future reschedule/update or counter
> > must be the dates rolled from the chairs Original meeting invitation
> > RRULE/RDATE/EXRULE/EXDATE.
>
> Yes, and I assume by 'original' you mean currently booked version of
> the object, as the 'original' may be of date (updated already).
NO NO NO!  That wont work!!  

Doesnt anyone here think this stuff thru on paper or on a marker board anymore??!!  Sheesh, I raised this issue over a year ago and so did someone else but I guess some folks have short memories.

The RFCs are in conflict in some parts.  ALL text that says that RECURRENCE-ID changes on reschedules, etc is WRONG!  IT WONT WORK!  IT 100% BREAKS WORKFLOW IN JUST 3 SIMPLE STEPS!!!!

(Think Im mad, Im not.  Im livid that some folks are NOT thinking a scenario thru and seeing that this is broken!  All except Tom and Ki and maybe Andrea if hes lurking still...  Ok, deep breath... Again... Continuing...)

Lets see if I can demonstrate that _any_ reassigning of RECURRENCE-ID breaks workflow!

I want to invite Doug, George, Tom and Ki to a repeating meeting that starts on 09-Jun-03 from  9AM EDT thru 10AM EDT and it repeats for 2 more Mondays (16-Jun-03 & 23-Jun-03).  The relevant property values in the REQUEST are:

M 09-Jun-03:
        DTSTART:20030609T140000Z
        DTEND:20030609T150000Z
        RECURRENCE-ID:20030609T140000Z
        SEQUENCE:0

M 16-Jun-03:
        DTSTART:20030616T140000Z
        DTEND:20030616T150000Z
        RECURRENCE-ID:20030616T140000Z
        SEQUENCE:0

M 23-Jun-03:
        DTSTART:20030623T140000Z
        DTEND:20030623T150000Z
        RECURRENCE-ID:20030623T140000Z
        SEQUENCE:0

I send the invitations to everyone and wait for responses.  I then find out that Tom and George both have conflicts so I decide to move the set to Wednesdays (11-Jun-03, 18-Jun-03, 25-Jun-03) and send out a reschedule notice.  The relevant property values in the reschedule REQUEST should be (in my own, Toms and Kis view):

W 11-Jun-03:
        DTSTART:20030611T140000Z
        DTEND:20030611T150000Z
        RECURRENCE-ID:20030609T140000Z
        SEQUENCE:1

W 18-Jun-03:
        DTSTART:20030618T140000Z
        DTEND:20030618T150000Z
        RECURRENCE-ID:20030616T140000Z
        SEQUENCE:1

W 25-Jun-03:
        DTSTART:20030625T140000Z
        DTEND:20030625T150000Z
        RECURRENCE-ID:20030625T140000Z
        SEQUENCE:1

From what Ive read it sounds as if Doug and George would agree with this EXCEPT that once received by each ATTENDEE the RECURRENCE-ID value would be changed to match the DTSTART value.  If thats the case then any further updates CANNOT BE MATCHED to the ATTENDEEs view of the meetings.  

That is, if Tom did not recieve the reschedule before accepting my initial request then his REPLY accepting just the first instance would look like:

        RECURRENCE-ID:20030609T140000Z
        SEQUENCE:0

How can I as the Organizer match this RECURRENCE-ID to any in my current set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z according to Doug/George)??  There is no match nor can I rely on the SEQUENCE values either since there is no match.  Perhaps Doug/George think that the Organizer MUST keep track of ALL possible RECURRENCE-IDs as each instances gets rescheduled...?? Ugh!!)  So just how can I correctly tell which instance Tom was accepting?

The more reschedules that have occured the worse this 'reassign the RECURRENCE-ID to the new DTSTART' bit gets and makes iMIP workflow (and CAP workflow too) that much more impossible to keep in sync!

BUT it gets WORSE!  (Yes Virginia, its true...)

If I had ADDed a new Monday instance to the repeat set after I rescheduled to Wednesdays (wait for it...) then I can easily mismatch Toms REPLY to an instance he may not have been invited to and may not even know about!  The new Monday instance would by 2445 rules be:

M 09-Jun-03:
        DTSTART:20030609T140000Z
        DTEND:20030609T150000Z
        RECURRENCE-ID:20030609T140000Z
        SEQUENCE:2

so I would mistakenly think that Tom accepted the ADDed entry and has not responded to the Wednesday instances at all although his SEQUENCE value was less than my current value and thus Id have to send a new REQUEST to him with the latest Monday info.  This can be bad, very very bad!

If however the RECURRENCE-ID NEVER EVER EVER changed once it was instanciated no matter where the instance got rescheduled to then I can easily match Toms reply to the proper intance (and know to send him the proper new snapshot of it in a new REQUEST).  

By now Im sure Doug is replying wth "Well do you have a proposal" and the answer is yes I do.  Ive had one for some time but its not fully typed into MSWord and then reformatted into draft form for the WG (Pat just gave me the converter program a couple weeks ago).  I am feverishly working on it to fully flesh it out so that it clearly details the problem with repeating meetings and then describes the solution.  I expect to post it to the WG sometime next week (I hate MSWord but I dont have LaTEX on my Win2K box...)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.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 005910AD85256D2E_=-- From owner-ietf-calendar@mail.imc.org Thu May 22 13:38: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 NAA22215 for ; Thu, 22 May 2003 13: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 h4MHDmAF036784 for ; Thu, 22 May 2003 10:13: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 h4MHDl25036783 for ietf-calendar-bks; Thu, 22 May 2003 10:13: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 h4MHDkAF036778 for ; Thu, 22 May 2003 10:13: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 h4MHDhv3027290 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 22 May 2003 10:13:46 -0700 Message-ID: <3ECD053D.4050903@Royer.com> Date: Thu, 22 May 2003 11:13:33 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070903060509040806050905" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070903060509040806050905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 05/21/2003 05:10:51 PM: > > > Don't even reference DTSTART. > > > The values for RECURRANCE-ID in any future reschedule/update or > counter > > > must be the dates rolled from the chairs Original meeting invitation > > > RRULE/RDATE/EXRULE/EXDATE. > > > > Yes, and I assume by 'original' you mean currently booked version of > > the object, as the 'original' may be of date (updated already). > > NO NO NO! That wont work!! Yes it does. If SEQUENCE:1 has an instance of MONDAY <- ORIGINAL And you say yes (book it). If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1' And you say yes (book it) If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY <- UPDATE '2' Nothing matches - the sending CUA is busted. UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1' instance (currently booked entry), not the original. So by original - I assume you mean the currently booked instance and not the SEQUENCE:1 (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 --------------ms070903060509040806050905 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjIxNzEzMzNaMCMGCSqGSIb3DQEJBDEWBBSX AuQPTakyK8ZrKZ7WaZ0ezNJ8ZjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAZ0YgEhrcS18i kszajBMQ7ieJMlomV7smxvzRK7zp0Bpa4SDuEPjpDEkMXzJ//HheL1HXs3WJg3XKD7Hk7Aml B7j4Ju5VYvYh4m5CrKpYxoFAR2SB134wQTJG2Qn3CYSh0Gw6o8zMr9N43CHnXvua7V1nO7Rb 8HYYdx3tjZmlRBbgiRZP2UM+T7s7Uo2D3LcaWR8mb5BpMFBMnpiuKvnBW479AOg9O4+TTdvZ HurKhuHUiDyXWyRfO7mmU8kboLsbIjCpIhb2h1noueoEzONLjHHm3gpudN1NuFUCA56yrH6x im76tt1yasUvecTdM2+Fp/mVPVNC1Ubnjn6KjvebMwAAAAAAAA== --------------ms070903060509040806050905-- From owner-ietf-calendar@mail.imc.org Thu May 22 13:51: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 NAA22599 for ; Thu, 22 May 2003 13:51: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 h4MHRKAF038071 for ; Thu, 22 May 2003 10:27: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 h4MHRK6H038070 for ietf-calendar-bks; Thu, 22 May 2003 10:27: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 h4MHRJAF038063 for ; Thu, 22 May 2003 10:27: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 h4MHRGv3027377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 22 May 2003 10:27:19 -0700 Message-ID: <3ECD0869.3040703@Royer.com> Date: Thu, 22 May 2003 11:27:05 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080703040504030309080404" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080703040504030309080404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > NO. I mean the initial dates from the inital invitation. Then no, that will not work as the initial invitation (say SEQUENCE:1) is out of date. If the currently booked entry is SEQUENCE:99, it is possible that none of the 'original'/'initial (SEQUENCE:1) instances are the same as SEQUENCE:98. There would be no way for the CUA to know what instance was being updated. Put another way, if the update sequence is 99. The CUA needs to have object/SEQUENCE:98 booked or SEQUENCE's 1-98 in the cal-inbox in order to know how to apply the SEQUENCE:99 update as the instances in SEQUENCE:99 apply to SEQUENCE:98 not the initial 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 --------------ms080703040504030309080404 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjIxNzI3MDVaMCMGCSqGSIb3DQEJBDEWBBTs khdSMadQ/B7eb59kq3TFilyDezBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAdpgRX/zkeHla EOl+1204YauL6qDC1iRBorsCmJhde2sac77hGeaktRRCtAxhRs0oYHfg6/KwdwLhYz5qRx3C TLvlfmk3zqhmG5MD9zUXX8KskR0rv4ja1gZzRoDCjqNWByxheqIBLrEgSSbLSnrkyM3MAKAb Hrs2whFOhblUkTMs3HF9xqz/E5y9pIMlTo2FiJZkTQl/mhyWPA805bbPt0OemAxTHb2aEP/2 gdYVGRAUd3uLzusuanhEctclmSxlmz92R/BaFqOIiAC4Y6lQRCh3WtlAdm9SKjqZBQWnEg4+ /ai/Ec3fjOKSCMDVAkE5AmwHuwehR33k5PikKT/BcAAAAAAAAA== --------------ms080703040504030309080404-- From owner-ietf-calendar@mail.imc.org Thu May 22 13:56: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 NAA22734 for ; Thu, 22 May 2003 13:56: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 h4MHeOAF039620 for ; Thu, 22 May 2003 10:40: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 h4MHeO6I039619 for ietf-calendar-bks; Thu, 22 May 2003 10:40: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 h4MHeNAF039612 for ; Thu, 22 May 2003 10:40: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 h4MHeKv3027490 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 22 May 2003 10:40:23 -0700 Message-ID: <3ECD0B7B.5030102@Royer.com> Date: Thu, 22 May 2003 11:40:11 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090107030105080200030605" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090107030105080200030605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > I want to invite Doug, George, Tom and Ki to a repeating meeting that > starts on 09-Jun-03 from 9AM EDT thru 10AM EDT and it repeats for 2 > more Mondays (16-Jun-03 & 23-Jun-03). The relevant property values in > the REQUEST are: > > M 09-Jun-03: > DTSTART:20030609T140000Z > DTEND:20030609T150000Z > RECURRENCE-ID:20030609T140000Z > SEQUENCE:0 > > M 16-Jun-03: > DTSTART:20030616T140000Z > DTEND:20030616T150000Z > RECURRENCE-ID:20030616T140000Z > SEQUENCE:0 > > M 23-Jun-03: > DTSTART:20030623T140000Z > DTEND:20030623T150000Z > RECURRENCE-ID:20030623T140000Z > SEQUENCE:0 > > I send the invitations to everyone and wait for responses. I then find > out that Tom and George both have conflicts so I decide to move the set > to Wednesdays (11-Jun-03, 18-Jun-03, 25-Jun-03) and send out a > reschedule notice. The relevant property values in the reschedule > REQUEST should be (in my own, Toms and Kis view): > > W 11-Jun-03: > DTSTART:20030611T140000Z > DTEND:20030611T150000Z > RECURRENCE-ID:20030609T140000Z > SEQUENCE:1 > > W 18-Jun-03: > DTSTART:20030618T140000Z > DTEND:20030618T150000Z > RECURRENCE-ID:20030616T140000Z > SEQUENCE:1 > > W 25-Jun-03: > DTSTART:20030625T140000Z > DTEND:20030625T150000Z > RECURRENCE-ID:20030625T140000Z > SEQUENCE:1 > > From what Ive read it sounds as if Doug and George would agree with > this EXCEPT that once received by each ATTENDEE the RECURRENCE-ID value > would be changed to match the DTSTART value. If thats the case then any > further updates CANNOT BE MATCHED to the ATTENDEEs view of the meetings. No - not what I said. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090107030105080200030605 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjIxNzQwMTFaMCMGCSqGSIb3DQEJBDEWBBQJ h8sRNPC+8iX69xuZ09zNcXqLIzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAvXBPcMmvDP6/ wR/elheCq3xUBbuH0TKKERNZ38xICWLnrPr76pcUgpx4FhWWPaeYwOxu7WkjWYP3Qy9/AmjW 4Rmjlj1tjuId2yaW8Hdw+drXKSADJQPX9pySiX/wVx+uURNLDrwruX1Yco6fRMrgrs3Q5REg 84QEU+hxAFh0AgKsMZwXMp2b4V8h59PpaP2S6MxMKFbSxJ1cAulAJEqIp0G1nQAr7wbmeJsM C8VrNcizvYPVF3g00VIBP8Zonly2G3jvRrx7yGk7tLf64vBEWYm+ptiJsmD8Fix1QhQHICHG FT9bJzvMdLKzVcb/SEv8zTRqaUyuh5FFhNze2NIh6gAAAAAAAA== --------------ms090107030105080200030605-- From owner-ietf-calendar@mail.imc.org Thu May 22 15:13: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 PAA26287 for ; Thu, 22 May 2003 15:13: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 h4MItXAF044542 for ; Thu, 22 May 2003 11:55: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 h4MItXCG044541 for ietf-calendar-bks; Thu, 22 May 2003 11:55: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4MItWAF044536 for ; Thu, 22 May 2003 11:55:33 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECD053D.4050903@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 22 May 2003 14:55:26 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/22/2003 02:55:31 PM, Serialize complete at 05/22/2003 02:55:31 PM Content-Type: multipart/alternative; boundary="=_alternative 0067D23185256D2E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067D23185256D2E_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 05/22/2003 01:13:33 PM: > > > Yes, and I assume by 'original' you mean currently booked version of > > > the object, as the 'original' may be of date (updated already). > > > > NO NO NO! That wont work!! > > Yes it does. No it does not. Follow the example I used on a marker board or paper if need be. The workflow breaks down because you cannot match REPLYs with REQUESTs over time esp. if they arrive staggered OR out of order!.. (I didnt describe the out of order case, Ill leave it as an exercise to the reader to work out since it results in the same mess. Hint: try working thru the example with a RECURRENCE-ID that never changes and see if it breaks anything...) > If SEQUENCE:1 has an instance of MONDAY <- ORIGINAL > And you say yes (book it). I was using 0 and 1 since thats how 2445 defines it but I think I can follow along... This is the original invitation and we have no problems here... > If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1' > And you say yes (book it) The text on RECURRENCE-ID that George cited conflicts with that in Sections 4.8.5.1 and 4.8.5.2 which say: However, in such cases the original "DTSTART" date MUST still be maintained by the calendaring and scheduling system because the original "DTSTART" value has inherent usage dependencies by other properties such as the "RECURRENCE-ID". You also both overlook the text in Section 4.8.4.4 that 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. The text clearly and unambiguously says "is still set to the original Friday meeting". At least we got it right here too. The paragraph that follows (Georges citation) conflicts w/this and as Tom, Ki and I claim, is in error. Back to your response: This was a case where we got it right the first time around. The RECURRENCE-ID is the same as the initial (aka original) DTSTART. So since the RECURRENCE-ID matches one found and the SEQUENCE is one less than I currently have I would agree that you can book it. However I vehemently disagree that RECURRENCE-ID gets rewritten as the current DTSTART though! > If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY <- UPDATE '2' > Nothing matches - the sending CUA is busted. Wrong. The CUA is NOT busted!!!!!! It sent a 100% perfectly valid and well formed iTIP REPLY based on the REQUEST it was given so how is it busted?!?! If you had not reassigned RECURRENCE-ID after applying UPDATE '1' you would not have this problem; you would easily be able to find it. This is why it cannot change every message. The real problem is in the way we worded the text George cited: RECURRENCE-ID MUST NEVER change once instanciated (see above). If it never does then you can EASILY match the REPLY to the proper instance (no matter its current DTSTART or SEQUENCE!). If it ever does then you MUST have _all_ the previous REQUESTs in order to properly locate the proper instance of the repeat set. Try justifying to users that they can never delete any previous REQUESTs because _your_CUA_ MUST have them around in case there are any future reschedules! Ive been down that path before and it just flat out does not work! Users always think "Why do I need that reschedule for Thursday if its been moved to Wednesday already? Ill just remove it from my queue/Inbox." and, poof, they delete some. Perhaps you expect to allow them to think they delete it when in fact they never do (or never can)... Gee, that sounds like a robust and scalable way to do it. After all iCalendar messages are supposed to be complete snapshots of the instances they refer to so its logical to have to keep ALL of the prior reschedules around just so you can 'follow the trail' of RECURRENCE-IDs to find the correct instance. Wonder what I was thinking... > UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1' > instance (currently booked entry), not the original. _Why_ MUST it be? That makes workflow impossible when > 1 reschedule has happened (ie: the SEQUENCEs differ by more than 1). If RECURRENCE-ID never changes then its easily matched and the proper instance is correctly and easily identified. > So by original - I assume you mean the currently booked instance > and not the SEQUENCE:1 (original)? I thought I was clear enough but I guess not. To be totally unambiguous: the RECURRENCE-ID value is assigned the DTSTART of the instance when it was instanciated and it NEVER EVER changes no matter how often DTSTART changes. So, in my examples (prev. msg) the RECURRENCE-IDs are assigned at SEQUENCE:0 and NEVER EVER change no matter when/where you move each instance to (separately or as a set). Simply put another way: UID is never changed once assigned and it uniquely and unambiguously identifys the entire repeat set. RECURRENCE-ID performs the same function but it is supposed to uniquely and unambiguously identify a particular instance w/in that set! Since UIDs never change, RECURRENCE-IDs shouldn't either... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.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 0067D23185256D2E_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 05/22/2003 01:13:33 PM:
> >  > Yes, and I assume by 'original' you mean currently booked version of
> >  > the object, as the 'original' may be of date (updated already).
> >
> > NO NO NO!  That wont work!!  
>
> Yes it does.
No it does not.  Follow the example I used on a marker board or paper if need be.  The workflow breaks down because you cannot match REPLYs with REQUESTs over time esp. if they arrive staggered OR out of order!.. (I didnt describe the out of order case, Ill leave it as an exercise to the reader to work out since it results in the same mess.  Hint: try working thru the example with a RECURRENCE-ID that never changes and see if it breaks anything...)

> If SEQUENCE:1 has an instance of MONDAY      <- ORIGINAL
> And you say yes (book it).
I was using 0 and 1 since thats how 2445 defines it but I think I can follow along...  This is the original invitation and we have no problems here...

> If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1'
> And you say yes (book it)
The text on RECURRENCE-ID that George cited conflicts with that in Sections 4.8.5.1 and 4.8.5.2 which say:

                 However, in such cases the original "DTSTART" date MUST
  still be maintained by the calendaring and scheduling system because
  the original "DTSTART" value has inherent usage dependencies by other
  properties such as the "RECURRENCE-ID".

You also both overlook the text in Section 4.8.4.4 that 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.

The text clearly and unambiguously says "is still set to the original Friday meeting".  At least we got it right here too.  The paragraph that follows (Georges citation) conflicts w/this and as Tom, Ki and I claim, is in error.

Back to your response:  This was a case where we got it right the first time around.  The RECURRENCE-ID is the same as the initial (aka original) DTSTART.  So since the RECURRENCE-ID matches one found and the SEQUENCE is one less than I currently have I would agree that you can book it.  However I vehemently disagree that RECURRENCE-ID gets rewritten as the current DTSTART though!

> If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY  <- UPDATE '2'
>   Nothing matches - the sending CUA is busted.
Wrong.  The CUA is NOT busted!!!!!!  It sent a 100% perfectly valid and well formed iTIP REPLY based on the REQUEST it was given so how is it busted?!?!

If you had not reassigned RECURRENCE-ID after applying UPDATE '1' you would not have this problem; you would easily be able to find it.  This is why it cannot change every message.

The real problem is in the way we worded the text George cited: RECURRENCE-ID MUST NEVER change once instanciated (see above).  If it never does then you can EASILY match the REPLY to the proper instance (no matter its current DTSTART or SEQUENCE!).  If it ever does then you MUST have _all_ the previous REQUESTs in order to properly locate the proper instance of the repeat set.  

Try justifying to users that they can never delete any previous REQUESTs because _your_CUA_ MUST have them around in case there are any future reschedules!  Ive been down that path before and it just flat out does not work!  Users always think "Why do I need that reschedule for Thursday if its been moved to Wednesday already?  Ill just remove it from my queue/Inbox." and, poof, they delete some.  Perhaps you expect to allow them to think they delete it when in fact they never do (or never can)...  Gee, that sounds like a robust and scalable way to do it.  After all iCalendar messages are supposed to be complete snapshots of the instances they refer to so its logical to have to keep ALL of the prior reschedules around just so you can 'follow the trail' of RECURRENCE-IDs to find the correct instance.   Wonder what I was thinking...

> UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1'
> instance (currently booked entry), not the original.
_Why_ MUST it be?  That makes workflow impossible when > 1 reschedule has happened (ie: the SEQUENCEs differ by more than 1).  

If RECURRENCE-ID never changes then its easily matched and the proper instance is correctly and easily identified.

> So by original - I assume you mean the currently booked instance
> and not the SEQUENCE:1 (original)?
I thought I was clear enough but I guess not.  To be totally unambiguous: the RECURRENCE-ID value is assigned the DTSTART of the instance when it was instanciated and it NEVER EVER changes no matter how often DTSTART changes.  So, in my examples (prev. msg) the RECURRENCE-IDs are assigned at SEQUENCE:0 and NEVER EVER change no matter when/where you move each instance to (separately or as a set).

Simply put another way: UID is never changed once assigned and it uniquely and unambiguously identifys the entire repeat set.  RECURRENCE-ID performs the same function but it is supposed to uniquely and unambiguously identify a particular instance w/in that set!  Since UIDs never change, RECURRENCE-IDs shouldn't either...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.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 0067D23185256D2E_=-- From owner-ietf-calendar@mail.imc.org Thu May 22 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 QAA28426 for ; Thu, 22 May 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 h4MKOnAF047077 for ; Thu, 22 May 2003 13: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 h4MKOmuG047076 for ietf-calendar-bks; Thu, 22 May 2003 13:24: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 h4MKOlAF047071 for ; Thu, 22 May 2003 13:24: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 h4MKOiv3028720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 22 May 2003 13:24:48 -0700 Message-ID: <3ECD3200.1020507@Royer.com> Date: Thu, 22 May 2003 14:24:32 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020309090707010409030404" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020309090707010409030404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 05/22/2003 01:13:33 PM: > > > > Yes, and I assume by 'original' you mean currently booked version of > > > > the object, as the 'original' may be of date (updated already). > > > > > > NO NO NO! That wont work!! > > > > Yes it does. > > No it does not. Follow the example I used on a marker board or paper if > need be. The workflow breaks down because you cannot match REPLYs with > REQUESTs over time esp. if they arrive staggered OR out of order! ... Which is why iTIP covers that exact problem. You have to do a REFRESH or wait until they all come in. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020309090707010409030404 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjIyMDI0MzNaMCMGCSqGSIb3DQEJBDEWBBQi 5GuynlEDrYLSPaOSULdbUWnPezBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAjKvduTq546Pb vacUGUf5u3C/IZUj+BNLtbJZxEXOjfsTgm/5d3bvbSUjLkxIBJ39yqEm+DVeyRBEDQ4VJ6Da IA60X5ui/010Bkdue8wwtKXnBTr73beqvaz19EyIE27+A63ffUWsIIY4D7OYZDdIHHUtlhBV axfuyiCppGe1pBeS2NFXurgHoc6zIt44BnOsTpkwmNKPToLsXM8g602ooNyOfFFYFKPBiSes JMBiihBy/ZZo7P4PfO19S9y6/An18k/Tmyk4lYeoxFTjcrK76mbU95Uzt6DXSdzg6EqG0D5X pvsd2rTOj2S4GVXX+eXPPWLLl6cMFsNdp0rwFt9qMgAAAAAAAA== --------------ms020309090707010409030404-- From owner-ietf-calendar@mail.imc.org Thu May 22 17:08: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 RAA28901 for ; Thu, 22 May 2003 17:08: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 h4MKqnAF048451 for ; Thu, 22 May 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 h4MKqnIn048450 for ietf-calendar-bks; Thu, 22 May 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 nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4MKqmAF048434 for ; Thu, 22 May 2003 13:52:49 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id 29B2C3F939 for ; Thu, 22 May 2003 22:43:13 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id EA8243B0; Thu, 22 May 2003 22:52:44 +0200 (MET DST) To: ietf-calendar@imc.org From: gustav.mango@safecareab.com Subject: Re: Re: Correct handling of Recurrence-id Message-Id: <20030522205244.EA8243B0@nw-pop4.wineasy.se> Date: Thu, 22 May 2003 22:52:44 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Thu May 22 22:30: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 WAA08968 for ; Thu, 22 May 2003 22:30: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 h4N2EIAF060359 for ; Thu, 22 May 2003 19:14: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 h4N2EIAI060358 for ietf-calendar-bks; Thu, 22 May 2003 19:14:18 -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 h4N2EGAF060353 for ; Thu, 22 May 2003 19:14:17 -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 h4N2EJep029038 for ; Thu, 22 May 2003 20:14:19 -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 h4N2EJhD028471 for ; Thu, 22 May 2003 19:14:19 -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 <0HFB00K89I7U03@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Thu, 22 May 2003 19:14:19 -0700 (PDT) Date: Thu, 22 May 2003 19:18:00 -0700 From: kiwong Subject: RE: Correct handling of Recurrence-id To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Ii+eEcqpHujkQO8o6HFPzQ)"; DIFFERENCES=Content-Language Content-language: en-USA Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_Ii+eEcqpHujkQO8o6HFPzQ) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Doug Royer [mailto:Doug@Royer.com] > Sent: Thursday, May 22, 2003 1:25 PM > To: ietf-calendar@imc.org > Subject: Re: Correct handling of Recurrence-id > > > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > Doug claimed on 05/22/2003 01:13:33 PM: > > > > > Yes, and I assume by 'original' you mean currently booked version of > > > > > the object, as the 'original' may be of date (updated already). > > > > > > > > NO NO NO! That wont work!! > > > > > > Yes it does. > > > > No it does not. Follow the example I used on a marker board or paper if > > need be. The workflow breaks down because you cannot match REPLYs with > > REQUESTs over time esp. if they arrive staggered OR out of order! ... > > Which is why iTIP covers that exact problem. You have to do a REFRESH > or wait until they all come in. > How does the REFRESH or wait work for Bruce's sample below? That is, if Tom did not recieve the reschedule before accepting my initial request then his REPLY accepting just the first instance would look like: RECURRENCE-ID:20030609T140000Z SEQUENCE:0 How can I as the Organizer match this RECURRENCE-ID to any in my current set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z according to Doug/George)?? There is no match nor can I rely on the SEQUENCE values either since there is no match. Perhaps Doug/George think that the Organizer MUST keep track of ALL possible RECURRENCE-IDs as each instances gets rescheduled...?? Ugh!!) So just how can I correctly tell which instance Tom was accepting? .... ki --Boundary_(ID_Ii+eEcqpHujkQO8o6HFPzQ) Content-id: 0 Content-type: TEXT/html; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT
> -----Original Message-----
> From: Doug Royer [mailto:Doug@Royer.com]
> Sent: Thursday, May 22, 2003 1:25 PM
> To: ietf-calendar@imc.org
> Subject: Re: Correct handling of Recurrence-id
>
>
>
> Bruce_Kahn@notesdev.ibm.com wrote:
> >
> > Doug claimed on 05/22/2003 01:13:33 PM:
> > > > > Yes, and I assume by 'original' you mean currently booked version of
> > > > > the object, as the 'original' may be of date (updated already).
> > > >
> > > > NO NO NO! That wont work!!
> > >
> > > Yes it does.
> >
> > No it does not. Follow the example I used on a marker board or paper if
> > need be. The workflow breaks down because you cannot match REPLYs with
> > REQUESTs over time esp. if they arrive staggered OR out of order! ...
>
> Which is why iTIP covers that exact problem. You have to do a REFRESH
> or wait until they all come in.
>
How does the REFRESH or wait work for Bruce's sample below?
That is, if Tom did not recieve the reschedule before accepting my initial request then his REPLY accepting just the first instance would look like:
RECURRENCE-ID:20030609T140000Z
SEQUENCE:0
How can I as the Organizer match this RECURRENCE-ID to any in my current set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z according to Doug/George)?? There is no match nor can I rely on the SEQUENCE values either since there is no match. Perhaps Doug/George think that the Organizer MUST keep track of ALL possible RECURRENCE-IDs as each instances gets rescheduled...?? Ugh!!) So just how can I correctly tell which instance Tom was accepting?
....
ki
--Boundary_(ID_Ii+eEcqpHujkQO8o6HFPzQ)-- From owner-ietf-calendar@mail.imc.org Fri May 23 11: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 LAA09635 for ; Fri, 23 May 2003 11:27: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 h4NF8PAF025754 for ; Fri, 23 May 2003 08:08: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 h4NF8Pn2025753 for ietf-calendar-bks; Fri, 23 May 2003 08:08:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NF8NAF025748 for ; Fri, 23 May 2003 08:08:24 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECD3200.1020507@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 11:04:34 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 11:08:15 AM, Serialize complete at 05/23/2003 11:08:15 AM, Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 11:08:16 AM Content-Type: multipart/alternative; boundary="=_alternative 0052AAB085256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0052AAB085256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug said on 05/22/2003 04:24:32 PM: > > No it does not. Follow the example I used on a marker board or paper if > > need be. The workflow breaks down because you cannot match REPLYs with > > REQUESTs over time esp. if they arrive staggered OR out of order! ... > > Which is why iTIP covers that exact problem. You have to do a REFRESH > or wait until they all come in. And by what magic/voodoo does a CUA know it has to send a REFRESH in this case? Toms CUA got a perfectly valid and legitimate REQUEST to which it sent a perfectly valid REPLY. WHY in the world would it think it needed to do a REFRESH before it could send the REPLY?? The SEQUENCE was 0 so why would it even remotely suspect that it needed to REFRESH, its the first instance of the REQUEST!! All of this sounds like workflow thrashing and not a recognition of the problem. Ill cover it in detail in the proper sub-thread... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0052AAB085256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug said on 05/22/2003 04:24:32 PM:
> > No it does not.  Follow the example I used on a marker board or paper if
> > need be.  The workflow breaks down because you cannot match REPLYs with
> > REQUESTs over time esp. if they arrive staggered OR out of order! ...
>
> Which is why iTIP covers that exact problem. You have to do a REFRESH
> or wait until they all come in.
And by what magic/voodoo does a CUA know it has to send a REFRESH in this case?  

Toms CUA got a perfectly valid and legitimate REQUEST to which it sent a perfectly valid REPLY.  WHY in the world would it think it needed to do a REFRESH before it could send the REPLY??  The SEQUENCE was 0 so why would it even remotely suspect that it needed to REFRESH, its the first instance of the REQUEST!!

All of this sounds like workflow thrashing and not a recognition of the problem.  Ill cover it in detail in the proper sub-thread...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0052AAB085256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 12:04: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 MAA10713 for ; Fri, 23 May 2003 12:04: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 h4NFhLAF026883 for ; Fri, 23 May 2003 08:43: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 h4NFhL6s026882 for ietf-calendar-bks; Fri, 23 May 2003 08:43: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NFhKAF026870 for ; Fri, 23 May 2003 08:43:20 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECD053D.4050903@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 11:31:35 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 11:43:10 AM, Serialize complete at 05/23/2003 11:43:10 AM Content-Type: multipart/alternative; boundary="=_alternative 0055240A85256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0055240A85256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/22/2003 01:13:33 PM: > If SEQUENCE:1 has an instance of MONDAY <- ORIGINAL > And you say yes (book it). > > If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1' > And you say yes (book it) > > If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY <- UPDATE '2' > Nothing matches - the sending CUA is busted. > > UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1' > instance (currently booked entry), not the original. In spending some time fuming in traffic last night I realized that Doug / George have reinvented the abominable "Delta" model of workflow for repeating meetings! That is, in order for ANY new iTIP message to be properly interpreted the recipient MUST have ALL of the previous messages and treat each one as a delta change to be applied to the previous one(s) in order to arrive at the right value(s). This "delta" model was quashed and banished when we first encountered the myriad problems that this introduces into workflow, etc. Thats why we declared that all iCalendar objects be full and complete snapshots of the entrys they represent so that they can be processed w/o requiring all kinds of extra gyrations or jumping thru flaming hoops or disembowling of feathered animals on keyboards. So lets take an couple minutes to analyze why the "delta" model is the wrong approach to take: 1: We cannot guarantee that every previous message has arrived at the recipients address. As such, if any message _ever_ is lost then the entire workflow breaks down. Also, data can arrive delayed and out of order making it impossible for workflow to be performed accurately (I often get Dougs replys to my notes waayy before I get my own postings via the IMC list server which gives my threading agents fits!) 2: We cannot prevent users from deleting 'old' messages nor should we require that _all_ previous messages be preserved in case we need to perform some new scheduling action. 3: There is no reliable way for a CUA to tell when the 'last' message in the delta chain has arrived and that workflow can safely be performed. There is no magic indicator property nor can one be safely added. Otherwise an UPDATE 3 (for above) would also have it and thus any CUA would mistake UPDATE 2 as the last one rather than UPDATE 3. Its a chicken and egg type of problem recognizing "the last" or actual message to take workflow actions on. 4: The WG burned lots of gray cells recognizing the fact that the only way to keep workflow functioning was to make each message a full and complete snapshot for that entry/instance. I strongly believe that after we made the design choice to make messages full and complete by themselves that we left in some artifacts of the delta model and that the text that George cited is one such artifact. If anyone can show how using a "delta" model actually will work w/o making workflow seem like alchemy I would love to read it. In the mean time I will stand quite firm in my claim that "Delta is bad!". As I said before (but it may not have sunk in so Ill say it again): The RECURRENCE-ID is akin to the UID in its function. The UID is fixed and unchanging from the initial assignment of it and is used to uniquely identify the non-repeating entry or a repeating instance set. The RECURRENCE-ID performs the same function but within the repeat set. The RECURRENCE-ID is fixed and unchanging from the initial assigment of it and is used to uniquely identify the repeating entry no matter where it has been rescheduled to. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0055240A85256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/22/2003 01:13:33 PM:
> If SEQUENCE:1 has an instance of MONDAY      <- ORIGINAL
> And you say yes (book it).
>
> If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1'
> And you say yes (book it)
>
> If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY  <- UPDATE '2'
>   Nothing matches - the sending CUA is busted.
>
> UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1'
> instance (currently booked entry), not the original.
In spending some time fuming in traffic last night I realized that Doug / George have reinvented the abominable "Delta" model of workflow for repeating meetings!  That is, in order for ANY new iTIP message to be properly interpreted the recipient MUST have ALL of the previous messages and treat each one as a delta change to be applied to the previous one(s) in order to arrive at the right value(s).  

This "delta" model was quashed and banished when we first encountered the myriad problems that this introduces into workflow, etc.  Thats why we declared that all iCalendar objects be full and complete snapshots of the entrys they represent so that they can be processed w/o requiring all kinds of extra gyrations or jumping thru flaming hoops or disembowling of feathered animals on keyboards.

So lets take an couple minutes to analyze why the "delta" model is the wrong approach to take:

1: We cannot guarantee that every previous message has arrived at the recipients address.  As such, if any message _ever_ is lost then the entire workflow breaks down.  Also, data can arrive delayed and out of order making it impossible for workflow to be performed accurately (I often get Dougs replys to my notes waayy before I get my own postings via the IMC list server which gives my threading agents fits!)

2: We cannot prevent users from deleting 'old' messages nor should we require that _all_ previous messages be preserved in case we need to perform some new scheduling action.

3: There is no reliable way for a CUA to tell when the 'last' message in the delta chain has arrived and that workflow can safely be performed.  There is no magic indicator property nor can one be safely added.  Otherwise an UPDATE 3 (for above) would also have it and thus any CUA would mistake UPDATE 2 as the last one rather than UPDATE 3.  Its a chicken and egg type of problem recognizing "the last" or actual message to take workflow actions on.

4: The WG burned lots of gray cells recognizing the fact that the only way to keep workflow functioning was to make each message a full and complete snapshot for that entry/instance.  

I strongly believe that after we made the design choice to make messages full and complete by themselves that we left in some artifacts of the delta model and that the text that George cited is one such artifact.  If anyone can show how using a "delta" model actually will work w/o making workflow seem like alchemy I would love to read it.  In the mean time I will stand quite firm in my claim that "Delta is bad!".

As I said before (but it may not have sunk in so Ill say it again): The RECURRENCE-ID is akin to the UID in its function.  The UID is fixed and unchanging from the initial assignment of it and is used to uniquely identify the non-repeating entry or a repeating instance set.  The RECURRENCE-ID performs the same function but within the repeat set.  The RECURRENCE-ID is fixed and unchanging from the initial assigment of it and is used to uniquely identify the repeating entry no matter where it has been rescheduled to.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0055240A85256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 12:24: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 MAA11437 for ; Fri, 23 May 2003 12:24: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 h4NG95AF027601 for ; Fri, 23 May 2003 09:09: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 h4NG955a027599 for ietf-calendar-bks; Fri, 23 May 2003 09:09: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NG94AF027587 for ; Fri, 23 May 2003 09:09:04 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECD0869.3040703@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 12:03:32 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 12:08:53 PM, Serialize complete at 05/23/2003 12:08:53 PM Content-Type: multipart/alternative; boundary="=_alternative 0058111885256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058111885256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 05/22/2003 01:27:05 PM: > > NO. I mean the initial dates from the inital invitation. > > Then no, that will not work as the initial invitation > (say SEQUENCE:1) is out of date. Err, it will ONLY work if what Toms says occurs... > There would be no way > for the CUA to know what instance was being updated. > > Put another way, if the update sequence is 99. The CUA needs > to have object/SEQUENCE:98 booked or SEQUENCE's 1-98 in the > cal-inbox in order to know how to apply the SEQUENCE:99 > update as the instances in SEQUENCE:99 apply to SEQUENCE:98 > not the initial invitation. This is a 'delta' model!! It does not work for C&S! We have no way to guarantee that every ATTENDEE got (and kept!) all previous REQUESTs! That is why each iTIP message is a complete snapshot of the instance/entry in question. Keeping each and every previous message around just is not practical (gonna hold 98 copies of that 52 instance 'weekly' repeating entry in you 16M PDA AND do CAP?!?! Since each iTIP message is a complete snapshow, WHY are the previous entries necessary? They are ONLY necessary if you try to build a 'delta' model and thus roll all the differences forward to reach the final value. But there is no need for doing any of this if the iTIP message is a complete snapshot, yes? Reassigning just the RECURRENCE-ID by following a 'delta chain' is ludicrous given that the message is the entire snapshot. Why make RECURRENCE-ID the only 'delta' item?? This strongly smells of an artifact from the initial delta design we had (and removed in Chicago I believe; ask Derik, Steve or Frank). Lets fix it (Ill send my proposal next week if I can get back to it and not spend more time trying to show why its bad) and move along... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0058111885256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 05/22/2003 01:27:05 PM:
> > NO.   I mean the initial dates from the inital invitation.
>
> Then no, that will not work as the initial invitation
> (say SEQUENCE:1) is out of date.

Err, it will ONLY work if what Toms says occurs...

>                                There would be no way
> for the CUA to know what instance was being updated.
>
> Put another way, if the update sequence is 99. The CUA needs
> to have object/SEQUENCE:98 booked or SEQUENCE's 1-98 in the
> cal-inbox in order to know how to apply the SEQUENCE:99
> update as the instances in SEQUENCE:99 apply to SEQUENCE:98
> not the initial invitation.
This is a 'delta' model!!  It does not work for C&S!  We have no way to guarantee that every ATTENDEE got (and kept!) all previous REQUESTs!  That is why each iTIP message is a complete snapshot of the instance/entry in question.  

Keeping each and every previous message around just is not practical (gonna hold 98 copies of that 52 instance 'weekly' repeating entry in you 16M PDA AND do CAP?!?!  Since each iTIP message is a complete snapshow, WHY are the previous entries necessary?  They are ONLY necessary if you try to build a 'delta' model and thus roll all the differences forward to reach the final value.  But there is no need for doing any of this if the iTIP message is a complete snapshot, yes?

Reassigning just the RECURRENCE-ID by following a 'delta chain' is ludicrous given that the message is the entire snapshot.  Why make RECURRENCE-ID the only 'delta' item??

This strongly smells of an artifact from the initial delta design we had (and removed in Chicago I believe; ask Derik, Steve or Frank).  Lets fix it (Ill send my proposal next week if I can get back to it and not spend more time trying to show why its bad) and move along...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0058111885256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 12:24: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 MAA11442 for ; Fri, 23 May 2003 12:24: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 h4NG8gAF027577 for ; Fri, 23 May 2003 09:08: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 h4NG8gOB027576 for ietf-calendar-bks; Fri, 23 May 2003 09:08: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 h4NG8fAF027568 for ; Fri, 23 May 2003 09:08: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 h4NG8cv3004671 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 09:08:41 -0700 Message-ID: <3ECE477C.3050409@Royer.com> Date: Fri, 23 May 2003 10:08:28 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040808070504010609030502" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040808070504010609030502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit kiwong wrote: > > -----Original Message----- > > From: Doug Royer [mailto:Doug@Royer.com] > > Sent: Thursday, May 22, 2003 1:25 PM > > To: ietf-calendar@imc.org > > Subject: Re: Correct handling of Recurrence-id > > > > > > > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > > > Doug claimed on 05/22/2003 01:13:33 PM: > > > > > > Yes, and I assume by 'original' you mean currently booked > version of > > > > > > the object, as the 'original' may be of date (updated already). > > > > > > > > > > NO NO NO! That wont work!! > > > > > > > > Yes it does. > > > > > > No it does not. Follow the example I used on a marker board or paper if > > > need be. The workflow breaks down because you cannot match REPLYs with > > > REQUESTs over time esp. if they arrive staggered OR out of order! ... > > > > Which is why iTIP covers that exact problem. You have to do a REFRESH > > or wait until they all come in. > > > How does the REFRESH or wait work for Bruce's sample below? > That is, if Tom did not recieve the reschedule before accepting my > initial request then his REPLY accepting just the first instance would > look like: > RECURRENCE-ID:20030609T140000Z > SEQUENCE:0 Yes. > How can I as the Organizer match this RECURRENCE-ID to any in my current > set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z according to > Doug/George)?? There is no match nor can I rely on the SEQUENCE values > either since there is no match. Perhaps Doug/George think that the > Organizer MUST keep track of ALL possible RECURRENCE-IDs as each > instances gets rescheduled...?? Ugh!!) So just how can I correctly tell > which instance Tom was accepting? No - send him the newest. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040808070504010609030502 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMxNjA4MjhaMCMGCSqGSIb3DQEJBDEWBBQ6 2P5iXo8NxDKWwUnBsnq5bsXwLTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAq7rQVDVEsqJg Xr5Dr3PsCqDItutMwKMRjOGVDU/alxmAU7VcXPmU1d3oIbtZUKy3Njnqld+wMf93MvxIJIVh EPXD4xRfzLzC+O9Xqg5jp5PG+HSt7b8rTi/lPMxkfCSMOA0B1mHK07oMSSkL5lxwRn7eHsCY ZFJkoGag2yvJXn7A3Fp0qWldBFf9gruwrHnPKDB7w0/woeMO5jVLgyNZfufx1keb0pXBJGSu hKuTOXEqHc9VFFXFbCAiw8finBReEapiew1vsyoMwOb7QSUdNeSNZ/d5LDaoWghOMQeg+jbO weozhuLlVwaybAIlQlUlNKruieRES0vDaiHTuUus7gAAAAAAAA== --------------ms040808070504010609030502-- From owner-ietf-calendar@mail.imc.org Fri May 23 12:28: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 MAA11630 for ; Fri, 23 May 2003 12: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 h4NG95AF027602 for ; Fri, 23 May 2003 09:09: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 h4NG95Eg027600 for ietf-calendar-bks; Fri, 23 May 2003 09:09: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NG94AF027586 for ; Fri, 23 May 2003 09:09:04 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 11:52:54 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 12:08:53 PM, Serialize complete at 05/23/2003 12:08:53 PM Content-Type: multipart/alternative; boundary="=_alternative 005717B985256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005717B985256D2F_= Content-Type: text/plain; charset="US-ASCII" I wrote on 05/22/2003 12:14:15 PM: > Lets see if I can demonstrate that _any_ reassigning of RECURRENCE- > ID breaks workflow! I now realize that in my attempt to be calm and collected in composing the example I left off the other side of the example: What it looks like if RECURRENCE-ID _is_ fixed when its initially assigned. Im sorry about that. Ill correct that oversight now and see if that helps those disbelivers out there. Go see the initial example for the Organizers view of the data in case you forgot it... Summarily: I invite Doug, George, Tom and Ki to a repeating meeting. I then rescheduled the entire set to a different day... > if Tom did not recieve the reschedule before accepting my > initial request then his REPLY accepting just the first instance > would look like: > > RECURRENCE-ID:20030609T140000Z > SEQUENCE:0 > > How can I as the Organizer match this RECURRENCE-ID to any in my > current set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z > according to Doug/George)?? I claim that that the RECURRENCE-ID set should be (20030609T140000Z, 20030616T140000Z & 20030623T140000Z) which represent the initial instances they were created for. If this were the case then I can very easily match Toms reply to the instance that was moved to a different date (and/or time). I can see that he replyed to SEQUENCE:0 but Im now at SEQUENCE:1 and thus I can opt to resend a new REQUEST for the proper entry: W 11-Jun-03: DTSTART:20030611T140000Z DTEND:20030611T150000Z RECURRENCE-ID:20030609T140000Z SEQUENCE:1 It may be that Tom did get the reschedule REQUEST and that another REPLY is on the way but it not required NOR is it a problem if it is. His second REPLY accepting the RECURRENCE-ID:20030609T140000Z "passes in email" as my new REQUEST to Tom gets sent out. Once his REPLY arrives I can easily see that Tom will be at the correct Wednesday meeting. For Toms part, he may get a second REQUEST for RECURRENCE-ID:20030609T140000Z but since the SEQUENCE matches what he already has and so does the DTSTART/DTEND he can treat it as a NOOP (or as a possible non-rescheduling update like a change in DESCRIPTION, etc if the CUA wants to do a 'diff' of the properties). In any case, both Tom and I would be happy because I was easily able to match his REPLY to the proper entry and take the best course of action w/o accidentally mismatching the REPLY to the right instance. > The more reschedules that have occured the worse this 'reassign the > RECURRENCE-ID to the new DTSTART' bit gets and makes iMIP workflow > (and CAP workflow too) that much more impossible to keep in sync! This is NOT a problem if the RECURRENCE-ID never changes. Go ahead and try it... If I move the entire set yet again to Thursdays (SEQUENCE:2) and then to Fridays (SEQUENCE:3) I would have the following in my calendar: F 13-Jun-03: DTSTART:20030613T140000Z DTEND:20030613T150000Z RECURRENCE-ID:20030609T140000Z SEQUENCE:3 F 20-Jun-03: DTSTART:20030620T140000Z DTEND:20030620T150000Z RECURRENCE-ID:20030616T140000Z SEQUENCE:3 F 27-Jun-03: DTSTART:20030627T140000Z DTEND:20030627T150000Z RECURRENCE-ID:20030625T140000Z SEQUENCE:3 so if Ki now gets around to accepting my Wednesay 20-Jun-03 reschedule REQUEST (SEQUENCE:1) and sends me back: RECURRENCE-ID:20030616T140000Z SEQUENCE:1 I can quickly and effortlessly see that he missed (or ignored or never got) at least 2 reschedule REQUESTs (SEQUENCEs 2 and 3) and I can easily resend the correct REQUEST: DTSTART:20030620T140000Z DTEND:20030620T150000Z RECURRENCE-ID:20030616T140000Z SEQUENCE:3 Thats never ever guaranted possible in a 'delta' model (see other sub-thread from this AM)! It can only be done reliably 100% of the time if RECURRENCE-ID never changes. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.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 005717B985256D2F_= Content-Type: text/html; charset="US-ASCII"
I wrote on 05/22/2003 12:14:15 PM:
> Lets see if I can demonstrate that _any_ reassigning of RECURRENCE-
> ID breaks workflow!

I now realize that in my attempt to be calm and collected in composing the example I left off the other side of the example: What it looks like if RECURRENCE-ID _is_ fixed when its initially assigned.  Im sorry about that.  Ill correct that oversight now and see if that helps those disbelivers out there.

Go see the initial example for the Organizers view of the data in case you forgot it...  Summarily: I invite Doug, George, Tom and Ki to a repeating meeting.  I then rescheduled the entire set to a different day...

>         if Tom did not recieve the reschedule before accepting my
> initial request then his REPLY accepting just the first instance
> would look like:
>
>         RECURRENCE-ID:20030609T140000Z
>         SEQUENCE:0
>
> How can I as the Organizer match this RECURRENCE-ID to any in my
> current set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z
> according to Doug/George)??  

I claim that that the RECURRENCE-ID set should be (20030609T140000Z, 20030616T140000Z & 20030623T140000Z) which represent the initial instances they were created for.  

If this were the case then I can very easily match Toms reply to the instance that was moved to a different date (and/or time).  I can see that he replyed to SEQUENCE:0 but Im now at SEQUENCE:1 and thus I can opt to resend a new REQUEST for the proper entry:

W 11-Jun-03:
       DTSTART:20030611T140000Z
       DTEND:20030611T150000Z
       RECURRENCE-ID:20030609T140000Z
       SEQUENCE:1

It may be that Tom did get the reschedule REQUEST and that another REPLY is on the way but it not required NOR is it a problem if it is.  His second REPLY accepting the RECURRENCE-ID:20030609T140000Z "passes in email" as my new REQUEST to Tom gets sent out.  Once his REPLY arrives I can easily see that Tom will be at the correct Wednesday meeting.

For Toms part, he may get a second REQUEST for RECURRENCE-ID:20030609T140000Z but since the SEQUENCE matches what he already has and so does the DTSTART/DTEND he can treat it as a NOOP (or as a possible non-rescheduling update like a change in DESCRIPTION, etc if the CUA wants to do a 'diff' of the properties).

In any case, both Tom and I would be happy because I was easily able to match his REPLY to the proper entry and take the best course of action w/o accidentally mismatching the REPLY to the right instance.

> The more reschedules that have occured the worse this 'reassign the
> RECURRENCE-ID to the new DTSTART' bit gets and makes iMIP workflow
> (and CAP workflow too) that much more impossible to keep in sync!

This is NOT a problem if the RECURRENCE-ID never changes.  Go ahead and try it...  

If I move the entire set yet again to Thursdays (SEQUENCE:2) and then to Fridays (SEQUENCE:3) I would have the following in my calendar:

F 13-Jun-03:
       DTSTART:20030613T140000Z
       DTEND:20030613T150000Z
       RECURRENCE-ID:20030609T140000Z
       SEQUENCE:3

F 20-Jun-03:
       DTSTART:20030620T140000Z
       DTEND:20030620T150000Z
       RECURRENCE-ID:20030616T140000Z
       SEQUENCE:3

F 27-Jun-03:
       DTSTART:20030627T140000Z
       DTEND:20030627T150000Z
       RECURRENCE-ID:20030625T140000Z
       SEQUENCE:3

so if Ki now gets around to accepting my Wednesay 20-Jun-03 reschedule REQUEST (SEQUENCE:1) and sends me back:

        RECURRENCE-ID:20030616T140000Z
       SEQUENCE:1
I can quickly and effortlessly see that he missed (or ignored or never got) at least 2 reschedule REQUESTs (SEQUENCEs 2 and 3) and I can easily resend the correct REQUEST:

        DTSTART:20030620T140000Z
       DTEND:20030620T150000Z
       RECURRENCE-ID:20030616T140000Z
       SEQUENCE:3

Thats never ever guaranted possible in a 'delta' model (see other sub-thread from this AM)!  It can only be done reliably 100% of the time if RECURRENCE-ID never changes.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.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 005717B985256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 12:29: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 MAA11704 for ; Fri, 23 May 2003 12:29: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 h4NGA9AF027651 for ; Fri, 23 May 2003 09:10: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 h4NGA9OJ027650 for ietf-calendar-bks; Fri, 23 May 2003 09:10: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 h4NGA8AF027645 for ; Fri, 23 May 2003 09:10: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 h4NGA5v3004681 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 09:10:08 -0700 Message-ID: <3ECE47D7.1080309@Royer.com> Date: Fri, 23 May 2003 10:09:59 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040705000403050308090107" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040705000403050308090107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug said on 05/22/2003 04:24:32 PM: > > > No it does not. Follow the example I used on a marker board or > paper if > > > need be. The workflow breaks down because you cannot match REPLYs > with > > > REQUESTs over time esp. if they arrive staggered OR out of order! ... > > > > Which is why iTIP covers that exact problem. You have to do a REFRESH > > or wait until they all come in. > > And by what magic/voodoo does a CUA know it has to send a REFRESH in > this case? It is covered in iTIP. If you get an update for SEQUENCE:3 and you have SEQUENCE:1, do a REFRESH and get the latest copy. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040705000403050308090107 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMxNjA5NTlaMCMGCSqGSIb3DQEJBDEWBBRt rRnv/pNKLXxZBHUcD6vxSr8JTzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAK3lbXN5KbhzL AuZ+GKAMMNd/C0F90Mr1/4S8A3IUJ1TlAR8GU2vwcHK9V1WeSfi8WHYJ9qLVf0mc2E6AOJKN xQTytmbMgTSjE6vVE882kcRB5iJDjO1Fj/u6ZUz8zLuS0W1KUdV7meHGN48vZaYvoYOIthwD EeQXJ9bFYcUUfGZ93QTgUGhwPGQWvdE0YTyuExA+YGOOWx7VfjnYJJPFFsr4ZjNsr6hE7Wox LMYTvoSGQICXX8NFAg8OriGAbzOgBbNcOzDkl0GJku6PxyE5R6A78v9MEjNC97f53uBeEtvF +mIQd1fTT/FdVesFAyO4b7G/AfcQQ8G0+tGngwb51AAAAAAAAA== --------------ms040705000403050308090107-- From owner-ietf-calendar@mail.imc.org Fri May 23 12:30: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 MAA11753 for ; Fri, 23 May 2003 12:30: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 h4NGDHAF027985 for ; Fri, 23 May 2003 09:13: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 h4NGDHVs027984 for ietf-calendar-bks; Fri, 23 May 2003 09:13: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 h4NGDGAF027975 for ; Fri, 23 May 2003 09:13: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 h4NGDDv3004711 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 09:13:16 -0700 Message-ID: <3ECE4894.9030605@Royer.com> Date: Fri, 23 May 2003 10:13:08 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040108010709080703050904" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040108010709080703050904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 05/22/2003 01:13:33 PM: > > If SEQUENCE:1 has an instance of MONDAY <- ORIGINAL > > And you say yes (book it). > > > > If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1' > > And you say yes (book it) > > > > If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY <- UPDATE '2' > > Nothing matches - the sending CUA is busted. > > > > UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1' > > instance (currently booked entry), not the original. > > In spending some time fuming in traffic last night I realized that Doug > / George have reinvented the abominable "Delta" model of workflow for > repeating meetings! That is, in order for ANY new iTIP message to be > properly interpreted the recipient MUST have ALL of the previous > messages and treat each one as a delta change to be applied to the > previous one(s) in order to arrive at the right value(s). No, not correct. I am simply stating that this problem is resolved in 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 --------------ms040108010709080703050904 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMxNjEzMDhaMCMGCSqGSIb3DQEJBDEWBBR7 9EhfT6+pwokqdISNlflmhPxXDDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAt/GPtll7B5F3 4E7DaNq9xUtx/yBvUF4BqAR1fDbPc9AaHf8wdczqfIfLOcOIu2ug4bigC53uAucRyHvv8P+J zFt6ZwcGCrs1OOCRron2lp0VfxZyyngVnY3d7hMPXojog6dOix1tlNZKCTqZV9PgrSDlLeNF VG4hteNDdSUhp+Nwb2G0O8GEhlqq0BwDtkNmkF69X/YDP961JXIgwjHA5eAgHDLQ5oWlSebj ExLgQ/pYVdJ5yJnIjCco2MV5U/cXTbfS6MeQlR/j7qMqwoKkDnPuRnN1Bn2hfpVmMrr8tE9L 3t5YFUsWKOd80QXEObi1Fy1lxi2rhws1APPPrn06wwAAAAAAAA== --------------ms040108010709080703050904-- From owner-ietf-calendar@mail.imc.org Fri May 23 12: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 MAA11790 for ; Fri, 23 May 2003 12:31: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 h4NGG8AF028231 for ; Fri, 23 May 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 h4NGG8t6028229 for ietf-calendar-bks; Fri, 23 May 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 ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NGG7AF028216 for ; Fri, 23 May 2003 09:16:08 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECCEEFF.1010304@centive.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 12:15:57 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 12:15:56 PM, Serialize complete at 05/23/2003 12:15:56 PM Content-Type: multipart/alternative; boundary="=_alternative 0059341785256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059341785256D2F_= Content-Type: text/plain; charset="US-ASCII" John wrote on 05/22/2003 11:38:39 AM: > Except that, in the most common case, your CUA receives your incoming > iTIP messages only when you open them in your MUA. I suppose it could > say, "This message is out of sequence; I'll hold it until I get the > missing message(s)". Any by what magic would a MUA/CUA know that there are other pending or incoming REQUESTs that it has to wait for? There is no onus to send out new REQUESTS but the Organzier really should when SEQUENCE changes. Then again, if the messages got lost in transit then can the invitee do nothing with the REQUEST? All of this goes away as an issue if we get rid of the concept of applying deltas to the RECURRENCE-ID. Then again maybe some folks like langiushing... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0059341785256D2F_= Content-Type: text/html; charset="US-ASCII"
John wrote on 05/22/2003 11:38:39 AM:
> Except that, in the most common case, your CUA receives your incoming
> iTIP messages only when you open them in your MUA.  I suppose it could
> say, "This message is out of sequence; I'll hold it until I get the
> missing message(s)".
Any by what magic would a MUA/CUA know that there are other pending or incoming REQUESTs that it has to wait for?  

There is no onus to send out new REQUESTS but the Organzier really should when SEQUENCE changes.  

Then again, if the messages got lost in transit then can the invitee do nothing with the REQUEST?  

All of this goes away as an issue if we get rid of the concept of applying deltas to the RECURRENCE-ID.  Then again maybe some folks like langiushing...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0059341785256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 12:35: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 MAA11964 for ; Fri, 23 May 2003 12:35: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 h4NGG8AF028230 for ; Fri, 23 May 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 h4NGG8fq028228 for ietf-calendar-bks; Fri, 23 May 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 ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NGG7AF028215 for ; Fri, 23 May 2003 09:16:08 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECD0B7B.5030102@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 12:12:18 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 12:15:56 PM, Serialize complete at 05/23/2003 12:15:56 PM Content-Type: multipart/alternative; boundary="=_alternative 0058DE4B85256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058DE4B85256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug said on 05/22/2003 01:40:11 PM: > > From what Ive read it sounds as if Doug and George would agree with > > this EXCEPT that once received by each ATTENDEE the RECURRENCE-ID value > > would be changed to match the DTSTART value. If thats the case then any > > further updates CANNOT BE MATCHED to the ATTENDEEs view of the meetings. > > No - not what I said. Sorry if I misunderstood you then. Your other reply reguarding RECURRENCE-ID was: > If SEQUENCE:1 has an instance of MONDAY <- ORIGINAL > And you say yes (book it). > > If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1' > And you say yes (book it) > > If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY <- UPDATE '2' > Nothing matches - the sending CUA is busted. > > UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1' > instance (currently booked entry), not the original. I must have misread your bit on UPDATE 2 then. Just what does "use the RECURRANCE-ID of the UPDATE '1' instance (currently booked entry), not the original." mean if it does not mean that the RECURRENCE-ID value is changed as each UPDATE is recieved??? If the RECURRENCE-ID changes then ONLY if everyone has the entire trail of SEQUENCE and RECURRENCE-ID values can matching be possible! Or is there a way to miss UPDATE 1 and still recover? Oh yeah, just how would an invitee recover the missing UPDATE 1 from the Organizer? By sending a REFRESH for that SEQUENCE/RECURRENCE-ID? Assuming that were true then it becomes encumbant on the Organizer to save off copies of every instance ever created in case someone lost one message somewhere along the line. Gee, thats comforting to know. And if the Organizer loses one for some reason?? The entry is effectively never recoverable! Great workflow... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0058DE4B85256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug said on 05/22/2003 01:40:11 PM:
> >  From what Ive read it sounds as if Doug and George would agree with
> > this EXCEPT that once received by each ATTENDEE the RECURRENCE-ID value
> > would be changed to match the DTSTART value.  If thats the case then any
> > further updates CANNOT BE MATCHED to the ATTENDEEs view of the meetings.
>
> No - not what I said.
Sorry if I misunderstood you then.  Your other reply reguarding RECURRENCE-ID was:

> If SEQUENCE:1 has an instance of MONDAY      <- ORIGINAL
> And you say yes (book it).
>
> If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1'
> And you say yes (book it)
>
> If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY  <- UPDATE '2'
>   Nothing matches - the sending CUA is busted.
>
> UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1'
> instance (currently booked entry), not the original.

I must have misread your bit on UPDATE 2 then.  Just what does "use the RECURRANCE-ID of the UPDATE '1' instance (currently booked entry), not the original." mean if it does not mean that the RECURRENCE-ID value is changed as each UPDATE is recieved???  

If the RECURRENCE-ID changes then ONLY if everyone has the entire trail of SEQUENCE and RECURRENCE-ID values can matching be possible!  Or is there a way to miss UPDATE 1 and still recover?

Oh yeah, just how would an invitee recover the missing UPDATE 1 from the Organizer?  By sending a REFRESH for that SEQUENCE/RECURRENCE-ID?  Assuming that were true then it becomes encumbant on the Organizer to save off copies of every instance ever created in case someone lost one message somewhere along the line.  Gee, thats comforting to know.  And if the Organizer loses one for some reason??  The entry is effectively never recoverable!  Great workflow...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0058DE4B85256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 12:50: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 MAA13069 for ; Fri, 23 May 2003 12:50: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 h4NGSlAF029229 for ; Fri, 23 May 2003 09:28: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 h4NGSlfD029228 for ietf-calendar-bks; Fri, 23 May 2003 09:28:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NGSkAF029223 for ; Fri, 23 May 2003 09:28:47 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id B797D3F8CE for ; Fri, 23 May 2003 18:19:08 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id A11D4313; Fri, 23 May 2003 18:28:42 +0200 (MET DST) To: "ietf-calendar@imc.org" From: gustav.mango@safecareab.com Subject: Re: Re: Correct handling of Recurrence-id Message-Id: <20030523162842.A11D4313@nw-pop4.wineasy.se> Date: Fri, 23 May 2003 18:28:42 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Fri May 23 13:33: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 NAA15738 for ; Fri, 23 May 2003 13:33: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 h4NH8mAF031623 for ; Fri, 23 May 2003 10:08: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 h4NH8mcK031621 for ietf-calendar-bks; Fri, 23 May 2003 10:08: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-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 h4NH8jAF031597 for ; Fri, 23 May 2003 10:08:45 -0700 (PDT) (envelope-from sv134512@iplanet.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-1.sun.com (8.12.9/8.12.9) with ESMTP id h4NH8f4Z007309; Fri, 23 May 2003 10:08:42 -0700 (PDT) Received: from ms-usca15-11.red.iplanet.com (ms-usca15-11.red.iplanet.com [192.18.56.153]) by dm-usca19-13.red.iplanet.com (8.11.7+Sun/8.10.2/IPLANET,v1.2) with ESMTP id h4NH83e22915; Fri, 23 May 2003 10:08:03 -0700 (PDT) Received: from iplanet.com (satyan.red.iplanet.com [192.18.144.108]) by ipost.red.iplanet.com (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HFC00FFCNMHVE@ipost.red.iplanet.com>; Fri, 23 May 2003 10:08:41 -0700 (PDT) Date: Fri, 23 May 2003 10:08:41 -0700 From: sv134512@iplanet.com Subject: Re: Correct handling of Recurrence-id To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Reply-to: satyanarayana.vempati@sun.com Message-id: <3ECE5599.D6AB868@iplanet.com> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT What Bruce says makes perfect sense. Unfortunately the RFC 2445 (and 2446) are ambiguous regarding the issue. Let us say an instance of recurrence is changed several times (initial value at instantiation:r(0), later changed to r(1), r(2), ... r(n-1), r(n). All we really need are r(0) and r(n) to locate and update the instance: the other changes do not add any value. Requiring that the entire "chain " of recurrence changes be seen by each CUA in the correct sequence creates several unnecessary conundrums without any corresponding benefits. The RFCs SHOULD be amended/clarified to this effect. Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 05/22/2003 01:13:33 PM: > > If SEQUENCE:1 has an instance of MONDAY <- ORIGINAL > > And you say yes (book it). > > > > If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1' > > And you say yes (book it) > > > > If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY <- UPDATE '2' > > Nothing matches - the sending CUA is busted. > > > > UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1' > > instance (currently booked entry), not the original. > > In spending some time fuming in traffic last night I realized that > Doug / George have reinvented the abominable "Delta" model of workflow > for repeating meetings! That is, in order for ANY new iTIP message to > be properly interpreted the recipient MUST have ALL of the previous > messages and treat each one as a delta change to be applied to the > previous one(s) in order to arrive at the right value(s). > > This "delta" model was quashed and banished when we first encountered > the myriad problems that this introduces into workflow, etc. Thats > why we declared that all iCalendar objects be full and complete > snapshots of the entrys they represent so that they can be processed > w/o requiring all kinds of extra gyrations or jumping thru flaming > hoops or disembowling of feathered animals on keyboards. > > So lets take an couple minutes to analyze why the "delta" model is the > wrong approach to take: > > 1: We cannot guarantee that every previous message has arrived at the > recipients address. As such, if any message _ever_ is lost then the > entire workflow breaks down. Also, data can arrive delayed and out of > order making it impossible for workflow to be performed accurately (I > often get Dougs replys to my notes waayy before I get my own postings > via the IMC list server which gives my threading agents fits!) > > 2: We cannot prevent users from deleting 'old' messages nor should we > require that _all_ previous messages be preserved in case we need to > perform some new scheduling action. > > 3: There is no reliable way for a CUA to tell when the 'last' message > in the delta chain has arrived and that workflow can safely be > performed. There is no magic indicator property nor can one be safely > added. Otherwise an UPDATE 3 (for above) would also have it and thus > any CUA would mistake UPDATE 2 as the last one rather than UPDATE 3. > Its a chicken and egg type of problem recognizing "the last" or > actual message to take workflow actions on. > > 4: The WG burned lots of gray cells recognizing the fact that the only > way to keep workflow functioning was to make each message a full and > complete snapshot for that entry/instance. > > I strongly believe that after we made the design choice to make > messages full and complete by themselves that we left in some > artifacts of the delta model and that the text that George cited is > one such artifact. If anyone can show how using a "delta" model > actually will work w/o making workflow seem like alchemy I would love > to read it. In the mean time I will stand quite firm in my claim that > "Delta is bad!". > > As I said before (but it may not have sunk in so Ill say it again): > The RECURRENCE-ID is akin to the UID in its function. The UID is > fixed and unchanging from the initial assignment of it and is used to > uniquely identify the non-repeating entry or a repeating instance set. > The RECURRENCE-ID performs the same function but within the repeat > set. The RECURRENCE-ID is fixed and unchanging from the initial > assigment of it and is used to uniquely identify the repeating entry > no matter where it has been rescheduled to. > > Bruce > =========================================================================== > Bruce Kahn INet: > Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the > FAX... > Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Fri May 23 14:01: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 OAA17747 for ; Fri, 23 May 2003 14:01: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 h4NHnAAF036629 for ; Fri, 23 May 2003 10: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 h4NHnAaf036628 for ietf-calendar-bks; Fri, 23 May 2003 10:49: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NHnAAF036616 for ; Fri, 23 May 2003 10:49:10 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE477C.3050409@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 13:40:44 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 01:48:54 PM, Serialize complete at 05/23/2003 01:48:54 PM Content-Type: multipart/alternative; boundary="=_alternative 0060F73685256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0060F73685256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/23/2003 12:08:28 PM: > > How can I as the Organizer match this RECURRENCE-ID to any in my current > > set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z according to > > Doug/George)?? There is no match nor can I rely on the SEQUENCE values > > either since there is no match. Perhaps Doug/George think that the > > Organizer MUST keep track of ALL possible RECURRENCE-IDs as each > > instances gets rescheduled...?? Ugh!!) So just how can I correctly tell > > which instance Tom was accepting? > > No - send him the newest. And just how does the the newest one help him if there have been multiple reschedules (ie: Moved yet again from Wednesday to Thursday and then to Friday)?? Does the Organizer have to build a 'chain' of missing ones for Tom to roll up into the final value for Friday? Or was there some interim solution I didnt see that shows us how to go from SEQUENCE:0 (Monday) to SEQUENCE:3 (Friday) and magically caculate the correct RECURRENCE-IDs to match Friday? By your previous example of UPDATE 2 and UPDATE 3, if the RECURRENCE-ID is not changed appropriately per reschedule its not possible to find a match or get the right value so how would a new, single REQUEST at SEQUENCE:3 get Tom onto the same page as the rest of us? Im sorry but I just dont see 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 0060F73685256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/23/2003 12:08:28 PM:
> > How can I as the Organizer match this RECURRENCE-ID to any in my current
> > set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z according to
> > Doug/George)?? There is no match nor can I rely on the SEQUENCE values
> > either since there is no match. Perhaps Doug/George think that the
> > Organizer MUST keep track of ALL possible RECURRENCE-IDs as each
> > instances gets rescheduled...?? Ugh!!) So just how can I correctly tell
> > which instance Tom was accepting?
>
> No - send him the newest.
And just how does the the newest one help him if there have been multiple reschedules (ie: Moved yet again from Wednesday to Thursday and then to Friday)??  

Does the Organizer have to build a 'chain' of missing ones for Tom to roll up into the final value for Friday?  Or was there some interim solution I didnt see that shows us how to go from SEQUENCE:0 (Monday) to SEQUENCE:3 (Friday) and magically caculate the correct RECURRENCE-IDs to match Friday?

By your previous example of UPDATE 2 and UPDATE 3, if the RECURRENCE-ID is not changed appropriately per reschedule its not possible to find a match or get the right value so how would a new, single REQUEST at SEQUENCE:3 get Tom onto the same page as the rest of us?  Im sorry but I just dont see 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 0060F73685256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 14: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 OAA18418 for ; Fri, 23 May 2003 14: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 h4NI1fAF037061 for ; Fri, 23 May 2003 11:01: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 h4NI1ft0037060 for ietf-calendar-bks; Fri, 23 May 2003 11:01: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 h4NI1eAF037053 for ; Fri, 23 May 2003 11:01: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 h4NI1cv3005495 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 11:01:40 -0700 Message-ID: <3ECE61F8.5080908@Royer.com> Date: Fri, 23 May 2003 12:01:28 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: <3ECE5599.D6AB868@iplanet.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080505020001060802070807" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080505020001060802070807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit sv134512@iplanet.com wrote: > RECURRENCE-ID is akin to the UID in its function. The UID is fixed and > unchanging from the initial assignment of it and is used to uniquely > identify the non-repeating entry or a repeating instance set. The > RECURRENCE-ID performs the same function but within the repeat set. The > RECURRENCE-ID is fixed and unchanging from the initial > assigment of it and is used to uniquely identify the repeating entry no > matter where it has been rescheduled to. Not true. RECURRENCE-ID is only like UID when the SEQUENCE and UID are known. So RECURRENCE-ID applies to the verison of the object where UID and SEQUENCE match the update. A RECURRENCE-ID by itself has no meaning. Only when the SEQUENCE number and UID are known does RECURRENCE-ID have any meaning. A RECURRENCE-ID is an instance of UID (x) SEQUENCE (y). It is NOT an instanec of UID (x) 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 --------------ms080505020001060802070807 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMxODAxMjlaMCMGCSqGSIb3DQEJBDEWBBQ9 beh2cfcDIxCWgX0e1I+LuhdDQjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAv0prDyUNOREQ mf7C6IjIRIKl+bY+GNtbiZEO+bjgVc00NyGA1kLW05V6EmrqatthC8SU3ZuVCGr5rWhGCPRj QfjAOxDHF1R/xxoaRyD3TziouqeWFkUx3HAIarQgszutDJdG90THihn3txWfc9ihzs5vgiy0 3SLFBudsPyI+Nfn4lLOGv7Ms5CGBIPoQ6Al4somskykCKy5kZ2UU3zdYK8UYLv91J/D+0cdH oK3ghvyPRD/U5tjhe8OMB+LHmKpxqcXM2a75aMeq32VuFVTuJR4OBMtx0uSxYMAi0k0PcOXk FDc5Gy0fcWY3eA1i8O/n95yx1GJmBqMRXmpRkLcs8QAAAAAAAA== --------------ms080505020001060802070807-- From owner-ietf-calendar@mail.imc.org Fri May 23 14:32: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 OAA19120 for ; Fri, 23 May 2003 14:32: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 h4NIAfAF037458 for ; Fri, 23 May 2003 11:10: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 h4NIAfdF037457 for ietf-calendar-bks; Fri, 23 May 2003 11:10:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NIAeAF037452 for ; Fri, 23 May 2003 11:10:41 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE47D7.1080309@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 14:06:08 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 02:10:41 PM, Serialize complete at 05/23/2003 02:10:41 PM Content-Type: multipart/alternative; boundary="=_alternative 00634A8285256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00634A8285256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 05/23/2003 12:09:59 PM: > > And by what magic/voodoo does a CUA know it has to send a REFRESH in > > this case? > > It is covered in iTIP. > If you get an update for SEQUENCE:3 and you have SEQUENCE:1, > do a REFRESH and get the latest copy. But how could Toms CUA derive the correct RECURRENCE-ID value from the new SEQUENCE:3 info? Also, his CUA has not seen SEQUENCE:2 or 3 yet so why would it think to do a REFRESH?? It has no need to!! The only time it would need to (in _your_ model) is if it got SEQUENCE:3 and did not get SEQUENCE:2. Thats because it has no way to determine the proper RECURRENCE-ID value because of the missing SEQUENCE:2. Im not making this up, I got it from what you wrote previously: > UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1' > instance (currently booked entry), not the original. so are you saying that the REQUEST I send to Tom in response to his REFRESH would be different than the initial SEQUENCE:3 REQUEST I sent to everyone before? It would have to be to adhere to what you said before OR it the REQUEST MUST contain all the 'links in the reschedule chain' between SEQUENCE:1 and SEQUENCE:3 so that Tom could 'follow the chain'. Based on your text, Im assuming that the RECURRENCE-ID I resend to Tom for SEQUENCE:3 would have to be RECURRENCE-ID:20030611T140000Z in for this new REQUEST yes?? Thats the only way that Tom at SEQUENCE:1 could ever remotely be able to apply the SEQUENCE:3 info and get a new 'matching' RECURRENCE-ID of 20030613T140000Z that the rest of us share... Is this accurate? (This effectively 'skips' the Thursday reschedule at RECURRENCE-ID:20030612T140000Z at SEQUENCE:2) However doing this can cause problems if Tom does get the previous REQUESTs to move him up to SEQUENCE:3. After all in the iMIP world there is going to be latency involved. Well, if not problems at least some odd behaviour/results on Toms' end. Heres why... Since Tom did actually get SEQUENCE:2 and SEQUENCE:3 he is able to recalculate the RECURRENCE-IDs by following the reschedule 'chain'. So now he is at SEQUENCE:3 and RECURRENCE-ID:20030613T140000Z with a particular DTSTAMP (hopefully). He now gets in my new REQUEST to bring him up to SEQUENCE:3. Following the iTIP rules in Section 2.1.5 Message Sequencing Toms CUA would see that the new message has a newer DTSTAMP and thus should be processed. The rub is though that the RECURRENCE-ID will not match the 'previous' instances (SEQUENCE:2 was RECURRENCE-ID:20030612T140000Z). As such his CUA would have to follow the rules and send a REFRESH to me. This of course would cause the same viscious cycle all over again. However, if Tom had NOT recived SEQUENCE:2 and 3 yet then he could be able to process the REQUEST I just sent. This is not a failure of any CUA since each CUA did the proper thing. This is a failure on the base designs part to remove all vestiges of the 'delta' model because in 1 case it can get Tom into a non-recoverable case. Or did I simply overlook something in following the workflow paths and actions??... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00634A8285256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 05/23/2003 12:09:59 PM:
> > And by what magic/voodoo does a CUA know it has to send a REFRESH in
> > this case?  
>
> It is covered in iTIP.
> If you get an update for SEQUENCE:3 and you have SEQUENCE:1,
> do a REFRESH and get the latest copy.
But how could Toms CUA derive the correct RECURRENCE-ID value from the new SEQUENCE:3 info?  Also, his CUA has not seen SEQUENCE:2 or 3 yet so why would it think to do a REFRESH??  It has no need to!!  

The only time it would need to (in _your_ model) is if it got SEQUENCE:3 and did not get SEQUENCE:2.   Thats because it has no way to determine the proper RECURRENCE-ID value because of the missing SEQUENCE:2.  Im not making this up, I got it from what you wrote previously:

> UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1'
> instance (currently booked entry), not the original.

so are you saying that the REQUEST I send to Tom in response to his REFRESH would be different than the initial SEQUENCE:3 REQUEST I sent to everyone before?  It would have to be to adhere to what you said before OR it the REQUEST MUST contain all the 'links in the reschedule chain' between SEQUENCE:1 and SEQUENCE:3 so that Tom could 'follow the chain'.

Based on your text, Im assuming that the RECURRENCE-ID I resend to Tom for SEQUENCE:3 would have to be RECURRENCE-ID:20030611T140000Z in for this new REQUEST yes??  Thats the only way that Tom at SEQUENCE:1 could ever remotely be able to apply the SEQUENCE:3 info and get a new 'matching' RECURRENCE-ID of 20030613T140000Z that the rest of us share...  Is this accurate?  (This effectively 'skips' the Thursday reschedule at RECURRENCE-ID:20030612T140000Z at SEQUENCE:2)

However doing this can cause problems if Tom does get the previous REQUESTs to move him up to SEQUENCE:3.  After all in the iMIP world there is going to be latency involved.  Well, if not problems at least some odd behaviour/results on Toms' end.  Heres why...

Since Tom did actually get SEQUENCE:2 and SEQUENCE:3 he is able to recalculate the RECURRENCE-IDs by following the reschedule 'chain'.  So now he is at SEQUENCE:3 and RECURRENCE-ID:20030613T140000Z with a particular DTSTAMP (hopefully).  He now gets in my new REQUEST to bring him up to SEQUENCE:3.  Following the iTIP rules in Section 2.1.5 Message Sequencing Toms CUA would see that the new message has a newer DTSTAMP and thus should be processed.  The rub is though that the RECURRENCE-ID will not match the 'previous' instances (SEQUENCE:2 was RECURRENCE-ID:20030612T140000Z).  As such his CUA would have to follow the rules and send a REFRESH to me.  This of course would cause the same viscious cycle all over again.

However, if Tom had NOT recived SEQUENCE:2 and 3 yet then he could be able to process the REQUEST I just sent.

This is not a failure of any CUA since each CUA did the proper thing.  This is a failure on the base designs part to remove all vestiges of the 'delta' model because in 1 case it can get Tom into a non-recoverable case.

Or did I simply overlook something in following the workflow paths and actions??...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00634A8285256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 14:45: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 OAA19641 for ; Fri, 23 May 2003 14:45: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 h4NIRBAF037924 for ; Fri, 23 May 2003 11:27: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 h4NIRBn5037923 for ietf-calendar-bks; Fri, 23 May 2003 11:27: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NIRAAF037914 for ; Fri, 23 May 2003 11:27:10 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EC91F79.1070408@centive.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 14:22:32 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 02:27:10 PM, Serialize complete at 05/23/2003 02:27:10 PM Content-Type: multipart/alternative; boundary="=_alternative 0064CAAD85256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064CAAD85256D2F_= Content-Type: text/plain; charset="US-ASCII" John wrote on 05/19/2003 02:16:25 PM: > > That is what it means. If a repeating component has 10 instances > > in which it will occur. Then each has instance has a RECURRENCE-ID > > equivalent to its own start time. > > Basically, if you took the RECUR and rewrote it as a series of RDATEs, > the RECURRENCE-ID of each instance would be equal to the corresponding > RDATE. ONLY the first time the instaces are created! After that the RECURRENCE-ID values are fixed and NEVER EVER EVER change even if the RDATEs do! Otherwise you will run into the same kinds of "Which instance was he accepting?" quandry Ive mentioned elsewhere in this thread. Or can you explain Dougs model to me because Im still not seeing how things work properly.. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0064CAAD85256D2F_= Content-Type: text/html; charset="US-ASCII"
John wrote on 05/19/2003 02:16:25 PM:
> > That is what it means. If a repeating component has 10 instances
> > in which it will occur. Then each has instance has a RECURRENCE-ID
> > equivalent to its own start time.
>
> Basically, if you took the RECUR and rewrote it as a series of RDATEs,
> the RECURRENCE-ID of each instance would be equal to the corresponding
> RDATE.
ONLY the first time the instaces are created!  After that the RECURRENCE-ID values are fixed and NEVER EVER EVER change even if the RDATEs do!

Otherwise you will run into the same kinds of "Which instance was he accepting?" quandry Ive mentioned elsewhere in this thread.  Or can you explain Dougs model to me  because Im still not seeing how things work properly..

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0064CAAD85256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 14:47: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 OAA19681 for ; Fri, 23 May 2003 14:47: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 h4NIRBAF037926 for ; Fri, 23 May 2003 11:27: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 h4NIRBdh037925 for ietf-calendar-bks; Fri, 23 May 2003 11:27: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NIRAAF037913 for ; Fri, 23 May 2003 11:27:10 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE4894.9030605@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 14:17:19 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 02:27:10 PM, Serialize complete at 05/23/2003 02:27:10 PM Content-Type: multipart/alternative; boundary="=_alternative 0064507185256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064507185256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 05/23/2003 12:13:08 PM: > > repeating meetings! That is, in order for ANY new iTIP message to be > > properly interpreted the recipient MUST have ALL of the previous > > messages and treat each one as a delta change to be applied to the > > previous one(s) in order to arrive at the right value(s). > > No, not correct. Umm, then how else would you describe the model of: > If SEQUENCE:1 has an instance of MONDAY <- ORIGINAL > And you say yes (book it). > > If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1' > And you say yes (book it) > > If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY <- UPDATE '2' > Nothing matches - the sending CUA is busted. > > UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1' > instance (currently booked entry), not the original. This clearly says that for SEQUENCE:3 the RECURRENCE-ID "MUST" be that of the SEQUENCE:2. How is that NOT a delta?!??!?! This says for SEQUENCE:3 your RECURRENCE-ID MUST be that of SEQUENCE:2 and for SEQUENCE:2 the RECURRENCE-ID MUST be that of SEQUENCE:1. Thus, to get to SEQUENCE:n I MUST have a chain of SEQUENCE values from 0 thru n-1. If RECURRENCE-ID changes then by definition each change (aka delta) MUST be available to keep the process working. > I am simply stating that this problem is resolved in iTIP. Umm, not its not because iTIP messages are complete snapshots. As such, if there is a breakage the Organzier can send 1 REQUEST with the latest definition of the event/instance and that should fix it up. This is technially not possible given your description above since there is no way to get past any missing SEQUENCE values and 'derive' the latest RECURRENCE-ID since the Organizer simply sends the 'latest' SEQUENCE and not any arbitrary one (ie: SEQUENCE:2).. Can you please show how if Tom misses SEQUENCE:2 and I am currently at SEQUENCE:3 that my CUA would/could construct the proper REQUEST to get him back in sync w/the rest of us?? I just dont see 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 0064507185256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 05/23/2003 12:13:08 PM:
> > repeating meetings!  That is, in order for ANY new iTIP message to be
> > properly interpreted the recipient MUST have ALL of the previous
> > messages and treat each one as a delta change to be applied to the
> > previous one(s) in order to arrive at the right value(s).  
>
> No, not correct.
Umm, then how else would you describe the model of:

> If SEQUENCE:1 has an instance of MONDAY      <- ORIGINAL
> And you say yes (book it).
>
> If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1'
> And you say yes (book it)
>
> If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY  <- UPDATE '2'
>   Nothing matches - the sending CUA is busted.
>
> UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1'
> instance (currently booked entry), not the original.

This clearly says that for SEQUENCE:3 the RECURRENCE-ID "MUST" be that of the SEQUENCE:2.  How is that NOT a delta?!??!?!

This says for SEQUENCE:3 your RECURRENCE-ID MUST be that of SEQUENCE:2 and for SEQUENCE:2 the RECURRENCE-ID MUST be that of SEQUENCE:1.  Thus, to get to SEQUENCE:n I MUST have a chain of SEQUENCE values from 0 thru n-1.  If RECURRENCE-ID changes then by definition each change (aka delta) MUST be available to keep the process working.

> I am simply stating that this problem is resolved in iTIP.
Umm, not its not because iTIP messages are complete snapshots.  As such, if there is a breakage the Organzier can send 1 REQUEST with the latest definition of the event/instance and that should fix it up.  This is technially not possible given your description above since there is no way to get past any missing SEQUENCE values and 'derive' the latest RECURRENCE-ID since the Organizer simply sends the 'latest' SEQUENCE and not any arbitrary one (ie: SEQUENCE:2)..

Can you please show how if Tom misses SEQUENCE:2 and I am currently at SEQUENCE:3 that my CUA would/could construct the proper REQUEST to get him back in sync w/the rest of us??  I just dont see 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 0064507185256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 14:59: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 OAA20100 for ; Fri, 23 May 2003 14:59: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 h4NImYAF038404 for ; Fri, 23 May 2003 11:48: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 h4NImYSe038403 for ietf-calendar-bks; Fri, 23 May 2003 11:48: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NImWAG038384 for ; Fri, 23 May 2003 11:48:33 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE61F8.5080908@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 14:41:26 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 02:48:32 PM, Serialize complete at 05/23/2003 02:48:32 PM Content-Type: multipart/alternative; boundary="=_alternative 0066859185256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066859185256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug climed on 05/23/2003 02:01:28 PM: > Not true. > > RECURRENCE-ID is only like UID when the SEQUENCE and UID are known. > So RECURRENCE-ID applies to the verison of the object where UID > and SEQUENCE match the update. Sorry but _that_ is not true. Go recheck RFC 2446, Section 2.1.5 Message Sequencing: 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. So RECURRENCE-ID is used in conjunction with UID and BEFORE SEQUENCE checking. Why? Simple: you have to find the right instance before you can check if the message is older, newer, etc.! > A RECURRENCE-ID by itself has no meaning. Only when the SEQUENCE > number and UID are known does RECURRENCE-ID have any meaning. Nope, go reread that bit and check the ordering again... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0066859185256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug climed on 05/23/2003 02:01:28 PM:
> Not true.
>
> RECURRENCE-ID is only like UID when the SEQUENCE and UID are known.
> So RECURRENCE-ID applies to the verison of the object where UID
> and SEQUENCE match the update.
Sorry but _that_ is not true.  

Go recheck RFC 2446, Section 2.1.5 Message Sequencing:

   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.
So RECURRENCE-ID is used in conjunction with UID and BEFORE SEQUENCE checking.  Why?  Simple: you have to find the right instance before you can check if the message is older, newer, etc.!
> A RECURRENCE-ID by itself has no meaning. Only when the SEQUENCE
> number and UID are known does RECURRENCE-ID have any meaning.
Nope, go reread that bit and check the ordering again...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0066859185256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 15:06: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 PAA20661 for ; Fri, 23 May 2003 15:06: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 h4NIk5AF038338 for ; Fri, 23 May 2003 11:46: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 h4NIk5TH038337 for ietf-calendar-bks; Fri, 23 May 2003 11:46: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 h4NIk4AF038331 for ; Fri, 23 May 2003 11:46: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 h4NIk1v3005843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 11:46:04 -0700 Message-ID: <3ECE6C5F.8010009@Royer.com> Date: Fri, 23 May 2003 12:45:51 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070902070208060407060302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070902070208060407060302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 05/23/2003 12:08:28 PM: > > > How can I as the Organizer match this RECURRENCE-ID to any in my > current > > > set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z > according to > > > Doug/George)?? There is no match nor can I rely on the SEQUENCE values > > > either since there is no match. Perhaps Doug/George think that the > > > Organizer MUST keep track of ALL possible RECURRENCE-IDs as each > > > instances gets rescheduled...?? Ugh!!) So just how can I correctly > tell > > > which instance Tom was accepting? > > > > No - send him the newest. > > And just how does the the newest one help him if there have been > multiple reschedules (ie: Moved yet again from Wednesday to Thursday and > then to Friday)?? ATTENDEE-1 has: UID:1 SEQUENCE:2 Now iTIP does not have an 'update' method. So lets say the ORGANIZER sends a: METHOD:CANCEL UID:1 SEQUENCE:10 RECURRENCE-ID: monday... ATTENDEE-1 notices that only SEQUENCE:2 has been processed and therefore knows to send a REFRESH to the ORGANIZER. As the latest is SEQUENCE:10, the ORGANIZER sends a "REQUEST" method SEQUENCE:10 object to the attendee (as defined in iTIP). Now the attendee has SEQUENCE:10, now the newly received CANCEL/UID:1/SEQUENCE:10 is irrelevant and can be thrown away as ATTENDEE-1 now has the latest object. Now ATTENDEE-1 can REPLY, or COUNTER the SEQUENCE:10 object. Any instances from SEQUENCE:2 in ATTENDEE-1's calendar that are not in SEQUENCE:10 are no longer part of that object. So ATTENDE-1 can COUNTER or delete them. In 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. No one needs to know the intermediate objects. > Does the Organizer have to build a 'chain' of missing ones for Tom to > roll up into the final value for Friday? No. However the ORGANIZER may wish to keep track of who did a REPLY to the newest SEQUENCE and perhaps re-send a REQUEST with the newest SEQUENCE in it to the non-responsive ATTENDEE. Or perhaps the ORGANIZER keeps track of the SEQUENCE value in each reply to each ATTENDEE. So if ATTENDEE-1 had only replied to SEQUENCE:2, then the ORGANIZER could optimize their code knowing that if a CANCEL SEQUENCE:10 were sent to ATTENDEE-1 that the first thing that ATTENDEE-1 would do was a REFRESH. So knowing that ATTENDEE-1 had only done a REPLY/SEQUENCE:2, could instead of sending ATTENDEE-1 the CANCEL, instead send ATTENDEE-1 a REQUEST/SEQUENCE:10 avoiding that extra send/reply loop. The ORGANIZER controls the object. > Or was there some interim > solution I didnt see that shows us how to go from SEQUENCE:0 (Monday) to > SEQUENCE:3 (Friday) and magically caculate the correct RECURRENCE-IDs to > match Friday? No, simply do a REFRESH and get the latest copy, then the ATTENDEE can do a REPLY or COUNTER to that 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 --------------ms070902070208060407060302 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMxODQ1NTFaMCMGCSqGSIb3DQEJBDEWBBTi cDRlUytLwTmDR59ERYg38vJqTzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAbvqzPCb3mRsF i7GJrUeZo/G3rcQwMERDKCP75zWUD0cAcR4W1e/qHtUNyS7DC4PTzBTZ0NTXyv5guiTtn1xL BT3RR2q8QeJwzU6Z5Uigc0zThZMxBG2zOiGhHFWVF3Q7NZLlLbE3VvXynwC3c+XzSClbbrsT +LSZdf/KihTGF0+zU8RdF77r5eKpGXTJm9KoCGg3O2x7lQ4IqvpIC43JfYpJDgBHk8qFx5CH E7zKkpVOUpzYDAH09snE7WWh8n49tir5KEBFTIf4CcfwFT4XeHXo2foIrB218QE+Qp0Wm5ik faPQQQb3EcZRjQCB+4IeYpfP0QDTGh6Hkgd9Hnb3/AAAAAAAAA== --------------ms070902070208060407060302-- From owner-ietf-calendar@mail.imc.org Fri May 23 15:08: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 PAA20891 for ; Fri, 23 May 2003 15:08: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 h4NIq0AF038541 for ; Fri, 23 May 2003 11:52: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 h4NIq0sG038540 for ietf-calendar-bks; Fri, 23 May 2003 11:52: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 h4NIpxAF038532 for ; Fri, 23 May 2003 11:51: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 h4NIpvv3005904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 11:52:00 -0700 Message-ID: <3ECE6DC7.1030307@Royer.com> Date: Fri, 23 May 2003 12:51:51 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000602010601040603060302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000602010601040603060302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug responded on 05/23/2003 12:09:59 PM: > > > And by what magic/voodoo does a CUA know it has to send a REFRESH in > > > this case? > > > > It is covered in iTIP. > > If you get an update for SEQUENCE:3 and you have SEQUENCE:1, > > do a REFRESH and get the latest copy. > > But how could Toms CUA derive the correct RECURRENCE-ID value from the > new SEQUENCE:3 info? It does not need to as the SEQUENCE:3 object contains the current state of the object. iTIP does not have an UPDATE method. The way that you update is to change something, increment the SEQUENCE, then send a REQUET to the ATTENDEEs. > Also, his CUA has not seen SEQUENCE:2 or 3 yet so > why would it think to do a REFRESH?? It has no need to!! Because that is what SEQUENCE is used for. If you get something newer and you can not figure it out, do a REFRESH to get the laest copy and throw your copy away. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000602010601040603060302 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMxODUxNTJaMCMGCSqGSIb3DQEJBDEWBBTm wVrVuPZlQrvqm9k93cGtvEg04DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAww2DRAFIOmcH bmvrcjNtPikAN/g8bU0iRiuRSsvjWQYKO1fZDRMHohFnXbGl07jDrd0FZSpKGvmFZKboq3C2 SwnACeMrCXcfo0rhtDNn1nLaXIjD5fYByWzGPhm0UudZ60bBURcM9Lfb9JvRYrvzR6Gxv5DU m/nk6gmO3S31p17vZIN2vuHGYBFTi5Q0KJi+YQXrQ04iPqO9nk3riBfwEbzN1iEP9N759GYU X7a4bPV4wmPe1LzpUEeFv2JYTsJxIadomL19HxKQ2rijVzmaqC+8a+sNBli8+mqqM6Acu8Wy f5fOfyt/OYJ5mwgSAa7QlbJgcbbXBq/vPXVdKt49uAAAAAAAAA== --------------ms000602010601040603060302-- From owner-ietf-calendar@mail.imc.org Fri May 23 15:19: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 PAA21870 for ; Fri, 23 May 2003 15:19: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 h4NJ1sAF039123 for ; Fri, 23 May 2003 12:01: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 h4NJ1sCb039122 for ietf-calendar-bks; Fri, 23 May 2003 12:01: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 h4NJ1rAF039116 for ; Fri, 23 May 2003 12:01: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 h4NJ1pv3005989 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 12:01:53 -0700 Message-ID: <3ECE7019.5020606@Royer.com> Date: Fri, 23 May 2003 13:01:45 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070503090501030507080906" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070503090501030507080906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > John wrote on 05/19/2003 02:16:25 PM: > > > That is what it means. If a repeating component has 10 instances > > > in which it will occur. Then each has instance has a RECURRENCE-ID > > > equivalent to its own start time. > > > > Basically, if you took the RECUR and rewrote it as a series of RDATEs, > > the RECURRENCE-ID of each instance would be equal to the corresponding > > RDATE. > > ONLY the first time the instaces are created! After that the > RECURRENCE-ID values are fixed and NEVER EVER EVER change even if the > RDATEs do! > > Otherwise you will run into the same kinds of "Which instance was he > accepting?" quandry Ive mentioned elsewhere in this thread. Or can you > explain Dougs model to me because Im still not seeing how things work > properly.. Bruces responses above are contrary to RFC-2446. The RECURRENCE-ID values only usable with a known UID and SEQUENCE. Bruces comments are only valid when SEQUENCE == 0, when there has never been a ADD or CANCEL, there have been no significant revision to the calendar component (as defined in 2445), as long as DTSTART, DTEND, DUE, RDATE, RRULE, EXDATE, EXRULE, STATUS, LOCATION, and perhaps more have not changed - as defined in 2445. The 'which instance' is not an issue. The instance is UID/RECURRENCE-ID/SEQUENCE and sometimes DTSTAMP. That is 'an 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 --------------ms070503090501030507080906 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMxOTAxNDVaMCMGCSqGSIb3DQEJBDEWBBT0 0IQjWUY1OWPcw2pZefpIwobFdjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAn/pprURtIthA E6mhJID46GlRsTJQfsQKmbZj7zKKaKBTHXQlqABleikUV5eSu0BY2tkzWmIOQxulTutsqnYN jKhu4R+MNpkG7p14is4kzh8tY9QRdfLs+hFQ9sips8WQadiAFa7uTu7BSWzzBoi0FSsRazu6 HWiMXr5GK/eQXEVw0nU0w/L3h9jshUgPlqpKvGaoA0zzxq6kUnQJ5JAJmSSEP3hdcCdF2Ws9 9xp8xJPclAp4vb1IQ3D0XHUDXUIZ2hmVI0hJtCif5Zy3/BDrkzg1bH7Cg9J8VsRU7Cm0Np4y NBTrZxCDfOJm2ffyeu0Wl8j1mUbcg9w+OEtDAcv3hQAAAAAAAA== --------------ms070503090501030507080906-- From owner-ietf-calendar@mail.imc.org Fri May 23 15:45: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 OAA20099 for ; Fri, 23 May 2003 14:59: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 h4NImXAF038397 for ; Fri, 23 May 2003 11:48: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 h4NImXh8038396 for ietf-calendar-bks; Fri, 23 May 2003 11:48: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NImWAF038384 for ; Fri, 23 May 2003 11:48:33 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EC51C58.80502@Royer.com> To: ietf-calendar@imc.org Subject: Re: iTIP REPLY question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 14:28:24 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 02:48:32 PM, Serialize complete at 05/23/2003 02:48:32 PM Content-Type: multipart/alternative; boundary="=_alternative 0065545585256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065545585256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug said on 05/16/2003 01:14:00 PM: > So - yes you can do that. Many will not allow that. > Many public read-only calendar will however allow anonymous > access to view public calendars and many will not. I know we agree on stuff, we've done it before and we can do it again... So what about my other issues related to firewalls, inter/intranets, etc? Or the point about my REQUEST is NOT bogus because I was able to get it to your calendar just fine using CAP and you were perfectly able to read and parse it; the only problem was that you have no way to get back to my CS to respond... Or the comparison between mail and routing vs CAP?... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0065545585256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug said on 05/16/2003 01:14:00 PM:
> So - yes you can do that. Many will not allow that.
> Many public read-only calendar will however allow anonymous
> access to view public calendars and many will not.
I know we agree on stuff, we've done it before and we can do it again...

So what about my other issues related to firewalls, inter/intranets, etc?  

Or the point about my REQUEST is NOT bogus because I was able to get it to your calendar just fine using CAP and you were perfectly able to read and parse it; the only problem was that you have no way to get back to my CS to respond...

Or the comparison between mail and routing vs CAP?...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0065545585256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 15:50: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 PAA22779 for ; Fri, 23 May 2003 15:50: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 h4NJbiAF040330 for ; Fri, 23 May 2003 12:37: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 h4NJbifY040329 for ietf-calendar-bks; Fri, 23 May 2003 12:37: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 h4NJbeAF040324 for ; Fri, 23 May 2003 12:37: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 h4NJbcv3006256 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 12:37:41 -0700 Message-ID: <3ECE7879.30809@Royer.com> Date: Fri, 23 May 2003 13:37:29 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040407030901000006030105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040407030901000006030105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug climed on 05/23/2003 02:01:28 PM: > > Not true. > > > > RECURRENCE-ID is only like UID when the SEQUENCE and UID are known. > > So RECURRENCE-ID applies to the verison of the object where UID > > and SEQUENCE match the update. > > Sorry but _that_ is not true. > > Go recheck RFC 2446, Section 2.1.5 Message Sequencing: > > 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. > > So RECURRENCE-ID is used in conjunction with UID and BEFORE SEQUENCE > checking. Why? Simple: you have to find the right instance before you > can check if the message is older, newer, etc.! Which was my point!? You will notice that UID *was* in my sentence you quoted!? As was SEQUENCE. > > A RECURRENCE-ID by itself has no meaning. Only when the SEQUENCE > > number and UID are known does RECURRENCE-ID have any meaning. > > Nope, go reread that bit and check the ordering again... I do not need to, you correctly quoted the RFC above. It is only usable when UID and SEQENCE are known. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040407030901000006030105 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMxOTM3MjlaMCMGCSqGSIb3DQEJBDEWBBTg t+jBcFnKE8eRJiRNwvkq29MDIDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAlEqIrFDyz7ga NkIOqsGJioPnZ5UjTgoo+KSrsKbOs6PEqvlfqTTYFRhRLkpE+KQGdFCE19O6l68TBqFJF+2M 3I2FkkdMWApF94HVBR445RsdfF7KDWmwhac1J0XIKa60oieqBfNzUrRwL0UEUT+L4Pv3ye5v 5LZULao1a4TTQEbfk+EaiWWIfnba/ln981qUC0FzEKxgq0VNclyeFBvyRnKTnJOQoHv3vO9m LZbo7oMr3ZCATC1P+Rio8s5+GaivOO8Bjuu4oePjeuAKWnqdwoNJZdC1eXOvzLBCdnAQqSSx RqLc+pmLbM6nUzweCHW9JLTyQUHiRn1y9Mye7z79DQAAAAAAAA== --------------ms040407030901000006030105-- From owner-ietf-calendar@mail.imc.org Fri May 23 15:55: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 PAA22974 for ; Fri, 23 May 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 h4NJdDAF040376 for ; Fri, 23 May 2003 12:39: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 h4NJdDeY040374 for ietf-calendar-bks; Fri, 23 May 2003 12:39: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 h4NJdCAF040369 for ; Fri, 23 May 2003 12:39: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 h4NJd8v3006273 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 12:39:13 -0700 Message-ID: <3ECE78D7.4080703@Royer.com> Date: Fri, 23 May 2003 13:39:03 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050004010809080605040506" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050004010809080605040506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug said on 05/16/2003 01:14:00 PM: > > So - yes you can do that. Many will not allow that. > > Many public read-only calendar will however allow anonymous > > access to view public calendars and many will not. > > I know we agree on stuff, we've done it before and we can do it again... > > So what about my other issues related to firewalls, inter/intranets, etc? The issue was "can you" and "must you". The answers are "yes" and "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 --------------ms050004010809080605040506 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMxOTM5MDNaMCMGCSqGSIb3DQEJBDEWBBQ0 frXrQiMrAvdIGqKYDGMqnvmcujBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEANslJec1+EnCY 7nPOSATWUbbLl4ULcFGqpR71PbmYURNfYaf7g/8pDSqHSWip03IR7Ve1vc+9a0ENUuhCgA5c JK9I6Qm3QXVAZoYobDsjLTtIy8GWla+9+Mwit8zH/mCWi8AaHe8HO6Yhkcmz70qr/FXRSSR7 bGUsjvbqD+MeSpHo5f/7IZU8adFg5fGoqk5jbiqTcGD4Z6csL21LTyFWDJkcwEpwF+xTbQV1 7qvZECF5AoaMH99oAWJQ4rDl6vn9tjWhIBRJNlEU0WYJ4A2WabbolYi29DPwRSLEzFsQV/An 0pKQNTrITwB9JfQ9b1w+ZB0Xv9TF7xnIPnka3Wh5TQAAAAAAAA== --------------ms050004010809080605040506-- From owner-ietf-calendar@mail.imc.org Fri May 23 16:48:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25450 for ; Fri, 23 May 2003 16:48: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 h4NKa6AF043116 for ; Fri, 23 May 2003 13: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 h4NKa6PF043115 for ietf-calendar-bks; Fri, 23 May 2003 13: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NKa5AF043110 for ; Fri, 23 May 2003 13:36:05 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE78D7.4080703@Royer.com> To: ietf-calendar@imc.org Subject: Re: iTIP REPLY question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 16:22:25 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 04:35:59 PM, Serialize complete at 05/23/2003 04:35:59 PM Content-Type: multipart/alternative; boundary="=_alternative 006FC4AA85256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006FC4AA85256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 05/23/2003 03:39:03 PM: > > So what about my other issues related to firewalls, inter/intranets, etc? > > The issue was "can you" and "must you". The answers are "yes" and "no". I dont think you recall my original questions/comments Im referring to here so Ill repost them here to refresh everyones memory. I had replied: > > > > How do I access the other CS? > > > > > > If the ORGANIZER property is a CAP uri, then open a connection > > > to that uri. > > > > Will this work for the case where CS's are behind firewalls and thus not > > necessarily exposed to external DNS servers? > > > > Can you at INET-consulting.com resolve my alice.iris.com CAP server? > > If you set your ORGANIZER property value to CAP:alice.iris.com, I would > expect to be able to CAP reply to that address. You are assuming that because my CUA was able to get outside the firewall and reach your CS somehow that your CUA MUST be able to both find and contact my CS to return the REPLY. This is NOT necessarily true. Companys have few qualms about allowing outbound access by their people (ie: HTTP or SOCKS proxying) but they have cast in diamond (harder than stone!) rules against allowing external access to their internal networks let alone servers. As such I would be able to reach your CS (assuming you allow access to your servers from outside your firewall!) but you have a snowballs chance in a nuclear blast of even getting the IP of my CS and reaching it from your CUA. Unlike mail which has pretty well understood processes/needs and does not require exposing internal networks/servers directly to outsiders, CAP has an implic limitation that every CS involved must be directly reachable by the CUAs involved (remember, we took out 'fan out' and this is one side effect of that). As such CAP only works as intended if companies expose their networks/servers and thats going to be a hard sell, especially to larger companies. > > You'll probably get "Unknown host" from your DNS server. So what > > should your CUA do at that point? > > I would call you on the phone and tell you you sent me a bogus > CAP object. Then delete the object from my store. Its NOT bogus! It was perfectly formed and properly routed from my CUA to your CS. Just because you cannot get to my CS does not mean the CAP object is bad! If I had used a CS that is not valid (alice.iris.com is valid) or the data in the CAP object was bad then Id agree. However its 100% correct to EVERYONE ELSE who can reach my CS so how does that make the object bad? If your CUA can process the REQUEST just fine then how is it bad? Its not a problem w/the data; its a problem in the design/expectations. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006FC4AA85256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 05/23/2003 03:39:03 PM:
> > So what about my other issues related to firewalls, inter/intranets, etc?  
>
> The issue was "can you" and "must you". The answers are "yes" and "no".
I dont think you recall my original questions/comments Im referring to here so Ill repost them here to refresh everyones memory.  I had replied:

<SNIPPET>
> >  > > How do I access the other CS?
> >  >
> >  > If the ORGANIZER property is a CAP uri, then open a connection
> >  > to that uri.
> >
> > Will this work for the case where CS's are behind firewalls and thus not
> > necessarily exposed to external DNS servers?  
> >
> > Can you at INET-consulting.com resolve my alice.iris.com CAP server?
>
> If you set your ORGANIZER property value to CAP:alice.iris.com, I would
> expect to be able to CAP reply to that address.

You are assuming that because my CUA was able to get outside the firewall and reach your CS somehow that your CUA MUST be able to both find and contact my CS to return the REPLY.  This is NOT necessarily true.  

Companys have few qualms about allowing outbound access by their people (ie: HTTP or SOCKS proxying) but they have cast in diamond (harder than stone!) rules against allowing external access to their internal networks let alone servers.  As such I would be able to reach your CS (assuming you allow access to your servers from outside your firewall!) but you have a snowballs chance in a nuclear blast of even getting the IP of my CS and reaching it from your CUA.

Unlike mail which has pretty well understood processes/needs and does not require exposing internal networks/servers directly to outsiders, CAP has an implic limitation that every CS involved must be directly reachable by the CUAs involved (remember, we took out 'fan out' and this is one side effect of that).  As such CAP only works as intended if companies expose their networks/servers and thats going to be a hard sell, especially to larger companies.

> >  You'll probably get "Unknown host" from your DNS server.  So what
> > should your CUA do at that point?
>
> I would call you on the phone and tell you you sent me a bogus
> CAP object. Then delete the object from my store.

Its NOT bogus!  It was perfectly formed and properly routed from my CUA to your CS.  Just because you cannot get to my CS does not mean the CAP object is bad!  If I had used a CS that is not valid (alice.iris.com is valid) or the data in the CAP object was bad then Id agree.  However its 100% correct to EVERYONE ELSE who can reach my CS so how does that make the object bad?  If your CUA can process the REQUEST just fine then how is it bad?  Its not a problem w/the data; its a problem in the design/expectations.
</SNIPPET>
Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006FC4AA85256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 17:28: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 RAA26716 for ; Fri, 23 May 2003 17:28: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 h4NL9uAF045374 for ; Fri, 23 May 2003 14:09: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 h4NL9tbH045373 for ietf-calendar-bks; Fri, 23 May 2003 14:09: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 h4NL9sAF045367 for ; Fri, 23 May 2003 14:09: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 h4NL9qv3007117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 14:09:55 -0700 Message-ID: <3ECE8E16.3020505@Royer.com> Date: Fri, 23 May 2003 15:09:42 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040106050503000602040201" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040106050503000602040201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 05/23/2003 03:39:03 PM: > > > So what about my other issues related to firewalls, > inter/intranets, etc? > > > > The issue was "can you" and "must you". The answers are "yes" and "no". > > I dont think you recall my original questions/comments Im referring to > here so Ill repost them here to refresh everyones memory. I had replied: > ... > > You are assuming that because my CUA was able to get outside the > firewall and reach your CS somehow that your CUA MUST be able to both > find and contact my CS to return the REPLY. This is NOT necessarily > true. It is true that you can send REQUEST objects and break them in such a way that no one can reply. Don't do that. Such objects are bogus and should be deleted. Just like a email with a bogus 'From' line. Your example is not a valid comparison. My internal email address is not the same as my world-known email address. And there is no RFC or standard solution to the problem. How do I get email replies? Because of a gateway that knows what I did. And because I set my 'From' and 'Reply-To' to be my world usable e-mail address and not my internal email address. And that is not defined in any RFC. It is a vendor feature of many vendor MUA's and gateways. So, if you want to advertise CAP addresses, ether make a gateway that translates for you, or only send out your world reachable CAP address. Or make your CUA smart and send your local CAP address to local users and your global CAP address to non-local users. MX records are only used to find which system accepts '...@royer.com', it has nothing to do with if my internal e-mail address is reachable from the outside. If I were to set my reply-to address to be my internal e-mail address - all of my email would bounce. Just like with CAP or iMIP. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040106050503000602040201 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMyMTA5NDJaMCMGCSqGSIb3DQEJBDEWBBQ4 WwaeYCFrr+Mis5pmMz01vaP8/TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAs56EAWH3eYAW QKwkYsbEQX6HGPjvjIS6tujR4MBu7dXzHEnfZoWL6DEq0SX+nWzqYS66Bwekq9136YZmY85m VBzufd4302tnA8kxVBuU2Tqwxwxkr1wHyxPQOUaxqceHcX3ecqtd9Z6ivdXX0h1jrTNglEWO qi6WaWjZNgCZe1eTIhVBObDWzwXUZcnIMsjU77Tn8Vffguv5K4sXKdiTJOlAcK/GpK4COMFW 5/rbJak/sM8IJLlF72r9eIPENKEbpUqGu83w6nR2DHDO64uPnLbf4DVq6++ezy+GMmGvahG+ qD+Vn2rVIm20enLx4G8HOGx3E9/+3bujzSTa/Vf0PgAAAAAAAA== --------------ms040106050503000602040201-- From owner-ietf-calendar@mail.imc.org Fri May 23 17:32: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 RAA26790 for ; Fri, 23 May 2003 17:32: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 h4NLJ7AF045756 for ; Fri, 23 May 2003 14: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 h4NLJ7j6045755 for ietf-calendar-bks; Fri, 23 May 2003 14:19: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NLJ6AF045745 for ; Fri, 23 May 2003 14:19:06 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE6C5F.8010009@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 17:10:07 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 05:18:58 PM, Serialize complete at 05/23/2003 05:18:58 PM Content-Type: multipart/alternative; boundary="=_alternative 0074229285256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0074229285256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 05/23/2003 02:45:51 PM: > > And just how does the the newest one help him if there have been > > multiple reschedules (ie: Moved yet again from Wednesday to Thursday and > > then to Friday)?? > > ATTENDEE-1 has: > UID:1 > SEQUENCE:2 > > Now iTIP does not have an 'update' method. So lets say the ORGANIZER > sends a: Lets try to stay focused on the basic example I used before (Monday -> Wednesday -> Thursday -> Friday) shall we? Otherwise we cant reach any clear resolution. Ill be more than happy to consider this new example after this one. So using the example we've already used, Tom has REPLYd with: M 09-Jun-03: RECURRENCE-ID:20030609T140000Z SEQUENCE:0 but Ive already rescheduled twice more (Wednesday -> Thursday was SEQUENCE:2 and Thursday -> Friday was SEQUENCE:3) so Im at: F 13-Jun-03: DTSTART:20030613T140000Z DTEND:20030613T150000Z RECURRENCE-ID:20030609T140000Z SEQUENCE:3 F 20-Jun-03: DTSTART:20030620T140000Z DTEND:20030620T150000Z RECURRENCE-ID:20030616T140000Z SEQUENCE:3 F 27-Jun-03: DTSTART:20030627T140000Z DTEND:20030627T150000Z RECURRENCE-ID:20030623T140000Z SEQUENCE:3 by my claims of a fixed RECURRENCE-ID(and backed by the conflicting citation from "4.8.4.4 Recurrence ID"). As such I can see that Tom has replyed to a stale version of the meeting and I can easily send him the correct new REQUEST. However by your previous claims that RECURRENCE-ID is changed to match the DTSTART after the entry is rescheduled ("So it IS always the same as the 'booked' object instance." and the conflicting citation from 4.8.4.4 too). As such you would be at: F 13-Jun-03: DTSTART:20031311T140000Z DTEND:20030613T150000Z RECURRENCE-ID:20030613T140000Z SEQUENCE:3 F 20-Jun-03: DTSTART:20030620T140000Z DTEND:20030620T150000Z RECURRENCE-ID:20030620T140000Z SEQUENCE:3 F 27-Jun-03: DTSTART:20030627T140000Z DTEND:20030627T150000Z RECURRENCE-ID:20030627T140000Z SEQUENCE:3 So just how can I tell exactly which instance Tom was accepting?? NO RECURRENCE-IDs match. No SEQUENCEs match. I guess you could just say "Send them all over again" and I resend a new REQUEST with the data from above. However what the heck can Tom do with it? He has a snowballs chance in a microwaves chance of matching up the initial REQUEST he got with the new REQUEST. The UIDs match but NO RECURRENCE-IDs match. His CUA of course would conform to 2446, Section 4.7.2 Bad RECURRENCE-ID which says: 2. The component with the referenced "UID" has been found, the "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be found. [Snip] 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. Gee, isnt that exactly what just happened?? Didnt I just send a REQUEST that was to be the 'updated version'?? Guess we can just keep looping until something special happens and it just works or the meeting passes and Tom fails to show up... > In 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. > > No one needs to know the intermediate objects. Given your comments about changing RECURRENCE-ID based on the 'booked' value of DTSTART they (the invitees) MUST absolutely, positively, 100% know them! Otherwise they can never match them up if they miss ANY reschedules!! The only way that you do NOT need the intermediate REQUESTs is if the key values (UID and RECURRENCE-ID in repeating instances if you read bullet 1 above your citation) does not change! > > Does the Organizer have to build a 'chain' of missing ones for Tom to > > roll up into the final value for Friday? > > No. However the ORGANIZER may wish to keep track of who did a REPLY > to the newest SEQUENCE and perhaps re-send a REQUEST with the newest > SEQUENCE in it to the non-responsive ATTENDEE. Ok, I still cannot see how Tom who has: M 09-Jun-03: DTSTART:20030609T140000Z DTEND:20030609T150000Z RECURRENCE-ID:20030609T140000Z SEQUENCE:0 is going to be able to match it to the newly received REQUEST you send that has: F 13-Jun-03: DTSTART:20031311T140000Z DTEND:20030613T150000Z RECURRENCE-ID:20030613T140000Z SEQUENCE:3 The primary key for finding a repeating instance is UID & RECURRENCE-ID but these do NOT match between the initial REQUEST and the subsequent REQUEST. So how can Tom get resync'd??? The only way for Tom to be able to get resync'd is if UID and RECURRENCE-ID never change. If you change the primary key, you'll never be able to make a match! (If you change the locks on your house, can you get in using the old keys?) > Or perhaps the ORGANIZER keeps track of the SEQUENCE value in each > reply to each ATTENDEE. No 'perhaps' about it. If the id changes, the Organizer MUST so they can build a chain to get all invitees to the same view of the repeat set. However can easily fail as Ive shown before given the latency involved in iMIP and the potential for in-transit loss. See previous postings today on that if need be. > The ORGANIZER controls the object. Thats not in contention. They do however have to obey the constraints of the system/model. For example they cannot decrement SEQUENCE when rescheduling; they cannot make the DTEND before the DTSTART, etc. Ok, they CAN if they use notepad or a non-compliant CUA but we are not talking about that scenario. In any case, this has no bearing on the rules in question governing RECURRENCE-ID. > No, simply do a REFRESH and get the latest copy, then the ATTENDEE > can do a REPLY or COUNTER to that object. I cant see this working. Please show me exactly how. Ill keep asking until someone can show me how Tom will be able to resync the correct instance to Friday in the case where RECURRENCE-IDs change and he misses one or more interim reschedules... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0074229285256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 05/23/2003 02:45:51 PM:
> > And just how does the the newest one help him if there have been
> > multiple reschedules (ie: Moved yet again from Wednesday to Thursday and
> > then to Friday)??  
>
> ATTENDEE-1 has:
>    UID:1
>    SEQUENCE:2
>
> Now iTIP does not have an 'update' method. So lets say the ORGANIZER
> sends a:
Lets try to stay focused on the basic example I used before (Monday -> Wednesday -> Thursday -> Friday) shall we?  Otherwise we cant reach any clear resolution.  Ill be more than happy to consider this new example after this one.

So using the example we've already used, Tom has REPLYd with:

M 09-Jun-03:
        RECURRENCE-ID:20030609T140000Z
        SEQUENCE:0

but Ive already rescheduled twice more (Wednesday -> Thursday was SEQUENCE:2 and Thursday -> Friday was SEQUENCE:3) so Im at:

F 13-Jun-03:
       DTSTART:20030613T140000Z
       DTEND:20030613T150000Z
       RECURRENCE-ID:20030609T140000Z
       SEQUENCE:3
F 20-Jun-03:
       DTSTART:20030620T140000Z
       DTEND:20030620T150000Z
       RECURRENCE-ID:20030616T140000Z
       SEQUENCE:3

F 27-Jun-03:
       DTSTART:20030627T140000Z
       DTEND:20030627T150000Z
       RECURRENCE-ID:20030623T140000Z
       SEQUENCE:3
by my claims of a fixed RECURRENCE-ID(and backed by the conflicting citation from "4.8.4.4 Recurrence ID").  As such I can see that Tom has replyed to a stale version of the meeting and I can easily send him the correct new REQUEST.

However by your previous claims that RECURRENCE-ID is changed to match the DTSTART after the entry is rescheduled ("So it IS always the same as the 'booked' object instance." and the conflicting citation from 4.8.4.4 too).  As such you would be at:

F 13-Jun-03:
       DTSTART:20031311T140000Z
       DTEND:20030613T150000Z
       RECURRENCE-ID:20030613T140000Z
       SEQUENCE:3
F 20-Jun-03:
       DTSTART:20030620T140000Z
       DTEND:20030620T150000Z
       RECURRENCE-ID:20030620T140000Z
       SEQUENCE:3

F 27-Jun-03:
       DTSTART:20030627T140000Z
       DTEND:20030627T150000Z
       RECURRENCE-ID:20030627T140000Z
       SEQUENCE:3

So just how can I tell exactly which instance Tom was accepting??  NO RECURRENCE-IDs match.  No SEQUENCEs match.  I guess you could just say "Send them all over again" and I resend a new REQUEST with the data from above.

However what the heck can Tom do with it?  He has a snowballs chance in a microwaves chance of matching up the initial REQUEST he got with the new REQUEST.  The UIDs match but NO RECURRENCE-IDs match.  His CUA of course would conform to 2446, Section 4.7.2 Bad RECURRENCE-ID which says:

   2.  The component with the referenced "UID" has been found, the
      "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
      found.
[Snip]
   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.

Gee, isnt that exactly what just happened??  Didnt I just send a REQUEST that was to be the 'updated version'??  Guess we can just keep looping until something special happens and it just works or the meeting passes and Tom fails to show up...

> In 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.
>
> No one needs to know the intermediate objects.
Given your comments about changing RECURRENCE-ID based on the 'booked' value of DTSTART they (the invitees) MUST absolutely, positively, 100% know them!  Otherwise they can never match them up if they miss ANY reschedules!!

The only way that you do NOT need the intermediate REQUESTs is if the key values (UID and RECURRENCE-ID in repeating instances if you read bullet 1 above your citation) does not change!

> > Does the Organizer have to build a 'chain' of missing ones for Tom to
> > roll up into the final value for Friday?
>
> No. However the ORGANIZER may wish to keep track of who did a REPLY
> to the newest SEQUENCE and perhaps re-send a REQUEST with the newest
> SEQUENCE in it to the non-responsive ATTENDEE.
Ok, I still cannot see how Tom who has:

M 09-Jun-03:
        DTSTART:20030609T140000Z
       DTEND:20030609T150000Z
       RECURRENCE-ID:20030609T140000Z
        SEQUENCE:0

is going to be able to match it to the newly received REQUEST you send that has:

F 13-Jun-03:
       DTSTART:20031311T140000Z
       DTEND:20030613T150000Z
       RECURRENCE-ID:20030613T140000Z
       SEQUENCE:3
The primary key for finding a repeating instance is UID & RECURRENCE-ID but these do NOT match between the initial REQUEST and the subsequent REQUEST.  So how can Tom get resync'd???

The only way for Tom to be able to get resync'd is if UID and RECURRENCE-ID never change.  If you change the primary key, you'll never be able to make a match!  (If you change the locks on your house, can you get in using the old keys?)

> Or perhaps the ORGANIZER keeps track of the SEQUENCE value in each
> reply to each ATTENDEE.

No 'perhaps' about it.  If the id changes, the Organizer MUST so they can build a chain to get all invitees to the same view of the repeat set.  However can easily fail as Ive shown before given the latency involved in iMIP and the potential for in-transit loss.  See previous postings today on that if need be.

> The ORGANIZER controls the object.
Thats not in contention.  They do however have to obey the constraints of the system/model.  For example they cannot decrement SEQUENCE when rescheduling; they cannot make the DTEND before the DTSTART, etc.  Ok, they CAN if they use notepad or a non-compliant CUA but we are not talking about that scenario.  In any case, this has no bearing on the rules in question governing RECURRENCE-ID.

> No, simply do a REFRESH and get the latest copy, then the ATTENDEE
> can do a REPLY or COUNTER to that object.
I cant see this working.   Please show me exactly how.  Ill keep asking until someone can show me how Tom will be able to resync the correct instance to Friday in the case where RECURRENCE-IDs change and he misses one or more interim reschedules...  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0074229285256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 18:04: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 SAA27566 for ; Fri, 23 May 2003 18:04: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 h4NLleAF046824 for ; Fri, 23 May 2003 14:47: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 h4NLleaL046823 for ietf-calendar-bks; Fri, 23 May 2003 14:47: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 h4NLlcAF046813 for ; Fri, 23 May 2003 14:47: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 h4NLlbv3007438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 14:47:40 -0700 Message-ID: <3ECE96ED.6070404@Royer.com> Date: Fri, 23 May 2003 15:47:25 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010501040803040802060109" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010501040803040802060109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 05/23/2003 02:45:51 PM: > > > And just how does the the newest one help him if there have been > > > multiple reschedules (ie: Moved yet again from Wednesday to > Thursday and > > > then to Friday)?? > > > > ATTENDEE-1 has: > > UID:1 > > SEQUENCE:2 > > > > Now iTIP does not have an 'update' method. So lets say the ORGANIZER > > sends a: > > Lets try to stay focused on the basic example I used before (Monday -> > Wednesday -> Thursday -> Friday) shall we? Otherwise we cant reach any > clear resolution. Ill be more than happy to consider this new example > after this one. Simply do a REFRESH. Then it does not matter how many times you 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 --------------ms010501040803040802060109 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMyMTQ3MjVaMCMGCSqGSIb3DQEJBDEWBBQp 3Xx0z7JpRgj3jUw9S3dTYlc2uTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAFkTSMFWL5Wtu rwHKKAnocfeKy6sxv3JvZzMbuq8+aTo16efeIz0ZwPaxmzM6aASfb45qsKMdtvQD1SQlam9W kw1QxbfLbTtRUKpu9SV0LX4g/6/9t+9qg8qg2EmgKGWPr+xNdzgmMfF+J0B+1j+VYovfJtRR TzSN8LF7SuHnOuvG6mnTVAA4rWkthIRaEzxpHWaPJxcrtg6Kh6g0uUbenTJc+pMbNsZrjyE9 mWId2HyIQmroZM26OVIv/WTTfsYIYmUBz4/A1gCVqB50i/mYCUsGjEtYQ2kSJmqBAjq7F7Ei gFwt/wlbZ+Ze7qD5p25eVKmw6qXKOyuOrz66xsr8zwAAAAAAAA== --------------ms010501040803040802060109-- From owner-ietf-calendar@mail.imc.org Fri May 23 19:07: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 TAA29705 for ; Fri, 23 May 2003 19:07: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 h4NMtUAF048739 for ; Fri, 23 May 2003 15: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 h4NMtUbD048737 for ietf-calendar-bks; Fri, 23 May 2003 15:55:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NMtTAG048724 for ; Fri, 23 May 2003 15:55:29 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE7019.5020606@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 18:44:05 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 06:55:17 PM, Serialize complete at 05/23/2003 06:55:17 PM Content-Type: multipart/alternative; boundary="=_alternative 007CBCB185256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007CBCB185256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug fired back on 05/23/2003 03:01:45 PM: > > ONLY the first time the instaces are created! After that the > > RECURRENCE-ID values are fixed and NEVER EVER EVER change even if the > > RDATEs do! > > > > Otherwise you will run into the same kinds of "Which instance was he > > accepting?" quandry Ive mentioned elsewhere in this thread. Or can you > > explain Dougs model to me because Im still not seeing how things work > > properly.. > > > Bruces responses above are contrary to RFC-2446. Please cite. Ive already ponited out the relevant parts in 2445 and 2446. What did I misquote?? Please also show me how changing the RECURRENCE-ID on every reschedule works if any are missed? I still have yet to see it (nor can I find anything in iTIP that supports your claims). > The RECURRENCE-ID values only usable with a known UID and SEQUENCE. WRONG! Please reread 2446, Section 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. For repeating instances the key is not just UID but UID and RECURRENCE-ID. In case you missed it before, Section 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. the rest of the steps use "UID" but that is not a literal 'just "UID"', for a repeating instance its the UID/RECURRENCE-ID. This was done for brevitys sake in the editing because we use "UID" in lots of places in the specs and its WAAAYY too cumbersome to constantly say" the "UID" property (or the combination of "UID" and "RECURRENCE-ID" properties in teh case of a recurring component)". > Bruces comments are only valid when SEQUENCE == 0, when there has > never been a ADD or CANCEL, there have been no significant revision to > the calendar component (as defined in 2445), as long as DTSTART, > DTEND, DUE, RDATE, RRULE, EXDATE, EXRULE, STATUS, LOCATION, and > perhaps more have not changed - as defined in 2445. Absolutely false. Ill keep pointing back to Section 3.2.2 REQUEST if I have to until it sinks in... Go reread it again please. > The 'which instance' is not an issue. The instance is > UID/RECURRENCE-ID/SEQUENCE and sometimes DTSTAMP. That > is 'an instance'. You argue my point now, thanks! If RECURRENCE-ID changes then you are describing a different instance; NOT the same instance at a different date/time! By 2446 Section 3.2.2, if an invitee gets a new REQUEST for a different RECURRENCE-ID then they can consider it a new invitation to a new instance of that repeat set. Thus Tom thinks we are meeting on both Monday (RECURRENCE-ID:20030609T140000Z) AND on Friday (RECURRENCE-ID:20030613T140000Z) when in fact we are no longer meeting on Monday! Now can you see why 'deltas' are bad?!? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... Warning: Dates in Calendar are closer than they appear. --=_alternative 007CBCB185256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug fired back on 05/23/2003 03:01:45 PM:
> > ONLY the first time the instaces are created!  After that the
> > RECURRENCE-ID values are fixed and NEVER EVER EVER change even if the
> > RDATEs do!
> >
> > Otherwise you will run into the same kinds of "Which instance was he
> > accepting?" quandry Ive mentioned elsewhere in this thread.  Or can you
> > explain Dougs model to me  because Im still not seeing how things work
> > properly..
>
>
> Bruces responses above are contrary to RFC-2446.
Please cite.  Ive already ponited out the relevant parts in 2445 and 2446.  What did I misquote??

Please also show me how changing the RECURRENCE-ID on every reschedule works if any are missed?  I still have yet to see it (nor can I find anything in iTIP that supports your claims).

> The RECURRENCE-ID values only usable with a known UID and SEQUENCE.
WRONG!  Please reread 2446, Section 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.

For repeating instances the key is not just UID but UID and RECURRENCE-ID.  In case you missed it before, Section 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.

the rest of the steps use "UID" but that is not a literal 'just "UID"', for a repeating instance its the UID/RECURRENCE-ID.  This was done for brevitys sake in the editing because we use "UID" in lots of places in the specs and its WAAAYY too cumbersome to constantly say" the "UID" property (or the combination of "UID" and "RECURRENCE-ID" properties in teh case of a recurring component)".  

> Bruces comments are only valid when SEQUENCE == 0, when there has
> never been a ADD or CANCEL, there have been no significant revision to
> the calendar component (as defined in 2445), as long as DTSTART,
> DTEND, DUE, RDATE, RRULE, EXDATE, EXRULE, STATUS, LOCATION, and
> perhaps more have not changed - as defined in 2445.
Absolutely false.  Ill keep pointing back to Section 3.2.2 REQUEST if I have to until it sinks in...  Go reread it again please.

> The 'which instance' is not an issue. The instance is
> UID/RECURRENCE-ID/SEQUENCE and sometimes DTSTAMP. That
> is 'an instance'.
You argue my point now, thanks!  If RECURRENCE-ID changes then you are describing a different instance; NOT the same instance at a different date/time!

By 2446 Section 3.2.2, if an invitee gets a new REQUEST for a different RECURRENCE-ID then they can consider it a new invitation to a new instance of that repeat set.  Thus Tom thinks we are meeting on both Monday (RECURRENCE-ID:20030609T140000Z) AND on Friday (RECURRENCE-ID:20030613T140000Z) when in fact we are no longer meeting on Monday!  Now can you see why 'deltas' are bad?!?

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

--=_alternative 007CBCB185256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 19:07: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 TAA29708 for ; Fri, 23 May 2003 19:07: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 h4NMtUAF048733 for ; Fri, 23 May 2003 15: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 h4NMtU5H048731 for ietf-calendar-bks; Fri, 23 May 2003 15:55:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NMtTAF048724 for ; Fri, 23 May 2003 15:55:29 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE6D31.9050509@ENG.SUN.COM> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 18:29:50 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 06:55:16 PM, Serialize complete at 05/23/2003 06:55:17 PM, Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 06:55:17 PM Content-Type: multipart/alternative; boundary="=_alternative 007B6EFE85256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B6EFE85256D2F_= Content-Type: text/plain; charset="US-ASCII" Arnaud Quillaud wrote on 05/23/2003 02:49:21 PM: > But what is the advantage of the opposite interpretation of the spec > (changing RECURRENCE-ID over time) ? Or what are the disadvantages > of fixed RECURRENCE-ID ? I thought I covered them already earlier today but Ill try to resummarize the probelms with the 'delta' model: 1: We cannot guarantee that every previous message has arrived at the recipients address. As such, if any message _ever_ is lost then the entire workflow breaks down. Also, data can arrive delayed and out of order making it impossible for workflow to be performed accurately (I often get Dougs replys to my notes waayy before I get my own postings via the IMC list server which gives my threading agents fits!) 2: We cannot prevent users from deleting 'old' messages nor should we require that _all_ previous messages be preserved in case we need to perform some new scheduling action. 3: There is no reliable way for a CUA to tell when the 'last' message in the delta chain has arrived and that workflow can safely be performed. There is no magic indicator property nor can one be safely added. Otherwise an UPDATE 3 (for above) would also have it and thus any CUA would mistake UPDATE 2 as the last one rather than UPDATE 3. Its a chicken and egg type of problem recognizing "the last" or actual message to take workflow actions on. 4: The WG burned lots of gray cells recognizing the fact that the only way to keep workflow functioning was to make each message a full and complete snapshot for that entry/instance. If you search the WG archives you will find more detailed discussions on delta vs full snapshots (or whatever we called it then) and why a delta design is unreliable. > I think we now all understand the proposed > model. It would be great to now see why it might be the best approach. Actually both models are just interpretations of the text in 2445, Section 4.8.4.4 Recurrence ID: 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. The former paragraph is the justification for the "fixed and never changing RECURRENCE-ID" model . The latter paragraph is the justification for the "it changes based on the 'booked' value of DTSTART" model. As I said before, in the past we have found residual text in the spec that should have been removed when some change was made but it was not. I strongly suspect that this another case of this. > version 2: The RECURRENCE-ID is equal to the DTSTART of the instance > at a given time. When sending an iTIP REQUEST that corresponds to a > change of DTSTART for a particular instance, the RECURRENCE-ID is > equal to the previous value of the DTSTART. In any subsequent > REQUEST, the RECURRENCE-ID is equal to the new DTSTART (that is, > until the DTSTART is changed again). Hence, the RECURRENCE-ID > identifying an instance might change over time. No 'might' about it. If the DTSTART changes then so would the RECURRENCE-ID. Therefore unless DTSTART never changes (ie: the entry only gets longer/shorter) the RECURRENCE-ID will always change by this version. > The only disadvantage of version 1 that I can think of is about > someone joining the party while some rescheduling has already > occured. Since the newcommer won't have the SEQUENCE: 0 of the > recurrence set, he might interpret the set of RECURRENCE-ID > differently. But maybe this is just because I don't understand what > the right iTIP workflow is. Its not a problem for the non-delta model. The Organizer simply sends a new invitee a REQUEST that contains the information they will need to correctly identify the instance and put it on the right date/time. So, continuing the example I used earlier to add Arnaud to Friday 13-Jun-03 I would simply send the following REQUEST: BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:Bruce@widget.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Bruce@widget.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Doug: Mailto:Doug@Royer.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=George: Mailto:George@fizbin.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Tom: Mailto:Tom@example.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Ki: Mailto:Ki@sun.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Arnaud: Mailto:Arnaud@sun.com DTSTART:20030613T140000Z DTEND:20030613T150000Z SUMMARY:Head bashing UID:calsrv.widget.com-873970198738777@widget.com SEQUENCE:3 RECURRENCE-ID:20030609T140000Z DTSTAMP:20030523T225900Z END:VEVENT END:VCALENDAR If the RECURRENCE-ID never changes then it matches the SEQUENCE:0 value. So, Arnaud would use the rules under 2446, Section 2.1.5 Message Sequencing to see that he has a new REQUEST from me he has never seen before and thus treat it like a new invitation. He clicks the Accept button on his UI and his CUA sends me back the properly crafted REPLY. Since he has the RECURRENCE-ID that everyone else shares (and that never changes) any future reschedules to him will be just that, reschedules and not a new invitation. All of this is spelled out in iTIP, Section 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. BTW: here UID is not meant to be literally just UID but UID/RECURRENCE-ID (as described under Message Sequencing in iTIP). It was done this way for brevity (ask Frank/Steve if you doubt me). The same cannot be said of the version 2 ("delta") model. The only way for me to add Arnaud would be to send him the initial snapshot and then ALL of the reschedules up to the current point. Otherwise he could not possibly share the same RECURRENCE-ID that I do and thus not be able to do proper workflow. There of course also is the problem of getting the chain of changes to Arnaud intact. Given the unambiguious description from 3.2.2 above the version 2 REQUESTs would result in an initial Friday 13-Jun-03 entry being added to his calendar. However if I reschedule again, new RECURRENCE-IDs are created. By the iTIP text above Arnaud would be forced to treat any new SEQUENCE:4 / RECURRENCE-ID:20030610T140000Z as a totally new invitation; NOT AS A RESCHEDULE OF THE FRIDAY INSTANCE HE ALREADY HAS!. This is a very strong reason why deltas are bad! (I need to try decaf I think...) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007B6EFE85256D2F_= Content-Type: text/html; charset="US-ASCII"
Arnaud Quillaud wrote on 05/23/2003 02:49:21 PM:
> But what is the advantage of the opposite interpretation of the spec
> (changing RECURRENCE-ID over time) ? Or what are the disadvantages
> of fixed RECURRENCE-ID ?

I thought I covered them already earlier today but Ill try to resummarize the probelms with the 'delta' model:

1: We cannot guarantee that every previous message has arrived at the recipients address.  As such, if any message _ever_ is lost then the entire workflow breaks down.  Also, data can arrive delayed and out of order making it impossible for workflow to be performed accurately (I often get Dougs replys to my notes waayy before I get my own postings via the IMC list server which gives my threading agents fits!)

2: We cannot prevent users from deleting 'old' messages nor should we require that _all_ previous messages be preserved in case we need to perform some new scheduling action.

3: There is no reliable way for a CUA to tell when the 'last' message in the delta chain has arrived and that workflow can safely be performed.  There is no magic indicator property nor can one be safely added.  Otherwise an UPDATE 3 (for above) would also have it and thus any CUA would mistake UPDATE 2 as the last one rather than UPDATE 3.  Its a chicken and egg type of problem recognizing "the last" or actual message to take workflow actions on.

4: The WG burned lots of gray cells recognizing the fact that the only way to keep workflow functioning was to make each message a full and complete snapshot for that entry/instance.  

If you search the WG archives you will find more detailed discussions on delta vs full snapshots (or whatever we called it then) and why a delta design is unreliable.

>                          I think we now all understand the proposed
> model. It would be great to now see why it might be the best approach.
Actually both models are just interpretations of the text in 2445, Section 4.8.4.4 Recurrence ID:

   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.

The former paragraph is the justification for the "fixed and never changing RECURRENCE-ID" model .  The latter paragraph is the justification for the "it changes based on the 'booked' value of DTSTART" model.

As I said before, in the past we have found residual text in the spec that should have been removed when some change was made but it was not.  I strongly suspect that this another case of this.

> version 2: The RECURRENCE-ID is equal to the DTSTART of the instance
> at a given time. When sending an iTIP REQUEST that  corresponds to a
> change of DTSTART for a particular instance, the RECURRENCE-ID is
> equal to the previous value of the DTSTART. In any subsequent
> REQUEST, the RECURRENCE-ID is equal to the new DTSTART (that is,
> until the DTSTART is changed again). Hence, the RECURRENCE-ID
> identifying an instance might change over time.
No 'might' about it.  If the DTSTART changes then so would the RECURRENCE-ID.  Therefore unless DTSTART never changes (ie: the entry only gets longer/shorter) the RECURRENCE-ID will always change by this version.

> The only disadvantage of version 1 that I can think of is about
> someone joining the party while some rescheduling has already
> occured. Since the newcommer won't have the SEQUENCE: 0 of the
> recurrence set, he might interpret the set of RECURRENCE-ID
> differently. But maybe this is just because I don't understand what
> the right iTIP workflow is.
Its not a problem for the non-delta model.  The Organizer simply sends a new invitee a REQUEST that contains the information they will need to correctly identify the instance and put it on the right date/time.  So, continuing the example I used earlier to add Arnaud to Friday 13-Jun-03 I would simply send the following REQUEST:

   BEGIN:VCALENDAR
  PRODID:-//ACME/DesktopCalendar//EN
  METHOD:REQUEST
  VERSION:2.0
  BEGIN:VEVENT
  ORGANIZER:Mailto:Bruce@widget.com
  ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Bruce@widget.com
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Doug:Mailto:Doug@Royer.com
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=George:Mailto:George@fizbin.com
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Tom:Mailto:Tom@example.com
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Ki:Mailto:Ki@sun.com
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Arnaud:Mailto:Arnaud@sun.com
  DTSTART:20030613T140000Z
  DTEND:20030613T150000Z
  SUMMARY:Head bashing
  UID:calsrv.widget.com-873970198738777@widget.com
  SEQUENCE:3
   RECURRENCE-ID:20030609T140000Z
  DTSTAMP:20030523T225900Z
  END:VEVENT
  END:VCALENDAR

If the RECURRENCE-ID never changes then it matches the SEQUENCE:0 value.  So, Arnaud would use the rules under 2446, Section 2.1.5 Message Sequencing to see that he has a new REQUEST from me he has never seen before and thus treat it like a new invitation.  He clicks the Accept button on his UI and his CUA sends me back the properly crafted REPLY.  Since he has the RECURRENCE-ID that everyone else shares (and that never changes) any future reschedules to him will be just that, reschedules and not a new invitation.  

All of this is spelled out in iTIP, Section 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.

BTW: here UID is not meant to be literally just UID but UID/RECURRENCE-ID (as described under Message Sequencing in iTIP).  It was done this way for brevity (ask Frank/Steve if you doubt me).

The same cannot be said of the version 2 ("delta") model.  The only way for me to add Arnaud would be to send him the initial snapshot and then ALL of the reschedules up to the current point.  Otherwise he could not possibly share the same RECURRENCE-ID that I do and thus not be able to do proper workflow.  There of course also is the problem of getting the chain of changes to Arnaud intact.

Given the unambiguious description from 3.2.2 above the version 2 REQUESTs would result in an initial Friday 13-Jun-03 entry being added to his calendar.  However if I reschedule again, new RECURRENCE-IDs are created.  By the iTIP text above Arnaud would be forced to treat any new SEQUENCE:4 / RECURRENCE-ID:20030610T140000Z as a totally new invitation; NOT AS A RESCHEDULE OF THE FRIDAY INSTANCE HE ALREADY HAS!.  This is a very strong reason why deltas are bad!  (I need to try decaf I think...)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007B6EFE85256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 19:33: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 TAA00343 for ; Fri, 23 May 2003 19:33: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 h4NNLKAF049354 for ; Fri, 23 May 2003 16:21: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 h4NNLKkT049353 for ietf-calendar-bks; Fri, 23 May 2003 16:21: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 h4NNLIAF049348 for ; Fri, 23 May 2003 16:21: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 h4NNLHv3008096 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 May 2003 16:21:20 -0700 Message-ID: <3ECEACE8.5050607@Royer.com> Date: Fri, 23 May 2003 17:21:12 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080109050804030903090408" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080109050804030903090408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Arnaud Quillaud wrote on 05/23/2003 02:49:21 PM: > > But what is the advantage of the opposite interpretation of the spec > > (changing RECURRENCE-ID over time) ? Or what are the disadvantages > > of fixed RECURRENCE-ID ? > > I thought I covered them already earlier today but Ill try to > resummarize the probelms with the 'delta' model: > > 1: We cannot guarantee that every previous message has arrived at the > recipients address. As such, if any message _ever_ is lost then the > entire workflow breaks down. > .......... All of this has been solved. Just compare the UID, SEQUENCE, Possibly RECURRENCE-ID and DTSTAMP per iTIP and iCAL. If you have an old copy - do a REFRESH. Done. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080109050804030903090408 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjMyMzIxMTJaMCMGCSqGSIb3DQEJBDEWBBQP 8I41f7TIc9okP6ZzzHo+Kt16/TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAhiEnRMNDhBBd DmbwxcHUiGjjKROoRWgIEntZ8MZmtdL2DsVcmSiU6MLI5wD5LuhgBV3kvitQt9aTMAEzmRZP mfGXV0JgcxisOgEZcG46y8tDe/YQasQG8O8vOKop70SSAIyB9tUpP2d/cAVizCa4VaornEsK awacVH9CG6V+3oFXOJi/2JZe8wU9AHaaQ0DMiYbXFuG3VFAmGJW3kOLk7Oo3WPBf2uDkpxPw bsis31a+vZvRESGisSoEmHklutVbbBE61e+yD+a7DXLgUJPMZPyz8OE6jusKWEHu5uPu/2im +Qo9AscttsfO2bLHpr1ihkBpt5DIX2Z1fjQe1MUy/gAAAAAAAA== --------------ms080109050804030903090408-- From owner-ietf-calendar@mail.imc.org Fri May 23 19:37: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 TAA00413 for ; Fri, 23 May 2003 19:37: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 h4NNQQAF049440 for ; Fri, 23 May 2003 16:26: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 h4NNQQw3049438 for ietf-calendar-bks; Fri, 23 May 2003 16:26: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NNQPAF049422 for ; Fri, 23 May 2003 16:26:25 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE7879.30809@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 18:56:28 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 07:26:11 PM, Serialize complete at 05/23/2003 07:26:11 PM Content-Type: multipart/alternative; boundary="=_alternative 007DDF3685256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007DDF3685256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug shot back on 05/23/2003 03:37:29 PM: > > > RECURRENCE-ID is only like UID when the SEQUENCE and UID are known. > > > So RECURRENCE-ID applies to the verison of the object where UID > > > and SEQUENCE match the update. > > > > Sorry but _that_ is not true. > > > > Go recheck RFC 2446, Section 2.1.5 Message Sequencing: > > > > 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. > > > > So RECURRENCE-ID is used in conjunction with UID and BEFORE SEQUENCE > > checking. Why? Simple: you have to find the right instance before you > > can check if the message is older, newer, etc.! > > Which was my point!? Your ordering of usage/evaluation is whats wrong. You totally missed the implication of Step 1. UID and RECURRENCE-ID are first used in combination to find a set and instance and THEN SEQUENCE is used. > > Nope, go reread that bit and check the ordering again... > > I do not need to, you correctly quoted the RFC above. > It is only usable when UID and SEQENCE are known. SEQUENCE is Step 2. If you find NO match for the UID/RECURRENCE-ID pair then by iTIP, Section 3.2.2 its a new invitation and NOT an update to an existing one (this is derived from the 2.1.5 above and 3.2.2 as well; no match on the primary key with a new RECURRENCE-ID means its a new invitation). Still, none of this exactly hows the iTIP messages that get sent in your view of things compared to the non-delta examples Ive already shown. Can you please show me the iTIP fragments that my CUA would send back in response to Tom's REPLY?? Note that Toms CUA would not need to send a REFRESH for the initial invitation since hes acting on the first one. The quandry Im having is what my CUA would send back to him when I see his REPLY is old... Everything I can imagine that matches your changing RECURRENCE-ID causes his CUA to treat it as a second new invitation (see iTIP 3.2.2) and thus he gets doubly booked and not resync'd. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007DDF3685256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug shot back on 05/23/2003 03:37:29 PM:
> >  > RECURRENCE-ID is only like UID when the SEQUENCE and UID are known.
> >  > So RECURRENCE-ID applies to the verison of the object where UID
> >  > and SEQUENCE match the update.
> >
> > Sorry but _that_ is not true.  
> >
> > Go recheck RFC 2446, Section 2.1.5 Message Sequencing:
> >
> >   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.
> >
> > So RECURRENCE-ID is used in conjunction with UID and BEFORE SEQUENCE
> > checking.  Why?  Simple: you have to find the right instance before you
> > can check if the message is older, newer, etc.!
>
> Which was my point!?
Your ordering of usage/evaluation is whats wrong.  You totally missed the implication of Step 1.  UID and RECURRENCE-ID are first used in combination to find a set and instance and THEN SEQUENCE is used.

> > Nope, go reread that bit and check the ordering again...
>
> I do not need to, you correctly quoted the RFC above.
> It is only usable when UID and SEQENCE are known.
SEQUENCE is Step 2.  If you find NO match for the UID/RECURRENCE-ID pair then by iTIP, Section 3.2.2 its a new invitation and NOT an update to an existing one (this is derived from the 2.1.5 above and 3.2.2 as well; no match on the primary key with a new RECURRENCE-ID means its a new invitation).

Still, none of this exactly hows the iTIP messages that get sent in your view of things compared to the non-delta examples Ive already shown.  

Can you please show me the iTIP fragments that my CUA would send back in response to Tom's REPLY??  Note that Toms CUA would not need to send a REFRESH for the initial invitation since hes acting on the first one.  The quandry Im having is what my CUA would send back to him when I see his REPLY is old...  Everything I can imagine that matches your changing RECURRENCE-ID causes his CUA to treat it as a second new invitation (see iTIP 3.2.2) and thus he gets doubly booked and not resync'd.  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007DDF3685256D2F_=-- From owner-ietf-calendar@mail.imc.org Fri May 23 19:37: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 TAA00415 for ; Fri, 23 May 2003 19:37: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 h4NNQQAF049439 for ; Fri, 23 May 2003 16:26: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 h4NNQQjb049437 for ietf-calendar-bks; Fri, 23 May 2003 16:26: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NNQPAF049423 for ; Fri, 23 May 2003 16:26:25 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE6DC7.1030307@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 23 May 2003 19:09:08 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 07:26:11 PM, Serialize complete at 05/23/2003 07:26:11 PM Content-Type: multipart/alternative; boundary="=_alternative 007F080A85256D2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007F080A85256D2F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/23/2003 02:51:51 PM: > > But how could Toms CUA derive the correct RECURRENCE-ID value from the > > new SEQUENCE:3 info? > > It does not need to as the SEQUENCE:3 object contains the current > state of the object. This has digressed more than a little so Ill try to refocus before I head out. By current iTIP rules (prev. citations) why would Toms CUA know/have to do a REFRESH if it got a SEQUENCE:3 and it had a SEQUENCE:1 value. You now say that it would not. However it would have to IF RECURRENCE-ID values changed based on the interim DTSTART values. In order to properly determine the RECURRENCE-ID of SEQUENCE:3 and match it to the existing SEQUENCE:1 entry something has to be done. The ONLY way to follow iTIP rules on using UID/RECURRENCE-ID AND THEN SEQUENCE to find the referneced instance is to NEVER ALLOW RECURRENCE-ID to change. Otherwise you have a chase where each SEQUENCE change involves 'rekeying' instances and that just wont work. > Because that is what SEQUENCE is used for. If you get something > newer and you can not figure it out, do a REFRESH to get > the laest copy and throw your copy away. I dont follow you. If Tom has SEQUENCE:1 and he gets in a SEQUENCE:3, WHY does he need to do a REFRESH? What cant his CUA "figure out" if its a complete snapshot? By the iTIP rules under 3.2.2 he would treat any new UID/RECURRENCE-ID pair as a new invitation if not found or as an update to an existing entry if found. The ONLY need I can think of is so that it can get a chain of RECURRENCE-IDs to relink everything. After all per 2446, 2.1.5 Message Sequencing: 3. "Attendees" send "REPLY" messages to the "Organizer". For replies where the "UID" property value is the same, the value of the "SEQUENCE" property indicates the revision of the component to which the "Attendee" is replying. The reply with the highest numeric value for the "SEQUENCE" property obsoletes all other replies with lower values. Thus if he gets SEQUENCE:3 and he already has 1 then he can just act on the new SEQUENCE:3 REQUEST. Its totally self contained so why is any action apart from a REPLY needed?!?! Im sorry but I must be missing something if its not to build a chain of RECURRENCE-IDs. After all a true complete snapshow with a higher SEQUENCE value is already defined obsolete "all other replys with lower values". Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.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 007F080A85256D2F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/23/2003 02:51:51 PM:
> > But how could Toms CUA derive the correct RECURRENCE-ID value from the
> > new SEQUENCE:3 info?
>
> It does not need to as the SEQUENCE:3 object contains the current
> state of the object.

This has digressed more than a little so Ill try to refocus before I head out.

By current iTIP rules (prev. citations) why would Toms CUA know/have to do a REFRESH if it got a SEQUENCE:3 and it had a SEQUENCE:1 value. You now say that it would not.  However it would have to IF RECURRENCE-ID values changed based on the interim DTSTART values.  In order to properly determine the RECURRENCE-ID of SEQUENCE:3 and match it to the existing SEQUENCE:1 entry something has to be done.  The ONLY way to follow iTIP rules on using UID/RECURRENCE-ID AND THEN SEQUENCE to find the referneced instance is to NEVER ALLOW RECURRENCE-ID to change.  Otherwise you have a chase where each SEQUENCE change involves 'rekeying' instances and that just wont work.

> Because that is what SEQUENCE is used for. If you get something
> newer and you can not figure it out, do a REFRESH to get
> the laest copy and throw your copy away.
I dont follow you.  If Tom has SEQUENCE:1 and he gets in a SEQUENCE:3, WHY does he need to do a REFRESH?  What cant his CUA "figure out" if its a complete snapshot?  By the iTIP rules under 3.2.2 he would treat any new UID/RECURRENCE-ID pair as a new invitation if not found or as an update to an existing entry if found.

The ONLY need I can think of is so that it can get a chain of RECURRENCE-IDs to relink everything.  After all per 2446, 2.1.5 Message Sequencing:

   3.  "Attendees" send "REPLY" messages to the "Organizer".  For
      replies where the "UID" property value is the same, the value of
      the "SEQUENCE" property indicates the revision of the component
      to which the "Attendee" is replying.  The reply with the highest
      numeric value for the "SEQUENCE" property obsoletes all other
      replies with lower values.

Thus if he gets SEQUENCE:3 and he already has 1 then he can just act on the new SEQUENCE:3 REQUEST.  Its totally self contained so why is any action apart from a REPLY needed?!?!  

Im sorry but I must be missing something if its not to build a chain of RECURRENCE-IDs.  After all a true complete snapshow with a higher SEQUENCE value is already defined obsolete "all other replys with lower values".  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.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 007F080A85256D2F_=-- From owner-ietf-calendar@mail.imc.org Sat May 24 12:50: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 MAA00233 for ; Sat, 24 May 2003 12:49: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 h4OGcYAF014013 for ; Sat, 24 May 2003 09:38: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 h4OGcYww014012 for ietf-calendar-bks; Sat, 24 May 2003 09:38: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 h4OGcWAF014007 for ; Sat, 24 May 2003 09:38: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 h4OGcUv3015091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 24 May 2003 09:38:33 -0700 Message-ID: <3ECFA001.8020005@Royer.com> Date: Sat, 24 May 2003 10:38:25 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020601000902070008030103" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020601000902070008030103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug shot back on 05/23/2003 03:37:29 PM: > > > > RECURRENCE-ID is only like UID when the SEQUENCE and UID are known. > > > > So RECURRENCE-ID applies to the verison of the object where UID > > > > and SEQUENCE match the update. > > > > > > Sorry but _that_ is not true. > > > > > > Go recheck RFC 2446, Section 2.1.5 Message Sequencing: > > > > > > 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. > > > > > > So RECURRENCE-ID is used in conjunction with UID and BEFORE SEQUENCE > > > checking. Why? Simple: you have to find the right instance before > you > > > can check if the message is older, newer, etc.! > > > > Which was my point!? > > Your ordering of usage/evaluation is whats wrong. You totally missed > the implication of Step 1. UID and RECURRENCE-ID are first used in > combination to find a set and instance and THEN SEQUENCE is used. I missed no such thing. I was not responding to the order of or combination of checking. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020601000902070008030103 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjQxNjM4MjVaMCMGCSqGSIb3DQEJBDEWBBQR nZj2KMaBXbvx8JzOWxPZ886quDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAkx7ewqrOfaEo Cwhc1s5F25PZTp3zGdNskM6noeEw1fIUBuK0MIgD26iVws8lVuTawGcd8SIW/JO3ctdIpsOD 4mLvqXfjhhRbJ9SDlKWlnHbAeOpnoK4fD2pa8wwykU5Yt275lYmJmNnWDh/rbmqyaMnEW9Te Y97aymARTJQxUS4FV/vVUhSZ6wg6g+W93oSzWt8pr0q0nfz7CDgI9I7/vSmSJ6YHaLC42X69 kgsOHqznvI00SXp+g6ITfNrJKcy+ycZSeerwZAEz50Xym96ME1L2IYIXfyr50NgZOf1kt4nY bMPpzp9J/SWkaI7vkP8CcthaMyMec5E+gWgoQ7fZIgAAAAAAAA== --------------ms020601000902070008030103-- From owner-ietf-calendar@mail.imc.org Sat May 24 13:36: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 MAA00234 for ; Sat, 24 May 2003 12:49: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 h4OGb5AF013995 for ; Sat, 24 May 2003 09:37: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 h4OGb52G013994 for ietf-calendar-bks; Sat, 24 May 2003 09:37: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 h4OGb4AF013989 for ; Sat, 24 May 2003 09:37: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 h4OGb1v3015081 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 24 May 2003 09:37:04 -0700 Message-ID: <3ECF9F9B.6080302@Royer.com> Date: Sat, 24 May 2003 10:36:43 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010002030503080509060608" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010002030503080509060608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 05/23/2003 02:51:51 PM: > > > But how could Toms CUA derive the correct RECURRENCE-ID value from the > > > new SEQUENCE:3 info? > > > > It does not need to as the SEQUENCE:3 object contains the current > > state of the object. > > This has digressed more than a little so Ill try to refocus before I > head out. > > By current iTIP rules (prev. citations) why would Toms CUA know/have to > do a REFRESH if it got a SEQUENCE:3 and it had a SEQUENCE:1 value. Because it says so in 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 --------------ms010002030503080509060608 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjQxNjM2NDNaMCMGCSqGSIb3DQEJBDEWBBTV T0udZ3DnX7JavMMTfCiR9uejcTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEATY5+C1+q2+3z Gi2vT1mPWcmYUiUMii4IqZMV0SslmiczHe/evoIC3eZDZGWvEc4QHyJ1U284lBemjDn0BlHI lQSkeJwUzvQ36z0MtPDCq6Uoir7VrY4YIEDyO7y0YEV7uIAa9OQtb7hsyMKuRqssk07JczhM s4ma/0I7tbUloUWdXFeyNNIjcUHAXjxKZQpHAxBurrGS3bkANez4Gt5dsu0sRHov1ixMsBmI IPqfQ6gYHue7xe2U+3B45OU/ePnVLH7uUV48u+cemxEyYuo5gMGf1BolLLzH7V1/vyR2id6Q wHuz/nO+umRqalW/S7hhiqQ2Ur578uKUPDNbWQROtgAAAAAAAA== --------------ms010002030503080509060608-- From owner-ietf-calendar@mail.imc.org Tue May 27 12:21: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 MAA18762 for ; Tue, 27 May 2003 12: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 h4RFxVAF063755 for ; Tue, 27 May 2003 08:59: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 h4RFxVIG063754 for ietf-calendar-bks; Tue, 27 May 2003 08:59:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from aretha.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RFxTAF063749 for ; Tue, 27 May 2003 08:59:30 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE8E16.3020505@Royer.com> To: ietf-calendar@imc.org Subject: Re: iTIP REPLY question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 27 May 2003 11:49:20 -0400 X-MIMETrack: Serialize by Router on Aretha/Iris(Build V603_M2_05212003NP|May 21, 2003) at 05/27/2003 12:09:24 PM, Serialize complete at 05/27/2003 12:09:24 PM Content-Type: multipart/alternative; boundary="=_alternative 0056AED985256D33_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056AED985256D33_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/23/2003 05:09:42 PM: > It is true that you can send REQUEST objects and break them in such > a way that no one can reply. Don't do that. Such objects are bogus > and should be deleted. Just like a email with a bogus 'From' line. So the object that everyone inside my firewall can read, parse and understand just fine (as well as respond to) is bogus because you have no way to send back a response... This is not 'breaking' them so that "no one can reply"; its only a problem if you MUST be able to directly penetrate a firewall or other security cordon. And just how is my CUA to know you cannot get back to me if it can reach you if it can reach your CAP server using something like SOCKSs? I dont view this as an error with the data; I view this as a protocol limitation/problem. After all the data itself is fine. The _only _ problem seems to be that your CUA cannot find a route back to alice.iris.com using CAP... > How do I get email replies? Because of a gateway that knows > what I did. Not strictly true. Your MUA does NOT use the routing info in the Received headers to follow any return path; it uses the Reply-To header and its configured SMTP server. The MUA gives routing control over to the MTA and it handles getting the reply to the right place. From RFC 2821 (SMTP): SMTP clients that transfer all traffic, regardless of the target domain names associated with the individual messages, or that do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable. In CAP, the CSs do no such feature nor have we left any hooks for it in CAP 1.0. EVERY CUA must perform the task of the MTAs and this makes CUAs either very complex or restricted to where they can do CAP (ie: only inside a firewall or only outside). In fact, SMTP has lots of text addressing 'relaying' that we never even consider in CAP 1.0 (an entire Section 3.7 even). In any case the problem is NOT rooted in 'bad data' but in a weakness of the current design. > Or make your CUA smart and send your local CAP address > to local users and your global CAP address to non-local users. However we have no prose in CAP 1.0 around doing any kind of mapping between "local" and "non-local" CAP addresses. In the email sense this is also handled by the MTAs but although CUAs are taking on the role of MTAs they have no guidelines for doing this bit either. > MX records are only used to find which system accepts '...@royer.com', > it has nothing to do with if my internal e-mail address is reachable > from the outside. All my MTA/MUA cares about is reaching royer.com. How it gets from there to your 'internal' address is a function of sendmail really, NOT SMTP. Again from 2821, Section 5. Address Resolution and Mail Handling: If an SMTP server receives a message with a destination for which it is a designated Mail eXchanger, it MAY relay the message (potentially after having rewritten the MAIL FROM and/or RCPT TO addresses), make final delivery of the message, or hand it off using some mechanism outside the SMTP-provided transport environment. Of course, neither of the latter require that the list of MX records be examined further. One difference between the email and CAP analogies is that email is store and forward over possibly multiple hops whereas CAP is a real time PRC utilizing a strict point to point design. The store/forward vs realtime is not that crucial (store/forward can done quickly enough to be a slow 'realtime' action of sort). The real factor is that email can be over multiple hops whereas CAP MUST be direct with no proxying or relaying involved. While adding full relaying in could take some time, if we had some hooks in CAP 1.0 that allowed a CAP 2.x CS to do relaying and for a CAP 1.0 CUA to unambiguously detect this then this issue could be fixable in a later version of CAP. As it stands now, CAP 1.0 has no hooks nor clear means for expansion in this area going forwards and this should be at least looked considered for CAP 1.0. I am NOT advocating that we delay CAP to put in full relaying features just that we put in some kind of hooks or prose to make CAP 2.0 easier... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0056AED985256D33_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/23/2003 05:09:42 PM:
> It is true that you can send REQUEST objects and break them in such
> a way that no one can reply. Don't do that. Such objects are bogus
> and should be deleted. Just like a email with a bogus 'From' line.
So the object that everyone inside my firewall can read, parse and understand just fine (as well as respond to)  is bogus because you have no way to send back a response...  This is not 'breaking' them so that "no one can reply"; its only a problem if you MUST be able to directly penetrate a firewall or other security cordon.

And just how is my CUA to know you cannot get back to me if it can reach you if it can reach your CAP server using something like SOCKSs?

I dont view this as an error with the data; I view this as a protocol limitation/problem.  After all the data itself is fine.  The _only _ problem seems to be that your CUA cannot find a route back to alice.iris.com using CAP...

> How do I get email replies? Because of a gateway that knows
> what I did.

Not strictly true.  Your MUA does NOT use the routing info in the Received headers to follow any return path; it uses the Reply-To header and its configured SMTP server.  The MUA gives routing control over to the MTA and it handles getting the reply to the right place.  From RFC 2821 (SMTP):

   SMTP clients that transfer all traffic, regardless of the
  target domain names associated with the individual messages, or that
  do not maintain queues for retrying message transmissions that
  initially cannot be completed, may otherwise conform to this
  specification but are not considered fully-capable.

In CAP, the CSs do no such feature nor have we left any hooks for it in CAP 1.0.  EVERY CUA must perform the task of the MTAs and this makes CUAs either very complex or restricted to where they can do CAP (ie: only inside a firewall or only outside).  

In fact, SMTP has lots of text addressing 'relaying' that we never even consider in CAP 1.0 (an entire Section 3.7 even).  In any case the problem is NOT rooted in 'bad data' but in a weakness of the current design.

>          Or make your CUA smart and send your local CAP address
> to local users and your global CAP address to non-local users.
However we have no prose in CAP 1.0 around doing any kind of mapping between "local" and "non-local" CAP addresses.  In the email sense this is also handled by the MTAs but although CUAs are taking on the role of MTAs they have no guidelines for doing this bit either.

> MX records are only used to find which system accepts '...@royer.com',
> it has nothing to do with if my internal e-mail address is reachable
> from the outside.

All my MTA/MUA cares about is reaching royer.com.  How it gets from there to your 'internal' address is a function of sendmail really, NOT SMTP.  Again from 2821, Section 5. Address Resolution and Mail Handling:

   If an SMTP server receives a message with a destination for which it
  is a designated Mail eXchanger, it MAY relay the message (potentially
  after having rewritten the MAIL FROM and/or RCPT TO addresses), make
  final delivery of the message, or hand it off using some mechanism
  outside the SMTP-provided transport environment.  Of course, neither
  of the latter require that the list of MX records be examined
  further.
One difference between the email and CAP analogies is that email is store and forward over possibly multiple hops whereas CAP is a real time PRC utilizing a strict point to point design.  The store/forward vs realtime is not that crucial (store/forward can done quickly enough to be a slow 'realtime' action of sort).  The real factor is that email can be over multiple hops whereas CAP MUST be direct with no proxying or relaying involved.  

While adding full relaying in could take some time, if we had some hooks in CAP 1.0 that allowed a CAP 2.x CS to do relaying and for a CAP 1.0 CUA to unambiguously detect this then this issue could be fixable in a later version of CAP.  As it stands now, CAP 1.0 has no hooks nor clear means for expansion in this area going forwards and this should be at least looked considered for CAP 1.0.  I am NOT advocating that we delay CAP to put in full relaying features just that we put in some kind of hooks or prose to make CAP 2.0 easier...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0056AED985256D33_=-- From owner-ietf-calendar@mail.imc.org Tue May 27 13:27: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 NAA20392 for ; Tue, 27 May 2003 13:27: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 h4RH1VAF066047 for ; Tue, 27 May 2003 10:01: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 h4RH1Vhl066046 for ietf-calendar-bks; Tue, 27 May 2003 10:01:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RH1UAF066041 for ; Tue, 27 May 2003 10:01:30 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECE96ED.6070404@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 27 May 2003 12:54:48 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/27/2003 01:01:21 PM, Serialize complete at 05/27/2003 01:01:21 PM Content-Type: multipart/alternative; boundary="=_alternative 005CAD1A85256D33_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CAD1A85256D33_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/23/2003 05:47:25 PM: > > > Now iTIP does not have an 'update' method. So lets say the ORGANIZER > > > sends a: > > > > Lets try to stay focused on the basic example I used before (Monday -> > > Wednesday -> Thursday -> Friday) shall we? Otherwise we cant reach any > > clear resolution. Ill be more than happy to consider this new example > > after this one. > > Simply do a REFRESH. > Then it does not matter how many times you update. Umm, the Organizer is NOT the one who sends a REFRESH. REFRESH is sent by invitees who, for whatever reason, think they need to get the current view of things. As such, I would NOT be sending a REFRESH, Tom would have to. This of course begs the question as to why would he think he has to if he just got the initial invitation with a SEQUENCE:0? As the Organzier I could see that Toms REPLY was for an older SEQUENCE and automagically send a new REQUEST with the latest snapshot of the event. I have shown what would be in _my_ resent REQUEST but I have yet to see what would be in the one you think should be sent... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005CAD1A85256D33_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/23/2003 05:47:25 PM:
> >  > Now iTIP does not have an 'update' method. So lets say the ORGANIZER
> >  > sends a:
> >
> > Lets try to stay focused on the basic example I used before (Monday ->
> > Wednesday -> Thursday -> Friday) shall we?  Otherwise we cant reach any
> > clear resolution.  Ill be more than happy to consider this new example
> > after this one.
>
> Simply do a REFRESH.
> Then it does not matter how many times you update.
Umm, the Organizer is NOT the one who sends a REFRESH.  REFRESH is sent by invitees who, for whatever reason, think they need to get the current view of things.  

As such, I would NOT be sending a REFRESH, Tom would have to.  This of course begs the question as to why would he think he has to if he just got the initial invitation with a SEQUENCE:0?

As the Organzier I could see that Toms REPLY was for an older SEQUENCE and automagically send a new REQUEST with the latest snapshot of the event.  I have shown what would be in _my_  resent REQUEST but I have yet to see what would be in the one you think should be sent...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005CAD1A85256D33_=-- From owner-ietf-calendar@mail.imc.org Tue May 27 13:44: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 NAA21097 for ; Tue, 27 May 2003 13:44: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 h4RHXAAF068000 for ; Tue, 27 May 2003 10: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 h4RHXASU067999 for ietf-calendar-bks; Tue, 27 May 2003 10: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 h4RHX9AF067994 for ; Tue, 27 May 2003 10: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 h4RHX4v3001863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 27 May 2003 10:33:09 -0700 Message-ID: <3ED3A146.50406@Royer.com> Date: Tue, 27 May 2003 11:32:54 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090005090706090702030107" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090005090706090702030107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 05/23/2003 05:09:42 PM: > > It is true that you can send REQUEST objects and break them in such > > a way that no one can reply. Don't do that. Such objects are bogus > > and should be deleted. Just like a email with a bogus 'From' line. > > So the object that everyone inside my firewall can read, parse and > understand just fine (as well as respond to) is bogus because you have > no way to send back a response... I said no such thing. From this point forward I'll simply reply to technical questions that have not already been answered. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090005090706090702030107 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjcxNzMyNTRaMCMGCSqGSIb3DQEJBDEWBBQm uYVleDQS2G1KeHOhZnTAZjnTiDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAlaxj0077rtD0 uKWY9fNZ3zoPUos2MDV+p1yHSqlELXF7w6n/XxNf+Z5619TH2dIvgEDth09n5wKLQtwo2kmo cC7cQKRGvNATkEVs/QtR7RNt4MVF4D3bu/jiMoDDKSaTKqD9taCoOA1HCAl8oKNymmMM3OXw OZLoatpv3aEd7rvpxWRi2lgmRhIY8A827PDkQObU+EEWhFLHFKbk3auT5Q7ZBoLX7z4A31fX rdBUvoYYGtAGfl3Zq8aPkuraJ/dE7DmzG3YnYsONKQHtYTQ+7Uz9CJIDLlvJWyP4rbNt6dtm BOYd5VgSgn31UCBelYZrgqqk7mnp1sTTSnUigu06OQAAAAAAAA== --------------ms090005090706090702030107-- From owner-ietf-calendar@mail.imc.org Tue May 27 13:46: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 NAA21337 for ; Tue, 27 May 2003 13:46: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 h4RHYXAF068041 for ; Tue, 27 May 2003 10:34: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 h4RHYX9B068040 for ietf-calendar-bks; Tue, 27 May 2003 10:34: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 h4RHYWAF068034 for ; Tue, 27 May 2003 10:34: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 h4RHYUv3001875 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 27 May 2003 10:34:33 -0700 Message-ID: <3ED3A1A0.6090805@Royer.com> Date: Tue, 27 May 2003 11: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.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010906080005020003090401" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010906080005020003090401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Simply do a REFRESH. > > Then it does not matter how many times you update. > > Umm, the Organizer is NOT the one who sends a REFRESH. REFRESH is sent > by invitees who, for whatever reason, think they need to get the current > view of things. The quote of mine you included is correct. And you will note the word 'ORGANIZER' is not included in my quote. We agree. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010906080005020003090401 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjcxNzM0MjRaMCMGCSqGSIb3DQEJBDEWBBSv 2HqmpbncZejilB4u+8nf5Ut3GTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAjiFuTCR1LWmy CEEjKoMhYRCcoz5xo8dgYrxTAAbvi1sHHqvAnAjsqexbSPp2Rn3CU7RTN63nLbSOzCOZ1vz4 GdyC11n9QpQpVHlOJoi93AM6482UjdOSxgWERXAeu4vwTcr+tVNE/eVlYpf19uc/oEKwtqWH CHvz5U3LrYifK2xLiCqPvK4DlyqDL6evLd9xK3pPoJrMCmKBsvOQn1rcNjbMXITKOq6rhAur rAL5WsD8XT3PBrItaqpucOCrccpHE0/UWpcd48lZSG8CrjwepL8SzYbGu9ECcYKdt5zAKf9l r31LhNYHFSL8KcKGaOyFcDTs63EIxOt48pN/jZuOcgAAAAAAAA== --------------ms010906080005020003090401-- From owner-ietf-calendar@mail.imc.org Tue May 27 14: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 OAA22509 for ; Tue, 27 May 2003 14: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 h4RHw4AF069114 for ; Tue, 27 May 2003 10:58: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 h4RHw4PL069112 for ietf-calendar-bks; Tue, 27 May 2003 10:58:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RHw3AF069102 for ; Tue, 27 May 2003 10:58:03 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECEACE8.5050607@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 27 May 2003 13:38:43 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/27/2003 01:57:51 PM, Serialize complete at 05/27/2003 01:57:51 PM Content-Type: multipart/alternative; boundary="=_alternative 0060B26A85256D33_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0060B26A85256D33_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 05/23/2003 07:21:12 PM: > > 1: We cannot guarantee that every previous message has arrived at the > > recipients address. As such, if any message _ever_ is lost then the > > entire workflow breaks down. > > .......... > > All of this has been solved. > > Just compare the UID, SEQUENCE, Possibly RECURRENCE-ID and DTSTAMP > per iTIP and iCAL. If you have an old copy - do a REFRESH. No "possibly" about it for the repeating case which we are talking about now. iTIP is not conflicting on the regarding identifying instances and sequencing (Section 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. 2. The secondary key for referencing a component is the "SEQUENCE" property value. So for an instance of a repeating set the primary key to use is always UID/RECURRENCE-ID followed by a secondary key of SEQUENCE followed by DTSTAMP! The text that Doug/George have cited about rewriting the RECURRENCE-ID means that the _primary key_ would be changed for every reschedule to a particular instance. If the key changes then you cannot find the particular instance in question; you find nothing OR you find a different instance! This BREAKS WORKFLOW no matter what they claim! (Ill show you below in case you are not convinced.) The only way to always match the proper instance every time no matter how many reschedules have been involved/missed/etc is to make sure that the key never changes! Nothing Doug says can change that. I think that those that espouse a changing RECURRENCE-ID value have not looked at iTIP and how it distinguishes a new invitation from a reschedule (or update). Because the WG decided to simplify the list of METHODs in the base protocol from the original ~15+ down to the current set we had to overloade some METHOD values. To help distinguish between the possible cases of new vs reschedule vs update we put the sections in iTIP such as: 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. So lets take a look at how Toms CUA would respond to my and Dougs reschedule notices. Note: for brevity Im leaving off the time bits to keep the examples but they should be included for real. Now, lets start with my version... Since the RECURRENCE-ID never changes I would send Tom a new REQUEST with: DTSTART:20030613 DTEND:20030613 RECURRENCE-ID:20030609 SEQUENCE:3 for that first instance. Since Tom already has that RECURRENCE-ID then he would follow the behaviour from Section 3.2.2.1 and treat it as a reschedule notice for the correct instance (the one originally on M 09-Jun-03). Thus he knows that there is no a meeting on Monday 09-Jun-03 and he can accept/decline properly! Lets now take a look at the proposal to use a new RECURRENCE-ID per reschedule. Following what Doug has described so far I would have: DTSTART:20030613 DTEND:20030613 RECURRENCE-ID:20030612 SEQUENCE:3 since the previous DTSTART value was for R 12-Jun-03 (at SEQUENCE:2). If I recieve a REPLY from Tom for RECURRENCE-ID:20030609 at SEQUENCE:0 then I have a quandry. First off, I have to be able to match that RECURRENCE-ID to an instance of the repeat set but none will match. Unless my CUA maintains a full history of RECURRENCE-ID and SEQUENCE values for every revision of every instance. Ok, perhaps (yuck but perhaps)... So then I follow my internal reschedule 'chains' to determine that Tom was replying to the instance that is currently RECURRENCE-ID:20030613 and I would thus send him a new REQUEST with: DTSTART:20030613 DTEND:20030613 RECURRENCE-ID:20030612 SEQUENCE:3 for the first instance. Since Tom cannot find that RECURRENCE-ID then he would follow the behaviour from Section 3.2.2.1 and treat it as a new request since he does not have that RECURRENCE-IE for the given UID. So the 'update' I sent would be treated as a new invitation to a new instance! So now Tom thinks that he has been invited to an instance on Monday 09-Jun-03 (which he already accepted) AND he was just invited to a new instance on Friday 13-Jun-03 and he has to decide to attende or not. This means that Tom thinks there is a meeting on Monday (there isn't) and that there is another related instance on Friday. In fact its not 'another' instance but the one he originally accepted. Workflow could be partly restored in that if I never reschedule the Friday 13-Jun-03 instance again Tom will show up to it. However he will also show up on Monday where there is no meeting and no matter how many REFRESHes Tom sends, he will NEVER get any new information about it because my side thinks the latest snapshot is Friday and thus Id reREQUEST him for Friday. This breaks the workflow process. As more reschedules happen the more 'orphaned' instances get left on the invitees calendars because the primary key used to find them has been changed. This is not good and why we opt'd away from a 'delta' model so long ago. It can become worse if instances in a repeat set 'cross' at some point such that the rekeyd RECURRENCE-ID is shared between different instances at different points in time. The SEQUENCE values could match when the overlap happens so then it becomes impossible to accurately tell which instance is being referred to at any given time. To see this, simply do the following 5 steps: 1: Create a 2 entry repeating set for every Wednesday @ a given time. 2: Reschedule the first instance to the Friday between the two Wednesdays (now SEQUENCE:1) 3: Reschedule it again to the day before (Thursday, SEQUENCE:2) 4: Reschedule the second instance to the Friday between the two Wednesdays (now SEQUENCE:1 and same RECURRENCE-ID) 5: Reschedule it again to another day. So now if a REPLY for RECURRENCE-ID:THURSDAY / SEQUENCE:1 comes in, can you tell me which instance it was for AND more to the point what the correct new RECURRENCE-ID is?? Didn't think you could, at least not accurately... Ok, by now I hope that everyone can see that changing the primary instance key of UID/RECURRENCE-ID can totally munge workflow and create a mess whereas keeping a fixed primary instance key results in a much much simpler process and NO confusion... Any not see this? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0060B26A85256D33_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 05/23/2003 07:21:12 PM:
> > 1: We cannot guarantee that every previous message has arrived at the
> > recipients address.  As such, if any message _ever_ is lost then the
> > entire workflow breaks down.
>  > ..........
>
> All of this has been solved.
>
> Just compare the  UID, SEQUENCE, Possibly RECURRENCE-ID and DTSTAMP
> per iTIP and iCAL. If you have an old copy - do a REFRESH.
No "possibly" about it for the repeating case which we are talking about now.  iTIP is not conflicting on the regarding identifying instances and sequencing (Section 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.

   2.  The secondary key for referencing a component is the "SEQUENCE"
      property value.

So for an instance of a repeating set the primary key to use is always UID/RECURRENCE-ID followed by a secondary key of SEQUENCE followed by DTSTAMP!

The text that Doug/George have cited about rewriting the RECURRENCE-ID means that the _primary key_ would be changed for every reschedule to a particular instance.  If the key changes then you cannot find the particular instance in question; you find nothing OR you find a different instance!  This BREAKS WORKFLOW no matter what they claim!  (Ill show you below in case you are not convinced.)

The only way to always match the proper instance every time no matter how many reschedules have been involved/missed/etc is to make sure that the key never changes!  Nothing Doug says can change that.

I think that those that espouse a changing RECURRENCE-ID value have not looked at iTIP and how it distinguishes a new invitation from a reschedule (or update).  Because the WG decided to simplify the list of METHODs in the base protocol from the original ~15+ down to the current set we had to overloade some METHOD values.  To help distinguish between the possible cases of new vs reschedule vs update we put the sections in iTIP such as:

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.

So lets take a look at how Toms CUA would respond to my and Dougs reschedule notices.  

Note: for brevity Im leaving off the time bits to keep the examples but they should be included for real.  Now, lets start with my version...

Since the RECURRENCE-ID never changes I would send Tom a new REQUEST with:

       DTSTART:20030613
      DTEND:20030613
      RECURRENCE-ID:20030609
      SEQUENCE:3

for that first instance.  Since Tom already has that RECURRENCE-ID then he would follow the behaviour from Section 3.2.2.1 and treat it as a reschedule notice for the correct instance (the one originally on M 09-Jun-03).  Thus he knows that there is no a meeting on Monday 09-Jun-03 and he can accept/decline properly!

Lets now take a look at the proposal to use a new RECURRENCE-ID per reschedule.  Following what Doug has described so far I would have:

       DTSTART:20030613
      DTEND:20030613
      RECURRENCE-ID:20030612
      SEQUENCE:3

since the previous DTSTART value was for R 12-Jun-03 (at SEQUENCE:2).  If I recieve a REPLY from Tom for RECURRENCE-ID:20030609 at SEQUENCE:0 then I have a quandry.  First off, I have to be able to match that RECURRENCE-ID to an instance of the repeat set but none will match.  Unless my CUA maintains a full history of RECURRENCE-ID and SEQUENCE values for every revision of every instance.  Ok, perhaps (yuck but perhaps)...

So then I follow my internal reschedule 'chains' to determine that Tom was replying to the instance that is currently RECURRENCE-ID:20030613 and I would thus send him a new REQUEST with:

       DTSTART:20030613
      DTEND:20030613
      RECURRENCE-ID:20030612
      SEQUENCE:3

for the first instance.  Since Tom cannot find that RECURRENCE-ID then he would follow the behaviour from Section 3.2.2.1 and treat it as a new request since he does not have that RECURRENCE-IE for the given UID.  So the 'update' I sent would be treated as a new invitation to a new instance!  So now Tom thinks that he has been invited to an instance on Monday 09-Jun-03 (which he already accepted) AND he was just invited to a new instance on Friday 13-Jun-03 and he has to decide to attende or not.

This means that Tom thinks there is a meeting on Monday (there isn't) and that there is another related instance on Friday.  In fact its not 'another' instance but the one he originally accepted.  Workflow could be partly restored in that if I never reschedule the Friday 13-Jun-03 instance again Tom will show up to it.  However he will also show up on Monday where there is no meeting and no matter how many REFRESHes Tom sends, he will NEVER get any new information about it because my side thinks the latest snapshot is Friday and thus Id reREQUEST him for Friday.  This breaks the workflow process.

As more reschedules happen the more 'orphaned' instances get left on the invitees calendars because the primary key used to find them has been changed.  This is not good and why we opt'd away from a 'delta' model so long ago.

It can become worse if instances in a repeat set 'cross' at some point such that the rekeyd RECURRENCE-ID is shared between different instances at different points in time.  The SEQUENCE values could match when the overlap happens so then it becomes impossible to accurately tell which instance is being referred to at any given time.  To see this, simply do the following 5 steps:

1: Create a 2 entry repeating set for every Wednesday @ a given time.
2: Reschedule the first instance to the Friday between the two Wednesdays (now SEQUENCE:1)
3: Reschedule it again to the day before (Thursday, SEQUENCE:2)
4: Reschedule the second instance to the Friday between the two Wednesdays (now SEQUENCE:1 and same RECURRENCE-ID)
5: Reschedule it again to another day.

So now if a REPLY for RECURRENCE-ID:THURSDAY / SEQUENCE:1 comes in, can you tell me which instance it was for AND more to the point what the correct new RECURRENCE-ID is??  Didn't think you could, at least not accurately...

Ok, by now I hope that everyone can see that changing the primary instance key of UID/RECURRENCE-ID can totally munge workflow and create a mess whereas keeping a fixed primary instance key results in a much much simpler process and NO confusion...  Any not see this?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0060B26A85256D33_=-- From owner-ietf-calendar@mail.imc.org Tue May 27 15:09: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 PAA25804 for ; Tue, 27 May 2003 15:09: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 h4RIx8AF074058 for ; Tue, 27 May 2003 11:59: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 h4RIx8MF074057 for ietf-calendar-bks; Tue, 27 May 2003 11:59: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RIx7AF074052 for ; Tue, 27 May 2003 11:59:07 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED3A146.50406@Royer.com> To: ietf-calendar@imc.org Subject: Re: iTIP REPLY question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 27 May 2003 14:50:46 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/27/2003 02:58:52 PM, Serialize complete at 05/27/2003 02:58:52 PM Content-Type: multipart/alternative; boundary="=_alternative 00674B2485256D33_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00674B2485256D33_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 05/27/2003 01:32:54 PM: > Bruce_Kahn@notesdev.ibm.com wrote: > > > > Doug wrote on 05/23/2003 05:09:42 PM: > > > It is true that you can send REQUEST objects and break them in such > > > a way that no one can reply. Don't do that. Such objects are bogus > > > and should be deleted. Just like a email with a bogus 'From' line. > > > > So the object that everyone inside my firewall can read, parse and > > understand just fine (as well as respond to) is bogus because you have > > no way to send back a response... > > > I said no such thing. I left your quote intact above and I see that it says "no one can reply" followed by "Such objects are bogus." So Ill restate my last response to see if its more accurate: So the object that everyone inside my firewall can read, parse and understand jsut fine (as well as respond to) is NOT bogus just because only you cannot respond to it. As such then whose fault is it that your CUA cannot respond? I claim that this is a weakness in CAP (dealing with firewalls, etc) and not an issue with iTIP! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.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 00674B2485256D33_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 05/27/2003 01:32:54 PM:
> Bruce_Kahn@notesdev.ibm.com wrote:
> >
> > Doug wrote on 05/23/2003 05:09:42 PM:
> >  > It is true that you can send REQUEST objects and break them in such
> >  > a way that no one can reply. Don't do that. Such objects are bogus
> >  > and should be deleted. Just like a email with a bogus 'From' line.
> >
> > So the object that everyone inside my firewall can read, parse and
> > understand just fine (as well as respond to)  is bogus because you have
> > no way to send back a response...
>
>
> I said no such thing.
I left your quote intact above and I see that it says "no one can reply" followed by "Such objects are bogus."  

So Ill restate my last response to see if its more accurate:

So the object that everyone inside my firewall can read, parse and understand jsut fine (as well as respond to) is NOT bogus just because only you cannot respond to it.  As such then whose fault is it that your CUA cannot respond?  

I claim that this is a weakness in CAP (dealing with firewalls, etc) and not an issue with iTIP!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.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 00674B2485256D33_=-- From owner-ietf-calendar@mail.imc.org Tue May 27 15:41: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 PAA28102 for ; Tue, 27 May 2003 15:41: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 h4RJQFAF074854 for ; Tue, 27 May 2003 12:26: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 h4RJQFhd074853 for ietf-calendar-bks; Tue, 27 May 2003 12:26: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 h4RJQDAF074846 for ; Tue, 27 May 2003 12:26: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 h4RJQBv3002738 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 27 May 2003 12:26:14 -0700 Message-ID: <3ED3BBCE.3030608@Royer.com> Date: Tue, 27 May 2003 13:26:06 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070208050107090106040902" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070208050107090106040902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > So Ill restate my last response to see if its more accurate: > > So the object that everyone inside my firewall can read, parse and > understand jsut fine (as well as respond to) is NOT bogus just because > only you cannot respond to it. As such then whose fault is it that your > CUA cannot respond? I have made no such claim. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070208050107090106040902 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjcxOTI2MDZaMCMGCSqGSIb3DQEJBDEWBBQu c3LxLCmXUyd/CUsdJHWHK8LgvjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAJnQzHSB/DSv+ XPqQw/vSo/M7lXMDloKSEZar5w6b8ncgp+OG5y6f62Yc7gJOqQX6WOBFyE3sbfe1knTVGQ8l aSHtq39WaKOmexgKbKuT2ktD4I9WiX8PglfwPhLrgPni1hBvM2gCQJWe6+bR1uxdnxDF7i1M 0k/2/K7FUAlrfhzUw5t4/CqlM7d1CJ4Ehax42Oj2aNxhpWO7T538UtnOcnh99w2jiZZnghd6 i6g6+tGWCg+VupgD6sE4otScTFycgex3LBamWgQ94Zv9oZHTdGYbJZdwQcXByr0QpyvtRzZK y1YoBZw54x3KHIDKszQLXv+zMSN9SMvQQKZUjw2q+AAAAAAAAA== --------------ms070208050107090106040902-- From owner-ietf-calendar@mail.imc.org Tue May 27 16:21: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 QAA29740 for ; Tue, 27 May 2003 16:21: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 h4RK6lAF075706 for ; Tue, 27 May 2003 13:06: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 h4RK6l3d075705 for ietf-calendar-bks; Tue, 27 May 2003 13:06:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RK6kAF075700 for ; Tue, 27 May 2003 13:06:47 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED3A146.50406@Royer.com> To: ietf-calendar@imc.org Subject: Re: iTIP REPLY question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 27 May 2003 15:57:48 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/27/2003 04:06:47 PM, Serialize complete at 05/27/2003 04:06:47 PM Content-Type: multipart/alternative; boundary="=_alternative 006D6E5F85256D33_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D6E5F85256D33_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 05/27/2003 01:32:54 PM: > > Doug wrote on 05/23/2003 05:09:42 PM: > > > It is true that you can send REQUEST objects and break them in such > > > a way that no one can reply. Don't do that. Such objects are bogus > > > and should be deleted. Just like a email with a bogus 'From' line. > > > > So the object that everyone inside my firewall can read, parse and > > understand just fine (as well as respond to) is bogus because you have > > no way to send back a response... > > > I said no such thing. > In looking back in the archives a bit (just making sure I didnt totally misread your response) and I found that you actually did claim it was bogus. In your note dated 05/06/2003 10:17:52 AM CST you replied in part: > Can you at INET-consulting.com resolve my alice.iris.com CAP server? If you set your ORGANIZER property value to CAP:alice.iris.com, I would expect to be able to CAP reply to that address. > You'll probably get "Unknown host" from your DNS server. So what > should your CUA do at that point? I would call you on the phone and tell you you sent me a bogus CAP object. Then delete the object from my store. So you actually did claim that the iTIP message I sent that only you could not respond to was bogus. This is not quite what you said later on (see top quote). In any event the point of this thread was that CAP is really focused on CUA -> CS where the CUA is responsible for going to each CS in turn. However as I pointed out this is not always possible in a real world. This is not a problem in iMIP because the MTAs handle the routing/delivery rather than the MUA. In CAP the CUAs take on the role of the MTAs and that can be a problem (especially if we have no clear hooks in CAP 1.0 to allow for CS fanout, etc going forward). Its been said before but some folks seem to have forgotten it or do not think this is a possible problem. Im not one of them though... 'Nuff said. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.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 006D6E5F85256D33_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 05/27/2003 01:32:54 PM:
> > Doug wrote on 05/23/2003 05:09:42 PM:
> >  > It is true that you can send REQUEST objects and break them in such
> >  > a way that no one can reply. Don't do that. Such objects are bogus
> >  > and should be deleted. Just like a email with a bogus 'From' line.
> >
> > So the object that everyone inside my firewall can read, parse and
> > understand just fine (as well as respond to)  is bogus because you have
> > no way to send back a response...
>
>
> I said no such thing.
>
In looking back in the archives a bit (just making sure I didnt totally misread your response) and I found that you actually did claim it was bogus.  

In your note dated 05/06/2003 10:17:52 AM CST you replied in part:

> Can you at INET-consulting.com resolve my alice.iris.com CAP server?

If you set your ORGANIZER property value to CAP:alice.iris.com, I would
expect to be able to CAP reply to that address.

>  You'll probably get "Unknown host" from your DNS server.  So what
> should your CUA do at that point?

I would call you on the phone and tell you you sent me a bogus
CAP object. Then delete the object from my store.
So you actually did claim that the iTIP message I sent that only you could not respond to was bogus.  This is not quite what you said later on (see top quote).

In any event the point of this thread was that CAP is really focused on CUA -> CS where the CUA is responsible for going to each CS in turn.  However as I pointed out this is not always possible in a real world.  

This is not a problem in iMIP because the MTAs handle the routing/delivery rather than the MUA.  In CAP the CUAs take on the role of the MTAs and that can be a problem (especially if we have no clear hooks in CAP 1.0 to allow for CS fanout, etc going forward).  Its been said before but some folks seem to have forgotten it or do not think this is a possible problem.  Im not one of them though... 'Nuff said.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.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 006D6E5F85256D33_=-- From owner-ietf-calendar@mail.imc.org Tue May 27 16:42: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 QAA01308 for ; Tue, 27 May 2003 16:42: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 h4RKZIAF076497 for ; Tue, 27 May 2003 13:35: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 h4RKZIGG076496 for ietf-calendar-bks; Tue, 27 May 2003 13:35: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RKZIAF076491 for ; Tue, 27 May 2003 13:35:18 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECEB990.8080906@ENG.SUN.COM> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 27 May 2003 16:22:30 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/27/2003 04:35:17 PM, Serialize complete at 05/27/2003 04:35:17 PM Content-Type: multipart/alternative; boundary="=_alternative 006FB10B85256D33_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006FB10B85256D33_= Content-Type: text/plain; charset="US-ASCII" Arnaud Quillaud wrote on 05/23/2003 08:15:12 PM: > Now, Bruce wants to invite arnaud to all instances of the recurring > event. Arnaud has no information about this event in his CUA. So I'm > assuming Bruce will send him one iTIP request containing the > "master" event + the exception, right ? Yes. From 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 the iCalendar stream would contain the "base" definition followed by any instance specific data that "override the base" definition. > What will this request look like in your model ? > > Will it be: > > BEGIN:VCALENDAR > METHOD:REQUEST > ... > BEGIN:VEVENT > UID:that > SEQUENCE:1 > DTSTART: monday the 1st at 10am > RRULE: every monday forever > ATTENDEE: bob > ATTENDEE:arnaud > END:VEVENT > BEGIN:VEVENT > UID:that > SEQUENCE:1 > RECURRENCE-ID: monday the 8th at 10am > DTSTART: tuesday the 9th at 10am > ATTENDEE:bob > ATTENDEE:arnaud > END:VEVENT > END:VCALENDAR For the most part yes. The SEQUENCE property in the base would be 0, not 1 but close enough... (Since only the 2nd instance got rescheduled only its SEQUENCE value has changed.) > or will it be: > > BEGIN:VCALENDAR > BEGIN:VEVENT > UID:that > SEQUENCE:1 > DTSTART: monday the 1st at 10am > RRULE: every monday forever > RDATE: tuesday the 9th at 10am > EXDATE: monday the 8th at 10am > ATTENDEE: bob > ATTENDEE:arnaud > END:VEVENT > BEGIN:VEVENT > UID:that > SEQUENCE:1 > RECURRENCE-ID: monday the 8th at 10am > DTSTART: tuesday the 9th at 10am > ATTENDEE:bob > ATTENDEE:arnaud > END:VEVENT > END:VCALENDAR Not this because the "base" definition does NOT define the entire repeat set that was originally defined. It defines a set of [ "Every Monday Forever" + "Tuesday the 9th" - "Monday the 8th" ]. The "update" that follows now specifies an instance that was not part of the "base" (the RECURRENCE-ID is not reachable from the "base" because it was EXDATEed out). The other problem I see is that the 1st object defines a Tuesday the 9th instance initially thus making the RECURRENCE-ID for that instance of "Tuesday the 9th" and not "Monday the 8th" which later got rescheduled to the 9th (in the second object). This could mean that when a CUA rolls out both of these VEVENTs they 'dedup' the 2 "Tuesday the 9th" entries (per iCalendar) and may not be able to properly reschedule the Tuesday entry to a new date/time. > Or did I totally missed the logic of iTIP and does he send something else ? No, I think that was pretty much on track. The RFCs could use some prose in some areas and no doubt if you spend some cycles on repeating entries more gaps/mistakes will appear. Does this jive with your expectations? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006FB10B85256D33_= Content-Type: text/html; charset="US-ASCII"
Arnaud Quillaud wrote on 05/23/2003 08:15:12 PM:
> Now, Bruce wants to invite arnaud to all instances of the recurring
> event. Arnaud has no information about this event in his CUA. So I'm
> assuming Bruce will send him one iTIP request containing the
> "master" event + the exception, right ?
Yes.  From 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 the iCalendar stream would contain the "base" definition followed by any instance specific data that "override the base" definition.

> What will this request look like in your model ?
>
> Will it be:
>
> BEGIN:VCALENDAR
> METHOD:REQUEST
> ...
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> DTSTART: monday the 1st at 10am
> RRULE: every monday forever
> ATTENDEE: bob
> ATTENDEE:arnaud
> END:VEVENT
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> RECURRENCE-ID: monday the 8th at 10am
> DTSTART: tuesday the 9th at 10am
> ATTENDEE:bob
> ATTENDEE:arnaud
> END:VEVENT
> END:VCALENDAR
For the most part yes.  The SEQUENCE property in the base would be 0, not 1 but close enough... (Since only the 2nd instance got rescheduled only its SEQUENCE value has changed.)

> or will it be:
>
> BEGIN:VCALENDAR
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> DTSTART: monday the 1st at 10am
> RRULE: every monday forever
> RDATE: tuesday the 9th at 10am
> EXDATE: monday the 8th at 10am
> ATTENDEE: bob
> ATTENDEE:arnaud
> END:VEVENT
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> RECURRENCE-ID: monday the 8th at 10am
> DTSTART: tuesday the 9th at 10am
> ATTENDEE:bob
> ATTENDEE:arnaud
> END:VEVENT
> END:VCALENDAR
Not this because the "base" definition does NOT define the entire repeat set that was originally defined.  It defines a set of [ "Every Monday Forever" + "Tuesday the 9th" - "Monday the 8th" ].  The "update" that follows now specifies an instance that was not part of the "base" (the RECURRENCE-ID is not reachable from the "base" because it was EXDATEed out).

The other problem I see is that the 1st object defines a Tuesday the 9th instance initially thus making the RECURRENCE-ID for that instance of "Tuesday the 9th" and not "Monday the 8th" which later got rescheduled to the 9th (in the second object).  This could mean that when a CUA rolls out both of these VEVENTs they 'dedup' the 2 "Tuesday the 9th" entries (per iCalendar) and may not be able to properly reschedule the Tuesday entry to a new date/time.

> Or did I totally missed the logic of iTIP and does he send something else ?
No, I think that was pretty much on track.  The RFCs could use some prose in some areas and no doubt if you spend some cycles on repeating entries more gaps/mistakes will appear.

Does this jive with your expectations?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006FB10B85256D33_=-- From owner-ietf-calendar@mail.imc.org Tue May 27 16:46: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 QAA01375 for ; Tue, 27 May 2003 16:46: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 h4RKcRAF076562 for ; Tue, 27 May 2003 13:38: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 h4RKcRcb076561 for ietf-calendar-bks; Tue, 27 May 2003 13:38: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 h4RKcPAF076556 for ; Tue, 27 May 2003 13:38: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 h4RKcNv3003275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 27 May 2003 13:38:26 -0700 Message-ID: <3ED3CCB5.2080904@Royer.com> Date: Tue, 27 May 2003 14:38:13 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020803030408050905040408" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020803030408050905040408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 05/27/2003 01:32:54 PM: > > > Doug wrote on 05/23/2003 05:09:42 PM: > > > > It is true that you can send REQUEST objects and break them in such > > > > a way that no one can reply. Don't do that. Such objects are bogus > > > > and should be deleted. Just like a email with a bogus 'From' line. > > > > > > So the object that everyone inside my firewall can read, parse and > > > understand just fine (as well as respond to) is bogus because you > have > > > no way to send back a response... > > > > > > I said no such thing. > > > In looking back in the archives a bit (just making sure I didnt totally > misread your response) and I found that you actually did claim it was > bogus. > > In your note dated 05/06/2003 10:17:52 AM CST you replied in part: > > > Can you at INET-consulting.com resolve my alice.iris.com CAP server? > > If you set your ORGANIZER property value to CAP:alice.iris.com, I would > expect to be able to CAP reply to that address. > > > You'll probably get "Unknown host" from your DNS server. So what > > should your CUA do at that point? > > I would call you on the phone and tell you you sent me a bogus > CAP object. Then delete the object from my store. > > So you actually did claim that the iTIP message I sent that only you > could not respond to was bogus. This is not quite what you said later > on (see top quote). No Bruce. That is not what is says. The word 'expect' is in my quote. And it is true: You can send bogus REQUEST objects and break them in a way that no one can reply. > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020803030408050905040408 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjcyMDM4MTNaMCMGCSqGSIb3DQEJBDEWBBSP 3BjIHiG9im3Gc3zPo75J5YwfjTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAPfoXM/yHEfSo RP+PS7UFs2MHwgelMJyFm2ZgoCdYvBXS5UOEZtLhlShNiSEJqrnRRDoC7+7/6/mPEEABXl3E rIrOuJFT548LgW0IF2l1JSyBgX/EFr7hJsGBTkOE+xT5uRK/GFKTkeQUfdx8sxaBCoxXmBm3 NiEliu8VN7hBXTh00LX4HPm6V7YCHX3jPW69oFa9UNOJz+QOyu4FqK72jSVsDZfIkd5xaM/L Y8zyx4nXtWTT920DE2o3t92uMoR2yCgM0LvHvNIZToPqnDh3RbdpRZ/69vFU+/Q1qtFduLls StXkIDBJDM+86ND1tjGZvwgk/U5PC9+ilrlZMRcwZgAAAAAAAA== --------------ms020803030408050905040408-- From owner-ietf-calendar@mail.imc.org Tue May 27 17:45: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 RAA03837 for ; Tue, 27 May 2003 17:45: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 h4RLVYAF079541 for ; Tue, 27 May 2003 14:31: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 h4RLVYpL079539 for ietf-calendar-bks; Tue, 27 May 2003 14:31: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 h4RLVWAF079531 for ; Tue, 27 May 2003 14:31: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 h4RLVUv3003655 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 27 May 2003 14:31:33 -0700 Message-ID: <3ED3D929.4010901@Royer.com> Date: Tue, 27 May 2003 15:31:21 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050205000900000409080802" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050205000900000409080802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce - I can not find in my mail box or the IMC archives the e-mail that you are responding to. I can not find ANY email from "Arnaud Quillaud". Could you please post a link to the IMC site for this? Thanks! Bruce_Kahn@notesdev.ibm.com wrote: > > Arnaud Quillaud wrote on 05/23/2003 08:15:12 PM: > > Now, Bruce wants to invite arnaud to all instances of the recurring > > event. Arnaud has no information about this event in his CUA. So I'm > > assuming Bruce will send him one iTIP request containing the > > "master" event + the exception, right ? > > Yes. From 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 the iCalendar stream would contain the "base" definition followed by > any instance specific data that "override the base" definition. > > > What will this request look like in your model ? > > > > Will it be: > > > > BEGIN:VCALENDAR > > METHOD:REQUEST > > ... > > BEGIN:VEVENT > > UID:that > > SEQUENCE:1 > > DTSTART: monday the 1st at 10am > > RRULE: every monday forever > > ATTENDEE: bob > > ATTENDEE:arnaud > > END:VEVENT > > BEGIN:VEVENT > > UID:that > > SEQUENCE:1 > > RECURRENCE-ID: monday the 8th at 10am > > DTSTART: tuesday the 9th at 10am > > ATTENDEE:bob > > ATTENDEE:arnaud > > END:VEVENT > > END:VCALENDAR > > For the most part yes. The SEQUENCE property in the base would be 0, > not 1 but close enough... (Since only the 2nd instance got rescheduled > only its SEQUENCE value has changed.) > > > or will it be: > > > > BEGIN:VCALENDAR > > BEGIN:VEVENT > > UID:that > > SEQUENCE:1 > > DTSTART: monday the 1st at 10am > > RRULE: every monday forever > > RDATE: tuesday the 9th at 10am > > EXDATE: monday the 8th at 10am > > ATTENDEE: bob > > ATTENDEE:arnaud > > END:VEVENT > > BEGIN:VEVENT > > UID:that > > SEQUENCE:1 > > RECURRENCE-ID: monday the 8th at 10am > > DTSTART: tuesday the 9th at 10am > > ATTENDEE:bob > > ATTENDEE:arnaud > > END:VEVENT > > END:VCALENDAR > > Not this because the "base" definition does NOT define the entire repeat > set that was originally defined. It defines a set of [ "Every Monday > Forever" + "Tuesday the 9th" - "Monday the 8th" ]. The "update" that > follows now specifies an instance that was not part of the "base" (the > RECURRENCE-ID is not reachable from the "base" because it was EXDATEed > out). > > The other problem I see is that the 1st object defines a Tuesday the 9th > instance initially thus making the RECURRENCE-ID for that instance of > "Tuesday the 9th" and not "Monday the 8th" which later got rescheduled > to the 9th (in the second object). This could mean that when a CUA > rolls out both of these VEVENTs they 'dedup' the 2 "Tuesday the 9th" > entries (per iCalendar) and may not be able to properly reschedule the > Tuesday entry to a new date/time. > > > Or did I totally missed the logic of iTIP and does he send something > else ? > > No, I think that was pretty much on track. The RFCs could use some > prose in some areas and no doubt if you spend some cycles on repeating > entries more gaps/mistakes will appear. > > Does this jive with your expectations? > > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050205000900000409080802 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjcyMTMxMjFaMCMGCSqGSIb3DQEJBDEWBBTp hY7c/aGMMgzzvUwOwbm5s2db0zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAZHgpcEP2FIUg 6RFMZnhmOITI3E186ui9UW6bWZf8Uz5SpRQQF3AoS2Se8By/sgwVOGNfMhFY4H581IwRXX+/ EuWbJkGMCksF/O0hBCEyUfFMxK77AliPmzoM50FcJkC3bTk1EFDHZR7qQpPdzkP2svQ7vDrB 6AF14DtFHadGtLP5PN/ICrJZdgv8YE6/byjrq018LrA3OriBEaLzHeFev1SfuBrvrek9KtI3 u2SzL/dyoqw2xu2iaMPyL7NePhOO1vfQwdUnc6xnSpAZVtGvA3OdPLmPIrGdJ2QobR6hGuUf q4MS5HFSnwmvb51c1LNHmISFIrxsewIScHkgmeXY5gAAAAAAAA== --------------ms050205000900000409080802-- From owner-ietf-calendar@mail.imc.org Tue May 27 17:49: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 RAA03942 for ; Tue, 27 May 2003 17:49: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 h4RLfOAF080469 for ; Tue, 27 May 2003 14:41: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 h4RLfOjS080468 for ietf-calendar-bks; Tue, 27 May 2003 14:41: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 h4RLfNAF080463 for ; Tue, 27 May 2003 14:41: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 h4RLfLv3003729 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 27 May 2003 14:41:24 -0700 Message-ID: <3ED3DB7B.4020105@Royer.com> Date: Tue, 27 May 2003 15:41:15 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070700070003050007040301" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070700070003050007040301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > What will this request look like in your model ? > > > > Will it be: > > > > BEGIN:VCALENDAR > > METHOD:REQUEST > > ... > > BEGIN:VEVENT > > UID:that > > SEQUENCE:1 > > DTSTART: monday the 1st at 10am > > RRULE: every monday forever > > ATTENDEE: bob > > ATTENDEE:arnaud > > END:VEVENT > > BEGIN:VEVENT > > UID:that > > SEQUENCE:1 > > RECURRENCE-ID: monday the 8th at 10am > > DTSTART: tuesday the 9th at 10am > > ATTENDEE:bob > > ATTENDEE:arnaud > > END:VEVENT > > END:VCALENDAR What would be the point of the above object? As it is a REQUEST, why not just create an object SEQUENCE: that is what you want? What is the point of this? Would it not be better to: BEGIN:VCALENDAR METHOD:REQUEST ... BEGIN:VEVENT UID:that SEQUENCE:1 DTSTART: monday the 1st at 10am RRULE: every monday forever EXDATE: monday the 8th at 10am RDATE: tuesday the 9th at 10am ATTENDEE: bob ATTENDEE:arnaud 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 --------------ms070700070003050007040301 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjcyMTQxMTVaMCMGCSqGSIb3DQEJBDEWBBQz TYAHo05ADW/MrZ7dxqdHmLl0CDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAZ4hYPKz1pEI3 ZxO6n8NdoeQM5oydVVEzuXzVO9SZgzzFt65WX3iSiOnPVcI2/TJh1LjxzEFUhZb6YUsPtJHy eK1LGK+IiTrgTdt7xQzrziZ4rL6GczEnWksE2akYd2MbHd8FJWiZ/1t30pJ4Wz+6Nnl+52Jg 5s/qMO8B3BT1vh3Xo/sFZgLPCcSAjshKkLu9bC0QyTsbsumQOUL4jx8kkqqKgchkL8PHbkfz Tf+/aJNf304oqFNAqYfffkV6rTWPIdo9ditaEpMzFoVnxEj9V0FNdep/E82uCi0AW0U1/h4q ycNNBBVJMRIO6i80kuDXaNh40P5V5Nb8XMCyvPjK5gAAAAAAAA== --------------ms070700070003050007040301-- From owner-ietf-calendar@mail.imc.org Wed May 28 11:20: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 LAA08022 for ; Wed, 28 May 2003 11:20: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 h4SEwHAF046512 for ; Wed, 28 May 2003 07:58: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 h4SEwHvr046510 for ietf-calendar-bks; Wed, 28 May 2003 07:58: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SEwGAF046488 for ; Wed, 28 May 2003 07:58:16 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED3D929.4010901@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 28 May 2003 10:58:10 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/28/2003 10:58:17 AM, Serialize complete at 05/28/2003 10:58:17 AM Content-Type: multipart/alternative; boundary="=_alternative 005214FD85256D34_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005214FD85256D34_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/27/2003 05:31:21 PM: > Bruce - I can not find in my mail box or the IMC archives the e-mail > that you are responding to. > > I can not find ANY email from "Arnaud Quillaud". Could you please > post a link to the IMC site for this? > > Thanks! The person is Arnaud Quillaud and he has been posting some comments to the me and CCing the list (or visa versa). I just assumed they were also getting to the list. In checking the IMC archives I see this is not the case. Im guessing that Arnaud is NOT a WG member so postings to the list do not get thru the IMC list manager. Ive sent him a note asking about this. In the mean time, here is the posting he sent that I was replying to (Im editing out the text/html body part for brevity though): Received: from e6.ny.us.ibm.com ([9.14.6.106]) by ace.notesdev.ibm.com (Lotus Domino Build V602_05122003NP) with ESMTP id 2003052320153916-21133 for ; Fri, 23 May 2003 20:15:39 -0400 Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [205.159.212.202]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4O0Fb82170396 for ; Fri, 23 May 2003 20:15:38 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by capricorn.iris.com (Lotus Domino Build V602_03262003NP) with ESMTP id 2003052320142983-24223 for ; Fri, 23 May 2003 20:14:29 -0400 Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4O0F5ep011439; Fri, 23 May 2003 18:15:06 -0600 (MDT) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4O0F5Kw022242; Fri, 23 May 2003 17:15:05 -0700 (PDT) Received: from ENG.SUN.COM (iabs-2k.red.iplanet.com [192.18.144.144]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with ESMTP id <0HFD00A0D7D5OT@mpkmail.eng.sun.com>; Fri, 23 May 2003 17:15:05 -0700 (PDT) Date: Fri, 23 May 2003 17:15:12 -0700 From: Arnaud Quillaud Subject: Re: Correct handling of Recurrence-id To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Message-id: <3ECEB990.8080906@ENG.SUN.COM> MIME-version: 1.0 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 References: X-MIMETrack: Itemize by SMTP Server on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at 05/23/2003 08:14:30 PM, Serialize by Router on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at 05/23/2003 08:14:31 PM, Serialize complete at 05/23/2003 08:14:31 PM, Itemize by SMTP Server on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 08:15:39 PM, Serialize by Notes Client on Bruce Kahn/Westford/IBM(Build V70_04022003NP|April 02, 2003) at 05/28/2003 10:53:40 AM, Serialize complete at 05/28/2003 10:53:40 AM Content-type: multipart/alternative; boundary="Boundary_(ID_83e9+ab581aIPJMEfd9TIw)" --Boundary_(ID_83e9+ab581aIPJMEfd9TIw) Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Bruce_Kahn@notesdev.ibm.com wrote: > > > The only disadvantage of version 1 that I can think of is about > > someone joining the party while some rescheduling has already > > occured. Since the newcommer won't have the SEQUENCE: 0 of the > > recurrence set, he might interpret the set of RECURRENCE-ID > > differently. But maybe this is just because I don't understand what > > the right iTIP workflow is. > > Its not a problem for the non-delta model. The Organizer simply sends > a new invitee a REQUEST that contains the information they will need > to correctly identify the instance and put it on the right date/time. > So, continuing the example I used earlier to add Arnaud to Friday > 13-Jun-03 I would simply send the following REQUEST: > > BEGIN:VCALENDAR > PRODID:-//ACME/DesktopCalendar//EN > METHOD:REQUEST > VERSION:2.0 > BEGIN:VEVENT > ORGANIZER:Mailto:Bruce@widget.com > ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Bruce@widget.com > > ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Doug: Mailto:Doug@Royer.com > > ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=George: Mailto:George@fizbin.com > > ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Tom: Mailto:Tom@example.com > > ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Ki: Mailto:Ki@sun.com > > ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Arnaud: Mailto:Arnaud@sun.com > DTSTART:20030613T140000Z > DTEND:20030613T150000Z > SUMMARY:Head bashing > UID:calsrv.widget.com-873970198738777@widget.com > SEQUENCE:3 > RECURRENCE-ID:20030609T140000Z > DTSTAMP:20030523T225900Z > END:VEVENT > END:VCALENDAR > In my example, I was talking about the case where the Organizer wants to invite a totally new attendee to the whole serie, not just a particular instance. initial REQUEST. Bruce invites bob and only bob: BEGIN:VEVENT UID:that SEQUENCE:0 DTSTART: monday the 1st at 10am RRULE: every monday forever ATTENDEE: bob END:VEVENT Bruce changes the second instance to tuesday, so he sends a new iTIP REQUEST to bob: BEGIN:VEVENT UID:that SEQUENCE:1 RECURRENCE-ID: monday the 8th at 10am DTSTART: tuesday the 9th at 10am ATTENDEE:bob END:VEVENT Now, Bruce wants to invite arnaud to _all _instances of the recurring event. Arnaud has no information about this event in his CUA. So I'm assuming Bruce will send him one iTIP request containing the "master" event + the exception, right ? What will this request look like in your model ? Will it be: BEGIN:VCALENDAR METHOD:REQUEST ... BEGIN:VEVENT UID:that SEQUENCE:1 DTSTART: monday the 1st at 10am *RRULE: every monday forever* ATTENDEE: bob ATTENDEE:arnaud END:VEVENT BEGIN:VEVENT UID:that SEQUENCE:1 RECURRENCE-ID: monday the 8th at 10am DTSTART: tuesday the 9th at 10am ATTENDEE:bob ATTENDEE:arnaud END:VEVENT END:VCALENDAR or will it be: BEGIN:VCALENDAR BEGIN:VEVENT UID:that SEQUENCE:1 DTSTART: monday the 1st at 10am *RRULE: every monday forever RDATE: tuesday the 9th at 10am EXDATE: monday the 8th at 10am* ATTENDEE: bob ATTENDEE:arnaud END:VEVENT BEGIN:VEVENT UID:that SEQUENCE:1 RECURRENCE-ID: monday the 8th at 10am DTSTART: tuesday the 9th at 10am ATTENDEE:bob ATTENDEE:arnaud END:VEVENT END:VCALENDAR Or did I totally missed the logic of iTIP and does he send something else ? Thanks, Arnaud --Boundary_(ID_83e9+ab581aIPJMEfd9TIw) Content-transfer-encoding: 7BIT Content-type: text/html; charset=us-ascii [Snip, snip] --Boundary_(ID_83e9+ab581aIPJMEfd9TIw)-- Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005214FD85256D34_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/27/2003 05:31:21 PM:
> Bruce - I can not find in my mail box or the IMC archives the e-mail
> that you are responding to.
>
> I can not find ANY email from "Arnaud Quillaud". Could you please
> post a  link to the IMC site for this?
>
> Thanks!
The person is Arnaud Quillaud <Arnaud.Quillaud@Eng.Sun.COM> and he has been posting some comments to the me and CCing the list (or visa versa).  I just assumed they were also getting to the list.  In checking the IMC archives I see this is not the case.

Im guessing that Arnaud is NOT a WG member so postings to the list do not get thru the IMC list manager.  Ive sent him a note asking about this.  In the mean time, here is the posting he sent that I was replying to (Im editing out the text/html body part for brevity though):

Received: from e6.ny.us.ibm.com ([9.14.6.106])
         by ace.notesdev.ibm.com (Lotus Domino Build V602_05122003NP)
         with ESMTP id 2003052320153916-21133
         for <Bruce_Kahn@notesdev.ibm.com> ;
         Fri, 23 May 2003 20:15:39 -0400
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [205.159.212.202])
                by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4O0Fb82170396
                for <Bruce_Kahn@notesdev.ibm.com>; Fri, 23 May 2003 20:15:38 -0400
Received: from brmea-mail-3.sun.com ([192.18.98.34])
         by capricorn.iris.com (Lotus Domino Build V602_03262003NP)
         with ESMTP id 2003052320142983-24223
         for <Bruce_Kahn@notesdev.ibm.com> ;
         Fri, 23 May 2003 20:14:29 -0400
Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45])
                by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4O0F5ep011439;
                Fri, 23 May 2003 18:15:06 -0600 (MDT)
Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131])
                by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4O0F5Kw022242;
                Fri, 23 May 2003 17:15:05 -0700 (PDT)
Received: from ENG.SUN.COM (iabs-2k.red.iplanet.com [192.18.144.144])
by mpkmail.eng.sun.com
(iPlanet Messaging Server 5.2 Patch 1 (built Apr  2 2002))
with ESMTP id <0HFD00A0D7D5OT@mpkmail.eng.sun.com>; Fri,
23 May 2003 17:15:05 -0700 (PDT)
Date: Fri, 23 May 2003 17:15:12 -0700
From: Arnaud Quillaud <Arnaud.Quillaud@Eng.Sun.COM>
Subject: Re: Correct handling of Recurrence-id
To: Bruce_Kahn@notesdev.ibm.com
Cc: ietf-calendar@imc.org
Message-id: <3ECEB990.8080906@ENG.SUN.COM>
MIME-version: 1.0
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826
References:
<OFCDB74C02.22104DB7-ON85256D2F.007434BC-85256D2F.007B6F03@notesdev.ibm.com>
X-MIMETrack: Itemize by SMTP Server on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at
05/23/2003 08:14:30 PM,
                Serialize by Router on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at
05/23/2003 08:14:31 PM,
                Serialize complete at 05/23/2003 08:14:31 PM,
                Itemize by SMTP Server on Ace/Iris(Build V602_05122003NP|May 12, 2003) at
05/23/2003 08:15:39 PM,
                Serialize by Notes Client on Bruce Kahn/Westford/IBM(Build V70_04022003NP|April
02, 2003) at 05/28/2003 10:53:40 AM,
                Serialize complete at 05/28/2003 10:53:40 AM
Content-type: multipart/alternative;
boundary="Boundary_(ID_83e9+ab581aIPJMEfd9TIw)"


--Boundary_(ID_83e9+ab581aIPJMEfd9TIw)
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii; format=flowed

Bruce_Kahn@notesdev.ibm.com wrote:

>
> > The only disadvantage of version 1 that I can think of is about
> > someone joining the party while some rescheduling has already
> > occured. Since the newcommer won't have the SEQUENCE: 0 of the
> > recurrence set, he might interpret the set of RECURRENCE-ID
> > differently. But maybe this is just because I don't understand what
> > the right iTIP workflow is.
>
> Its not a problem for the non-delta model.  The Organizer simply sends
> a new invitee a REQUEST that contains the information they will need
> to correctly identify the instance and put it on the right date/time.
>  So, continuing the example I used earlier to add Arnaud to Friday
> 13-Jun-03 I would simply send the following REQUEST:
>
>    BEGIN:VCALENDAR
>   PRODID:-//ACME/DesktopCalendar//EN
>   METHOD:REQUEST
>   VERSION:2.0
>   BEGIN:VEVENT
>   ORGANIZER:Mailto:Bruce@widget.com
>   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Bruce@widget.com
>  
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Doug:Mailto:Doug@Royer.com
>  
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=George:Mailto:George@fizbin.com
>  
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Tom:Mailto:Tom@example.com
>  
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Ki:Mailto:Ki@sun.com
>  
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Arnaud:Mailto:Arnaud@sun.com
>   DTSTART:20030613T140000Z
>   DTEND:20030613T150000Z
>   SUMMARY:Head bashing
>   UID:calsrv.widget.com-873970198738777@widget.com
>   SEQUENCE:3
>    RECURRENCE-ID:20030609T140000Z
>   DTSTAMP:20030523T225900Z
>   END:VEVENT
>   END:VCALENDAR
>
In my example, I was talking about the case where the Organizer wants to
invite a totally new attendee to the whole serie, not just a particular
instance.

initial REQUEST. Bruce invites bob and only bob:

BEGIN:VEVENT
UID:that
SEQUENCE:0
DTSTART: monday the 1st at 10am
RRULE: every monday forever
ATTENDEE: bob
END:VEVENT

Bruce changes the second instance to tuesday, so he sends a new iTIP
REQUEST to bob:

BEGIN:VEVENT
UID:that
SEQUENCE:1
RECURRENCE-ID: monday the 8th at 10am
DTSTART: tuesday the 9th at 10am
ATTENDEE:bob
END:VEVENT

Now, Bruce wants to invite arnaud to _all _instances of the recurring
event. Arnaud has no information about this event in his CUA. So I'm
assuming Bruce will send him one iTIP request containing the "master"
event + the exception, right ?

What will this request look like in your model ?

Will it be:

BEGIN:VCALENDAR
METHOD:REQUEST
...
BEGIN:VEVENT
UID:that
SEQUENCE:1
DTSTART: monday the 1st at 10am
*RRULE: every monday forever*
ATTENDEE: bob
ATTENDEE:arnaud
END:VEVENT
BEGIN:VEVENT
UID:that
SEQUENCE:1
RECURRENCE-ID: monday the 8th at 10am
DTSTART: tuesday the 9th at 10am
ATTENDEE:bob
ATTENDEE:arnaud
END:VEVENT
END:VCALENDAR

or will it be:

BEGIN:VCALENDAR
BEGIN:VEVENT
UID:that
SEQUENCE:1
DTSTART: monday the 1st at 10am
*RRULE: every monday forever
RDATE: tuesday the 9th at 10am
EXDATE: monday the 8th at 10am*
ATTENDEE: bob
ATTENDEE:arnaud
END:VEVENT
BEGIN:VEVENT
UID:that
SEQUENCE:1
RECURRENCE-ID: monday the 8th at 10am
DTSTART: tuesday the 9th at 10am
ATTENDEE:bob
ATTENDEE:arnaud
END:VEVENT
END:VCALENDAR

Or did I totally missed the logic of iTIP and does he send something else ?

Thanks,

Arnaud

--Boundary_(ID_83e9+ab581aIPJMEfd9TIw)
Content-transfer-encoding: 7BIT
Content-type: text/html; charset=us-ascii

[Snip, snip]
--Boundary_(ID_83e9+ab581aIPJMEfd9TIw)--
Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005214FD85256D34_=-- From owner-ietf-calendar@mail.imc.org Wed May 28 11:22: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 LAA08128 for ; Wed, 28 May 2003 11:22: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 h4SF5WAF047734 for ; Wed, 28 May 2003 08:05: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 h4SF5WoJ047733 for ietf-calendar-bks; Wed, 28 May 2003 08:05: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SF5VAF047715 for ; Wed, 28 May 2003 08:05:31 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED3D929.4010901@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 28 May 2003 11:02:32 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/28/2003 11:05:31 AM, Serialize complete at 05/28/2003 11:05:31 AM Content-Type: multipart/alternative; boundary="=_alternative 00527B3385256D34_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00527B3385256D34_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/27/2003 05:31:21 PM: > I can not find ANY email from "Arnaud Quillaud". Could you please > post a link to the IMC site for this? And here is the 2nd posting he sent in reply to my reply to his first posting (the 2nd one I sent but #1 in the ordering), again sans HTML: Received: from e31.co.us.ibm.com ([9.14.4.129]) by ace.notesdev.ibm.com (Lotus Domino Build V602_05122003NP) with ESMTP id 2003052319595385-21118 for ; Fri, 23 May 2003 19:59:53 -0400 Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [205.159.212.202]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4NNxru9253464 for ; Fri, 23 May 2003 19:59:53 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by capricorn.iris.com (Lotus Domino Build V602_03262003NP) with ESMTP id 2003052319584589-24208 for ; Fri, 23 May 2003 19:58:45 -0400 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4NNxMYU017219; Fri, 23 May 2003 17:59:22 -0600 (MDT) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4NNxLuc027717; Fri, 23 May 2003 16:59:21 -0700 (PDT) Received: from ENG.SUN.COM (iabs-2k.red.iplanet.com [192.18.144.144]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with ESMTP id <0HFD00A0S6MXOT@mpkmail.eng.sun.com>; Fri, 23 May 2003 16:59:21 -0700 (PDT) Date: Fri, 23 May 2003 16:59:28 -0700 From: Arnaud Quillaud Subject: Re: Correct handling of Recurrence-id To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Message-id: <3ECEB5E0.6020504@ENG.SUN.COM> MIME-version: 1.0 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 References: X-MIMETrack: Itemize by SMTP Server on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at 05/23/2003 07:58:46 PM, Serialize by Router on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at 05/23/2003 07:58:46 PM, Serialize complete at 05/23/2003 07:58:46 PM, Itemize by SMTP Server on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 07:59:54 PM, Serialize by Notes Client on Bruce Kahn/Westford/IBM(Build V70_04022003NP|April 02, 2003) at 05/28/2003 10:59:13 AM, Serialize complete at 05/28/2003 10:59:13 AM Content-type: multipart/alternative; boundary="Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)" --Boundary_(ID_AaJntEE6BeSgWe5jsMypqw) Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Bruce_Kahn@notesdev.ibm.com wrote: > > Arnaud Quillaud wrote on 05/23/2003 02:49:21 PM: > > But what is the advantage of the opposite interpretation of the spec > > (changing RECURRENCE-ID over time) ? Or what are the disadvantages > > of fixed RECURRENCE-ID ? > > I thought I covered them already earlier today but Ill try to > resummarize the probelms with the 'delta' model: ... Sorry, I was probably not clear enough. My question was not aimed at you. Let me try to rephrase it: First, I think we all agree that the current RFCs are not crystal clear in that area, otherwise, we wouldn't have this interesting discussion. Then, I don't really like to use names, as this discussion is not just about 2 people arguing, but to be more clear, let's say we have the Bruce model on one hand and the Doug model on the other hand. You (Bruce) have been quite clear about why you think your model makes everybody's life easier, is the only one that truely works, etc... I would like to to hear now, from Doug or from others, why they think their model is simpler/better. There is probably some good reasons why they think we should go that way. It would help the debate if they could expose those reasons, just like you've exposed yours. Arnaud --Boundary_(ID_AaJntEE6BeSgWe5jsMypqw) Content-transfer-encoding: 7BIT Content-type: text/html; charset=us-ascii [Snip, snip] --Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)-- Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00527B3385256D34_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/27/2003 05:31:21 PM:
> I can not find ANY email from "Arnaud Quillaud". Could you please
> post a  link to the IMC site for this?
And here is the 2nd posting he sent in reply to my reply to his first posting (the 2nd one I sent but #1 in the ordering), again sans HTML:

Received: from e31.co.us.ibm.com ([9.14.4.129])
         by ace.notesdev.ibm.com (Lotus Domino Build V602_05122003NP)
         with ESMTP id 2003052319595385-21118
         for <Bruce_Kahn@notesdev.ibm.com> ;
         Fri, 23 May 2003 19:59:53 -0400
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [205.159.212.202])
                by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4NNxru9253464
                for <Bruce_Kahn@notesdev.ibm.com>; Fri, 23 May 2003 19:59:53 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43])
         by capricorn.iris.com (Lotus Domino Build V602_03262003NP)
         with ESMTP id 2003052319584589-24208
         for <Bruce_Kahn@notesdev.ibm.com> ;
         Fri, 23 May 2003 19:58:45 -0400
Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19])
                by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4NNxMYU017219;
                Fri, 23 May 2003 17:59:22 -0600 (MDT)
Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131])
                by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4NNxLuc027717;
                Fri, 23 May 2003 16:59:21 -0700 (PDT)
Received: from ENG.SUN.COM (iabs-2k.red.iplanet.com [192.18.144.144])
by mpkmail.eng.sun.com
(iPlanet Messaging Server 5.2 Patch 1 (built Apr  2 2002))
with ESMTP id <0HFD00A0S6MXOT@mpkmail.eng.sun.com>; Fri,
23 May 2003 16:59:21 -0700 (PDT)
Date: Fri, 23 May 2003 16:59:28 -0700
From: Arnaud Quillaud <Arnaud.Quillaud@Eng.Sun.COM>
Subject: Re: Correct handling of Recurrence-id
To: Bruce_Kahn@notesdev.ibm.com
Cc: ietf-calendar@imc.org
Message-id: <3ECEB5E0.6020504@ENG.SUN.COM>
MIME-version: 1.0
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826
References:
<OFCDB74C02.22104DB7-ON85256D2F.007434BC-85256D2F.007B6F03@notesdev.ibm.com>
X-MIMETrack: Itemize by SMTP Server on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at
05/23/2003 07:58:46 PM,
                Serialize by Router on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at
05/23/2003 07:58:46 PM,
                Serialize complete at 05/23/2003 07:58:46 PM,
                Itemize by SMTP Server on Ace/Iris(Build V602_05122003NP|May 12, 2003) at
05/23/2003 07:59:54 PM,
                Serialize by Notes Client on Bruce Kahn/Westford/IBM(Build V70_04022003NP|April
02, 2003) at 05/28/2003 10:59:13 AM,
                Serialize complete at 05/28/2003 10:59:13 AM
Content-type: multipart/alternative;
boundary="Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)"


--Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii; format=flowed

Bruce_Kahn@notesdev.ibm.com wrote:

>
> Arnaud Quillaud wrote on 05/23/2003 02:49:21 PM:
> > But what is the advantage of the opposite interpretation of the spec
> > (changing RECURRENCE-ID over time) ? Or what are the disadvantages
> > of fixed RECURRENCE-ID ?
>
> I thought I covered them already earlier today but Ill try to
> resummarize the probelms with the 'delta' model:

...
Sorry, I was probably not clear enough. My question was not aimed at you.
Let me try to rephrase it:
First, I think we all agree that the current RFCs are not crystal clear
in that area, otherwise, we wouldn't have this interesting discussion.
Then, I don't really like to use names, as this discussion is not just
about 2 people arguing, but to be more clear, let's say we have the
Bruce model on one hand and the Doug model on the other hand.
You (Bruce) have been quite clear about why you think your model makes
everybody's life easier, is the only one that truely works, etc...
I would like to to hear now, from Doug or from others, why they think
their model is simpler/better. There is probably some good reasons why
they think we should go that way. It would help the debate if they could
expose those reasons, just like you've exposed yours.

Arnaud

--Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)
Content-transfer-encoding: 7BIT
Content-type: text/html; charset=us-ascii

[Snip, snip]

--Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)--
Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00527B3385256D34_=-- From owner-ietf-calendar@mail.imc.org Wed May 28 11:31:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08608 for ; Wed, 28 May 2003 11:31: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 h4SF2LAF047230 for ; Wed, 28 May 2003 08: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 h4SF2LIU047229 for ietf-calendar-bks; Wed, 28 May 2003 08:02: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SF2IAF047201 for ; Wed, 28 May 2003 08:02:19 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED3D929.4010901@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 28 May 2003 11:00:02 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/28/2003 11:02:20 AM, Serialize complete at 05/28/2003 11:02:20 AM Content-Type: multipart/alternative; boundary="=_alternative 005240D985256D34_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005240D985256D34_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/27/2003 05:31:21 PM: > I can not find ANY email from "Arnaud Quillaud". Could you please > post a link to the IMC site for this? Here is the initial posting he sent last Friday too (again sans the HTML body part): Received: from e31.co.us.ibm.com ([9.14.4.129]) by ace.notesdev.ibm.com (Lotus Domino Build V602_05122003NP) with ESMTP id 2003052314494871-20712 for ; Fri, 23 May 2003 14:49:48 -0400 Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [205.159.212.202]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4NInou9253416 for ; Fri, 23 May 2003 14:49:50 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by capricorn.iris.com (Lotus Domino Build V602_03262003NP) with ESMTP id 2003052314484437-23842 for ; Fri, 23 May 2003 14:48:44 -0400 Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4NInELv008141; Fri, 23 May 2003 11:49:14 -0700 (PDT) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4NInEL0019362; Fri, 23 May 2003 11:49:14 -0700 (PDT) Received: from ENG.SUN.COM (iabs-2k.red.iplanet.com [192.18.144.144]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with ESMTP id <0HFC00AK7SA29J@mpkmail.eng.sun.com>; Fri, 23 May 2003 11:49:14 -0700 (PDT) Date: Fri, 23 May 2003 11:49:21 -0700 From: Arnaud Quillaud Subject: Re: Correct handling of Recurrence-id To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Message-id: <3ECE6D31.9050509@ENG.SUN.COM> MIME-version: 1.0 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 References: X-MIMETrack: Itemize by SMTP Server on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at 05/23/2003 02:48:44 PM, Serialize by Router on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at 05/23/2003 02:48:45 PM, Serialize complete at 05/23/2003 02:48:45 PM, Itemize by SMTP Server on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/23/2003 02:49:48 PM, Serialize by Notes Client on Bruce Kahn/Westford/IBM(Build V70_04022003NP|April 02, 2003) at 05/28/2003 10:56:52 AM, Serialize complete at 05/28/2003 10:56:52 AM Content-type: multipart/alternative; boundary="Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)" --Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g) Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Hello, The proponents of the fixed RECURRENCE-ID have explained in quite some details already why this seems like the right approach. But what is the advantage of the opposite interpretation of the spec (changing RECURRENCE-ID over time) ? Or what are the disadvantages of fixed RECURRENCE-ID ? I think we now all understand the proposed model. It would be great to now see _why _it might be the best approach. We have two interpretation of the RECURRENCE-ID: version 1: The RECURRENCE-ID is equal to the DTSTART of the instance as defined in the initial recurring component (that is, it is included in the recurrence set (RRULE + RDATE - EXRULE -EXDATE) in the SEQUENCE 0 recurring component). Or as Bruce puts it: "The RECURRENCE-ID is fixed and unchanging from the initial assigment of it and is used to uniquely identify the repeating entry no matter where it has been rescheduled to." version 2: The RECURRENCE-ID is equal to the DTSTART of the instance at a given time. When sending an iTIP REQUEST that corresponds to a change of DTSTART for a particular instance, the RECURRENCE-ID is equal to the previous value of the DTSTART. In any subsequent REQUEST, the RECURRENCE-ID is equal to the new DTSTART (that is, until the DTSTART is changed again). Hence, the RECURRENCE-ID identifying an instance might change over time. The only disadvantage of version 1 that I can think of is about someone joining the party while some rescheduling has already occured. Since the newcommer won't have the SEQUENCE: 0 of the recurrence set, he might interpret the set of RECURRENCE-ID differently. But maybe this is just because I don't understand what the right iTIP workflow is. Here is an example: initial REQUEST: BEGIN:VEVENT SEQUENCE:0 DTSTART: monday the 1st at 10am RRULE: every monday forever ATTENDEE: bob END:VEVENT changing the second instance to tuesday BEGIN:VEVENT SEQUENCE:1 RECURRENCE-ID: monday the 8th at 10am DTSTART: tuesday the 9th at 10am ATTENDEE:bob END:VEVENT Now, john joins the party. The organizer will send him a request containing the "master" event + the exception. What recurrence set (RRULE + RDATE + EXDATE + EXRULE) should the organizer send him ? Is it: RRULE: every monday forever RDATE: tuesday the 9th at 10am EXDATE: monday the 8th at 10am or should he send the initial recurrence set which was just: RRULE: every monday forever ? If it is the former, then, with option 1, we will have a RECURRENCE-ID that doesn't correspond to the recurrence set. If it is the later, then the recurrence set doesn't reflect the full list of instances. That said, this might just be a problem of definition of what the RECURRENCE-ID is. We might say that, as the recurrence set evolves, a particular RECURRENCE-ID might end up being part of the EXDATE. Anyway, this doesn't seem like a major problem. Arnaud --Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g) Content-transfer-encoding: 7BIT Content-type: text/html; charset=us-ascii [Snip, snip] --Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)-- Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005240D985256D34_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/27/2003 05:31:21 PM:
> I can not find ANY email from "Arnaud Quillaud". Could you please
> post a  link to the IMC site for this?
Here is the initial posting he sent last Friday too (again sans the HTML body part):

Received: from e31.co.us.ibm.com ([9.14.4.129])
         by ace.notesdev.ibm.com (Lotus Domino Build V602_05122003NP)
         with ESMTP id 2003052314494871-20712
         for <Bruce_Kahn@notesdev.ibm.com> ;
         Fri, 23 May 2003 14:49:48 -0400
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [205.159.212.202])
                by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4NInou9253416
                for <Bruce_Kahn@notesdev.ibm.com>; Fri, 23 May 2003 14:49:50 -0400
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
         by capricorn.iris.com (Lotus Domino Build V602_03262003NP)
         with ESMTP id 2003052314484437-23842
         for <Bruce_Kahn@notesdev.ibm.com> ;
         Fri, 23 May 2003 14:48:44 -0400
Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45])
                by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4NInELv008141;
                Fri, 23 May 2003 11:49:14 -0700 (PDT)
Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131])
                by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4NInEL0019362;
                Fri, 23 May 2003 11:49:14 -0700 (PDT)
Received: from ENG.SUN.COM (iabs-2k.red.iplanet.com [192.18.144.144])
by mpkmail.eng.sun.com
(iPlanet Messaging Server 5.2 Patch 1 (built Apr  2 2002))
with ESMTP id <0HFC00AK7SA29J@mpkmail.eng.sun.com>; Fri,
23 May 2003 11:49:14 -0700 (PDT)
Date: Fri, 23 May 2003 11:49:21 -0700
From: Arnaud Quillaud <Arnaud.Quillaud@Eng.Sun.COM>
Subject: Re: Correct handling of Recurrence-id
To: Bruce_Kahn@notesdev.ibm.com
Cc: ietf-calendar@imc.org
Message-id: <3ECE6D31.9050509@ENG.SUN.COM>
MIME-version: 1.0
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826
References:
<OF68B3F1E7.9ACB5A17-ON85256D2F.0058E7ED-85256D2F.0059341B@notesdev.ibm.com>
X-MIMETrack: Itemize by SMTP Server on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at
05/23/2003 02:48:44 PM,
                Serialize by Router on Capricorn/Iris(Build V602_03262003NP|March 26, 2003) at
05/23/2003 02:48:45 PM,
                Serialize complete at 05/23/2003 02:48:45 PM,
                Itemize by SMTP Server on Ace/Iris(Build V602_05122003NP|May 12, 2003) at
05/23/2003 02:49:48 PM,
                Serialize by Notes Client on Bruce Kahn/Westford/IBM(Build V70_04022003NP|April
02, 2003) at 05/28/2003 10:56:52 AM,
                Serialize complete at 05/28/2003 10:56:52 AM
Content-type: multipart/alternative;
boundary="Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)"


--Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii; format=flowed

Hello,

The proponents of the fixed RECURRENCE-ID have explained in quite some
details already why this seems like the right approach.
But what is the advantage of the opposite interpretation of the spec
(changing RECURRENCE-ID over time) ? Or what are the disadvantages of
fixed RECURRENCE-ID ? I think we now all understand the proposed model.
It would be great to now see _why _it might be the best approach.

We have two  interpretation of the RECURRENCE-ID:

version 1: The RECURRENCE-ID is equal to the DTSTART of the instance as
defined in the initial recurring component (that is, it is included in
the recurrence set (RRULE + RDATE - EXRULE -EXDATE) in the SEQUENCE 0
recurring component). Or as Bruce puts it: "The RECURRENCE-ID is fixed
and unchanging from the initial assigment of it and is used to uniquely
identify the repeating entry no matter where it has been rescheduled to."

version 2: The RECURRENCE-ID is equal to the DTSTART of the instance at
a given time. When sending an iTIP REQUEST that  corresponds to a change
of DTSTART for a particular instance, the RECURRENCE-ID is equal to the
previous value of the DTSTART. In any subsequent REQUEST, the
RECURRENCE-ID is equal to the new DTSTART (that is, until the DTSTART is
changed again). Hence, the RECURRENCE-ID identifying an instance might
change over time.

The only disadvantage of version 1 that I can think of is about someone
joining the party while some rescheduling has already occured. Since the
newcommer won't have the SEQUENCE: 0 of the recurrence set, he might
interpret the set of RECURRENCE-ID differently. But maybe this is just
because I don't understand what the right iTIP workflow is.
Here is an example:

initial REQUEST:

BEGIN:VEVENT
SEQUENCE:0
DTSTART: monday the 1st at 10am
RRULE: every monday forever
ATTENDEE: bob
END:VEVENT

changing the second instance to tuesday

BEGIN:VEVENT
SEQUENCE:1
RECURRENCE-ID: monday the 8th at 10am
DTSTART: tuesday the 9th at 10am
ATTENDEE:bob
END:VEVENT

Now, john joins the party. The organizer will send him a request
containing the "master" event + the exception.
What recurrence set (RRULE + RDATE + EXDATE + EXRULE) should the
organizer send him ? Is it:

RRULE: every monday forever
RDATE: tuesday the 9th at 10am
EXDATE: monday the 8th at 10am

or should he send the initial recurrence set which was just:

RRULE: every monday forever

?
If it is the former, then, with option 1, we will have a RECURRENCE-ID
that doesn't correspond to the recurrence set.
If it is the later, then the recurrence set doesn't reflect the full
list of instances.

That said, this might just be a problem of definition of what the
RECURRENCE-ID is. We might say that, as the recurrence set evolves, a
particular RECURRENCE-ID might end up being part of the EXDATE.

Anyway, this doesn't seem like a major problem.


Arnaud

--Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)
Content-transfer-encoding: 7BIT
Content-type: text/html; charset=us-ascii

[Snip, snip]

--Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)--
Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005240D985256D34_=-- From owner-ietf-calendar@mail.imc.org Wed May 28 11:36: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 LAA08799 for ; Wed, 28 May 2003 11: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 h4SFFkAF049089 for ; Wed, 28 May 2003 08:15: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 h4SFFk2R049088 for ietf-calendar-bks; Wed, 28 May 2003 08:15: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SFFjAF049083 for ; Wed, 28 May 2003 08:15:45 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED3DB7B.4020105@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 28 May 2003 11:13:35 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/28/2003 11:15:45 AM, Serialize complete at 05/28/2003 11:15:45 AM Content-Type: multipart/alternative; boundary="=_alternative 00537E5185256D34_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00537E5185256D34_= Content-Type: text/plain; charset="US-ASCII" Doug asked on 05/27/2003 05:41:15 PM: > What would be the point of the above object? > As it is a REQUEST, why not just create an object SEQUENCE: > that is what you want? What is the point of this? The point is that the REQUEST contains a full snapshot of the repeating entry set from my calendar in such a way that the invitee (Arnaud) can properly create it in his calendar and use the same UID/RECURRENCE-ID/SEQUENCE key values that I would so we can easily do workflow. Since we share the same keys we can match up instances correctly and not worry about phantom or incorrect bookings, etc. Using a higher SEQUENCE is not what I want. See below for why not. > Would it not be better to: > > BEGIN:VCALENDAR > METHOD:REQUEST > ... > BEGIN:VEVENT > UID:that > SEQUENCE:1 > DTSTART: monday the 1st at 10am > RRULE: every monday forever > EXDATE: monday the 8th at 10am > RDATE: tuesday the 9th at 10am > ATTENDEE: bob > ATTENDEE:arnaud > END:VEVENT > END:VCALENDAR Not unless you want to entirely invalidate all other REPLYs to all other instances that are NOT being rescheduled. PLUS you would have to now renegotiate SEQUENCE:1 responses from all other invitees (ok, only Bob in this case but so what). Only the 2nd instance changed so only it needs to be rev'd to SEQUENCE:1. The rest are still unchanged and as such should not be rev'd. Now, _could_ I rev to SEQUENCE:1 for all instances? Sure. But then why would I want to since it means I now have to repeat the entire process of negotation/workflow w/all the other invitees. Their REPLYs at SEQUENCE:0 would be 'old' and thus invalid. If you repeat this "just rev it and forget it" approach for multiple instances it makes workflow tedious at best and a deterance to using it at worst. Not a good idea if you want folks to actually use this is it? After all the 4th Monday has not changed yet Ive had to reREQUEST everyone 14 times because the 2nd and 3rd instances got rescheduled 5 times each (not including the rescheduling that they cause each other to have to do). Yuck! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00537E5185256D34_= Content-Type: text/html; charset="US-ASCII"
Doug asked on 05/27/2003 05:41:15 PM:
> What would be the point of the above object?
> As it is a REQUEST, why not just create an object SEQUENCE:<next>
> that is what you want? What is the point of this?
The point is that the REQUEST contains a full snapshot of the repeating entry set from my calendar in such a way that the invitee (Arnaud) can properly create it in his calendar and use the same UID/RECURRENCE-ID/SEQUENCE key values that I would so we can easily do workflow.   Since we share the same keys we can match up instances correctly and not worry about phantom or incorrect bookings, etc.

Using a higher SEQUENCE is not what I want.  See below for why not.

> Would it not be better to:
>
>     BEGIN:VCALENDAR
>     METHOD:REQUEST
>     ...
>     BEGIN:VEVENT
>     UID:that
>     SEQUENCE:1
>     DTSTART: monday the 1st at 10am
>     RRULE: every monday forever
>     EXDATE: monday the 8th at 10am
>     RDATE: tuesday the 9th at 10am
>     ATTENDEE: bob
>     ATTENDEE:arnaud
>     END:VEVENT
>     END:VCALENDAR
Not unless you want to entirely invalidate all other REPLYs to all other instances that are NOT being rescheduled.  PLUS you would have to now renegotiate SEQUENCE:1 responses from all other invitees (ok, only Bob in this case but so what).  
Only the 2nd instance changed so only it needs to be rev'd to SEQUENCE:1.  The rest are still unchanged and as such should not be rev'd.

Now, _could_ I rev to SEQUENCE:1 for all instances?  Sure.  But then why would I want to since it means I now have to repeat the entire process of negotation/workflow w/all the other invitees.  Their REPLYs at SEQUENCE:0 would be 'old' and thus invalid.  If you repeat this "just rev it and forget it" approach for multiple instances it makes workflow tedious at best and a deterance to using it at worst.  Not a good idea if you want folks to actually use this is it?  After all the 4th Monday has not changed yet Ive had to reREQUEST everyone 14 times because the 2nd and 3rd instances got rescheduled 5 times each (not including the rescheduling that they cause each other to have to do).  Yuck!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00537E5185256D34_=-- From owner-ietf-calendar@mail.imc.org Wed May 28 18: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 SAA26308 for ; Wed, 28 May 2003 18:06: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 h4SLloAF069157 for ; Wed, 28 May 2003 14:47: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 h4SLlo1D069156 for ietf-calendar-bks; Wed, 28 May 2003 14:47: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 h4SLlmAF069151 for ; Wed, 28 May 2003 14:47:49 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h4SLlhv3016963 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 28 May 2003 14:47:46 -0700 Message-ID: <3ED52E75.5010606@Royer.com> Date: Wed, 28 May 2003 15:47:33 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: Arnaud.Quillaud@Eng.Sun.COM Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050507060107080901040507" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050507060107080901040507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > In my example, I was talking about the case where the Organizer wants to > invite a totally new attendee to the whole serie, not just a particular > instance. That can be done without any RECURRENCE-ID updates. Simply send a REQUEST to the new ATTENDEE. There is NO requirement all all ATTENDEEs be notified so you do not incremnet the SEQUENCE number. You just send a copy of the existing object with the new ATTENDEEs added, to the new ATTENEES only. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050507060107080901040507 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjgyMTQ3MzNaMCMGCSqGSIb3DQEJBDEWBBQH K9DLnSabRg4h2ZFz08b1dnFO7zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAwBNGoycnp88A ojJVesFTlBjcBwDZBIsp3711BUwSr8teSvvy7SNmBP2dD5GOPKSa1S+7l7vhlRR2d5hIZyb5 8ZPUoHG8xKoF9VXR+LNFp5sBXPaY8wixVT6Zbl7Cm+5DxEpFi0czPRXyq/cy8FnHWWeli8LJ KLjOTlnEXB0kEzZzTGE8wMjeJLIw4vzQU9zEQMAY9hIyPhbuA8CBshjDL4MXJSC3Rp4Tlk1F 8bguCXjnuS/wOvHLr4IYyitgDowUzPS7f/S1c41VP2qw5qejSfqC5oG8peUgAVEA+xxC0aQV fww2BVGBzEvoCNLuBSkkeYy55D5A5KS1bZadO416AAAAAAAAAA== --------------ms050507060107080901040507-- From owner-ietf-calendar@mail.imc.org Wed May 28 18:16: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 SAA27474 for ; Wed, 28 May 2003 18:16: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 h4SLxdAF070221 for ; Wed, 28 May 2003 14:59: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 h4SLxd3O070219 for ietf-calendar-bks; Wed, 28 May 2003 14:59: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 h4SLxcAF070211 for ; Wed, 28 May 2003 14:59: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 h4SLxWv3017055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 28 May 2003 14:59:35 -0700 Message-ID: <3ED5313F.4040406@Royer.com> Date: Wed, 28 May 2003 15:59:27 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: Arnaud.Quillaud@Eng.Sun.COM Subject: Re: Correct handling of Recurrence-id (master object) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000200030108040304000204" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000200030108040304000204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > Now, Bruce wants to invite arnaud to _all _instances of the recurring > event. Arnaud has no information about this event in his CUA. So I'm > assuming Bruce will send him one iTIP request containing the "master" > event + the exception, right ? > > What will this request look like in your model ? Simply send the new REQUEST object that represents the current ORGANIZER view of the object with the new ATTENDEE added to the new ATTENDEEs only. It can be done with EXDATE/EXRULE or additional RRULE or RDATE properties. The METHOD:ADD can be used in a separate VCALENDAR object when details about the meetings (or whatever) can not be described in one object. Also, there is no requrement that all ATTENDEEs see the exact same object. That is you could send each ATTENDEE an object that only contains them in the ATTENDEE list. You could also send them an object that only contains the instances that they will be attendending or are invited to attend. It can be done with RRULE, RDATE, EXRULE and EXDATE. Only the ORGANIZER CUA would need to know when different objects are sent to various 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 --------------ms000200030108040304000204 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjgyMTU5MjdaMCMGCSqGSIb3DQEJBDEWBBS1 mFJACy8f65o/2vLLSgWPMLzoxDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYC8ctoUh8D9m wrS4DyFUbJ/iRSbHjA3Ee7S/baS96R9oxS0CVSO7QTwBxUEF/G9M7FhWDxRFDZeiJsCGZF/u BzOGaEp1Jskw8/7kqygqqvUJSJa+jwrFAC4CEKXXl6HxTXkkhFZFkLTHGG+8MSRyV5gTxUIh q+U4HxquEZdl+BH1fcmt7/3BR8JfkqhMNY+AY/GBPgpndWrNPoVKr5+Ar3d+00HGOwxjsWR0 18cZQr/Fj5e4P/atLUdnwI4YzrcjR9VVf0s9ZshszlT/4wqosCXKvTtW/TCAR/vdCEmbwboG ezKca+qkPZhtDFxeoRkBdIO5jNPhmvaKl2irYOHQZwAAAAAAAA== --------------ms000200030108040304000204-- From owner-ietf-calendar@mail.imc.org Wed May 28 18: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 SAA27783 for ; Wed, 28 May 2003 18: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 h4SM8LAF070818 for ; Wed, 28 May 2003 15:08: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 h4SM8LKJ070817 for ietf-calendar-bks; Wed, 28 May 2003 15:08: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 h4SM8JAF070810 for ; Wed, 28 May 2003 15:08: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 h4SM89v3017161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 28 May 2003 15:08:13 -0700 Message-ID: <3ED53344.2060804@Royer.com> Date: Wed, 28 May 2003 16:08:04 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: Arnaud.Quillaud@Eng.Sun.COM Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020301080307070407010303" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020301080307070407010303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > Arnaud Quillaud wrote on 05/23/2003 02:49:21 PM: > > Sorry, I was probably not clear enough. My question was not aimed at you. > Let me try to rephrase it: > First, I think we all agree that the current RFCs are not crystal clear > in that area, otherwise, we wouldn't have this interesting discussion. > Then, I don't really like to use names, as this discussion is not just > about 2 people arguing, but to be more clear, let's say we have the > Bruce model on one hand and the Doug model on the other hand. > You (Bruce) have been quite clear about why you think your model makes > everybody's life easier, is the only one that truely works, etc... > I would like to to hear now, from Doug or from others, why they think > their model is simpler/better. There is probably some good reasons why > they think we should go that way. It would help the debate if they could > expose those reasons, just like you've exposed yours. At any point in time when a CUA gets an existing UID with a SEQUENCE number '1' more than it has, then it just processes the object. At any point in time when a CUA gets an existing UID with a SEQUENCE number '2' or more than it has, then it MUST do a REFRESH as there is no way what so ever to known what a specific RECURRENCE-ID means if you do not have the current SEQUENCE. For all the ATTENDEE/CUA knows all of the original instances were canceled in the missing SEQUENCE object. You MUST do a REFRESH 100% of the time when your SEQUENCE number is more than '1' out of sync. No tracking of history required at all by the ATTENDEE. The ORGANIZERs CUA must keep track of who send REPLY objects for each SEQUENCE in both models. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020301080307070407010303 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjgyMjA4MDRaMCMGCSqGSIb3DQEJBDEWBBSD Q098iU8YZO3xr5Fzq0ly27CL7TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAX4pxbSewz5T2 LdUcIjfjjkz4bHZNSW77BZUF6NhNO0Izvyx6op4FslH4ST568Bn2XkIzVSjXTOpf48OCFJDT uCqYd2XYU3208Y5/cUYEZ5qI+QGnBhA+5QF6TZs1BiVb/ym5L3NtoxX9/xsq8IADMpb+d6SG Hz+74WKOY0oYkd0l8GZf0mGL2K2REYk2nbcAEMXftt1tcOGWIL02Ouef3XeWmGQuwavrQg13 jSqAj1PDj+nQRdxRp0VisX0IOLSMfYXdjjqDzSaJXVv4j2UkoaMzdSfEJzi8ODPR1xvxZOF3 EGFaiTdUyLSChAYQloR0GpaEIVaepS7LE9D6VGx/TQAAAAAAAA== --------------ms020301080307070407010303-- From owner-ietf-calendar@mail.imc.org Wed May 28 19:14: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 TAA29216 for ; Wed, 28 May 2003 19:14: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 h4SN2uAF072162 for ; Wed, 28 May 2003 16:02: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 h4SN2uip072161 for ietf-calendar-bks; Wed, 28 May 2003 16:02: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 h4SN2tAF072155 for ; Wed, 28 May 2003 16:02: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 h4SN2rv3017679 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 28 May 2003 16:02:56 -0700 Message-ID: <3ED54013.7070705@Royer.com> Date: Wed, 28 May 2003 17:02:43 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010000030005080507000903" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010000030005080507000903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug asked on 05/27/2003 05:41:15 PM: > > What would be the point of the above object? > > As it is a REQUEST, why not just create an object SEQUENCE: > > that is what you want? What is the point of this? > > The point is that the REQUEST contains a full snapshot of the repeating > entry set from my calendar in such a way that the invitee (Arnaud) can > properly create it in his calendar and use the same > UID/RECURRENCE-ID/SEQUENCE key values that I would so we can easily do > workflow. Since we share the same keys we can match up instances > correctly and not worry about phantom or incorrect bookings, etc. > > Using a higher SEQUENCE is not what I want. See below for why not. > > > Would it not be better to: > > > > BEGIN:VCALENDAR > > METHOD:REQUEST > > ... > > BEGIN:VEVENT > > UID:that > > SEQUENCE:1 > > DTSTART: monday the 1st at 10am > > RRULE: every monday forever > > EXDATE: monday the 8th at 10am > > RDATE: tuesday the 9th at 10am > > ATTENDEE: bob > > ATTENDEE:arnaud > > END:VEVENT > > END:VCALENDAR > > Not unless you want to entirely invalidate all other REPLYs to all other > instances that are NOT being rescheduled. PLUS you would have to now > renegotiate SEQUENCE:1 responses from all other invitees (ok, only Bob > in this case but so what). > Only the 2nd instance changed so only it needs to be rev'd to > SEQUENCE:1. The rest are still unchanged and as such should not be rev'd. > > Now, _could_ I rev to SEQUENCE:1 for all instances? Sure. But then why > would I want to since it means I now have to repeat the entire process > of negotation/workflow w/all the other invitees. Forcing all CUA to remember SEQUENCE:0 and all updated objects (new SEQUENCES) is less desirable and not the current RFC model. If you only alter/add/cancel 1 instance, then you are required to increment the SEQUENCE number. (iCAL 4.8.7.4 Sequence Number). It is NOT optional! The fact that it forces all ATTENDEEs to do another REPLY was discussed on this list and was accepted. So unless you are talking about some hypothetical next revision and not yet proposed iCal - that is just not the way the spec reads. > Their REPLYs at > SEQUENCE:0 would be 'old' and thus invalid. If you repeat this "just > rev it and forget it" approach for multiple instances it makes workflow > tedious at best and a deterance to using it at worst. Yes - A SEQUENCE:1 RECURRENCE-ID:x when is all you have is SEQUENCE:0 is invalid. Do a REFRESH and get SEQUENCE:1 > Not a good idea > if you want folks to actually use this is it? After all the 4th Monday > has not changed yet Ive had to reREQUEST everyone 14 times because the > 2nd and 3rd instances got rescheduled 5 times each (not including the > rescheduling that they cause each other to have to do). Yuck! We did discuss this problem on the list (pre-2445) and the consensus was you can create a smart CUA that notices what the differences and automate much of the work. But - yes. You must increment the SEQUENCE number and then the ATTENDEEs must then REPLY to the new REQUEST/SEQUENCE (automated or not). If ONE instance changes then the existing ATTTENDEEs MUST REPLY to that change. If not, how would they know to COUNTER if they wished. I could imagine an optimized CUA that could only send what effected each ATTENDEE to limit the amount of REQUESTs and REPLYs, however the spec says if the instances change, the SEQUENCE must be updated. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010000030005080507000903 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjgyMzAyNDNaMCMGCSqGSIb3DQEJBDEWBBQl PKqthgCXXULa9zXM/fItvKGzAjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEANvD6Ei/HXkOk JCp55ws1wTUxKZs0pncysNZM1hRcVFAfdfhgjJECYGkGmKerwQNzTYCjHFH2YgCOhqdw4ute F8I6xoyF9Nx1sXps5SA7WVfpEf84flyXqjCd7dkHDviuvcxE8aUI2l+Q3aLgFvmHZDKy6/Z6 85vt6jtfamhVGi+vA9DbBtEqqcr3ysYB4+2dCNagBklG0orKrzvVeOOln6apHRhGHzucxFsl XGe9LMa0ci1xG/VVDCRDKviqiL8j2E7pPlA+2updFXGUFsofrzP9gDrqkpz1Whoe97mbiliQ FMABKPG0rDeHLv+++zHyvSYeUv8eIRQb+f15/FI//AAAAAAAAA== --------------ms010000030005080507000903-- From owner-ietf-calendar@mail.imc.org Thu May 29 10:45: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 KAA06095 for ; Thu, 29 May 2003 10:45: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 h4TEWdAF035775 for ; Thu, 29 May 2003 07:32: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 h4TEWdWu035774 for ietf-calendar-bks; Thu, 29 May 2003 07:32:39 -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 h4TEWbAF035766 for ; Thu, 29 May 2003 07:32:37 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: New threaded list archive of our mailing list MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Thu, 29 May 2003 10:32:39 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 05/29/2003 10:32:39 AM, Serialize complete at 05/29/2003 10:32:39 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Bruce Kahn has always kept a really cool threaded list archive of our mailing list. I am now hosting it on my server. Right now, it's as of 5/23. I plan on making a current as possible via some agents. For now, I think you all will find it useful. Thanks Bruce for this database. http://server2.egenconsulting.com/ietf/ietfcns.nsf ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 From owner-ietf-calendar@mail.imc.org Thu May 29 11:56: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 LAA08222 for ; Thu, 29 May 2003 11:56: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 h4TFdHAF042022 for ; Thu, 29 May 2003 08:39: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 h4TFdG3N042021 for ietf-calendar-bks; Thu, 29 May 2003 08:39:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TFdFAF042015 for ; Thu, 29 May 2003 08:39:16 -0700 (PDT) (envelope-from acampi@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 210) id 941D51556B; Thu, 29 May 2003 17:39:07 +0200 (CEST) Date: Thu, 29 May 2003 17:39:07 +0200 From: Andrea Campi To: ietf-calendar@imc.org Cc: harrie@inet.it Subject: CAP-QUERY ABNF disagrees with examples Message-ID: <20030529153906.GF1699@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.4i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, a colleague just noticed the ABNF for CAL-QUERY (6.1.1) doesn't agree with examples elsewhere in the draft. In most (all?) cases the examples are right. - cap-factor = cap-colval SP cap-oper SP col-value / cap-colval SP "NOT LIKE" SP col-value / cap-colval SP "LIKE" SP col-value / cap-colval SP "IS NULL" / cap-colval SP "IS NOT NULL" / col-value SP "NOT IN" cap-colval" / col-value SP "IN" cap-colval" / "STATE()" "=" ( "BOOKED" / "UNPROCESSED" / "DELETED" ) But we always use STATE()='BOOKED' etc. (note the quotes around BOOKED. - cap-col = comp-name / comp-name "." cap-prop Shouldn't this be: cap-col = comp-name / comp-name "." cap-prop / cap-prop as the former forbids basic queries like: QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' END:VQUERY - the last example in 6.1.1.18 uses DELETE instead of DELETED: BEGIN:VQUERY QUERYID:Fetch UIDs of marked for delete VEVENTs and VTODOs QUERY:SELECT UID FROM VEVENT WHERE STATE() = 'DELETE' QUERY:SELECT UID FROM VTODO WHERE STATE() = 'DELETE' END:VQUERY Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu May 29 12:59: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 MAA10061 for ; Thu, 29 May 2003 12:59: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 h4TGYBAF043728 for ; Thu, 29 May 2003 09:34: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 h4TGYBSa043727 for ietf-calendar-bks; Thu, 29 May 2003 09:34:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TGYAAF043722 for ; Thu, 29 May 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 h4TGY7v3026484 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 29 May 2003 09:34:10 -0700 Message-ID: <3ED6367A.6070409@Royer.com> Date: Thu, 29 May 2003 10:34:02 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: Harrie Hazewinkel Subject: Re: CAP-QUERY ABNF disagrees with examples References: <20030529153906.GF1699@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080602050604080300020704" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080602050604080300020704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yes - thanks. I have updated the source and it will be in the next release of the draft. Andrea Campi wrote: > Hi, > > a colleague just noticed the ABNF for CAL-QUERY (6.1.1) doesn't > agree with examples elsewhere in the draft. In most (all?) cases > the examples are right. > > - cap-factor = cap-colval SP cap-oper SP col-value > / cap-colval SP "NOT LIKE" SP col-value > / cap-colval SP "LIKE" SP col-value > / cap-colval SP "IS NULL" > / cap-colval SP "IS NOT NULL" > / col-value SP "NOT IN" cap-colval" > / col-value SP "IN" cap-colval" > / "STATE()" "=" ( "BOOKED" > / "UNPROCESSED" > / "DELETED" ) > > But we always use STATE()='BOOKED' etc. (note the quotes around > BOOKED. > > - cap-col = comp-name > / comp-name "." cap-prop > > Shouldn't this be: > > cap-col = comp-name > / comp-name "." cap-prop > / cap-prop > > as the former forbids basic queries like: > > QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' > END:VQUERY > > - the last example in 6.1.1.18 uses DELETE instead of DELETED: > > BEGIN:VQUERY > QUERYID:Fetch UIDs of marked for delete VEVENTs and VTODOs > QUERY:SELECT UID FROM VEVENT WHERE STATE() = 'DELETE' > QUERY:SELECT UID FROM VTODO WHERE STATE() = 'DELETE' > END:VQUERY > > > Bye, > Andrea > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080602050604080300020704 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjkxNjM0MDJaMCMGCSqGSIb3DQEJBDEWBBTV WMjnVdGpPx9yA2rTloJSmIoBrzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAqdqezWZo5Nf+ GSYd7yorX1eZTQdemTXChMOs10jDV3Ki+rAS+x3hOzHjg918bfYoi08QOQLaiDoHlkC1v/jX zRTU2V32SRl/A0emJDH9X9oL47aDEkr8rPocn3Od9HQrJS8KNS/SCB4CzOmo/WO65FsgB2e0 3BDKJGMcxzZeI2Lw12jGS4Vulb7d8xZGTaTp+d0L34cI6GHY2joqfmS4jlk8VGj2r1U3J1o7 7Oh2uny4+EYOHfx4uK4DjwDupSkutift0CT0bXzDm5iRlUhazLJQEA4Fq4pAyAb8WUfaFZqf aNAfkLLLX1kVabWTbT1SdKfznfJUis+eNb9yv06EwQAAAAAAAA== --------------ms080602050604080300020704-- From owner-ietf-calendar@mail.imc.org Thu May 29 16:41: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 QAA18633 for ; Thu, 29 May 2003 16:41: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 h4TKRoAF056046 for ; Thu, 29 May 2003 13:27: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 h4TKRoj8056045 for ietf-calendar-bks; Thu, 29 May 2003 13:27: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TKRnAF056039 for ; Thu, 29 May 2003 13:27:49 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECFA001.8020005@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 29 May 2003 16:27:52 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/29/2003 04:27:52 PM, Serialize complete at 05/29/2003 04:27:52 PM Content-Type: multipart/alternative; boundary="=_alternative 00703BDC85256D35_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00703BDC85256D35_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 05/24/2003 12:38:25 PM: > > > > So RECURRENCE-ID is used in conjunction with UID and BEFORE SEQUENCE > > > > checking. Why? Simple: you have to find the right instance before > > you > > > > can check if the message is older, newer, etc.! > > > > > > Which was my point!? > > > > Your ordering of usage/evaluation is whats wrong. You totally missed > > the implication of Step 1. UID and RECURRENCE-ID are first used in > > combination to find a set and instance and THEN SEQUENCE is used. > > I missed no such thing. I was not responding to the order of or > combination of checking. Ok then I cannot seem to follow your argument about reassigning RECURRENCE-ID at all then. Help me out here. If UID/RECURRENCE-ID is the primary key for finding an instance of a repeating meeting then how can you find it the next time its rescheduled (ie: SEQUENCE is rev'd) since you claimed last week that RECURRENCE-ID is changed to the new DTSTART value when the instance is 'booked'?? If you change the key used to find the instance then how can you use it later on, especially if you missed 1 reschedule notice? Ive shown how it works in the fixed RECURRENCE-ID case last week but Ive yet to see the actual iTIP properties that would be sent in the delta case. Could you please demonstrate that?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00703BDC85256D35_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 05/24/2003 12:38:25 PM:
> >  > > So RECURRENCE-ID is used in conjunction with UID and BEFORE SEQUENCE
> >  > > checking.  Why?  Simple: you have to find the right instance before
> > you
> >  > > can check if the message is older, newer, etc.!
> >  >
> >  > Which was my point!?
> >
> > Your ordering of usage/evaluation is whats wrong.  You totally missed
> > the implication of Step 1.  UID and RECURRENCE-ID are first used in
> > combination to find a set and instance and THEN SEQUENCE is used.
>
> I missed no such thing. I was not responding to the order of or
> combination of checking.
Ok then I cannot seem to follow your argument about reassigning RECURRENCE-ID at all then.  Help me out here.

If UID/RECURRENCE-ID is the primary key for finding an instance of a repeating meeting then how can you find it the next time its rescheduled (ie: SEQUENCE is rev'd) since you claimed last week that RECURRENCE-ID is changed to the new DTSTART value when the instance is 'booked'??

If you change the key used to find the instance then how can you use it later on, especially if you missed 1 reschedule notice?  Ive shown how it works in the fixed RECURRENCE-ID case last week but Ive yet to see the actual iTIP properties that would be sent in the delta case.  Could you please demonstrate that??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00703BDC85256D35_=-- From owner-ietf-calendar@mail.imc.org Thu May 29 17:29: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 RAA20701 for ; Thu, 29 May 2003 17:29: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 h4TLIUAF057849 for ; Thu, 29 May 2003 14:18: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 h4TLIUbk057848 for ietf-calendar-bks; Thu, 29 May 2003 14:18: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 h4TLISAF057842 for ; Thu, 29 May 2003 14:18: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 h4TLIOv3028957 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 29 May 2003 14:18:29 -0700 Message-ID: <3ED67916.7000701@Royer.com> Date: Thu, 29 May 2003 15:18:14 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090005030001090304020300" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090005030001090304020300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 05/24/2003 12:38:25 PM: > > > > > So RECURRENCE-ID is used in conjunction with UID and BEFORE > SEQUENCE > > > > > checking. Why? Simple: you have to find the right instance > before > > > you > > > > > can check if the message is older, newer, etc.! > > > > > > > > Which was my point!? > > > > > > Your ordering of usage/evaluation is whats wrong. You totally missed > > > the implication of Step 1. UID and RECURRENCE-ID are first used in > > > combination to find a set and instance and THEN SEQUENCE is used. > > > > I missed no such thing. I was not responding to the order of or > > combination of checking. > > Ok then I cannot seem to follow your argument about reassigning > RECURRENCE-ID at all then. Help me out here. > > If UID/RECURRENCE-ID is the primary key for finding an instance of a > repeating meeting then how can you find it the next time its rescheduled > (ie: SEQUENCE is rev'd) since you claimed last week that RECURRENCE-ID > is changed to the new DTSTART value when the instance is 'booked'?? The key is UID/SEQUENCE/DTSTAMP/RECURENCE-ID. And the start time of any instance may be unique to that key. And the instance start time may be different per UID/SEQUENCE. That is 100% of all instance start times in SEQUENCE:0 may be 100% different in SEQUENCE:1. So an iCalendar CANCEL object with UID/SEQUENCE:5/DTSTART/RECURRENCE-ID:monday has NO meaning if you do not already have the UID/SEQUENCE:5 object. > If you change the key used to find the instance then how can you use it > later on, especially if you missed 1 reschedule notice? If your current (booked) SEQUENCE is '1'. Then RECURRENCE-ID in an iCalendar object that also has SEQUENCE:1 is the start time of the instance that matches the RECURRENCE-ID value for SEQUENCE:1. If your current (booked) SEQUENCE is '1'. And you get a CANCEL (or whatever) for a specific instance, and that CANCEL (or whatever) object has SEQUENCE:2, then you MUST do a REFRESH which will get you the entire SEQUENCE:2 object. Only then will you know what UID/SEQUENCE:2/DTSTART/RECURRENCE-ID instance is being canceled.. > Ive shown how > it works in the fixed RECURRENCE-ID case last week but Ive yet to see > the actual iTIP properties that would be sent in the delta case. Could > you please demonstrate that?? As far as 'delta'. The ORGANIZER sends out the latest copy with a new SEQUENCE when any of the relevant (as defined in 2445/2446) properties change. The CUAs then REPLY. You do not need to track 'delta's. If the CUA does not REPLY the ORGANIZER can re-send or ignore that fact. If later the SEQUENCE gets updated again, the ORGANIZER would send the SEQUENCE: object and the CUAs REPLY. The ORGANIZER adds instances with the ADD METHOD. Or by sending a new and complete iCalendar object(s) with the latest SEQUENCE. The ORGANIZER deletes instances with the CANCEL METHOD. You can send multiple BEGIN/END:VCALENDAR objects per mime object for complex ADD/CANCEL. You never need to track deltas. A CUA saves the latest SEQUENCE and applies ADDs and CANCELs to that. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090005030001090304020300 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjkyMTE4MTVaMCMGCSqGSIb3DQEJBDEWBBQL 0uo7v/tswOJkfAcFN4FS1MpSETBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAGmRDB/+4wIxB hNM4S0f4cLDYgI7IEzkkeSIkv3LJkpJorouSGu+5MRrLQwfTM7dQY55rTDwhqbCmykKKc9SY ahn1ynNcSCakgnOYzFcdHEo9c/mxdPrspFcuXUTbf100r54gJV8UHbowIrhGhORJniaA5BL5 Ac5N5FoTwfCnIdGhcULKOlUKk/mgAb86yuBkBNDDNFVyI90jYxMjLxlp7UQgoeHjW750j1iA nWq83ZIS9XFccsr7NsZI2Bwn1KHPYya8GVg/LGEDXv+m6Myo6QUEAmqiniNuekBPPg18NM2m HFpxZ9K27Tq3env4OgcucHkK1/7puxT/iFLTAC3HrwAAAAAAAA== --------------ms090005030001090304020300-- From owner-ietf-calendar@mail.imc.org Thu May 29 18:03: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 SAA22345 for ; Thu, 29 May 2003 18:03: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 h4TLpSAF059643 for ; Thu, 29 May 2003 14:51: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 h4TLpRLe059642 for ietf-calendar-bks; Thu, 29 May 2003 14:51:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TLpPAF059636 for ; Thu, 29 May 2003 14:51:26 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ECF9F9B.6080302@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 29 May 2003 17:29:09 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/29/2003 05:51:25 PM, Serialize complete at 05/29/2003 05:51:25 PM Content-Type: multipart/alternative; boundary="=_alternative 0075D83D85256D35_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075D83D85256D35_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 05/24/2003 12:36:43 PM: > > By current iTIP rules (prev. citations) why would Toms CUA know/have to > > do a REFRESH if it got a SEQUENCE:3 and it had a SEQUENCE:1 value. > > Because it says so in iTIP. I dont see anywhere in iTIP it says (paraphrasing) "If the SEQUENCE on a REQUEST is not just 1 value off from any existing one that the Invitee SHOULD / MUST send a "REFRESH" message to get the latest instance". If each iTIP REQUEST is the full snapshot of that instance then why would a CUA think that it needs to do a REFRESH if the SEQUENCE is only off by 2? So what if it missed the Thursday 12-Jun-03 REQUEST at SEQUENCE:2, the SEQUENCE:3 Friday is full and more recent!?! The only cases in iTIP that call out when a REFRESH SHOULD or MUST be sent are, Section 3.2.4 ADD: The "UID" must be that of the existing event. If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VEVENT". If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". Clearly this is not the case in the rescheduling examples we've used so far. Nor does it deal with the secondary key of SEQUENCE so I dont think you are referring to that bit. In checking Section 3.2.6 REFRESH I find: 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. There is no text or inference here as to exactly when a CUA would want to use a REFRESH. It could be driven by the CU themselves at any point (even if the UID/RECURRENCE-ID/SEQUENCE values match what the CU currently has!). It could be driven by some CUA logic that thinks "If the REQUEST SEQUENCE value is not exactly 1 higher than what I already have then do a REFRESH". However whats the use in that?? After all, the newer REQUEST with a higher SEQUENCE obsoletes the previous REQUESTs. From iTIP Section 2.1.5 Message Sequencing: 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. So, unless an ADD comes in for a non-existant UID or there is some pressing need / desire to issue a REFRESH I fail to see why a CUA would send one in the case we've been discussing. Since its clearly not an ADD case I really doubt that Tom or his CUA would want (certainly they do not NEED) to issue a REFRESH in response to the SEQUENCE:3 REQUEST. Given that SEQUENCE:3 obsoletes both SEQUENCE:0 thru SEQUENCE:1, why would Tom or his CUA do the REFRESH? The REQUEST that my CUA would send in response to the REFRESH would again use the same UID/RECURENCE-ID and a SEQUENCE:3 (the same that Tom JUST requested the REFRESH for). So what is he to do then? Issue another REFRESH?? Round and around we go... A REFRESH is not a magic bullet that can solve the fact that every time the UID/RECURRENCE-ID key changes the receiving CUA will treat the REQUEST like a NEW invitation rather than a rescheduling (per iTIP, Section 3.2.2.1 Rescheduling an Event). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0075D83D85256D35_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 05/24/2003 12:36:43 PM:
> > By current iTIP rules (prev. citations) why would Toms CUA know/have to
> > do a REFRESH if it got a SEQUENCE:3 and it had a SEQUENCE:1 value.
>
> Because it says so in iTIP.
I dont see anywhere in iTIP it says (paraphrasing) "If the SEQUENCE on a REQUEST is not just 1 value off from any existing one that the Invitee SHOULD / MUST send a "REFRESH" message to get the latest instance".  

If each iTIP REQUEST is the full snapshot of that instance then why would a CUA think that it needs to do a REFRESH if the SEQUENCE is only off by 2?  So what if it missed the Thursday 12-Jun-03 REQUEST at SEQUENCE:2, the SEQUENCE:3 Friday is full and more recent!?!  

The only cases in iTIP that call out when a REFRESH SHOULD or MUST be sent are, Section 3.2.4 ADD:

   The "UID" must be that of the existing event. If the "UID" property
  value in the "ADD" is not found on the recipient's calendar, then the
  recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
  updated with the latest version of the "VEVENT".  If an "Attendee"
  implementation does not support the "ADD" method it should respond
  with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".

Clearly this is not the case in the rescheduling examples we've used so far.  Nor does it deal with the secondary key of SEQUENCE so I dont think you are referring to that bit.

In checking Section 3.2.6 REFRESH I find:

   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.
There is no text or inference here as to exactly when a CUA would want to use a REFRESH.  It could be driven by the CU themselves at any point (even if the UID/RECURRENCE-ID/SEQUENCE values match what the CU currently has!).  It could be driven by some CUA logic that thinks "If the REQUEST SEQUENCE value is not exactly 1 higher than what I already have then do a REFRESH".  However whats the use in that??  After all, the newer REQUEST with a higher SEQUENCE obsoletes the previous REQUESTs.  

From iTIP Section 2.1.5 Message Sequencing:

   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.

  So, unless an ADD comes in for a non-existant UID or there is some pressing need / desire to issue a REFRESH I fail to see why a CUA would send one in the case we've been discussing.  Since its clearly not an ADD case I really doubt that Tom or his CUA would want (certainly they do not NEED) to issue a REFRESH in response to the SEQUENCE:3 REQUEST.  

  Given that SEQUENCE:3 obsoletes both SEQUENCE:0 thru SEQUENCE:1, why would Tom or his CUA do the REFRESH?   The REQUEST that my CUA would send in response to the REFRESH would again use the same UID/RECURENCE-ID and a SEQUENCE:3 (the same that Tom JUST requested the REFRESH for).  So what is he to do then?  Issue another REFRESH??  Round and around we go...

  A REFRESH is not a magic bullet that can solve the fact that every time the UID/RECURRENCE-ID key changes the receiving CUA will treat the REQUEST like a NEW invitation rather than a rescheduling (per iTIP, Section 3.2.2.1 Rescheduling an Event).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0075D83D85256D35_=-- From owner-ietf-calendar@mail.imc.org Thu May 29 18:24: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 SAA24358 for ; Thu, 29 May 2003 18:24: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 h4TMBJAF061506 for ; Thu, 29 May 2003 15:11: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 h4TMBJ8l061505 for ietf-calendar-bks; Thu, 29 May 2003 15:11: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TMBIAG061493 for ; Thu, 29 May 2003 15:11:19 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED5313F.4040406@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id (master object) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 29 May 2003 18:11:19 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/29/2003 06:11:16 PM, Serialize complete at 05/29/2003 06:11:16 PM Content-Type: multipart/alternative; boundary="=_alternative 0079B4BB85256D35_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079B4BB85256D35_= Content-Type: text/plain; charset="US-ASCII" Doug said on 05/28/2003 05:59:27 PM: > It can be done with EXDATE/EXRULE or additional RRULE or RDATE > properties. The METHOD:ADD can be used in a separate VCALENDAR > object when details about the meetings (or whatever) can not > be described in one object. Sorry to rain on your parade again but an ADD is NOT called for when inviting a new ATTENDEE. The ADD method is defined as: The "ADD" method allows the "Organizer" to add new instances to an existing event using a single ITIP message without redefining the entire recurring pattern. In the case of adding a totally new ATTENDEE, they do not have the "existing event" so ADD would be the WRONG method to use. In fact iTIP clearly rules that out: The "UID" must be that of the existing event. If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VEVENT". (I think the 'must' in line 1 should have been 'MUST' but thats just me...) > Also, there is no requrement that all ATTENDEEs see the exact same object. They do however need to see the same instance information such as DTSTART, DTEND, RDATE, RRULE, etc. Otherwise they are all using different repeating set definitions and thats BAD! They do not need to share the same ATTENDEE, COMMENT, etc properties though. > That is you could send each ATTENDEE an object that only contains them > in the ATTENDEE list. Yep. (Who says Doug and I never agree??...) > You could also send them an object that only > contains the instances that they will be attendending or are invited > to attend. Absolutely. There is NEVER a case in iTIP when we defined a case where REQUEST is used to inform an ATTENDEE about an event they are NOT invited to (party crashing aside). But Arnaud was asking about what iTIP object(s) would be sent to him to invite him to the entire set... > It can be done with RRULE, RDATE, EXRULE and EXDATE. Only > the ORGANIZER CUA would need to know when different objects are sent > to various ATTENDEEs. The Organzier CUA doesn't have to know anything about what was sent; just what to generate. It does not need to track the different iTIP objects that get sent out as they are supposed to be representative of the current view of the instance(s) involved. Once sent, the CUA has no need to keep track of the actual messages contents as it can easily rebuild it and resend it as necessary... If a CUA keeps copies of all iTIP messages sent to all ATTENDEEs in a repeating event then Id be more than a bit concerned about the bloating that would occur as rescheduling happens. I have yet to see any answers to my previous questions about what exact iTIP properties get sent to do resyncing in the model Doug advocates. Did I miss 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 0079B4BB85256D35_= Content-Type: text/html; charset="US-ASCII"
Doug said on 05/28/2003 05:59:27 PM:
> It can be done with EXDATE/EXRULE or additional RRULE or RDATE
> properties. The METHOD:ADD can be used in a separate VCALENDAR
> object when details about the meetings (or whatever) can not
> be described in one object.
Sorry to rain on your parade again but an ADD is NOT called for when inviting a new ATTENDEE.  The ADD method is defined as:

                 The "ADD" method allows the "Organizer" to add new
  instances to an existing event using a single ITIP message without
  redefining the entire recurring pattern.

In the case of adding a totally new ATTENDEE, they do not have the "existing event" so ADD would be the WRONG method to use.  In fact iTIP clearly rules that out:

   The "UID" must be that of the existing event. If the "UID" property
  value in the "ADD" is not found on the recipient's calendar, then the
  recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
  updated with the latest version of the "VEVENT".

(I think the 'must' in line 1 should have been 'MUST' but thats just me...)

> Also, there is no requrement that all ATTENDEEs see the exact same object.

They do however need to see the same instance information such as DTSTART, DTEND, RDATE, RRULE, etc.  Otherwise they are all using different repeating set definitions and thats BAD!  They do not need to share the same ATTENDEE, COMMENT, etc properties though.

> That is you could send each ATTENDEE an object that only contains them
> in the ATTENDEE list.

Yep.  (Who says Doug and I never agree??...)

>                       You could also send them an object that only
> contains the instances that they will be attendending or are invited
> to attend.

Absolutely.  There is NEVER a case in iTIP when we defined a case where REQUEST is used to inform an ATTENDEE about an event they are NOT invited to (party crashing aside).  

But Arnaud was asking about what iTIP object(s) would be sent to him to invite him to the entire set...  

>             It can be done with RRULE, RDATE, EXRULE and EXDATE. Only
> the ORGANIZER CUA would need to know when different objects are sent
> to various ATTENDEEs.
The Organzier CUA doesn't have to know anything about what was sent; just what to generate.  It does not need to track the different iTIP objects that get sent out as they are supposed to be representative of the current view of the instance(s) involved.  Once sent, the CUA has no need to keep track of the actual messages contents as it can easily rebuild it and resend it as necessary...

If a CUA keeps copies of all iTIP messages sent to all ATTENDEEs in a repeating event then Id be more than a bit concerned about the bloating that would occur as rescheduling happens.

I have yet to see any answers to my previous questions about what exact iTIP properties get sent to do resyncing in the model Doug advocates.  Did I miss 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 0079B4BB85256D35_=-- From owner-ietf-calendar@mail.imc.org Thu May 29 19:01: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 TAA26024 for ; Thu, 29 May 2003 19:01: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 h4TMr7AF062592 for ; Thu, 29 May 2003 15:53: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 h4TMr7aa062591 for ietf-calendar-bks; Thu, 29 May 2003 15:53: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 h4TMr6AF062586 for ; Thu, 29 May 2003 15:53: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 h4TMr4v3029854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 29 May 2003 15:53:07 -0700 Message-ID: <3ED68F47.40908@Royer.com> Date: Thu, 29 May 2003 16:52:55 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id (master object) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070308080405070103010906" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070308080405070103010906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug said on 05/28/2003 05:59:27 PM: > > It can be done with EXDATE/EXRULE or additional RRULE or RDATE > > properties. The METHOD:ADD can be used in a separate VCALENDAR > > object when details about the meetings (or whatever) can not > > be described in one object. > > Sorry to rain on your parade again but an ADD is NOT called for when > inviting a new ATTENDEE. The ADD method is defined as: > > The "ADD" method allows the "Organizer" to add new > instances to an existing event using a single ITIP message without > redefining the entire recurring pattern. True and the original example also did that: "Now, Bruce wants to invite arnaud to _all _instances of the recurring event. Arnaud has no information about this event in his CUA. So I'm assuming Bruce will send him one iTIP request containing the "master" event + the exception, right ? What will this request look like in your model ? " Yes - you can send them a REQUEST + 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 --------------ms070308080405070103010906 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjkyMjUyNTVaMCMGCSqGSIb3DQEJBDEWBBSz f5KCZfISvsGvhFHxZbJqTdPDGTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAWH070M+QaP58 om3eN4o/actuQ6+tVbA1qtd0kxmuDpCKoKqltRDXB470SLjkJqqq+LniXg9bk3Za/TJNVGfM tRRshvfTLxM+cafWG6ByjFOoP4JpK9+Oh+r0xX9dBDixRMu5q/RpN/NzAPACoHAVEzm3Bl9Z 9begGwGGDQjGiw+Og35OW9FtgIslv7Go7SH1HaNqqKUcFXQ3QAe6fiQ0s6OljUvJumIUyiR6 DZt4ErkK+qK70eF23Tmv33b1JJnNh1AmoJhEKV883lkL/gRpO7ehiz7pmdyI1IdtPBU8mF58 RwQ/Bcip6uJqqBGrxk4iZuZJhZp+pDSh9jb1PoiZkAAAAAAAAA== --------------ms070308080405070103010906-- From owner-ietf-calendar@mail.imc.org Thu May 29 19:11: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 SAA24357 for ; Thu, 29 May 2003 18:24: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 h4TMBJAF061499 for ; Thu, 29 May 2003 15:11: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 h4TMBJIE061498 for ietf-calendar-bks; Thu, 29 May 2003 15:11: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TMBIAF061493 for ; Thu, 29 May 2003 15:11:18 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP ABNF: queryc is only used in 1 command? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 29 May 2003 17:52:12 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/29/2003 06:11:15 PM, Serialize complete at 05/29/2003 06:11:15 PM Content-Type: multipart/alternative; boundary="=_alternative 0077F49D85256D35_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0077F49D85256D35_= Content-Type: text/plain; charset="US-ASCII" Unless I am mistaken I can only find 1 CAP command that uses the CAP-QL in the ABNF. That is the CREATE command. The way I got to this conclusion is by following the ABNF. I started with 6.1.1. CAL-QUERY Value Type: cal-query = "SELECT" SP cap-val SP "FROM" SP comp-name SP "WHERE" SP cap-expr / "SELECT" SP cap-cols SP "FROM" SP comp-name In looking for cal-query I find it used in the ABNF for, 8.33. RESTRICTION Property , 8.34. SCOPE Property and 8.26. QUERY property . The first 2 properties are part of VRIGHTs/VCARs and should be part of the ABNF of some command (I didnt trace up this tree though to be sure). I did however look at the ABNF for 8.26. QUERY property which says: query = "QUERY" other-params ":" cal-query CRLF In looking for references to query I only find a reference under 9.6. VQUERY Component: queryc = "BEGIN" ":" "VQUERY" CRLF queryprop "END" ":" "VCAR" CRLF queryprop = 1*( ; 'queryid' is OPTIONAL but MUST NOT occur ; more than once. If the "TARGET" property ; is supplied then the "QUERYID" property ; MUST BE supplied. ; queryid / target ; 'expand' is OPTIONAL but MUST NOT occur ; more than once. expand ; the following are OPTIONAL, and MAY occur ; more than once ; / name / other-props ; the following MUST occur at least once. ; / query ) So I looked for where queryc was used in CAP and I can only find 1 use of it in ANY command, the CREATE command in 10.1.4. CREATE Command : create-object = "BEGIN" ":" "VCALENDAR" CRLF ; If 'calprops' contain the "METHOD" property ; then this 'create-object' component MUST ; conform to [iTIP] restrictions. ; ; calprops MUST include 'create-cmd' ; calprops other-props 1*(create-comp) "END" ":" "VCALENDAR" CRLF ; NOTE: The 'VCALSTORE' component is not included in ; 'create-comp' as it is out of scope for CAP to create ; a new CS. ; create-comp = agendac / carc / queryc / timezonec / freebusyc / eventc / todoc / journalc / iana-comp / x-component So this makes me think that ALL OTHER CAP commands are unable to use VQUERYs. Clearly this is wrong but perhaps Im just not reading the ABNF properly. Anyone else see this? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... Warning: Dates in Calendar are closer than they appear. --=_alternative 0077F49D85256D35_= Content-Type: text/html; charset="US-ASCII"
Unless I am mistaken I can only find 1 CAP command that uses the CAP-QL in the ABNF.  That is the CREATE command.

The way I got to this conclusion is by following the ABNF.  I started with 6.1.1. CAL-QUERY Value Type:

  cal-query  = "SELECT"   SP   cap-val  SP
                       "FROM"     SP   comp-name SP
                       "WHERE"    SP   cap-expr

                     / "SELECT" SP cap-cols SP
                       "FROM"   SP comp-name
In looking for cal-query I find it used in the ABNF for, 8.33. RESTRICTION Property , 8.34. SCOPE Property  and 8.26. QUERY property .  The first 2 properties are part of VRIGHTs/VCARs and should be part of the ABNF of some command (I didnt trace up this tree though to be sure).  I did however look at the ABNF for 8.26. QUERY property which says:

query      = "QUERY" other-params ":" cal-query CRLF
In looking for references to query I only find a reference under 9.6. VQUERY Component:

queryc    =  "BEGIN" ":" "VQUERY" CRLF
            queryprop
            "END" ":" "VCAR" CRLF

queryprop = 1*(

         ; 'queryid' is OPTIONAL but MUST NOT occur
         ; more than once. If the "TARGET" property
         ; is supplied then the "QUERYID" property
         ; MUST BE supplied.
         ;
          queryid / target

         ; 'expand' is OPTIONAL but MUST NOT occur
         ; more than once.

          expand

         ; the following are OPTIONAL, and MAY occur
         ; more than once
         ;
         / name / other-props

         ; the following MUST occur at least once.
         ;
         / query

       )
So I looked for where queryc was used in CAP and I can only find 1 use of it in ANY command, the CREATE command in 10.1.4.  CREATE Command :

create-object = "BEGIN" ":" "VCALENDAR" CRLF
             ; If 'calprops' contain the "METHOD" property
             ; then this 'create-object' component MUST
             ; conform to [iTIP] restrictions.
             ;
             ; calprops MUST include 'create-cmd'
             ;
               calprops
               other-props
               1*(create-comp)
               "END" ":" "VCALENDAR" CRLF

             ; NOTE: The 'VCALSTORE' component is not included in
             ; 'create-comp' as it is out of scope for CAP to create
             ; a new CS.
             ;
create-comp = agendac / carc / queryc
              / timezonec / freebusyc
              / eventc / todoc / journalc
              / iana-comp / x-component

So this makes me think that ALL OTHER CAP commands are unable to use VQUERYs.  Clearly this is wrong but perhaps Im just not reading the ABNF properly.  Anyone else see this?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Warning: Dates in Calendar are closer than they appear. --=_alternative 0077F49D85256D35_=-- From owner-ietf-calendar@mail.imc.org Thu May 29 19: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 TAA26987 for ; Thu, 29 May 2003 19: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 h4TNCJAF063547 for ; Thu, 29 May 2003 16:12: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 h4TNCJ1L063546 for ietf-calendar-bks; Thu, 29 May 2003 16:12: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TNCIAF063538 for ; Thu, 29 May 2003 16:12:18 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED53344.2060804@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 29 May 2003 18:52:33 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/29/2003 07:12:12 PM, Serialize complete at 05/29/2003 07:12:12 PM Content-Type: multipart/alternative; boundary="=_alternative 007D7AFB85256D35_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007D7AFB85256D35_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 05/28/2003 06:08:04 PM: > At any point in time when a CUA gets an existing UID with a SEQUENCE > number '1' more than it has, then it just processes the object. This must be your interpretation of iTIP. However I see NOTHING in iTIP that expressly says "1 more than it has" (even paraphrased)... > At any point in time when a CUA gets an existing UID with a SEQUENCE > number '2' or more than it has, then it MUST do a REFRESH as there > is no way what so ever to known what a specific RECURRENCE-ID > means if you do not have the current SEQUENCE. Umm, this sounds as if you need SEQUENCE to determine RECURRENCE-ID. At least thats how I take" to know what a sepcific RECURRENCE-ID means if you dont have the current SEQUENCE" because you are predicating the RECURRENCE-ID on a particular SEQUENCE value. Unfortunately this is contrary to iTIP which says: 2. The secondary key for referencing a component is the "SEQUENCE" property value. For components where the "UID" [and "RECURRENCE-ID" -BK] is the same, the component with the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values. That is, for any given UID/RECURRENCE-ID key the CUA then uses SEQUENCE to determine if the message is old or not. This does not say use UID to find an set of instances, then the SEQUENCE to see if I can use the RECURRENCE-ID and then RECURRENCE-ID to find the exact instance. This UID -> SEQUENCE -> RECURRENCE-ID behaviour also assumes that ALL instances share the same SEQUENCE value. That really sucks!! That means if I reschedule just 1 instance (thus reving SEQUENCE one higher) I MUST ignore all REPLYs (& COUNTERs) I get for _all other instances_ because the SEQUENCE value changed even though the instances in question did NOT change! Ugh!!! Talk about workflow thrashing/nightmares! > For all the ATTENDEE/CUA > knows all of the original instances were canceled in the missing SEQUENCE > object. You MUST do a REFRESH 100% of the time when your SEQUENCE number > is more than '1' out of sync. ONLY IF YOU SUBSCRIBE TO THE "DELTA" MODEL! Yet even doing a REFRESH 100% of the time does NOT SOLVE the problem. Here's why: 1: I invite Doug, George, Tom and Ki to SEQUENCE:0 to 3 Mondays in a row. 2: I then reschedule to 3 Wednesdays in a row and send a SEQUENCE:1 REQUEST to them. 3: I reschedule again to 3 Thursdays in a row and send a SEQUENCE:2 REQUEST to them. 4: I reschedule again to 3 Fridays in a row and send a SEQUENCE:3 REQUEST to them. There are at least 2 problems with this situation which are unrecoverable: A: If the REQUEST from Step 4 arrives before the REQUESTs from Steps 2&3 then Doug is going to have to send a REFRESH to me. I get it and send a new REQUEST at SEQUENCE:3. However if he gets this before the others arrive (or after only 1 other arrives) then what can he do with it? Nothing! He MUST send another REFRESH request. This will in turn cause another unusable (by Doug) REQUEST to be resent and the pattern keeps looping. B: If any single entry in the chain of reschedules NEVER arrives then there is NO way to recover it using a REFRESH. The REFRESH will cause my CUA to send a REQUEST that reflects the current view of the entry, NOT one that reflects any missing REQUEST. As such, NO MATTER HOW MANY REFRESHes get sent by Doug in response to missing SEQUENCE:2 (or 1), there is NO way to send the information Dougs CUA would need to rebuild the missing SEQUENCE (and thus missed RECURRENCE-ID) entry. iTIP clearly says how a REFRESH works: 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. [Emphasis mine] So if Doug missed SEQUENCE:2 (or 1) then he would send a REFRESH using the UID and RECURRENCE-ID from the SEQUENCE:3 REQUEST. I would in turn send back a REQUEST with the exact same UID/RECURRENCE-ID/SEQUENCE values (since I didnt reschedule it yet again). So, Doug now has 2 REQUESTs. However NEITHER are usable because there is missing SEQUENCE:2 (or 1) information. This is precisely why we decided that each iTIP object would be a full snapshot of the instance in question and why the key values of UID & RECURRENCE-ID MUST NOT change. There is no known way to recover! REFRESHes will NOT do it... This is also why we put the text in bullet #2 in 2.1.5 about higher SEQUENCE values for the same UID / RECURRENCE-ID pair "obsoletes all other revisions of the component with lower values.". So what if you missed 3 interim messages? The SEQUENCE:5 data for a given UID / RECURRENCE-ID is more recent than any of the prior SEQUENCE values! Since UID never changes for an entry or a repeat set and RECURRENCE-ID never changes for an instance in a set you can ALWAYS just discard ANY prior SEQUENCE entries and be happy! ALWAYS! > No tracking of history required at all by the ATTENDEE. For a delta model it absolutely is! Otherwise you yave no chance to rewrite the RECURRENCE-IDs as the SEQUENCE value changes so you can properly identify the instance in question. Also, what good is a REFRESH if its the 'latest' and you missed 2 or more REQUESTs?? (Your claim at top, not my misquoting of you...) > The ORGANIZERs CUA must keep track of who send REPLY objects > for each SEQUENCE in both models. And what good is that?? You were just saying that a REFRESH object was required when > 1 is missing. Reread that bit from REFRESH I highlighted above. Factor in that a REFRESH has NO SEQUENCE property in it and as such the Organzier would have no way to even know what SEQUENCE caused the Invitee to need a REFRESH! Now please explain to me what good it does my CUA to keep track of that info in this model. So the Organzier for some unclear reason keeps track of responses at each SEQUENCE level but I fail to see what use that is to know that Ki said hed come to SEQUENCE:0 and SEQUENCE:2. Im at SEQUENCE:3 now so whop-de-doo! ANY workflow from SEQUENCE values under 3 are stale and should be ignored! Your CUA could keep them around not every one finds bloating that useful. I may want to know that Ki did respond but to an older version but responses per old SEQUENCE?? Whatever floats your boat. Still, that had nothing to do with the workflow recovers in the model you espouse. Can you please show me how a REFRESH magically solves the case of a missed (or purposely deleted by the CU) entry in the chain? Perhaps George can chime back in and rephrse what Doug's said so that its clear. Or if someone else out there can show how everything gets resync'd properly when RECURRENCE-IDs change per SEQUENCE Im all eyes! Anyone??!! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007D7AFB85256D35_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 05/28/2003 06:08:04 PM:
> At any point in time when a CUA gets an existing UID with a SEQUENCE
> number '1' more than it has, then it just processes the object.
This must be your interpretation of iTIP.  However I see NOTHING in iTIP that expressly says "1 more than it has" (even paraphrased)...

> At any point in time when a CUA gets an existing UID with a SEQUENCE
> number '2' or more than it has, then it MUST do a REFRESH as there
> is no way what so ever to known what a specific RECURRENCE-ID
> means if you do not have the current SEQUENCE.

Umm, this sounds as if you need SEQUENCE to determine RECURRENCE-ID.  At least thats how I take" to know what a sepcific RECURRENCE-ID means if you dont have the current SEQUENCE" because you are predicating the RECURRENCE-ID on a particular SEQUENCE value.

Unfortunately this is contrary to iTIP which says:

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

That is, for any given UID/RECURRENCE-ID key the CUA then uses SEQUENCE to determine if the message is old or not.  

This does not say use UID to find an set of instances, then the SEQUENCE to see if I can use the RECURRENCE-ID and then RECURRENCE-ID to find the exact instance.  This UID -> SEQUENCE -> RECURRENCE-ID behaviour also assumes that ALL instances share the same SEQUENCE value.  That really sucks!!  That means if I reschedule just 1 instance (thus reving SEQUENCE one higher) I MUST ignore all REPLYs (& COUNTERs) I get for _all other instances_ because the SEQUENCE value changed even though the instances in question did NOT change!  Ugh!!!  Talk about workflow thrashing/nightmares!

>                                                    For all the ATTENDEE/CUA
> knows all of the original instances were canceled in the missing SEQUENCE
> object. You MUST do a REFRESH 100% of the time when your SEQUENCE number
> is more than '1' out of sync.
ONLY IF YOU SUBSCRIBE TO THE "DELTA" MODEL!   Yet even doing a REFRESH 100% of the time does NOT SOLVE the problem.  Here's why:

1: I invite Doug, George, Tom and Ki to SEQUENCE:0 to 3 Mondays in a row.
2: I then reschedule to 3 Wednesdays in a row and send a SEQUENCE:1 REQUEST to them.
3: I reschedule again to 3 Thursdays in a row and send a SEQUENCE:2 REQUEST to them.
4: I reschedule again to 3 Fridays in a row and send a SEQUENCE:3 REQUEST to them.

There are at least 2 problems with this situation which are unrecoverable:

A: If the REQUEST from Step 4 arrives before the REQUESTs from Steps 2&3 then Doug is going to have to send a REFRESH to me.  I get it and send a new REQUEST at SEQUENCE:3.  However if he gets this before the others arrive (or after only 1 other arrives) then what can he do with it?  Nothing!  He MUST send another REFRESH request.  This will in turn cause another unusable (by Doug) REQUEST to be resent and the pattern keeps looping.

B: If any single entry in the chain of reschedules NEVER arrives then there is NO way to recover it using a REFRESH.  The REFRESH will cause my CUA to send a REQUEST that reflects the current view of the entry, NOT one that reflects any missing REQUEST.  As such, NO MATTER HOW MANY REFRESHes get sent by Doug in response to missing SEQUENCE:2 (or 1), there is NO way to send the information Dougs CUA would need to rebuild the missing SEQUENCE (and thus missed RECURRENCE-ID) entry.

iTIP clearly says how a REFRESH works:

                               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.

[Emphasis mine]  So if Doug missed SEQUENCE:2 (or 1) then he would send a REFRESH using the UID and RECURRENCE-ID from the SEQUENCE:3 REQUEST.  I would in turn send back a REQUEST with the exact same UID/RECURRENCE-ID/SEQUENCE values (since I didnt reschedule it yet again).  So, Doug now has 2 REQUESTs.  However NEITHER are usable because there is missing SEQUENCE:2 (or 1) information.

This is precisely why we decided that each iTIP object would be a full snapshot of the instance in question and why the key values of UID & RECURRENCE-ID MUST NOT change.  There is no known way to recover!  REFRESHes will NOT do it...  

This is also why we put the text in bullet #2 in 2.1.5 about higher SEQUENCE values for the same UID / RECURRENCE-ID pair "obsoletes all other revisions of the component with lower values.".  So what if you missed 3 interim messages?  The SEQUENCE:5 data for a given UID / RECURRENCE-ID is more recent than any of the prior SEQUENCE values!  

Since UID never changes for an entry or a repeat set and RECURRENCE-ID never changes for an instance in a set you can ALWAYS just discard ANY prior SEQUENCE entries and be happy!  ALWAYS!

> No tracking of history required at all by the ATTENDEE.
For a delta model it absolutely is!  Otherwise you yave no chance to rewrite the RECURRENCE-IDs as the SEQUENCE value changes so you can properly identify the instance in question.

Also, what good is a REFRESH if its the 'latest' and you missed 2 or more REQUESTs?? (Your claim at top, not my misquoting of you...)

> The ORGANIZERs CUA must keep track of who send REPLY objects
> for each SEQUENCE in both models.
And what good is that??  You were just saying that a REFRESH object was required when > 1 is missing. Reread that bit from REFRESH I highlighted above.  Factor in that a REFRESH has NO SEQUENCE property in it and as such the Organzier would have no way to even know what SEQUENCE caused the Invitee to need a REFRESH!  Now please explain to me what good it does my CUA to keep track of that info in this model.

So the Organzier for some unclear reason keeps track of responses at each SEQUENCE level but I fail to see what use that is to know that Ki said hed come to SEQUENCE:0 and SEQUENCE:2.  Im at SEQUENCE:3 now so whop-de-doo!  ANY workflow from SEQUENCE values under 3 are stale and should be ignored!  Your CUA could keep them around not every one finds bloating that useful.  I may want to know that Ki did respond but to an older version but responses per old SEQUENCE??  Whatever floats your boat.

Still, that had nothing to do with the workflow recovers in the model you espouse.  Can you please show me how a REFRESH magically solves the case of a missed (or purposely deleted by the CU) entry in the chain?  Perhaps George can chime back in and rephrse what Doug's said so that its clear.  Or if someone else out there can show how everything gets resync'd properly when RECURRENCE-IDs change per SEQUENCE Im all eyes!  Anyone??!!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007D7AFB85256D35_=-- From owner-ietf-calendar@mail.imc.org Thu May 29 19:44: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 TAA27784 for ; Thu, 29 May 2003 19:44: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 h4TNSDAF063978 for ; Thu, 29 May 2003 16:28: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 h4TNSDwc063977 for ietf-calendar-bks; Thu, 29 May 2003 16:28:13 -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 h4TNSCAF063971 for ; Thu, 29 May 2003 16:28:12 -0700 (PDT) (envelope-from cjohnson@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Thu, 29 May 2003 17:27:24 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 29 May 2003 17:27:08 -0600 From: "Craig Johnson" To: Subject: Default TARGET Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__NextPart_0__=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__NextPart_0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In the current draft the ABNF for TARGET indicates it is optional. From Section 2: ; These are optional, and may occur more ; than once. ; target / other-props )This definition allows TARGET to be absent from commands where it is not needed (GET-CAPABILITY, GENERATE-UID, etc.). The definition also allows TARGET to be absent when a TARGET might be expected (CREATE, SEARCH, DELETE, MODIFY). Nothing in the draft requires TARGET to be present for these commands; but without a TARGET these commands are useless. Taking advantage of this... it would be convenient in the absence of a TARGET to infer the current authenticated UPN as the TARGET (if the UPN maps to a calendar on the CS). Doing so facilitates a common CUA / CS interaction: a user accessing his own calendar. For example: suppose at the beginning of my workday I authenticate through my CUA to my CS as UserA. Subsequently, my CUA might issue a series of interactions to obtain current calendar information: Begin:VCalendar Version:2.0 Prodid://SomeCUA Cmd;id=GetTodaysAppts:Search Begin:VQuery . . . End:VQuery End:VCalendar Since there is no TARGET, the CS would assume TARGET:UserA. Ensuing CAP operations (CREATE, DELETE, etc) could also make this assumption. We have implemented this behavior in a preliminary CAP implementation and found it to be useful and convenient. How does the working group feel about defaulting the TARGET in this manner? Or should TARGET always be explicit? Either way, the draft needs adjustment to clarify the issue. C Johnson --=__NextPart_0__= Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: 8bit

In the current draft the ABNF for TARGET indicates it is optional.  From Section 2:

 

   ; These are optional, and may occur more
   ; than once.
   ;
   target / other-props )

This definition allows TARGET to be absent from commands where it is not needed (GET-CAPABILITY, GENERATE-UID, etc.).  The definition also allows TARGET to be absent when a TARGET might be expected (CREATE, SEARCH, DELETE, MODIFY).  Nothing in the draft requires TARGET to be present for these commands; but without a TARGET these commands are useless.

 

Taking advantage of this...  it would be convenient in the absence of a TARGET to infer the current authenticated UPN as the TARGET (if the UPN maps to a calendar on the CS).  Doing so facilitates a common CUA / CS interaction: a user accessing his own calendar.  For example: suppose at the beginning of my workday I authenticate through my CUA to my CS as UserA.  Subsequently, my CUA might issue a series of interactions to obtain current calendar information:

 

   Begin:VCalendar

   Version:2.0

   Prodid://SomeCUA

   Cmd;id=GetTodaysAppts:Search

   Begin:VQuery

   . . .

   End:VQuery

   End:VCalendar

 

Since there is no TARGET, the CS would assume TARGET:UserA.  Ensuing CAP operations (CREATE, DELETE, etc) could also make this assumption.  We have implemented this behavior in a preliminary CAP implementation and found it to be useful and convenient.

 

How does the working group feel about defaulting the TARGET in this manner? Or should TARGET always be explicit?  Either way, the draft needs adjustment to clarify the issue.

 

C Johnson

--=__NextPart_0__=-- From owner-ietf-calendar@mail.imc.org Thu May 29 20:02: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 UAA28462 for ; Thu, 29 May 2003 20:02: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 h4TNiLAF064797 for ; Thu, 29 May 2003 16:44: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 h4TNiLdn064796 for ietf-calendar-bks; Thu, 29 May 2003 16:44: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-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TNiIAF064791 for ; Thu, 29 May 2003 16:44:20 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED54013.7070705@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 29 May 2003 19:20:14 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/29/2003 07:44:13 PM, Serialize complete at 05/29/2003 07:44:13 PM Content-Type: multipart/alternative; boundary="=_alternative 008003EB85256D35_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 008003EB85256D35_= Content-Type: text/plain; charset="US-ASCII" Doug fired back on 05/28/2003 07:02:43 PM: > > Now, _could_ I rev to SEQUENCE:1 for all instances? Sure. But then why > > would I want to since it means I now have to repeat the entire process > > of negotation/workflow w/all the other invitees. > > Forcing all CUA to remember SEQUENCE:0 and all updated objects (new > SEQUENCES) is less desirable and not the current RFC model. What does NOT reving SEQUENCE on all non-rescheduled entrys have to do with forcing CUAs to remember SEQUENCE:0? The entires have not been rescheduled so they are by definition at SEQUENCE:0. > If you only alter/add/cancel 1 instance, then you are required to increment > the SEQUENCE number. (iCAL 4.8.7.4 Sequence Number). It is NOT > optional! I agree. However you seem to think that SEQUENCE is shared among all instances! It is NOT! The reason it isnt is simple: Because if it were then rescheduling any 1 instance of a repeating set would invalidate the REPLYs (COUNTERs, etc) to ALL other instances! Why should all the REPLYs to Arnauds 1st Monday be invalidated because the 2nd Monday moved around?!?!? It should not be. Each instance has its own distinct set of properties. The only thing that they MUST all share is UID. Beyond that, each instance can have different SUMMARYs, DESCRIPTIONs, ATTENDEE lists, (certainly) DTSTART & DTEND, etc. Workflow on a single instance of a repeating set should have NO impact on any other instances in that set. If I cancel the 6th Monday, should I invalidate all REPLYs to the other Mondays? Since a CANCEL rev's SEQUENCE it certainly sounds like Doug thinks it should. > The fact that it forces all ATTENDEEs to do another REPLY > was discussed on this list and was accepted. Not sure which discussion you are referring to Doug given the 6+ year history of the list... Which one did we say that SEQUENCE is shared among all instances? > So unless you are talking about some hypothetical next revision > and not yet proposed iCal - that is just not the way the spec > reads. The spec conflicts as it is written now, not in some hypothetical or mytical versions. Recall: 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.The "RANGE" parameter is used to specify the effective range of recurrence instances from the instance specified by the "RECURRENCE-ID" property value. The default value for the range parameter is the single recurrence instance only. The value can also be "THISANDPRIOR" to indicate a range defined by the given recurrence instance and all prior instances or the value can be "THISANDFUTURE" to indicate a range defined by the given recurrence instance and all subsequent instances. Both paragraphs from 2445. The former describes a fixed RECURRENCE-ID. The latter describes a changing RECURRENCE-ID. Im claiming that the latter is residual from the early delta model we had in iCalendar and is wrong. Ive shown how but I have yet to see any proof to the contrary that it is correct and it works. > > Their REPLYs at > > SEQUENCE:0 would be 'old' and thus invalid. If you repeat this "just > > rev it and forget it" approach for multiple instances it makes workflow > > tedious at best and a deterance to using it at worst. > > Yes - A SEQUENCE:1 RECURRENCE-ID:x when is all you have is SEQUENCE:0 > is invalid. Do a REFRESH and get SEQUENCE:1 REFRESHes wont solve the problems of a delta model. For the 'delta' model you wont get the missing instance(s) data so you cannot rebuild the chain of reschedules. For the non-delta model you have no need to REFRESH; the UID/RECURRENCE-ID match and since by iTIP 2.1.5 rules SEQUENCE:1 obsoletes SEQUENCE:0 the receiver can just act on it. > We did discuss this problem on the list (pre-2445) and the consensus was > you can create a smart CUA that notices what the differences and > automate much of the work. But - yes. You must increment the SEQUENCE > number and then the ATTENDEEs must then REPLY to the new REQUEST/SEQUENCE > (automated or not). This is totally, 100% unnecessary to do if the RECURRENCE-ID stays fixed (like the UID does!). You must be looking at a discussion we had when we did have a delta model in the workflow. However as iTIP Section 2.1.5 shows thats NOT the case any more: the highest SEQUENCE for any given UID/RECURRENCE-ID wins, the rest are obsolete and thus ignorable/deletable. Also, this does not address the issue of a missed SEQUENCE where the RECURRENCE-ID gets rewritten. As Ive noted ad naseum already today, a new REQUEST will have the same UID/RECURRENCE-ID/SEQUENCE values on it (and just a newer DTSTAMP) and so by iTIP rules on message sequencing it would "overrides all others." There is no mention of filling in some missing SEQUENCE so that a new RECURRENCE-ID could be calculated to keep the invitees and the Organizer in sync. > they wished. I could imagine an optimized CUA that could only > send what effected each ATTENDEE to limit the amount of REQUESTs > and REPLYs, however the spec says if the instances change, > the SEQUENCE must be updated. The SEQUENCE for the instance, NOT the entire 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... Warning: Dates in Calendar are closer than they appear. --=_alternative 008003EB85256D35_= Content-Type: text/html; charset="US-ASCII"
Doug fired back on 05/28/2003 07:02:43 PM:
> > Now, _could_ I rev to SEQUENCE:1 for all instances?  Sure.  But then why
> > would I want to since it means I now have to repeat the entire process
> > of negotation/workflow w/all the other invitees.
>
> Forcing all CUA to remember SEQUENCE:0 and all updated objects (new
> SEQUENCES) is less desirable and not the current RFC model.
What does NOT reving SEQUENCE on all non-rescheduled entrys have to do with forcing CUAs to remember SEQUENCE:0?  The entires have not been rescheduled so they are by definition at SEQUENCE:0.

> If you only alter/add/cancel 1 instance, then you are required to increment
> the SEQUENCE number. (iCAL 4.8.7.4 Sequence Number). It is NOT
> optional!
I agree.  However you seem to think that SEQUENCE is shared among all instances!  It is NOT!  

The reason it isnt is simple: Because if it were then rescheduling any 1 instance of a repeating set would invalidate the REPLYs (COUNTERs, etc) to ALL other instances!

Why should all the REPLYs to Arnauds 1st Monday be invalidated because the 2nd Monday moved around?!?!?  It should not be.  Each instance has its own distinct set of properties.  The only thing that they MUST all share is UID.  Beyond that, each instance can have different SUMMARYs, DESCRIPTIONs, ATTENDEE lists, (certainly) DTSTART & DTEND, etc.  Workflow on a single instance of a repeating set should have NO impact on any other instances in that set.  

If I cancel the 6th Monday, should I invalidate all REPLYs to the other Mondays?  Since a CANCEL rev's SEQUENCE it certainly sounds like Doug thinks it should.

> The fact that it forces all ATTENDEEs to do another REPLY
> was discussed on this list and was accepted.
Not sure which discussion you are referring to Doug given the 6+ year history of the list...  Which one did we say that SEQUENCE is shared among all instances?

> So unless you are talking about some hypothetical next revision
> and not yet proposed iCal - that is just not the way the spec
> reads.
The spec conflicts as it is written now, not in some hypothetical or mytical versions.  Recall:

   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.The "RANGE" parameter is used to specify
  the effective range of recurrence instances from the instance
  specified by the "RECURRENCE-ID" property value. The default value
  for the range parameter is the single recurrence instance only. The
  value can also be "THISANDPRIOR" to indicate a range defined by the
  given recurrence instance and all prior instances or the value can be
  "THISANDFUTURE" to indicate a range defined by the given recurrence
  instance and all subsequent instances.

Both paragraphs from 2445.  The former describes a fixed RECURRENCE-ID.  The latter describes a changing RECURRENCE-ID.  Im claiming that the latter is residual from the early delta model we had in iCalendar and is wrong.  Ive shown how but I have yet to see any proof to the contrary that it is correct and it works.

> > Their REPLYs at
> > SEQUENCE:0 would be 'old' and thus invalid.  If you repeat this "just
> > rev it and forget it" approach for multiple instances it makes workflow
> > tedious at best and a deterance to using it at worst.
>
> Yes - A SEQUENCE:1 RECURRENCE-ID:x when is all you have is SEQUENCE:0
> is invalid. Do a REFRESH and get SEQUENCE:1
REFRESHes wont solve the problems of a delta model.  For the 'delta' model you wont get the missing instance(s) data so you cannot rebuild the chain of reschedules.  For the non-delta model you have no need to REFRESH; the UID/RECURRENCE-ID match and since by iTIP 2.1.5 rules SEQUENCE:1 obsoletes SEQUENCE:0 the receiver can just act on it.

> We did discuss this problem on the list (pre-2445) and the consensus was
> you can create a smart CUA that notices what the differences and
> automate much of the work. But - yes. You must increment the SEQUENCE
> number and then the ATTENDEEs must then REPLY to the new REQUEST/SEQUENCE
> (automated or not).
This is totally, 100% unnecessary to do if the RECURRENCE-ID stays fixed (like the UID does!).  You must be looking at a discussion we had when we did have a delta model in the workflow.  However as iTIP Section 2.1.5 shows thats NOT the case any more: the highest SEQUENCE for any given UID/RECURRENCE-ID wins, the rest are obsolete and thus ignorable/deletable.

Also, this does not address the issue of a missed SEQUENCE where the RECURRENCE-ID gets rewritten.  As Ive noted ad naseum already today, a new REQUEST will have the same UID/RECURRENCE-ID/SEQUENCE values on it (and just a newer DTSTAMP) and so by iTIP rules on message sequencing it would "overrides all others."  There is no mention of filling in some missing SEQUENCE so that a new RECURRENCE-ID could be calculated to keep the invitees and the Organizer in sync.

> they wished. I could imagine an optimized CUA that could only
> send what effected each ATTENDEE to limit the amount of REQUESTs
> and REPLYs, however the spec says if the instances change,
> the SEQUENCE must be updated.
The SEQUENCE for the instance, NOT the entire 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...
Warning: Dates in Calendar are closer than they appear.

--=_alternative 008003EB85256D35_=-- From owner-ietf-calendar@mail.imc.org Thu May 29 20:04: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 UAA28491 for ; Thu, 29 May 2003 20:04: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 h4TNctAF064663 for ; Thu, 29 May 2003 16:38: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 h4TNctIQ064662 for ietf-calendar-bks; Thu, 29 May 2003 16:38:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TNcsAF064657 for ; Thu, 29 May 2003 16:38: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 h4TNcnv3030278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 29 May 2003 16:38:54 -0700 Message-ID: <3ED699FD.9010101@Royer.com> Date: Thu, 29 May 2003 17:38:37 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080608090201010807060200" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080608090201010807060200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 05/28/2003 06:08:04 PM: > > At any point in time when a CUA gets an existing UID with a SEQUENCE > > number '1' more than it has, then it just processes the object. > > This must be your interpretation of iTIP. However I see NOTHING in iTIP > that expressly says "1 more than it has" (even paraphrased)... True - that text is not in iTIP. Are you suggesting that SEQUENCE never changes? > > At any point in time when a CUA gets an existing UID with a SEQUENCE > > number '2' or more than it has, then it MUST do a REFRESH as there > > is no way what so ever to known what a specific RECURRENCE-ID > > means if you do not have the current SEQUENCE. > > Umm, this sounds as if you need SEQUENCE to determine RECURRENCE-ID. You do. Otherwise there would be NO way to ever determin the intended start time for an instance you do no have. > At > least thats how I take" to know what a sepcific RECURRENCE-ID means if > you dont have the current SEQUENCE" because you are predicating the > RECURRENCE-ID on a particular SEQUENCE value. > > Unfortunately this is contrary to iTIP which says: No keep reading. > 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. > > That is, for any given UID/RECURRENCE-ID key the CUA then uses SEQUENCE > to determine if the message is old or not. And if it is old, what good is RECURRENCE-ID in a CANCEL for an object where SEQUENCE:0 -never- contained the start time with that value you wish to CANCEL? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080608090201010807060200 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MjkyMzM4MzdaMCMGCSqGSIb3DQEJBDEWBBQr T/53x1umJGhNse0zncy7d9xwCTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAQC3E5wtuUuNk njPT7ANwldgdUd6Wdge3N//QQIz7iKz9YJuGqCWeUc5LocknPWk9i3Hf4ACYaJ4wWhJ2llld +L4rTKJMMr09IRU+aTOpS452nd6qo+HDskRGkZCNHqWc9TWGHoIjeg6vsoT69ybHvnf8liuf O3jWYPyZl5O+ve0RC4nNNq4+WMEIuziZg219WXinoFcNkTBxDsAeKxIFFAw+7RLY3q5zGKgn 6TBnvXG6xZcPzzNbVlEnrrzjIgcztgREgNgP/N4FzCBefSN2nlrL5BttL1tF2f0m0k6J+uYX E7GNMVSPKSecPjMypjpCYV46yVC9CVsGXtfZt3cyKgAAAAAAAA== --------------ms080608090201010807060200-- From owner-ietf-calendar@mail.imc.org Thu May 29 20:39: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 UAA00242 for ; Thu, 29 May 2003 20:39: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 h4U0UJAF065956 for ; Thu, 29 May 2003 17:30: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 h4U0UJOA065955 for ietf-calendar-bks; Thu, 29 May 2003 17:30: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 h4U0UIAF065950 for ; Thu, 29 May 2003 17:30: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 h4U0UEv3030816 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 29 May 2003 17:30:19 -0700 Message-ID: <3ED6A603.8040603@Royer.com> Date: Thu, 29 May 2003 18:29:55 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.orietf- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Default TARGET References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090205020103080204010903" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090205020103080204010903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think it is a great idea. However I would like it to be "the 'UPN's default calendar" not not specifically say it must be named to match the UPN. This makes virtual hosting easier. Example: UPN: Doug@Royer.com CALID: Doug@Royer.com CAP://Royer.com/Doug@Royer.com A bit ugly? I may wish the UPN to be 'Doug@Royer.com' and yet have my calendar named 'Doug': UPN: Doug@Royer.com CALID: Doug CAP://Royer.com/Doug And depending on the implementations model of virtual hosting it may or might not allow 'Doug' to be overloaded across virtual hosts, per UPN within distinct domains. So could we say?: If TARGET is not supplied then the implied target is the currently authenticated UPN's default calendar. The name of any UPNs default calendar is an administrative and policy issue that is not defined in this memo. I also think this would make L10N CALID's easier when the UPN is expected to be the same as their MAILTO URL and then their CALID could still be their 8-bit localized name (url-ized to be a valid url). Craig Johnson wrote: > In the current draft the ABNF for TARGET indicates it is optional. From > Section 2: > ... > > How does the working group feel about defaulting the TARGET in this > manner? Or should TARGET always be explicit? Either way, the > draft needs adjustment to clarify the issue. > > > > C Johnson > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090205020103080204010903 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MzAwMDI5NTZaMCMGCSqGSIb3DQEJBDEWBBQN vZFjkDbSVwkg6FGhsBjjRisYSzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAGUg3sUrWqAgI G3cnnVX2PQ+EXiWu1q+f9AdAw9Er5KKo+FPMc3acfxSdEhaklp4FjDDcUAbYCJnAdFjA5B/e X378l4wbtZFOEexSxnxD3soDnkKqvY6x2XlwBVPnYmb06m9CcrjQ6znV+N8u3FY9JLbl4vGn vBQXtW3ZK+9aP/GMRF86TRQhijQi9Q7j/MGc4engXrvfjt4GwPdBq3lLagkszBfggXLfxkfY 8rEJgbru/3KLMTFg+Tq95HUiphiyOvgEI9Q/juXhYFw5QE0w//ufN7D/U0rTUn9bgzglNTRN HPSTALCksHfVJJhqBU8p84asLmYQC6806GWYcDVFZQAAAAAAAA== --------------ms090205020103080204010903-- From owner-ietf-calendar@mail.imc.org Fri May 30 16:08: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 QAA25789 for ; Fri, 30 May 2003 16:08: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 h4UJtJAF049901 for ; Fri, 30 May 2003 12:55: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 h4UJtIZb049900 for ietf-calendar-bks; Fri, 30 May 2003 12:55:18 -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 h4UJtHAF049895 for ; Fri, 30 May 2003 12:55:17 -0700 (PDT) (envelope-from ki.wong@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 h4UJtJYU004320; Fri, 30 May 2003 13:55:19 -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 h4UJtI6f016884; Fri, 30 May 2003 12:55:18 -0700 (PDT) Received: from J02K (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 SMTP id <0HFP00IXDU06KZ@ha13sca-mail1.sfbay.sun.com>; Fri, 30 May 2003 12:55:18 -0700 (PDT) Date: Fri, 30 May 2003 12:59:09 -0700 From: kiwong Subject: Fw: Correct handling of Recurrence-id To: Bruce_Kahn@notesdev.ibm.com, ietf-calendar@imc.org Message-id: <004001c326e5$eefd74a0$869012c0@dvd2kdom.red.iplanet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > Still, that had nothing to do with the workflow recovers in the model you > > espouse. Can you please show me how a REFRESH magically solves the case > > of a missed (or purposely deleted by the CU) entry in the chain? Perhaps > > George can chime back in and rephrse what Doug's said so that its clear. > > Or if someone else out there can show how everything gets resync'd > > properly when RECURRENCE-IDs change per SEQUENCE Im all eyes! Anyone??!! > > > Thanks you Bruce! You put in a lot of examples and did a in-depth analysis of why delta changes RECURRENCE-IDs is a bad thing and I agree with you 100%. So far, I also don't see a convincing example for the benefit of delta changes RECURRENCE-IDs, nor do I see how delta changes RECURRENCE-ID will work for Bruce's samples. Keeping the RECURRENCE-ID constant is straight-forward and easy to understand. Not only it guarantees workflow will work, but work efficiently. And it eliminates the whole mess of delta changes RECURRENCE-ID ambiguity. So can someone give us the reason why we shouldn't do it? Or can someone walk through a complete RRULE example like what Bruce has done and demonstrate how delta changes RECURRENCE-ID can achieve the same goal?? Just to add one more perspective to this, Microsoft Exchange 2000 iTIP/iMIP works with recurring instances with the model of RECURRENCE-IDs never change. I believe this is same for Notes. Bruce, can you confirm? If your product requires interoperability with them, delta changes RECURRENCE-ID will have nothing but headaches. ki From owner-ietf-calendar@mail.imc.org Fri May 30 16:31: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 QAA26838 for ; Fri, 30 May 2003 16:31: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 h4UKKPAF050563 for ; Fri, 30 May 2003 13:20: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 h4UKKPHW050562 for ietf-calendar-bks; Fri, 30 May 2003 13:20:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UKKOAF050557 for ; Fri, 30 May 2003 13:20:24 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <004001c326e5$eefd74a0$869012c0@dvd2kdom.red.iplanet.com> To: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_05212003NP May 21, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Fri, 30 May 2003 16:22:46 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/30/2003 04:20:11 PM, Serialize complete at 05/30/2003 04:20:11 PM Content-Type: multipart/alternative; boundary="=_alternative 006F741D85256D36_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F741D85256D36_= Content-Type: text/plain; charset="US-ASCII" The RNext notes uses iCalendar model were RECURRENCE-ID's never change. This will not change unless there is a VERY good argument to do so. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com kiwong Sent by: owner-ietf-calendar@mail.imc.org 05/30/2003 03:59 PM To Bruce_Kahn@notesdev.ibm.com, ietf-calendar@imc.org cc Subject Fw: Correct handling of Recurrence-id > > Still, that had nothing to do with the workflow recovers in the model you > > espouse. Can you please show me how a REFRESH magically solves the case > > of a missed (or purposely deleted by the CU) entry in the chain? Perhaps > > George can chime back in and rephrse what Doug's said so that its clear. > > Or if someone else out there can show how everything gets resync'd > > properly when RECURRENCE-IDs change per SEQUENCE Im all eyes! Anyone??!! > > > Thanks you Bruce! You put in a lot of examples and did a in-depth analysis of why delta changes RECURRENCE-IDs is a bad thing and I agree with you 100%. So far, I also don't see a convincing example for the benefit of delta changes RECURRENCE-IDs, nor do I see how delta changes RECURRENCE-ID will work for Bruce's samples. Keeping the RECURRENCE-ID constant is straight-forward and easy to understand. Not only it guarantees workflow will work, but work efficiently. And it eliminates the whole mess of delta changes RECURRENCE-ID ambiguity. So can someone give us the reason why we shouldn't do it? Or can someone walk through a complete RRULE example like what Bruce has done and demonstrate how delta changes RECURRENCE-ID can achieve the same goal?? Just to add one more perspective to this, Microsoft Exchange 2000 iTIP/iMIP works with recurring instances with the model of RECURRENCE-IDs never change. I believe this is same for Notes. Bruce, can you confirm? If your product requires interoperability with them, delta changes RECURRENCE-ID will have nothing but headaches. ki --=_alternative 006F741D85256D36_= Content-Type: text/html; charset="US-ASCII"
The RNext notes uses iCalendar model  were RECURRENCE-ID's never change.  This will not change unless there is a  VERY good argument to do so.

_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


kiwong <ki.wong@sun.com>
Sent by: owner-ietf-calendar@mail.imc.org

05/30/2003 03:59 PM

To
Bruce_Kahn@notesdev.ibm.com, ietf-calendar@imc.org
cc
Subject
Fw: Correct handling of Recurrence-id







> > Still, that had nothing to do with the workflow recovers in the model
you
> > espouse.  Can you please show me how a REFRESH magically solves the case
> > of a missed (or purposely deleted by the CU) entry in the chain?
Perhaps
> > George can chime back in and rephrse what Doug's said so that its clear.
> > Or if someone else out there can show how everything gets resync'd
> > properly when RECURRENCE-IDs change per SEQUENCE Im all eyes!
Anyone??!!
> >
>

Thanks you Bruce! You put in a lot of examples and did a in-depth analysis
of why delta changes RECURRENCE-IDs is a bad thing and I agree with you
100%.
So far, I also don't see a convincing example for the benefit of delta
changes
RECURRENCE-IDs, nor do I see how delta changes RECURRENCE-ID will work for
Bruce's samples.

Keeping the RECURRENCE-ID constant is straight-forward and easy to
understand. Not only it guarantees workflow will work, but work efficiently.
And it eliminates the whole mess of delta changes RECURRENCE-ID ambiguity.
So can someone
give us the reason why we shouldn't do it? Or can someone walk through a
complete RRULE
example like what Bruce has done and demonstrate how delta changes
RECURRENCE-ID can achieve the same goal??

Just to add one more perspective to this, Microsoft Exchange 2000 iTIP/iMIP
works with recurring instances with the model of RECURRENCE-IDs never
change. I believe
this is same for Notes. Bruce, can you confirm? If your product requires
interoperability with them,
delta changes RECURRENCE-ID will have nothing but headaches.

ki
--=_alternative 006F741D85256D36_=-- From owner-ietf-calendar@mail.imc.org Fri May 30 17:03: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 RAA28253 for ; Fri, 30 May 2003 17:03: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 h4UKs8AF051531 for ; Fri, 30 May 2003 13:54: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 h4UKs8iM051529 for ietf-calendar-bks; Fri, 30 May 2003 13:54: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 h4UKs6AF051522 for ; Fri, 30 May 2003 13:54: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 h4UKs5v3011207 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 30 May 2003 13:54:07 -0700 Message-ID: <3ED7C4E4.6020002@Royer.com> Date: Fri, 30 May 2003 14:53:56 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040101020202000503070701" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040101020202000503070701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > The RNext notes uses iCalendar model were RECURRENCE-ID's never change. > This will not change unless there is a VERY good argument to do so. So if SEQUENCE:1 changes 100% of all instances. Then SEQUENCE:2 trying to cancel one of the new (SEQUENCE:1 instances. You can't becaues you would have no idea what was being canceled if the RECURRENCE-ID refer to the SEQUENCE:0 instances. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040101020202000503070701 Content-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/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MzAyMDUzNTZaMCMGCSqGSIb3DQEJBDEWBBQt X2+lm5qVU7dGQ+d2CqMBKW4wajBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAbl8q4f+g/6qk +WH96ZWtXLQ20+TtyVNJiK9xuqf3klVx40doakPPesQRvhxui5atH9CfgmF7Zwmrbw0DPTnp znSr90QPsilveg0i5GynJzxtrOubdqk9J4/SpWbatzSuBjCc0nf/r76kZXSzF4668VyNwbjn g9I7Cwco/rxkbTmiST4JOvocpM+f/pbjMTFH4g4EKJxPtAejiBAhi5W5SK53EEtPsv094t6j TcHEFqojWS+eabgJ7+iIke36HDjN8e2I4gXH82B+Wu5+XfRmXA+XosYamBxoxbZ2yAKFAZh1 cz97T/065Fg//w1nMDMcJw43j69FckhAUWUkvymNkAAAAAAAAA== --------------ms040101020202000503070701--