From owner-ietf-calendar@mail.imc.org Mon Jun 9 18:50: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 SAA24599 for ; Mon, 9 Jun 2003 18:50: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 h59MbsAF007716 for ; Mon, 9 Jun 2003 15:37: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 h59Mbs48007715 for ietf-calendar-bks; Mon, 9 Jun 2003 15:37:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from [165.227.249.150] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59MbrAG007710 for ; Mon, 9 Jun 2003 15:37:53 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 9 Jun 2003 15:37:53 -0700 To: ietf-calendar@imc.org From: Paul Hoffman / IMC Subject: ADMINISTRIVIA: testing the mailing list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi again. Apparently the list is having some problems, so I am sending this message to goose it. (And, if you're one of the people who want to unsubscribe, *do not* reply to the mailing list; you can send mail to me directly.) --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-calendar@mail.imc.org Tue Jun 10 00:10: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 AAA00280 for ; Tue, 10 Jun 2003 00:10: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 h5A40bAF017849 for ; Mon, 9 Jun 2003 21:00:37 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5A40bmK017848 for ietf-calendar-bks; Mon, 9 Jun 2003 21:00:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5A40ZAF017840; Mon, 9 Jun 2003 21:00:36 -0700 (PDT) (envelope-from mark@WebServiceSolutions.com) Received: from lin.home2.mark (CPE0080c6e8c57c-CM014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 0F0354FE7; Tue, 10 Jun 2003 00:00:33 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Mark Swanson Organization: Web Service Solutions, Inc. To: Paul Hoffman / IMC , ietf-calendar@imc.org Subject: Re: ADMINISTRIVIA: testing the mailing list Date: Tue, 10 Jun 2003 00:03:13 -0400 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200306100003.13866.mark@WebServiceSolutions.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5A40aAF017842 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On June 9, 2003 6:37 pm, Paul Hoffman / IMC wrote: > Hi again. Apparently the list is having some problems, so I am > sending this message to goose it. The last email I received was on May 30. Is there a website that has the messages that weren't emailed to me? Thanks. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web start (JNLP): http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Tue Jun 10 10:51: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 KAA04133 for ; Tue, 10 Jun 2003 10:51: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 h5AEZcAF074429 for ; Tue, 10 Jun 2003 07:35:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5AEZcha074428 for ietf-calendar-bks; Tue, 10 Jun 2003 07:35:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from [165.227.249.150] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AEZZAG074419; Tue, 10 Jun 2003 07:35:35 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200306100003.13866.mark@WebServiceSolutions.com> References: <200306100003.13866.mark@WebServiceSolutions.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 10 Jun 2003 07:22:18 -0700 To: Mark Swanson , ietf-calendar@imc.org From: Paul Hoffman / IMC Subject: Re: ADMINISTRIVIA: testing the mailing list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:03 AM -0400 6/10/03, Mark Swanson wrote: >On June 9, 2003 6:37 pm, Paul Hoffman / IMC wrote: >> Hi again. Apparently the list is having some problems, so I am >> sending this message to goose it. > >The last email I received was on May 30. Is there a website that has the >messages that weren't emailed to me? No, that was the last message that was sent to the list. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-calendar@mail.imc.org Wed Jun 11 11:32: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 LAA13715 for ; Wed, 11 Jun 2003 11:31: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 h5BFBurb065958 for ; Wed, 11 Jun 2003 08:11: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 h5BFBudC065957 for ietf-calendar-bks; Wed, 11 Jun 2003 08:11:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BFBsrb065949 for ; Wed, 11 Jun 2003 08:11:55 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Wed, 11 Jun 2003 10:57:47 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/11/2003 11:11:49 AM, Serialize complete at 06/11/2003 11:11:49 AM Content-Type: multipart/alternative; boundary="=_alternative 0051E59985256D42_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0051E59985256D42_= Content-Type: text/plain; charset="US-ASCII" This never showed up in list so sending again. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com ----- Forwarded by Robert Ransdell/Westford/IBM on 06/11/2003 10:54 AM ----- Robert Ransdell/Westford/IBM 06/04/2003 10:47 AM To ietf-calendar@imc.org cc Subject Re: Fw: Correct handling of Recurrence-id iTip section 3.2.5 CANCEL "When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be incremented." IS A BUG. There use to TWO methods CANCEL and REMOVE. The CANCEL meaning all attendees bumped the sequence. The remove did not. These to methods were combined into CANCEL. The combined CANCEL method can not bump the sequence number. If I invite 5 people to a meeting ( John, Bob, Sally, Jane, George) with sequence 0. I than decide I do not need Sally to come so I send a Cancel just to Sally with Sally as the Attendee line. I can not bump sequence on the Cancel. If I do, I have just invalidated the responses from John, Bob, Jane and George. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 05/30/2003 04:53 PM Please respond to ietf-calendar@imc.org To "ietf-calendar@imc.org" cc Subject Re: Fw: Correct handling of Recurrence-id 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 --=_alternative 0051E59985256D42_= Content-Type: text/html; charset="US-ASCII"
This never showed up in list so sending again.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com
----- Forwarded by Robert Ransdell/Westford/IBM on 06/11/2003 10:54 AM -----
Robert Ransdell/Westford/IBM

06/04/2003 10:47 AM

To
ietf-calendar@imc.org
cc
Subject
Re: Fw: Correct handling of Recurrence-idLink




iTip section 3.2.5 CANCEL
"When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be incremented." IS A BUG.

There use to TWO methods CANCEL and REMOVE. The CANCEL meaning all attendees bumped the sequence.  The remove did not.  These to methods were combined into CANCEL.  The combined CANCEL method can not bump the sequence number.

 If I invite 5 people to a meeting ( John, Bob, Sally, Jane, George) with sequence 0.  I than decide I do not need Sally to come so I send a Cancel just to Sally with Sally as the Attendee line.   I can not bump sequence on the Cancel.  If I do,  I have just invalidated the responses from John, Bob, Jane and George.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

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







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
--=_alternative 0051E59985256D42_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 11 16:24: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 QAA14015 for ; Wed, 11 Jun 2003 16:24: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 h5BK5Trb084383 for ; Wed, 11 Jun 2003 13:05: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 h5BK5ToR084382 for ietf-calendar-bks; Wed, 11 Jun 2003 13:05: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 h5BK5Rrb084377 for ; Wed, 11 Jun 2003 13:05: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 h5BK5Lbt009633 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 11 Jun 2003 13:05:27 -0700 Message-ID: <3EE78B75.5050604@Royer.com> Date: Wed, 11 Jun 2003 14:05:09 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.orgietf- 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="------------ms090305080107050909030906" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090305080107050909030906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > iTip section 3.2.5 CANCEL > "When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be > incremented." IS A BUG. > > There use to TWO methods CANCEL and REMOVE. The CANCEL meaning all > attendees bumped the sequence. The remove did not. These to methods > were combined into CANCEL. The combined CANCEL method can not bump the > sequence number. > > If I invite 5 people to a meeting ( John, Bob, Sally, Jane, George) > with sequence 0. I than decide I do not need Sally to come so I send a > Cancel just to Sally with Sally as the Attendee line. I can not bump > sequence on the Cancel. If I do, I have just invalidated the responses > from John, Bob, Jane and George. When you say "I can not bump sequence on the Cancel", you really mean 'You do not want to bump the sequence on the cancel'. If you send a CANCEL to a select set of ATTENDEEs then their CUA may say 'what is this' (say their CUA crashed), so they then send a REFRESH for UID XX. What do you send them? The old object that is canceled? A copy of the CANCEL - for which they will then send you a REFRESH again because they do not have a copy. That is why the SEQUENCE MUST be bumped. Else you have to keep a copy or be able to re-construct and remember they ATTENDEEs a,b, and c only get a CANCEL when talking about UID 123,2188,1083,... If however you BUMP the SEQUENCE each time, then you do not have to remember anything. The latest copy is always the correct copy. If you CANCEL the VEVENT, you MUST bump the SEQUENCE so that it then becomes the latest copy of the object and everyone knows if they do a REFRESH, that they get the CANCEL and not the old object. The argument that you have to re-send REQUESTs to everyone has been debated on this list and the answer is YES. Option 1: There is no requirement that each ATTENDEE see the entire ATTENDEE list. That is each ATTENDEE can be sent a unique copy of the VEVENT, with only their ATTENDEE in the object. With this model you may then send that one ATTENDEE a CANCEL, there is NO problem with bumping the SEQUENCE number as the copy is unique to ATTENDEE. So it is not a BUG. Option 2: All or some (2 or more) of the ATTENDEEs may get objects that contain all or some (1 or more) of the other ATTENDEEs. In this case you MUST send each ATTENDEE in that list a new CANCEL object with a bumped SEQUENCE so they are all in sync. So not a bug. This was discussed on this CALSCH WG list and both iCal and iTIP were planned and released so that both models would work. The SEQUENCE number MUST BE bumped with a 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 --------------ms090305080107050909030906 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTEyMDA1MDlaMCMGCSqGSIb3DQEJBDEWBBTl 744qMHklelbtA4rHBUrKp+DMPTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAc1t8oTsDhkh5 mKD35/kH4Rar/HYkYUvz67aCc1UATPzxBe4C4fRz4oUNt2MLxqjURUo5AOgNialTRsMcLjkg S828XzzYa8U1z3UZpwZKda6risq7mmV5KpWoHMN52lOCbVNNh5ikGosZfXGHzX12HnEkrLXX pLmqxhkcupxlD3W5Kt6HYH/c3MUj76YL/mLSJcIL1r40LsFUNCXVN6+1s8SaJzFYAstsgDuV CDxfzWH97a0FA9jbSgy0Hk0efk3R44hXlXVjz6uEkA8zFK81dtgeh2agikNPnNdt/Omurnwz t5UpJgLZlUTURss9dWiZBGhv+macofLHyl0xNvDFIQAAAAAAAA== --------------ms090305080107050909030906-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 12:32: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 MAA17783 for ; Thu, 12 Jun 2003 12:32: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 h5CGCkrb069645 for ; Thu, 12 Jun 2003 09:12:46 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CGCkKI069642 for ietf-calendar-bks; Thu, 12 Jun 2003 09:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CGCjrb069634 for ; Thu, 12 Jun 2003 09:12:45 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EE78B75.5050604@Royer.com> MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Subject: Re: Fw: Correct handling of Recurrence-id To: Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 12 Jun 2003 12:04:29 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 12:12:18 PM, Serialize complete at 06/12/2003 12:12:18 PM Content-Type: multipart/alternative; boundary="=_alternative 0051681185256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0051681185256D43_= Content-Type: text/plain; charset="US-ASCII" That's bogus. NO NO NO. If I bump the sequence number for a givent RECUR-ID or a non repeating meeting. Than all responses prior to this SEQUENCE are invalid. The attendees must send a new accept/decline. However when you send a CANCEL to an individual, the other attendees are not sent any a reschedule. Thus they do not repsond. Refer to my original example. When I send a CANCEL to a select subset of the invitees, I am REMOVING them as attendees. I send the UNID and in the case of a repeating meeting the RECUR-ID (The initial date of this individual repeat item) and the current sequence number. The way the CANCEL is suppose to work is that if the SEQUENCE number of the CANCEL is greater than the invitees current sequence number than the item is canceled. The invitee removes it from his/her calendar. If the sequence number of the CANCEL is equal to the invitees current sequence number and the DTSTAMP is also greaterthan the item is canceled. The invitee removes it from his/her calendar. If the sequence number is less than the invitee would either ignore it as stale data or send back a Refresh request with the UNID and the RECUR-ID (initial date of this individual repeat item). The only way that a CANCEL would have a sequence number less that the sequence of the invitee, is when the invitee had been removed and than re-invited. The chair would send back the current data which would be the re-invite. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/11/2003 04:05 PM Please respond to ietf-calendar@imc.orgietf- To "ietf-calendar@imc.org" cc Subject Re: Fw: Correct handling of Recurrence-id Robert_Ransdell@notesdev.ibm.com wrote: > > iTip section 3.2.5 CANCEL > "When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be > incremented." IS A BUG. > > There use to TWO methods CANCEL and REMOVE. The CANCEL meaning all > attendees bumped the sequence. The remove did not. These to methods > were combined into CANCEL. The combined CANCEL method can not bump the > sequence number. > > If I invite 5 people to a meeting ( John, Bob, Sally, Jane, George) > with sequence 0. I than decide I do not need Sally to come so I send a > Cancel just to Sally with Sally as the Attendee line. I can not bump > sequence on the Cancel. If I do, I have just invalidated the responses > from John, Bob, Jane and George. When you say "I can not bump sequence on the Cancel", you really mean 'You do not want to bump the sequence on the cancel'. If you send a CANCEL to a select set of ATTENDEEs then their CUA may say 'what is this' (say their CUA crashed), so they then send a REFRESH for UID XX. What do you send them? The old object that is canceled? A copy of the CANCEL - for which they will then send you a REFRESH again because they do not have a copy. That is why the SEQUENCE MUST be bumped. Else you have to keep a copy or be able to re-construct and remember they ATTENDEEs a,b, and c only get a CANCEL when talking about UID 123,2188,1083,... If however you BUMP the SEQUENCE each time, then you do not have to remember anything. The latest copy is always the correct copy. If you CANCEL the VEVENT, you MUST bump the SEQUENCE so that it then becomes the latest copy of the object and everyone knows if they do a REFRESH, that they get the CANCEL and not the old object. The argument that you have to re-send REQUESTs to everyone has been debated on this list and the answer is YES. Option 1: There is no requirement that each ATTENDEE see the entire ATTENDEE list. That is each ATTENDEE can be sent a unique copy of the VEVENT, with only their ATTENDEE in the object. With this model you may then send that one ATTENDEE a CANCEL, there is NO problem with bumping the SEQUENCE number as the copy is unique to ATTENDEE. So it is not a BUG. Option 2: All or some (2 or more) of the ATTENDEEs may get objects that contain all or some (1 or more) of the other ATTENDEEs. In this case you MUST send each ATTENDEE in that list a new CANCEL object with a bumped SEQUENCE so they are all in sync. So not a bug. This was discussed on this CALSCH WG list and both iCal and iTIP were planned and released so that both models would work. The SEQUENCE number MUST BE bumped with a 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 --=_alternative 0051681185256D43_= Content-Type: text/html; charset="US-ASCII"
That's bogus.

NO NO NO.
If I bump the sequence number for a givent RECUR-ID or a non repeating meeting. Than all responses prior to this SEQUENCE are invalid.  The attendees must send a new accept/decline.  However when you send a CANCEL to an individual, the other attendees are not sent any a reschedule.  Thus they do not repsond.

Refer to my original example.  When I send a CANCEL to a select subset of the invitees, I am REMOVING them as attendees.  I send the UNID and in the case of a repeating meeting the RECUR-ID (The initial date of this individual repeat item) and the current sequence number.

The way the CANCEL is suppose to work is that if the SEQUENCE number of the CANCEL is greater than the invitees current sequence number than the item is canceled.  The invitee removes it from his/her calendar.
If the sequence number of the CANCEL is equal to the invitees current sequence number and the DTSTAMP is also greaterthan the item is canceled.  The invitee removes it from his/her calendar.

If the sequence number is less than the invitee would either ignore it as stale data or send back a Refresh request with the UNID and the RECUR-ID (initial date of this individual repeat item).  The only way that a CANCEL would have a sequence number less that the sequence of the invitee, is when the invitee had been removed and than re-invited.  The chair would send back the current data which would be the re-invite.



_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/11/2003 04:05 PM
Please respond to
ietf-calendar@imc.orgietf-
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: Fw: Correct handling of Recurrence-id







Robert_Ransdell@notesdev.ibm.com wrote:

>
> iTip section 3.2.5 CANCEL
> "When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
> incremented." IS A BUG.
>
> There use to TWO methods CANCEL and REMOVE. The CANCEL meaning all
> attendees bumped the sequence.  The remove did not.  These to methods
> were combined into CANCEL.  The combined CANCEL method can not bump the
> sequence number.
>
>  If I invite 5 people to a meeting ( John, Bob, Sally, Jane, George)
> with sequence 0.  I than decide I do not need Sally to come so I send a
> Cancel just to Sally with Sally as the Attendee line.   I can not bump
> sequence on the Cancel.  If I do,  I have just invalidated the responses
> from John, Bob, Jane and George.

When you say "I can not bump sequence on the Cancel", you really mean
'You do not want to bump the sequence on the cancel'.

If you send a CANCEL to a select set of ATTENDEEs then their
CUA may say 'what is this' (say their CUA crashed), so they
then send a REFRESH for UID XX. What do you send them? The old object
that is canceled? A copy of the CANCEL - for which they will then
send you a REFRESH again because they do not have a copy. That is
why the SEQUENCE MUST be bumped. Else you have to keep a copy or
be able to re-construct and remember they ATTENDEEs a,b, and c only
get a CANCEL when talking about UID 123,2188,1083,...

If however you BUMP the SEQUENCE each time, then you do not
have to remember anything. The latest copy is always the
correct copy.

If you CANCEL the VEVENT, you MUST bump the SEQUENCE so that
it then becomes the latest copy of the object and everyone
knows if they do a REFRESH, that they get the CANCEL and not
the old object.

The argument that you have to re-send REQUESTs to everyone
has been debated on this list and the answer is YES.

Option 1: There is no requirement that each ATTENDEE see the
entire ATTENDEE list. That is each ATTENDEE can be sent
a unique copy of the VEVENT, with only their ATTENDEE
in the object. With this model you may then send that
one ATTENDEE a CANCEL, there is NO problem with bumping
the SEQUENCE number as the copy is unique to ATTENDEE.
So it is not a BUG.


Option 2: All or some (2 or more) of the ATTENDEEs may get objects
that contain all or some (1 or more) of the other ATTENDEEs.
In this case you MUST send each ATTENDEE in that list a new
CANCEL object with a bumped SEQUENCE so they are all in sync.
So not a bug.

This was discussed on this CALSCH WG list and both iCal and iTIP
were planned and released so that both models would work.
The SEQUENCE number MUST BE bumped with a 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
--=_alternative 0051681185256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 13:41:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20466 for ; Thu, 12 Jun 2003 13:41:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CHOTrb072013 for ; Thu, 12 Jun 2003 10:24: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 h5CHOT1n072012 for ietf-calendar-bks; Thu, 12 Jun 2003 10:24: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 h5CHORrb072007 for ; Thu, 12 Jun 2003 10:24: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 h5CHOMbt020714 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 Jun 2003 10:24:28 -0700 Message-ID: <3EE8B735.2070009@Royer.com> Date: Thu, 12 Jun 2003 11:24: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: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070306040404020300070109" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070306040404020300070109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > That's bogus. > > NO NO NO. > If I bump the sequence number for a givent RECUR-ID or a non repeating > meeting. Than all responses prior to this SEQUENCE are invalid. YES - and they MUST re-reply. That is what this WG had decided in the iTIP debates. It is NOT optional. Make you CUA smart and notice that nothing changed that the user cared about and auto-reply. > The > attendees must send a new accept/decline. However when you send a > CANCEL to an individual, the other attendees are not sent any a > reschedule. Thus they do not repsond. Not always true, in some cases *ALL* ATTENDEEs see object with *ALL* other ATTENDEEs. So you model will break in that case as their copy of the object IS obsolete. > Refer to my original example. When I send a CANCEL to a select subset > of the invitees, I am REMOVING them as attendees. I send the UNID and > in the case of a repeating meeting the RECUR-ID (The initial date of > this individual repeat item) and the current sequence number. That is not per-spec. > The way the CANCEL is suppose to work is that if the SEQUENCE number of > the CANCEL is greater than the invitees current sequence number than the > item is canceled. The invitee removes it from his/her calendar. Yes. > If the sequence number of the CANCEL is equal to the invitees current > sequence number and the DTSTAMP is also greaterthan the item is > canceled. The invitee removes it from his/her calendar. No that is not what iTIP says (minus its typo): 4.2.10 Removing Attendees ... The original meeting includes "A", "B", "C", and "D". The example below shows the "CANCEL" that "A" sends to "B". Note that in the example below the "STATUS" property is omitted. This is used when the meeting itself is cancelled and not when the intent is to remove an "Attendee" from the Event. Except it has a typo, it should read: ...This is used when the meeting itself is not cancelled and when the intent is to remove an "Attendee" from the Event. So your original post did not CANCEL the event, it simply removed an ATTENDEE. To CANCEL the entire EVENT, bump the 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 --------------ms070306040404020300070109 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTIxNzI0MDVaMCMGCSqGSIb3DQEJBDEWBBQy ZorsTjffnpJQ6AVRMx/swSrhrDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAS34RGAue67z6 T1QFZvvObAySRbwYW171nJbd4SDnVM3xqsLEaavcI0sZ9h1NIHzCLhWOl1orHODM/VNaaUp7 h85Hd8FZtpJrap8qgIgCzLLMqHpJz2p/PeD2CaBp840KPAjKS/ptuRL11hULztJd028zrq4l dfT1oo2sAGsnp6EkXqR8su1jmwzATk9cfm6bYqH/ExXDHgGn+PNk78GStiudjBMVKb7wocGS Rdsq7BmbEoWgVmsKk1Ra1pU9pqtDPrTbL2xKWqwkf3M4d9EKRwWT179qyEqWiizMldkZfacn QgNDbcmXIa63UOZXr3C/DFZavgWENxiiu0E8S4/DBQAAAAAAAA== --------------ms070306040404020300070109-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 14:02: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 OAA21164 for ; Thu, 12 Jun 2003 14:02: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 h5CHjmrb072642 for ; Thu, 12 Jun 2003 10:45:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CHjmhA072641 for ietf-calendar-bks; Thu, 12 Jun 2003 10:45:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CHjjrb072636 for ; Thu, 12 Jun 2003 10:45:46 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EE8B735.2070009@Royer.com> To: ietf-calendar@imc.org Subject: Re: CANCEL and SEQUENCE usage MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 12 Jun 2003 13:45:44 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 01:45:15 PM, Serialize complete at 06/12/2003 01:45:15 PM Content-Type: multipart/alternative; boundary="=_alternative 006145ED85256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006145ED85256D43_= Content-Type: text/plain; charset="US-ASCII" There is no mention in the iTip of sending the cancel request of 1 invitee to the entire set of attendees. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/12/2003 01:24 PM Please respond to ietf-calendar@imc.org To "ietf-calendar@imc.org" cc Subject Re: CANCEL and SEQUENCE usage Robert_Ransdell@notesdev.ibm.com wrote: > > That's bogus. > > NO NO NO. > If I bump the sequence number for a givent RECUR-ID or a non repeating > meeting. Than all responses prior to this SEQUENCE are invalid. YES - and they MUST re-reply. That is what this WG had decided in the iTIP debates. It is NOT optional. Make you CUA smart and notice that nothing changed that the user cared about and auto-reply. > The > attendees must send a new accept/decline. However when you send a > CANCEL to an individual, the other attendees are not sent any a > reschedule. Thus they do not repsond. Not always true, in some cases *ALL* ATTENDEEs see object with *ALL* other ATTENDEEs. So you model will break in that case as their copy of the object IS obsolete. > Refer to my original example. When I send a CANCEL to a select subset > of the invitees, I am REMOVING them as attendees. I send the UNID and > in the case of a repeating meeting the RECUR-ID (The initial date of > this individual repeat item) and the current sequence number. That is not per-spec. > The way the CANCEL is suppose to work is that if the SEQUENCE number of > the CANCEL is greater than the invitees current sequence number than the > item is canceled. The invitee removes it from his/her calendar. Yes. > If the sequence number of the CANCEL is equal to the invitees current > sequence number and the DTSTAMP is also greaterthan the item is > canceled. The invitee removes it from his/her calendar. No that is not what iTIP says (minus its typo): 4.2.10 Removing Attendees ... The original meeting includes "A", "B", "C", and "D". The example below shows the "CANCEL" that "A" sends to "B". Note that in the example below the "STATUS" property is omitted. This is used when the meeting itself is cancelled and not when the intent is to remove an "Attendee" from the Event. Except it has a typo, it should read: ...This is used when the meeting itself is not cancelled and when the intent is to remove an "Attendee" from the Event. So your original post did not CANCEL the event, it simply removed an ATTENDEE. To CANCEL the entire EVENT, bump the 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 --=_alternative 006145ED85256D43_= Content-Type: text/html; charset="US-ASCII"
There is no mention in the iTip of sending the cancel request of 1 invitee to the entire set of attendees.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/12/2003 01:24 PM
Please respond to
ietf-calendar@imc.org
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: CANCEL and SEQUENCE usage







Robert_Ransdell@notesdev.ibm.com wrote:
>
> That's bogus.
>
> NO NO NO.
> If I bump the sequence number for a givent RECUR-ID or a non repeating
> meeting. Than all responses prior to this SEQUENCE are invalid.

YES - and they MUST re-reply. That is what this WG had decided
in the iTIP debates. It is NOT optional.

Make you CUA smart and notice that nothing changed that the
user cared about and auto-reply.

>  The
> attendees must send a new accept/decline.  However when you send a
> CANCEL to an individual, the other attendees are not sent any a
> reschedule.  Thus they do not repsond.

Not always true, in some cases *ALL* ATTENDEEs see object with
*ALL* other ATTENDEEs. So you model will break in that case
as their copy of the object IS obsolete.

> Refer to my original example.  When I send a CANCEL to a select subset
> of the invitees, I am REMOVING them as attendees.  I send the UNID and
> in the case of a repeating meeting the RECUR-ID (The initial date of
> this individual repeat item) and the current sequence number.

That is not per-spec.


> The way the CANCEL is suppose to work is that if the SEQUENCE number of
> the CANCEL is greater than the invitees current sequence number than the
> item is canceled.  The invitee removes it from his/her calendar.

Yes.

> If the sequence number of the CANCEL is equal to the invitees current
> sequence number and the DTSTAMP is also greaterthan the item is
> canceled.  The invitee removes it from his/her calendar.

No that is not what iTIP says (minus its typo):

4.2.10 Removing Attendees

     ...

   The original meeting includes "A", "B", "C", and "D". The example
   below shows the "CANCEL" that "A" sends to "B". Note that in the
   example below the "STATUS" property is omitted. This is used when the
   meeting itself is cancelled and not when the intent is to remove an
   "Attendee" from the Event.

Except it has a typo, it should read:

   ...This is used when the
   meeting itself is not cancelled and when the intent is to remove an
   "Attendee" from the Event.


So your original post did not CANCEL the event, it simply
removed an ATTENDEE.

To CANCEL the entire EVENT, bump the 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
--=_alternative 006145ED85256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 14:38: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 OAA22429 for ; Thu, 12 Jun 2003 14:38:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CIN6rb073689 for ; Thu, 12 Jun 2003 11:23: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 h5CIN67B073688 for ietf-calendar-bks; Thu, 12 Jun 2003 11:23:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CIN4rb073683 for ; Thu, 12 Jun 2003 11:23:05 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED67916.7000701@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 12 Jun 2003 14:23:02 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 02:22:32 PM, Serialize complete at 06/12/2003 02:22:32 PM Content-Type: multipart/alternative; boundary="=_alternative 0064D58985256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064D58985256D43_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/29/2003 05:18:14 PM: > > 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. NO it is NOT!! Go re-read iTIP, Section 2.1.5 Message Sequencing! The primary key is UID/RECURRENCE-ID. The secondary key is SEQUENCE. When both the primary and secondary keys match existing data then DTSTAMP is used as a semi-tertiary key. Any other ordering is incorrect! > And the start time of any instance may be unique to that key. DTSTART is NOT a factor in determining instance identification OR message sequencing and as such is not related to any kinds of keys used. Why not you may think? Simple, if you change the keys you cannot find the proper entry/instance... > 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. Not 100% accurate. Had you said UID/RECURRENCE-ID/SEQUENCE I would have agreed with the first bit though. The UID and RECURRENCE-IDs NEVER EVER EVER EVER change no matter the other values because if you change the primary key to find an instance you dont find the same instance again! This is NOT a new topic; we covered it back in 1999 when Dan Hickman started the "Recurrence ID changes?" thread. I suggest that folks reread that thread since we did NOT make RECURRENCE-ID changable back then (for what I consider to be quite obvious reasons...). > 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. Lets just stay focused on the simple REQUEST/REPLY process shall we?! We can look at other examples after I see the iTIP data that you think works for the scenario we started already. Please show me the iTIP that makes a changing RECURRENCE-ID work for the missed REQUEST cases (or the general latency case). Please! > > 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 Tom missed SEQUENCE:1 then how could he properly recalculate the RECURRENCE-ID like you suggest? He has NO way to 'backtrack' down the chain of different RECURRENCE-IDs that happen after each SEQUENCE change. > 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. This does not address how the CUA would match the changed RECURRENCE-ID to the correct instance in the set. If the RECURRENCE-ID changed at each change of SEQUENCE as you claim then the CUA can only process the latest REQUEST if they have _all_ of the previous REQUESTs too so they can say "RECURRENCE-ID changes to Wednesday for SEQUENCE:1. Now it changes to Thursday for SEQUENCE:2. Finally it changes to Friday for SEQUENCE:3". If ANY of the REQUESTs between SEQUENCE:0 and SEQUENCE:3 are missing then its not possible to properly determine which Friday instance the Organizer is referring to. Right? > You never need to track deltas. A CUA saves the latest SEQUENCE > and applies ADDs and CANCELs to that. Please show the iTIP properties on how Toms CUA would deal with a missed SEQUENCE message. Ive asked before for it and Ive waited almost 2 weeks for some but nothng yet. I do agree about tracking deltas not being need in general though as each iTIP message is a complete snapshot (excluding REPLYs and CANCELs) of the entry or instances involved. However the only way to get from "RECURRENCE-ID on Wednesday for SEQUENCE:1" to "RECURRENCE-ID on Friday for SEQUENCE:3" is to apply the missing DTSTART value from SEQUENCE:2 that you never got. I strongly suggest that anyone who thinks that RECURRENCE-IDs change go to the archives and search a bit on RECURRENCE-ID and check out Dan Hickmans thread from 1999. There may be others but its clear that RECURRENCE-ID cannot change if you ever expect to be able to correctly identify instances when missed messages are involved. In the mean time Ill wait for Doug to provide the iTIP examples like Ive already done. Perhaps he can show how changing the primary key can work... 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 0064D58985256D43_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/29/2003 05:18:14 PM:
> > 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.
NO it is NOT!!  Go re-read iTIP, Section 2.1.5 Message Sequencing!

The primary key is UID/RECURRENCE-ID.  The secondary key is SEQUENCE.  When both the primary and secondary keys match existing data then DTSTAMP is used as a semi-tertiary key.  Any other ordering is incorrect!

> And the start time of any instance may be unique to that key.
DTSTART is NOT a factor in determining instance identification OR message sequencing and as such is not related to any kinds of keys used.  Why not you may think?  Simple, if you change the keys you cannot find the proper entry/instance...

> 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.
Not 100% accurate.  Had you said UID/RECURRENCE-ID/SEQUENCE I would have agreed with the first bit though.

The UID and RECURRENCE-IDs NEVER EVER EVER EVER change no matter the other values because if you change the primary key to find an instance you dont find the same instance again!  

This is NOT a new topic; we covered it back in 1999 when Dan Hickman started the "Recurrence ID changes?" thread.  I suggest that folks reread that thread since we did NOT make RECURRENCE-ID changable back then (for what I consider to be quite obvious reasons...).

> 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.
Lets just stay focused on the simple REQUEST/REPLY process shall we?!  We can look at other examples after I see the iTIP data that you think works for the scenario we started already.

Please show me the iTIP that makes a changing RECURRENCE-ID work for the missed REQUEST cases (or the general latency case).  Please!

>  > 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 Tom missed SEQUENCE:1 then how could he properly recalculate the RECURRENCE-ID like you suggest?  He has NO way to 'backtrack' down the chain of different RECURRENCE-IDs that happen after each SEQUENCE change.

> 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:<next> object and the CUAs REPLY.
This does not address how the CUA would match the changed RECURRENCE-ID to the correct instance in the set.  If the RECURRENCE-ID changed at each change of SEQUENCE as you claim then the CUA can only process the latest REQUEST if they have _all_ of the previous REQUESTs too so they can say "RECURRENCE-ID changes to Wednesday for SEQUENCE:1.  Now it changes to Thursday for SEQUENCE:2.  Finally it changes to Friday for SEQUENCE:3".  If ANY of the REQUESTs between SEQUENCE:0 and SEQUENCE:3 are missing then its not possible to properly determine which Friday instance the Organizer is referring to.  Right?

> You never need to track deltas. A CUA saves the latest SEQUENCE
> and applies ADDs and CANCELs to that.
Please show the iTIP properties on how Toms CUA would deal with a missed SEQUENCE message.  Ive asked before for it and Ive waited almost 2 weeks for some but nothng yet.

I do agree about tracking deltas not being need in general though as each iTIP message is a complete snapshot (excluding REPLYs and CANCELs) of the entry or instances involved.  However the only way to get from "RECURRENCE-ID on Wednesday for SEQUENCE:1" to "RECURRENCE-ID on Friday for SEQUENCE:3" is to apply the missing DTSTART value from SEQUENCE:2 that you never got.  

I strongly suggest that anyone who thinks that RECURRENCE-IDs change go to the archives and search a bit on RECURRENCE-ID and check out Dan Hickmans thread from 1999.  There may be others but its clear that RECURRENCE-ID cannot change if you ever expect to be able to correctly identify instances when missed messages are involved.

In the mean time Ill wait for Doug to provide the iTIP examples like Ive already done.  Perhaps he can show how changing the primary key can work...

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 0064D58985256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 15:02: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 PAA22985 for ; Thu, 12 Jun 2003 15:02:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CIrBrb075195 for ; Thu, 12 Jun 2003 11:53: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 h5CIrBUG075193 for ietf-calendar-bks; Thu, 12 Jun 2003 11:53:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CIrArb075188 for ; Thu, 12 Jun 2003 11:53:11 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: ietf-calendar@imc.org Subject: Re: CAP ABNF: queryc is only used in 1 command? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 12 Jun 2003 14:25:51 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 02:53:14 PM, Serialize complete at 06/12/2003 02:53:14 PM Content-Type: multipart/alternative; boundary="=_alternative 0065179585256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065179585256D43_= Content-Type: text/plain; charset="US-ASCII" I wrote on 05/29/2003 05:52:12 PM: > Unless I am mistaken I can only find 1 CAP command that uses the > CAP-QL in the ABNF. That is the CREATE command. [Snip, snip] > 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? Hmm, no responses either way. Can anyone else either confirm this suspicion or show me where I missed it in the ABNF? Anyone?? (Out of ~300+ folkson the list there has to be someone who can chip in...) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... Warning: Dates in Calendar are closer than they appear. --=_alternative 0065179585256D43_= Content-Type: text/html; charset="US-ASCII"
I wrote on 05/29/2003 05:52:12 PM:
> Unless I am mistaken I can only find 1 CAP command that uses the
> CAP-QL in the ABNF.  That is the CREATE command.
[Snip, snip]
> 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?

Hmm, no responses either way.  

Can anyone else either confirm this suspicion or show me where I missed it in the ABNF?  Anyone??  (Out of ~300+ folkson the list there has to be someone who can chip in...)

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

--=_alternative 0065179585256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 15:02: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 PAA23019 for ; Thu, 12 Jun 2003 15:02: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 h5CIrBrb075201 for ; Thu, 12 Jun 2003 11:53: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 h5CIrBT7075200 for ietf-calendar-bks; Thu, 12 Jun 2003 11:53:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CIrArb075187 for ; Thu, 12 Jun 2003 11:53:11 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED68F47.40908@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_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 12 Jun 2003 14:39:23 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 02:53:14 PM, Serialize complete at 06/12/2003 02:53:14 PM Content-Type: multipart/alternative; boundary="=_alternative 0066548F85256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066548F85256D43_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/29/2003 06:52:55 PM: > > 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: Who said Doug and I never agree?... > "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. Im NOT ADDing to the repeat set! As such an ADD method is NOT called for. The text was clear but Ill requote it w/emphasis (and include one more tidbit): 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. ... The "UID" must be that of the existing event. Arnaud is being added to the event set, NOT any new instances. As such a REQUEST + ADD is not a legit set of iTIP messages to send. Besides, if Im just now adding him to the event there is NO way he will have it on his calendar yet so that is yet another reason why ADD is not possible here. As the Organzier I only have to send 1 REQUEST to Arnaud and from there he should be able to get in sync w/everyone else. There is also the difficulty in relying on the ADD method. When we created ADD we had no shipping CUAs that supported that ability. We added it to iTIP because we knew we would eventually need it. That is also why we put in the caveat text under 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". _No_ other iTIP method has that last line about not supporting it. We added it because currently noone did support it and we wanted to be explciit in how to deal with it for interop reasons from Day 1. If you rely on a method that is not widely supported yet to do a basic "Add new Invitee" feature then you run a big risk (ignoring the fact that ADD cannot be used to send the initial REQUEST, etc). So since REQUEST + ADD is not a viable answer, could you please show us the iTIP that would 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 0066548F85256D43_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/29/2003 06:52:55 PM:
> > 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:
Who said Doug and I never agree?...

>    "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.
Im NOT ADDing to the repeat set!  As such an ADD method is NOT called for.  The text was clear but Ill requote it w/emphasis (and include one more tidbit):

                  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.
...
   The "UID" must be that of the existing event.

Arnaud is being added to the event set, NOT any new instances.  As such a REQUEST + ADD is not a legit set of iTIP messages to send.  Besides, if Im just now adding him to the event there is NO way he will have it on his calendar yet so that is yet another reason why ADD is not possible here.

As the Organzier I only have to send 1 REQUEST to Arnaud and from there he should be able to get in sync w/everyone else.

There is also the difficulty in relying on the ADD method.  When we created ADD we had no shipping CUAs that supported that ability.  We added it to iTIP because we knew we would eventually need it.  That is also why we put in the caveat text under 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".

_No_ other iTIP method has that last line about not supporting it.  We added it because currently noone did support it and we wanted to be explciit in how to deal with it for interop reasons from Day 1.  If you rely on a method that is not widely supported yet to do a basic "Add new Invitee" feature then you run a big risk (ignoring the fact that ADD cannot be used to send the initial REQUEST, etc).

So since REQUEST + ADD is not a viable answer, could you please show us the iTIP that would 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 0066548F85256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 15:04: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 PAA23157 for ; Thu, 12 Jun 2003 15:04:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CItwrb075624 for ; Thu, 12 Jun 2003 11:55:58 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CItwPv075623 for ietf-calendar-bks; Thu, 12 Jun 2003 11:55:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CItvrb075613 for ; Thu, 12 Jun 2003 11:55:57 -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 h5CItrbt021541 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 Jun 2003 11:55:58 -0700 Message-ID: <3EE8CCAF.7010604@Royer.com> Date: Thu, 12 Jun 2003 12:55: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: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030202020202070902010108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030202020202070902010108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > There is no mention in the iTip of sending the cancel request of 1 > invitee to the entire set of attendees. I did not mean to say that, I meant: ATTENDEE 0+ MUST include all "Attendees" being removed the event. MUST include all "Attendees" if the entire event is cancelled. So there is a way to remove one or more ATTENDEEs (a CANCEL for just those ATTENDEEs). There is a way to CANCEL one or more instances, or the entire object for all ATTENDEEs. And you are allowed to send the entire object to each individual attendees, or to all ATTENDEEs. Bumping SEQUENCE is valid during CANCEL and was what was agreed be the protocol. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030202020202070902010108 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTIxODU1NDNaMCMGCSqGSIb3DQEJBDEWBBRT A7al3le6qhIsB4/6mcnpJe4prDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAoibG49eynsre EGLwkdRnQ18LmFOXRA6EKRQBtzCEA4GJ3PEUxFE2Y6lrw/n/yqR/0wdXPhXy3WDhyXvn2A+6 MALyGKfN7auferNlvnbQvnrIxTOamqA8vfi9OMNKba3JG+v3n3/DS9VCJKm9HWX2e+4LSuy7 bhJRFzWFODIci7e9qpCRwlUgmNk44+mdI/7Tyy/Us4ri9U0KySSbOrBL/F64ZWEDLIjPUYPu CTAwBUdWJht7vbRJ3snrr6ExtCFQS08qNSvV22ASbPtMek8nrP3dicvui6A3ul4NV1bkvhLC bNQhAnKvlKcWRey8/9LBBxRjegr3Q7MShysM04SOyAAAAAAAAA== --------------ms030202020202070902010108-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 15:26:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24816 for ; Thu, 12 Jun 2003 15:26: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 h5CJERrb077312 for ; Thu, 12 Jun 2003 12:14: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 h5CJEQY6077311 for ietf-calendar-bks; Thu, 12 Jun 2003 12:14:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CJEQrb077306 for ; Thu, 12 Jun 2003 12:14:26 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EE8CCAF.7010604@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CANCEL and SEQUENCE usage MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 12 Jun 2003 15:17:03 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 03:14:28 PM, Serialize complete at 06/12/2003 03:14:28 PM Content-Type: multipart/alternative; boundary="=_alternative 0069647B85256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069647B85256D43_= Content-Type: text/plain; charset="US-ASCII" You are STILL missing the point. As the Chair I have a current sequence number. All the accepts/declines are based on that sequence number. If I have an accept but it is from a previous sequence number than the state of that attendee is WAITING FOR RESPONSE. Now I (under your rules ) bump the sequence number and send a Cancel to invitee A. No other invitees are sent any kind of message. Now Notes sequence number is 1 lager than all existing accepts/declines. Thus all invitees are now in WAITING FOR RESPONSE state. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/12/2003 02:55 PM Please respond to "ietf-calendar@imc.org" To ietf-calendar@imc.org cc Subject Re: CANCEL and SEQUENCE usage Robert_Ransdell@notesdev.ibm.com wrote: > > There is no mention in the iTip of sending the cancel request of 1 > invitee to the entire set of attendees. I did not mean to say that, I meant: ATTENDEE 0+ MUST include all "Attendees" being removed the event. MUST include all "Attendees" if the entire event is cancelled. So there is a way to remove one or more ATTENDEEs (a CANCEL for just those ATTENDEEs). There is a way to CANCEL one or more instances, or the entire object for all ATTENDEEs. And you are allowed to send the entire object to each individual attendees, or to all ATTENDEEs. Bumping SEQUENCE is valid during CANCEL and was what was agreed be the protocol. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.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 0069647B85256D43_= Content-Type: text/html; charset="US-ASCII"
You are STILL missing the point.
As the Chair I have a current sequence number.  All the accepts/declines are based on that sequence number.  If I have an accept but it is from a previous sequence number than the state of that attendee is WAITING FOR RESPONSE.
Now I (under your rules ) bump the sequence number and send a Cancel to invitee A.  No other invitees are sent any kind of message.
Now Notes sequence number is 1 lager than all existing accepts/declines.
Thus all invitees are now in  WAITING FOR RESPONSE state.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/12/2003 02:55 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
ietf-calendar@imc.org
cc
Subject
Re: CANCEL and SEQUENCE usage







Robert_Ransdell@notesdev.ibm.com wrote:
>
> There is no mention in the iTip of sending the cancel request of 1
> invitee to the entire set of attendees.

I did not mean to say that, I meant:

    ATTENDEE        0+     MUST include all "Attendees" being removed
                           the event. MUST include all "Attendees" if
                           the entire event is cancelled.


So there is a way to remove one or more ATTENDEEs (a CANCEL for just
those ATTENDEEs).

There is a way to CANCEL one or more instances, or the entire object
for all ATTENDEEs.

And you are allowed to send the entire object to each individual
attendees, or to all ATTENDEEs.

Bumping SEQUENCE is valid during CANCEL and was what was agreed
be the protocol.

--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.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 0069647B85256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 15:47:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25094 for ; Thu, 12 Jun 2003 15:47:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CJWYrb078279 for ; Thu, 12 Jun 2003 12:32: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 h5CJWYsh078278 for ietf-calendar-bks; Thu, 12 Jun 2003 12:32:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CJWXrb078273 for ; Thu, 12 Jun 2003 12:32:33 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED699FD.9010101@Royer.com> To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 12 Jun 2003 15:29:26 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 03:32:35 PM, Serialize complete at 06/12/2003 03:32:35 PM Content-Type: multipart/alternative; boundary="=_alternative 006B2CF685256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B2CF685256D43_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 05/29/2003 07:38:37 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? Not sure how you got "SEQUENCE never changes" from "I see NOTHING in iTIP that expressly says '1 more than it has' (even paraphrased)"... Still if your CUA wants to do a REFRESH if it misses just 1 REQUEST then thats your perogative but its not necessary if the REQUEST is a complete snapshot of the instance; the higher SEQUENCE one just obsoletes the older one. Im saying that UID and RECURRNECE-ID never changes! Everything else can change. (Primary keys cannot change, the rest can!) > > > 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. No, no, no!! Is iTIP section 2.1.5 NOT understandable?? Its quite clear in its ordering: 1: UID/RECURRENCE-ID is the primary key 2: SEQUENCE is the secondary key (hence you do NOT, NOT NOT use SEQUENCE to look for RECURRNECE-ID) 3: DTSTAMP as a tie breaker (aka tertiary key for when UID/RECURRENCE-ID matched _then_ SEQUENCE matched!) > Otherwise there would be NO way to ever determin the intended start > time for an instance you do no have. Sure you can: The DTSTART is the intended start time for the instance identified by the UID/RECURRENCE-ID primary key for the given SEQUENCE secondary key. Its only a problem if you change the primary key to a new value (ie: RECURRNECE-ID gets the new DTSTART value). If the RECURRENCE-ID never changes then its not an issue. Its easily demonstrated, go recheck the examples Ive provided already. Is this not a clear concept? RECURRENCE-ID cannot ever change or you have 0% chance of resyncing workflow if you miss 1 REQUEST in the process. > > 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? You will NEVER EVER have a CANCEL with SEQUENCE:0. Since entries are created at SEQUENCE:0 and iTIP Section 3.2.5 CANCEL clearly says: When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be incremented. then if I wanted to CANCEL an instance I would send the UID/RECURRENCE-ID I used all along with a higher SEQUENCE value. No problem there. What am I missing?? There is one workflow faupaux introduced in the rush to simplify the original method list down to the present set; CANCELing just an invitee and not the actual instance. If you read all of the prose in nearly all of the CANCEL sections in iTIP (3.2.5 for VEVENTs, 3.4.5 for VTODOs) you should not that there is NO prose about cancelling participation in the entry; it all talks about cancelling "of an existing event" or "of an existing "VTODO"". Thats because we had another method for 'uninviting' ATTENDEEs. At some point before we shipped someone changed the restriction tables to include: ATTENDEE 0+ MUST include all "Attendees" being removed the event. MUST include all "Attendees" if the entire event is cancelled. this was a mistake IMNHO because it now means that if I want to uninvite someone I have to CANCEL them (and thus rev SEQUENCE). This means then that I would have to invalidate my existing responses because SEQUENCE has changed. We didnt make the same mistake for VJOURNALs though where it was left as: ATTENDEE 0+ This is probably related to the cut/paste mistakes that are evident by such text as: (a) the "RECURRENCE-ID" property for an instance in the sequence MUST be specified with the "RANGE" property parameter value of THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the specified "VTODO" calendar component and all instances before (or after); or under Section 3.5.3 CANCEL for VJOURNALs. Notice that it refers to VTODO still... Ye Editors did make some mistakes and this was one of them. Still it is not unrecoverable. As an Organizer I can send a new REQUEST at the new SEQUENCE value to the existing ATTENDEEs that remain and either renegotate their participation or if their CUAs are clever enough the process could be semi-automatic. Still _none_ of this answers the question how a delta model will work for the missed REQUEST case. Its all a digression because its impossible to demonstrate resyncing in the delta case... To paraphrase: Show me the iTIP! Show me the 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... --=_alternative 006B2CF685256D43_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 05/29/2003 07:38:37 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?
Not sure how you got "SEQUENCE never changes" from "I see NOTHING in iTIP that expressly says '1 more than it has' (even paraphrased)"...   Still if your CUA wants to do a REFRESH if it misses just 1 REQUEST then thats your perogative but its not necessary if the REQUEST is a complete snapshot of the instance; the higher SEQUENCE one just obsoletes the older one.

Im saying that UID and RECURRNECE-ID never changes!  Everything else can change.  (Primary keys cannot change, the rest can!)

> >  > 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.
No, no, no!!  Is iTIP section 2.1.5 NOT understandable??  Its quite clear in its ordering:

1: UID/RECURRENCE-ID is the primary key
2: SEQUENCE is the secondary key (hence you do NOT, NOT NOT use SEQUENCE to look for RECURRNECE-ID)
3: DTSTAMP as a tie breaker (aka tertiary key for when UID/RECURRENCE-ID matched _then_ SEQUENCE matched!)

> Otherwise there would be NO way to ever determin the intended start
> time for an instance you do no have.
Sure you can:  The DTSTART is the intended start time for the instance identified by the UID/RECURRENCE-ID primary key for the given SEQUENCE secondary key.  Its only a problem if you change the primary key to a new value (ie: RECURRNECE-ID gets the new DTSTART value).

If the RECURRENCE-ID never changes then its not an issue.  Its easily demonstrated, go recheck the examples Ive provided already.  Is this not a clear concept?  

RECURRENCE-ID cannot ever change or you have 0% chance of resyncing workflow if you miss 1 REQUEST in the process.

> >    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?
You will NEVER EVER have a CANCEL with SEQUENCE:0.  Since entries are created at SEQUENCE:0 and iTIP Section 3.2.5 CANCEL clearly says:

   When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
  incremented.

then if I wanted to CANCEL an instance I would send the UID/RECURRENCE-ID I used all along with a higher SEQUENCE value.  No problem there.  What am I missing??

There is one workflow faupaux introduced in the rush to simplify the original method list down to the present set; CANCELing just an invitee and not the actual instance.  If you read all of the prose in nearly all of the CANCEL sections in iTIP (3.2.5 for VEVENTs, 3.4.5 for VTODOs) you should not that there is NO prose about cancelling participation in the entry; it all talks about cancelling "of an existing event" or "of an existing "VTODO"".  Thats because we had another method for 'uninviting' ATTENDEEs.  At some point before we shipped someone changed the restriction tables to include:

    ATTENDEE        0+     MUST include all "Attendees" being removed
                          the event. MUST include all "Attendees" if
                          the entire event is cancelled.
this was a mistake IMNHO because it now means that if I want to uninvite someone I have to CANCEL them (and thus rev SEQUENCE).  This means then that I would have to invalidate my existing responses because SEQUENCE has changed.  We didnt make the same mistake for VJOURNALs though where it was left as:

    ATTENDEE         0+
  This is probably related to the cut/paste mistakes that are evident by such text as:

   (a) the "RECURRENCE-ID" property for an instance in the sequence MUST
      be specified with the "RANGE" property parameter value of
      THISANDPRIOR (or THISANDFUTURE)  to indicate cancellation of the
      specified "VTODO" calendar component and all instances before (or
      after); or

under Section 3.5.3 CANCEL for VJOURNALs.  Notice that it refers to VTODO still...  Ye Editors did make some mistakes and this was one of them.  Still it is not unrecoverable.  As an Organizer I can send a new REQUEST at the new SEQUENCE value to the existing ATTENDEEs that remain and either renegotate their participation or if their CUAs are clever enough the process could be semi-automatic.

Still _none_ of this answers the question how a delta model will work for the missed REQUEST case.  Its all a digression because its impossible to demonstrate resyncing in the delta case...  

To paraphrase: Show me the iTIP!  Show me the 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... --=_alternative 006B2CF685256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 16:03: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 QAA25357 for ; Thu, 12 Jun 2003 16:03: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 h5CJrQrb078709 for ; Thu, 12 Jun 2003 12:53: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 h5CJrQaV078708 for ietf-calendar-bks; Thu, 12 Jun 2003 12:53:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CJrLrc078692 for ; Thu, 12 Jun 2003 12:53:24 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <004001c326e5$eefd74a0$869012c0@dvd2kdom.red.iplanet.com> To: kiwong Cc: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 12 Jun 2003 15:52:01 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 03:53:25 PM, Serialize complete at 06/12/2003 03:53:25 PM Content-Type: multipart/alternative; boundary="=_alternative 006CFAC885256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CFAC885256D43_= Content-Type: text/plain; charset="US-ASCII" Ki wrote on 05/30/2003 03:59:09 PM: > 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%. You're welcome. Im glad to hear that the examples were clear and informative. > 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. I havent seen any delta model examples yet and I doubt I ever will. Steve Silverberg, Derik Stenerson, Frank Dawson and I spent ~4+ hours at the Chicago IETF going over all the cases with a fine tooth comb before we all agreed that a delta model just wont work. Thats why we went to the absolute model for everything (and why iTIP messages are supposed to be complete snapshots that can just obsolete previous ones, etc). If you want to verify this, get in touch w/any of them. This however was not the first time this question came up. If you read the archives you will find that Dan Hickman raised the question back in July 1999 (Subject "Recurrence ID changes?") and I had expected that that would be the last the issue would be heard from. Guess I was mistaken. > 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? Lotus Organizer, Lotus Notes, Microsoft Outlook (not Outlook Express though) and Microsoft Exchange all use a fixed, unchanging RECURRENCE-ID. Im sure other products do too since as you've astutely noted using a delta model where RECURRENCE-ID changes can get you into unrecoverable situations quite easily. I just dont happen to have other products in-house to test with (but Im always available to interop test if anyone is interested). 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 006CFAC885256D43_= Content-Type: text/html; charset="US-ASCII"
Ki wrote on 05/30/2003 03:59:09 PM:
>  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%.
You're welcome.  Im glad to hear that the examples were clear and informative.

> 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.
I havent seen any delta model examples yet and I doubt I ever will.  Steve Silverberg, Derik Stenerson, Frank Dawson and I spent ~4+ hours at the Chicago IETF going over all the cases with a fine tooth comb before we all agreed that a delta model just wont work.  Thats why we went to the absolute model for everything (and why iTIP messages are supposed to be complete snapshots that can just obsolete previous ones, etc).  If you want to verify this, get in touch w/any of them.

This however was not the first time this question came up.  If you read the archives you will find that Dan Hickman raised the question back in July 1999 (Subject "Recurrence ID changes?") and I had expected that that would be the last the issue would be heard from.  Guess I was mistaken.

> 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?
Lotus Organizer, Lotus Notes, Microsoft Outlook (not Outlook Express though) and Microsoft Exchange all use a fixed, unchanging RECURRENCE-ID.  

Im sure other products do too since as you've astutely noted using a delta model where RECURRENCE-ID changes can get you into unrecoverable situations quite easily.  I just dont happen to have other products in-house to test with (but Im always available to interop test if anyone is interested).

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 006CFAC885256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 16:05:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25378 for ; Thu, 12 Jun 2003 16:05: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 h5CJrOrb078702 for ; Thu, 12 Jun 2003 12:53: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 h5CJrOL0078701 for ietf-calendar-bks; Thu, 12 Jun 2003 12:53:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CJrLrb078692 for ; Thu, 12 Jun 2003 12:53:22 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: "Craig Johnson" Cc: ietf-calendar@imc.org Subject: Re: Default TARGET MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 12 Jun 2003 14:57:15 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 03:53:23 PM, Serialize complete at 06/12/2003 03:53:23 PM Content-Type: multipart/alternative; boundary="=_alternative 0067F77F85256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067F77F85256D43_= Content-Type: text/plain; charset="US-ASCII" Craig wrote on 05/29/2003 07:27:08 PM: > In the current draft the ABNF for TARGET indicates it is optional. Another reason why I think the ABNF needs to be reformatted to be more akin to 2445. The current formatting makes mistakes or odd data likely. > 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. I think we should fix up the draft and NOT default TARGET. Heres why: 1: Not everyone has just 1 calendar. I happen to have 3 I use; 1 for work, 1 for personal/family and 1 for my Red Cross activities. As such if my CS is to default a TARGET to a particular calendar I now have to add new infrastructure to the CS. I now have to provide some means to match a UPN to a particular TARGET (a new CS requirement). I also need to have some means to change this. However many here will yell "Administration issue!" and say its out of scope for CAP. Great, a last minute feature/side effect that requires some OOB mechanism to manage from Day 1. 2: The behaviour for the changing identity case (IDENTIFY command) is unclear at best. Should my AA now default to my 'primary' calendar when she assumes my identity? I would expect not but some could argue so. 3: For the case where Im doing acutal Scheduling activities I may want to refer to my calendar and that of others. Then Id have to specify a TARGET of my primary calendar. Since the TARGET can be a relative calendar identifier which is not likely to be overly long, what is the real cost savings by defaulting it? 9 octets plus the relcalid length. Not a whole lot of extra savings... 4: There is no way for the CUA to find out what the default TARGET is from the CS so there is no way for the CUA to know what tell the CU or when to use a different relcalid. Just how would my CUA know it needed to send TARGET:BrucesFamilyCalendar or TARGET:BruceRedCross but not TARGET:BrucesWorkCalendar?? 5: Making assumptions, especially for stuff like DELETE, could be disasterous if the wrong default is used (and the CUA has 0% chance of determining what the default value is!). Imagine the user thinking they are cleaning out an old project calendar and infact they just erased the current one (or their personal one or ...) =:^( I see lots of questions / concerns about data safety and usability and the only real cost trade off is "9 octets + strlen(relcalid)" vs cleaning up the ABNF in CAP. I for one like it clearly spelled out in the text/ABNF since the savings is not likely to be that big anyway (compared to the cost of going "off box" to the CS, etc). I would vote for fixing the text and not defaulting anything! 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 0067F77F85256D43_= Content-Type: text/html; charset="US-ASCII"
Craig wrote on 05/29/2003 07:27:08 PM:
> In the current draft the ABNF for TARGET indicates it is optional.  
Another reason why I think the ABNF needs to be reformatted to be more akin to 2445.  The current formatting makes mistakes or odd data likely.

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

I think we should fix up the draft and NOT default TARGET.  Heres why:

1: Not everyone has just 1 calendar.  I happen to have 3 I use; 1 for work, 1 for personal/family and 1 for my Red Cross activities.  As such if my CS is to default a TARGET to a particular calendar I now have to add new infrastructure to the CS.  I now have to provide some means to match a UPN to a particular TARGET (a new CS requirement).  I also need to have some means to change this.  However many here will yell "Administration issue!" and say its out of scope for CAP.  Great, a last minute feature/side effect that requires some OOB mechanism to manage from Day 1.

2: The behaviour for the changing identity case (IDENTIFY command) is unclear at best.  Should my AA now default to my 'primary' calendar when she assumes my identity?  I would expect not but some could argue so.

3: For the case where Im doing acutal Scheduling activities I may want to refer to my calendar and  that of others.  Then Id have to specify a TARGET of my primary calendar.  Since the TARGET can be a relative calendar identifier which is not likely to be overly long, what is the real cost savings by defaulting it?  9 octets plus the relcalid length.  Not a whole lot of extra savings...

4: There is no way for the CUA to find out what the default TARGET is from the CS so there is no way for the CUA to know what tell the CU or when to use a different relcalid.  Just how would my CUA know it needed to send TARGET:BrucesFamilyCalendar or TARGET:BruceRedCross but not TARGET:BrucesWorkCalendar??

5: Making assumptions, especially for stuff like DELETE, could be disasterous if the wrong default is used (and the CUA has 0% chance of determining what the default value is!).  Imagine the user thinking they are cleaning out an old project calendar and infact they just erased the current one (or their personal one or ...)  =:^(

I see lots of questions / concerns about data safety and usability and the only real cost trade off is "9 octets + strlen(relcalid)" vs cleaning up the ABNF in CAP.  I for one like it clearly spelled out in the text/ABNF since the savings is not likely to be that big anyway (compared to the cost of going "off box" to the CS, etc).  I would vote for fixing the text and not defaulting anything!

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 0067F77F85256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 16:21: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 QAA25690 for ; Thu, 12 Jun 2003 16:21: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 h5CK8Hrb079214 for ; Thu, 12 Jun 2003 13:08: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 h5CK8HjD079213 for ietf-calendar-bks; Thu, 12 Jun 2003 13:08: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 h5CK8Grb079208 for ; Thu, 12 Jun 2003 13:08: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 h5CK8Bbt022157 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 Jun 2003 13:08:16 -0700 Message-ID: <3EE8DD80.9030300@Royer.com> Date: Thu, 12 Jun 2003 14:07: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: CAP ABNF: queryc is only used in 1 command? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050307000909090105040509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050307000909090105040509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The string 'CAP-QL' is not in CAP. Bruce_Kahn@notesdev.ibm.com wrote: > > I wrote on 05/29/2003 05:52:12 PM: > > Unless I am mistaken I can only find 1 CAP command that uses the > > CAP-QL in the ABNF. That is the CREATE command. > [Snip, snip] > > 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? > > Hmm, no responses either way. > > Can anyone else either confirm this suspicion or show me where I missed > it in the ABNF? Anyone?? (Out of ~300+ folkson the list there has to > be someone who can chip 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 --------------ms050307000909090105040509 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTIyMDA3MjlaMCMGCSqGSIb3DQEJBDEWBBQg n2dq5Njq50dc25ZTR/zkKNSynjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEACBzkehLD4wme lEdl/IrUiU1sBLjiLpWD08EwL+CV3/Rf2JCn28vUbckkSzDEQ5wzWi02e7XFGrsOYIoM2rZz n0b1PL5HsCi16tPVsqCfsxb3IEEM1JGYJX6xF3r1l+52VY+awz9dcRn3STyP0WKgHFdCw2Yj OmausM42ev3m7xpUTFTsjIlPczEn340PJabZ+y1FChFQSYOABgUG0z9OXdPOVEbi1PHZGFdz dk20qG9PtTzoX7lGwCqHrT7+aurjWaypkNY7ebHp+CcuHn1ZQicSbGebxKRT3s2Uu3dR/pyq FsEZ2V2xwfKxd7cvJyEtXC7l5inr6XngY19S6w1vXQAAAAAAAA== --------------ms050307000909090105040509-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 16:34: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 QAA26088 for ; Thu, 12 Jun 2003 16:34: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 h5CKNXrb079732 for ; Thu, 12 Jun 2003 13:23: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 h5CKNWSK079731 for ietf-calendar-bks; Thu, 12 Jun 2003 13:23:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CKNVrb079725 for ; Thu, 12 Jun 2003 13:23:32 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3ED7C4E4.6020002@Royer.com> To: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 12 Jun 2003 16:01:45 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 04:23:30 PM, Serialize complete at 06/12/2003 04:23:31 PM, Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 04:23:31 PM Content-Type: multipart/alternative; boundary="=_alternative 006DDF2985256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006DDF2985256D43_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 05/30/2003 04:53:56 PM: > 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. You can easily if the RECURRENCE-ID never changes. The CANCEL for UID/RECURRENCE-ID has a higher SEQUENCE value so it obsoletes the previous SEQUENCE data for that instance. Even if you never got SEQUENCE:1 you can properly identify the SEQUENCE:0 instance and mark it CANCELed. If the SEQUENCE:1 comes in later then its already been obsoleted (by iTIP Section 2.1.5, Rule #2) and can be safely ignored. If however you expect to rewrite the RECURRENCE-ID value for every new SEQUENCE then you run into the same kinds of problems you do if you miss a SEQUENCE. Its not possible to recover NOR can you act on SEQUENCE:2 until you get SEQUENCE:1. Or more generally, you cannot act on SEQUENCE:x unless you are currently at SEQUENCE:x-1 and since a REFRESH is always guaranteed to be at the latest SEQUENCE (x in this case). This topic is going nowhere since this has been discussed before (July 1999, "Recurrence ID changes?") and there has been no attempt to demonstrate how it could possibly work using actual iTIP data. Unless Doug or George can demonstate how to resync, etc using a delta model I suggest we make a strong WG note to remove the misleading text from the next revision of 2445 and move on. 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 006DDF2985256D43_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 05/30/2003 04:53:56 PM:
> 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.
You can easily if the RECURRENCE-ID never changes.  

The CANCEL for UID/RECURRENCE-ID has a higher SEQUENCE value so it obsoletes the previous SEQUENCE data for that instance.  Even if you never got SEQUENCE:1 you can properly identify the SEQUENCE:0 instance and mark it CANCELed.  If the SEQUENCE:1 comes in later then its already been obsoleted (by iTIP Section 2.1.5, Rule #2) and can be safely ignored.

If however you expect to rewrite the RECURRENCE-ID value for every new SEQUENCE then you run into the same kinds of problems you do if you miss a SEQUENCE.  Its not possible to recover NOR can you act on SEQUENCE:2 until you get SEQUENCE:1.  Or more generally, you cannot act on SEQUENCE:x unless you are currently at SEQUENCE:x-1 and since a REFRESH is always guaranteed to be at the latest SEQUENCE (x in this case).

This topic is going nowhere since this has been discussed before (July 1999, "Recurrence ID changes?") and there has been no attempt to demonstrate how it could possibly work using actual iTIP data.

Unless Doug or George can demonstate how to resync, etc using a delta model I suggest we make a strong WG note to remove the misleading text from the next revision of 2445 and move on.

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 006DDF2985256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 16:39: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 QAA26322 for ; Thu, 12 Jun 2003 16:39:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CKSjrb080097 for ; Thu, 12 Jun 2003 13:28:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CKSj1l080096 for ietf-calendar-bks; Thu, 12 Jun 2003 13:28:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CKSirb080089 for ; Thu, 12 Jun 2003 13:28:44 -0700 (PDT) (envelope-from cco@asitturnsout.org) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 3DE688D884 for ; Thu, 12 Jun 2003 13:28:45 -0700 (PDT) From: "Chris Olds" To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id Date: Thu, 12 Jun 2003 13:28:45 -0700 Message-Id: <20030612192905.M32638@asitturnsout.org> In-Reply-To: References: <3ED67916.7000701@Royer.com> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As a relative newcomer to the wooly world of calendar exchanges, I find that my interpretation of iTIP is simpler than either of Bruce and Doug's (as far as I understand them, at least). My mental model is that an application that uses iCal objects must manage them in a versioned manner. Objects are identified by UIDs, and the version of an object is identified by SEQUENCE numbers. If I get REQUEST containing an object (or objects, but since they must all share the same UID, I'm going to treat them as a single object), then I look at the SEQUENCE of the object I just got. If it is greater than the value I have, I need to update my schedule. If the SEQUENCE is the same as mine, it's an update to the details (so I may have new/more/less/different data to save, but no calendar changes) and/or a request for a reply (via "ATTENDEE;RSVP=TRUE"). If the sequence is less than mine, then I may discard it, since I know it is stale. Processing updates to the calendar (i.e., those with ANY sequence number greater than the one I have for that UID) simply requires that I be able to (at most) find the calendar entries generated by the object with that UID. Since a REQUEST will generally (always?) contain all the data for that event or entry, I could just delete all the saved data for the old version and replace it with the new version. Ah, you say, but what about RECURRENCE-ID?!?! Good question. In order for RECURRENCE-ID to be useful, it must refer to a specific version of the object containing it, and both parties must agree on which one. If I've got it right, Bruce thinks that the version to use is the first one (SEQUENCE:0), and Doug is saying that the version to use is the most recent one. I believe that "the most recent version" is the correct answer. My reasoning is that while RECURRENCE-ID is, if present, part of the primary key to use in finding an instance, it is only valid when used in relation to the correct version of the object in question. The problem with using the 0th version of the event to define RECURRENCE-ID is that I then need to have that value follow along as an instance is modified. This has all of the problems of the 'delta' model, and is further complicated by additions (via REQUEST or ADD) to the instance set. I've added my comments in-line, below. On Thu, 12 Jun 2003 14:23:02 -0400, Bruce_Kahn wrote > Doug wrote on 05/29/2003 05:18:14 PM: > > If later the SEQUENCE gets updated again, the ORGANIZER would send > > the SEQUENCE: object and the CUAs REPLY. > > This does not address how the CUA would match the changed RECURRENCE- > ID to the correct instance in the set. If the RECURRENCE-ID changed > at each change of SEQUENCE as you claim then the CUA can only > process the latest REQUEST if they have _all_ of the previous > REQUESTs too so they can say "RECURRENCE-ID changes to Wednesday for > SEQUENCE:1. Now it changes to Thursday for SEQUENCE:2. Finally it > changes to Friday for SEQUENCE:3". If ANY of the REQUESTs between > SEQUENCE:0 and SEQUENCE:3 are missing then its not possible to > properly determine which Friday instance the Organizer is referring > to. Right? Wrong. If I got SEQUENCE:0, and then SEQUENCE:3 for UID:xyzzy, I would ask for a REFRESH of UID:xyzzy, and defer processing until I got SEQUENCE:3 (or greater, but then the SEQUENCE:3 data would be discarded). When I have SEQUENCE:3, I can now use the RECURRENCE-ID (relative to that data) to determine what I need to change. I don't need to track the intermediate changes, since my processing can be as simple as deleting all the data I have for SEQUENCE:0 before I process SEQUENCE:3 (this is a little too simple to be friendly, but the idea is sound). > > You never need to track deltas. A CUA saves the latest SEQUENCE > > and applies ADDs and CANCELs to that. > > Please show the iTIP properties on how Toms CUA would deal with a > missed SEQUENCE message. Ive asked before for it and Ive waited > almost 2 weeks for some but nothng yet. When I notice a gap in the sequence, I either have the complete new data (no RECURRENCE-ID in the REQUEST I got), or I can ask for complete data (by asking for a REFRESH on the UID). > I do agree about tracking deltas not being need in general though as > each iTIP message is a complete snapshot (excluding REPLYs and > CANCELs) of the entry or instances involved. However the only way > to get from "RECURRENCE-ID on Wednesday for SEQUENCE:1" to > "RECURRENCE-ID on Friday for SEQUENCE:3" is to apply the missing > DTSTART value from SEQUENCE:2 that you never got. Ask for SEQUENCE:3, drop the data for SEQUENCE:1 when it comes in, then process the RECURRENCE-ID relative to SEQUENCE:3. If you can trace instances from seq:1 to seq:3 (most likely because they are they haven't changed), you're free to do so, but I don't see that it's a requrement. When the Organizer updates the SEQUENCE, the world is different, and she needs to let people know. Please help me understand if this model is broken, and if so, how. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Thu Jun 12 16:53: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 QAA26655 for ; Thu, 12 Jun 2003 16:53: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 h5CKhKrb080566 for ; Thu, 12 Jun 2003 13:43: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 h5CKhKXf080565 for ietf-calendar-bks; Thu, 12 Jun 2003 13:43: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 h5CKhJrb080560 for ; Thu, 12 Jun 2003 13:43: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 h5CKhDbt022510 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 Jun 2003 13:43:19 -0700 Message-ID: <3EE8E5D8.3070700@Royer.com> Date: Thu, 12 Jun 2003 14:43: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" Subject: Re: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090107030605040008080800" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090107030605040008080800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > You are STILL missing the point. > As the Chair I have a current sequence number. All the accepts/declines > are based on that sequence number. If I have an accept but it is from a > previous sequence number than the state of that attendee is WAITING FOR > RESPONSE. You are waiting them to REPLY/SEQENCE: - YES. > Now I (under your rules ) bump the sequence number and send a Cancel to > invitee A. No other invitees are sent any kind of message. > Now Notes sequence number is 1 lager than all existing accepts/declines. > Thus all invitees are now in WAITING FOR RESPONSE state. The ORGANIZER-CUA does not need to send a REQUEST for every change. It has to bump the SEQUENCE number for CANCEL. However you could optimize your code knowing that the ONLY thing that you did was remove ATTENDEEs, and bump the SEQUENCE in the ORGANIZER copy as specified, not send a new REQUEST, update the status as if the ATTENDEE's already replied as before. If/When that object changes in a way that otherwise updates the SEQUENCE and modifies data in the object that the application deems needed, then send them REQUEST/SEQUENCE: and they would never care, they would just REPLY never needing to know or caring why they missed SEQUENCE. As the specs mandate that higher SEQUENCESs obsolete lower SEQUENCE numbers for the same UID they would have to throw away the old data anyway. The SEQUENCE is updated under specific rules by '1'. However the ORGANIZER-CUA does not need to send them unless needed. The ATTENDEE-CUA already has to be coded to process objects out of order and with missing SEQUENCES. And as iTIP (or iCAL?) specifies that a newer SEQUENCE obsoletes all older with the same UID, then the ATTENDEE-CUA would have no problem processing SEQUENCE: -AND- You *could* in your CUA notice if you happened to get one that looks like SEQUENCE: and the only difference is missing ATTENDEEs, have your CUA auto-REPLY without ATTENDEE-CU intervention. One of the reasons for this being mandated is to allow for flexible scheduling needs based on the application. In some usages - The ATTENDEE may really need the other ATTENDEE lists, in many (most?) an ATTENDEE may never care. By forcing the above iTIP/iCAL model - both needs can be satisfied. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090107030605040008080800 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTIyMDQzMDRaMCMGCSqGSIb3DQEJBDEWBBSF aQQSpGJAmpngLgbfrQth4gBl4zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAm239dmiM9zkJ hIXUV9rCAYT2QMKsLViVceg477pbdke8fSKN+xDE5h7jZYQr47HyyzUi23M6xnQO8kj14X+Z dJffUFJAe65Zd5zp0c7Y9lKQRjwPjl1zKJ2xY7XkH2npPGiGf42lQAOl26JXVhPwJJhNSQ5/ gnOnVnxvW/LtvkLY7eY0AyQ+JeE9EGKO0fqodiXmqrXjmVbJtKWyHx73KZ18GBcQZhYKybda N+ULX1uedg+Ke/m+h4BoJ64MwMVLWt2sTAboFif2pFOr/PHJTA1wgD2w5s2x9MDHouMMAMvk Cx+sBeVlw10oEvLnhqgI2m8vBCqVtD1QNZNhAuqXPwAAAAAAAA== --------------ms090107030605040008080800-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 16:55: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 QAA26727 for ; Thu, 12 Jun 2003 16:55: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 h5CKkhrb080687 for ; Thu, 12 Jun 2003 13:46:43 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CKkhkE080686 for ietf-calendar-bks; Thu, 12 Jun 2003 13:46:43 -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 h5CKkfrb080681 for ; Thu, 12 Jun 2003 13:46: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 h5CKkbbt022542 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 Jun 2003 13:46:43 -0700 Message-ID: <3EE8E6A7.8010301@Royer.com> Date: Thu, 12 Jun 2003 14:46:31 -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="------------ms070808080900020704070606" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070808080900020704070606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 05/30/2003 04:53:56 PM: > > 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. > > You can easily if the RECURRENCE-ID never changes. 1) Unless you do not have it because you joined the event after SEQUENCE:0 was obsoleted. 2) Unless NONE of the current instances match up to ANY of the original instances. > Unless Doug or George can demonstate how to resync, etc using a delta > model I suggest we make a strong WG note to remove the misleading text > from the next revision of 2445 and move on. You do not have to SYNC - simply do a REFRESH and get the latest object version. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070808080900020704070606 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTIyMDQ2MzJaMCMGCSqGSIb3DQEJBDEWBBQ3 ECJO9ZA1rZWsQx1yh+V73J4vHzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEApgk0ZavSfjN0 0gQEUn/WMOVvCx8NC6aSW0YM3XYfKIbvzOKmWFl8yr9XNFNG88ufTkGbA/ybzc0M8tq4De9T Ovdd/KgFK2Km/DoLDYrgwjRgANgER2bqHnaCFItSJszoB+39zcyGr1NSsdxFDjRKYKrbs5A/ 6ppj0k34nhflj5D731xkWwy5Pc6Ic3KvshPEe2ZSdJ1H5Is+maz9a2K4AXQ41/ji9EuNxUFB tVps120UDdkREjT0zPFfPElOCgbrFqtazCh1KxzL5E+6WYzsjelF9Mn/9LcEaaxUqFVLZkcE xYbhbBbV1FxNSRuqMxJu9wqsDBLdbl4SA3oCX267RAAAAAAAAA== --------------ms070808080900020704070606-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 17:30: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 RAA27655 for ; Thu, 12 Jun 2003 17:30: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 h5CLJorb081697 for ; Thu, 12 Jun 2003 14:19: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 h5CLJnDT081696 for ietf-calendar-bks; Thu, 12 Jun 2003 14:19:50 -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 h5CLJnrb081690 for ; Thu, 12 Jun 2003 14:19:49 -0700 (PDT) (envelope-from arnaud.quillaud@sun.com) 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 h5CLJnYU016843 for ; Thu, 12 Jun 2003 15:19:49 -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 h5CLJnuc015361; Thu, 12 Jun 2003 14:19:49 -0700 (PDT) Received: from iabs-2k.red.iplanet.com (iabs-2k.red.iplanet.com [192.18.144.144]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with ESMTP id <0HGE00EP40L1CE@mpkmail.eng.sun.com>; Thu, 12 Jun 2003 14:19:49 -0700 (PDT) Date: Thu, 12 Jun 2003 14:19:52 -0700 From: Arnaud Quillaud Subject: RE: Fw: Correct handling of Recurrence-id To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rEilMy7XeepoiCE+6tv0Iw)"; DIFFERENCES=Content-Language Content-language: en-USA Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_rEilMy7XeepoiCE+6tv0Iw) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT > > > Unless Doug or George can demonstate how to resync, etc > using a delta > > model I suggest we make a strong WG note to remove the > misleading text > > from the next revision of 2445 and move on. > > You do not have to SYNC - simply do a REFRESH and get the > latest object > version. > But in Bruce model, you do *not* have to do a REFRESH. That sounds like a much simpler mechanism. So, what is the advantage of the changing recurrence-id model ? Arnaud --Boundary_(ID_rEilMy7XeepoiCE+6tv0Iw) Content-id: 0 Content-type: TEXT/html; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT >

> > Unless Doug or George can demonstate how to resync, etc
> using a delta
> > model I suggest we make a strong WG note to remove the
> misleading text
> > from the next revision of 2445 and move on.
>
> You do not have to SYNC - simply do a REFRESH and get the
> latest object
> version.
>
But in Bruce model, you do *not* have to do a REFRESH. That sounds like a much simpler mechanism.
So, what is the advantage of the changing recurrence-id model ?
Arnaud
--Boundary_(ID_rEilMy7XeepoiCE+6tv0Iw)-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 17:55: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 RAA28146 for ; Thu, 12 Jun 2003 17:55:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CLl4rb082776 for ; Thu, 12 Jun 2003 14:47:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CLl4Vl082775 for ietf-calendar-bks; Thu, 12 Jun 2003 14:47:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CLl3rb082769 for ; Thu, 12 Jun 2003 14:47: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 h5CLkwbt023131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 Jun 2003 14:47:04 -0700 Message-ID: <3EE8F4C6.5010504@Royer.com> Date: Thu, 12 Jun 2003 15:46:46 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.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="------------ms070901050607050405030707" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070901050607050405030707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Arnaud Quillaud wrote: > > > > > Unless Doug or George can demonstate how to resync, etc > > using a delta > > > model I suggest we make a strong WG note to remove the > > misleading text > > > from the next revision of 2445 and move on. > > > > You do not have to SYNC - simply do a REFRESH and get the > > latest object > > version. > > > But in Bruce model, you do *not* have to do a REFRESH. That sounds like > a much simpler mechanism. > So, what is the advantage of the changing recurrence-id model ? > Arnaud You are totally hosed if you were not part of SEQUENCE:0 or somehow loose your data. And when 100% of the original instances change and you somehow missed an important change. The new instances will not map to the SEQUENCE:0 instances and you might apply them incorrectly. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070901050607050405030707 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTIyMTQ2NDZaMCMGCSqGSIb3DQEJBDEWBBTV tfniP1IsA/VZou5nMfm0xP68QDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAOJKmxHdk2Hsn i+QOoA307WS7hPocIte7zspcpgsIRhkRTYcqKmZXe1GE1ZEZ9nI8ShOU2Wec59Hi+wI7hDQU ZcIl8fk8AfvcWCi1wE66Z56MaeVLeugWZMl9OzxtryuMPp3cfUq1t219Y/jbKA6oZ22d+OK5 WlB9HyXElaSgzMNKDl6uhwcj6z+ZSprXB0/32XTmEVHV9igXSGlAxN+lo+euuoeHTQiAYs4o ERTuv5/nCPoozunH5ONkHLUb6lpOrXTRUZ27C9Pivt6EbkJ0Unw8iSYxb3hEiRxTZFgd0faa FVQLU14UPlH27vBoWlDqMVE9uCX0C8wfA9/si7nXdgAAAAAAAA== --------------ms070901050607050405030707-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 17:56:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28182 for ; Thu, 12 Jun 2003 17:55: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 h5CLn2rb082832 for ; Thu, 12 Jun 2003 14:49:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CLn2av082831 for ietf-calendar-bks; Thu, 12 Jun 2003 14:49:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CLn1rb082826 for ; Thu, 12 Jun 2003 14:49:01 -0700 (PDT) (envelope-from cco@asitturnsout.org) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 8E6E98D884 for ; Thu, 12 Jun 2003 14:49:02 -0700 (PDT) From: "Chris Olds" To: "ietf-calendar@imc.org" Subject: RE: Fw: Correct handling of Recurrence-id Date: Thu, 12 Jun 2003 14:49:02 -0700 Message-Id: <20030612213402.M31365@asitturnsout.org> In-Reply-To: References: X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 12 Jun 2003 14:19:52 -0700, Arnaud Quillaud wrote > > > > You do not have to SYNC - simply do a REFRESH and get the > > latest object > > version. > > > > But in Bruce model, you do *not* have to do a REFRESH. That sounds > like a much simpler mechanism. > > So, what is the advantage of the changing recurrence-id model ? In Bruce's model, I need to keep track of the original recurrence-id of each instance of an event as they evolve. In the REFRESH model, all I need to do is get the current version of the object and I'm done. If I have the current version, I can use a message with a RECURRENCE-ID to update my view of the object; if I don't have the current version, I just found that out and I can ask for a REFRESH and I'm done. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Thu Jun 12 18:21: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 SAA29915 for ; Thu, 12 Jun 2003 18:21: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 h5CMCCrb083927 for ; Thu, 12 Jun 2003 15:12: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 h5CMCCvV083926 for ietf-calendar-bks; Thu, 12 Jun 2003 15:12:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CMCBrb083921 for ; Thu, 12 Jun 2003 15:12:11 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EE8E5D8.3070700@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CANCEL and SEQUENCE usage MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 12 Jun 2003 18:14:48 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 06:12:05 PM, Serialize complete at 06/12/2003 06:12:05 PM Content-Type: multipart/alternative; boundary="=_alternative 0079AA8685256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079AA8685256D43_= Content-Type: text/plain; charset="US-ASCII" So you are creating either thrashing or causing complexity in Chair side coding to handle something that is not a problem if you do not bump the sequence number on a CANCEL. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/12/2003 04:43 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: CANCEL and SEQUENCE usage Robert_Ransdell@notesdev.ibm.com wrote: > > You are STILL missing the point. > As the Chair I have a current sequence number. All the accepts/declines > are based on that sequence number. If I have an accept but it is from a > previous sequence number than the state of that attendee is WAITING FOR > RESPONSE. You are waiting them to REPLY/SEQENCE: - YES. > Now I (under your rules ) bump the sequence number and send a Cancel to > invitee A. No other invitees are sent any kind of message. > Now Notes sequence number is 1 lager than all existing accepts/declines. > Thus all invitees are now in WAITING FOR RESPONSE state. The ORGANIZER-CUA does not need to send a REQUEST for every change. It has to bump the SEQUENCE number for CANCEL. However you could optimize your code knowing that the ONLY thing that you did was remove ATTENDEEs, and bump the SEQUENCE in the ORGANIZER copy as specified, not send a new REQUEST, update the status as if the ATTENDEE's already replied as before. If/When that object changes in a way that otherwise updates the SEQUENCE and modifies data in the object that the application deems needed, then send them REQUEST/SEQUENCE: and they would never care, they would just REPLY never needing to know or caring why they missed SEQUENCE. As the specs mandate that higher SEQUENCESs obsolete lower SEQUENCE numbers for the same UID they would have to throw away the old data anyway. The SEQUENCE is updated under specific rules by '1'. However the ORGANIZER-CUA does not need to send them unless needed. The ATTENDEE-CUA already has to be coded to process objects out of order and with missing SEQUENCES. And as iTIP (or iCAL?) specifies that a newer SEQUENCE obsoletes all older with the same UID, then the ATTENDEE-CUA would have no problem processing SEQUENCE: -AND- You *could* in your CUA notice if you happened to get one that looks like SEQUENCE: and the only difference is missing ATTENDEEs, have your CUA auto-REPLY without ATTENDEE-CU intervention. One of the reasons for this being mandated is to allow for flexible scheduling needs based on the application. In some usages - The ATTENDEE may really need the other ATTENDEE lists, in many (most?) an ATTENDEE may never care. By forcing the above iTIP/iCAL model - both needs can be satisfied. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.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 0079AA8685256D43_= Content-Type: text/html; charset="US-ASCII"
So you are creating either thrashing or causing complexity in Chair side coding to handle something that is not a problem if you do not bump the sequence number on a CANCEL.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/12/2003 04:43 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: CANCEL and SEQUENCE usage







Robert_Ransdell@notesdev.ibm.com wrote:
>
> You are STILL missing the point.
> As the Chair I have a current sequence number.  All the accepts/declines
> are based on that sequence number.  If I have an accept but it is from a
> previous sequence number than the state of that attendee is WAITING FOR
> RESPONSE.

You are waiting them to REPLY/SEQENCE:<new> - YES.


> Now I (under your rules ) bump the sequence number and send a Cancel to
> invitee A.  No other invitees are sent any kind of message.
> Now Notes sequence number is 1 lager than all existing accepts/declines.
> Thus all invitees are now in  WAITING FOR RESPONSE state.

The ORGANIZER-CUA does not need to send a REQUEST for every
change. It has to bump the SEQUENCE number for CANCEL.

However you could optimize your code knowing that the ONLY thing
that you did was remove ATTENDEEs, and bump the SEQUENCE in the
ORGANIZER copy as specified, not send a new REQUEST, update the status
as if the ATTENDEE's already replied as before. If/When that object
changes in a way that otherwise updates the SEQUENCE and modifies
data in the object that the application deems needed, then
send them REQUEST/SEQUENCE:<say what they have + 2> and they
would never care, they would just REPLY never needing to know
or caring why they missed SEQUENCE<what they have + 1>.
As the specs mandate that higher  SEQUENCESs obsolete
lower SEQUENCE numbers for the same UID they would
have to throw away the old data anyway.

The SEQUENCE is updated under specific rules by '1'.
However the ORGANIZER-CUA does not need to send them
unless needed. The ATTENDEE-CUA already has to be coded
to process objects out of order and with missing SEQUENCES.
And as iTIP (or iCAL?) specifies that a newer SEQUENCE
obsoletes all older with the same UID, then the ATTENDEE-CUA
would have no problem processing SEQUENCE:<what they have + one-or-more>

-AND-

You *could* in your CUA notice if you happened to get one that
looks like SEQUENCE:<more-than-yours> and the only difference is missing
ATTENDEEs, have your CUA auto-REPLY without ATTENDEE-CU intervention.


One of the reasons for this being mandated is to allow for flexible
scheduling needs based on the application. In some usages  - The ATTENDEE
may really need the other ATTENDEE lists, in many (most?) an ATTENDEE
may never care. By forcing the above iTIP/iCAL model - both needs can
be satisfied.

--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.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 0079AA8685256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 19:12:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01050 for ; Thu, 12 Jun 2003 19:12:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CN30rb085141 for ; Thu, 12 Jun 2003 16:03: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 h5CN30HG085140 for ietf-calendar-bks; Thu, 12 Jun 2003 16:03: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 h5CN2wrb085135 for ; Thu, 12 Jun 2003 16:02: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 h5CN2tbt023737 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 Jun 2003 16:03:00 -0700 Message-ID: <3EE9068F.809@Royer.com> Date: Thu, 12 Jun 2003 17:02:39 -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: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030608080303030002020000" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030608080303030002020000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > So you are creating either thrashing or causing complexity in Chair side > coding to handle something that is not a problem if you do not bump the > sequence number on a CANCEL. I am not adding any complexity, you are trying to ignore the fact that it IS in the spec. Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030608080303030002020000 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTIyMzAyMzlaMCMGCSqGSIb3DQEJBDEWBBTb xb53mdqzkn92JDlBO6+AlbH+iDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAwHK2YMPYTB+y eHTrPfauBp8gBbqR4EMzSf7d871q1nNdXXiSCpm0MlI8V5XGzvL8B9DNDcgXwLWPvtc2JnSh R3EKj54AIexvwkjoCq+1Mt6lyhm9LgzKVrkcxpHEu2975NhOM54+AxgSvdFFOL6ohugXsT3b JlLWkMg5RwQ3/ncH3iI+w8c73BTmbxD4C3x4/WqZsCTFRdP05uSuP8qK3ttgrx4vo8BRSu53 Bgk0ZaI2FaTzvf7zywzXkqqDTyiJA6J7HoWgDnI+bjkxz4/74J2tT9pTaSeVrEDrJD9dYivb BV1PKgsGnEWiOyzOxW502VVyb4xdrnnnn8FuceEvQAAAAAAAAA== --------------ms030608080303030002020000-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 19:33:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01434 for ; Thu, 12 Jun 2003 19:33:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CNQtrb085797 for ; Thu, 12 Jun 2003 16:26: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 h5CNQsQ2085796 for ietf-calendar-bks; Thu, 12 Jun 2003 16:26:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CNQrrb085788 for ; Thu, 12 Jun 2003 16:26:54 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EE9068F.809@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CANCEL and SEQUENCE usage MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 12 Jun 2003 19:29:31 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/12/2003 07:26:44 PM, Serialize complete at 06/12/2003 07:26:44 PM Content-Type: multipart/alternative; boundary="=_alternative 008081D685256D43_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 008081D685256D43_= Content-Type: text/plain; charset="US-ASCII" Its a BUG created when they merged the Remove and Cancel METHODS _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/12/2003 07:02 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: CANCEL and SEQUENCE usage Robert_Ransdell@notesdev.ibm.com wrote: > > So you are creating either thrashing or causing complexity in Chair side > coding to handle something that is not a problem if you do not bump the > sequence number on a CANCEL. I am not adding any complexity, you are trying to ignore the fact that it IS in the spec. Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.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 008081D685256D43_= Content-Type: text/html; charset="US-ASCII"
Its a BUG  created when they merged the Remove and Cancel METHODS
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/12/2003 07:02 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: CANCEL and SEQUENCE usage







Robert_Ransdell@notesdev.ibm.com wrote:
>
> So you are creating either thrashing or causing complexity in Chair side
> coding to handle something that is not a problem if you do not bump the
> sequence number on a CANCEL.

I am not adding any complexity, you are trying to ignore the fact
that it IS in the spec.



 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.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 008081D685256D43_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 12 20:02: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 UAA02057 for ; Thu, 12 Jun 2003 20:02: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 h5CNsLrb086494 for ; Thu, 12 Jun 2003 16:54: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 h5CNsLPI086493 for ietf-calendar-bks; Thu, 12 Jun 2003 16:54: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 h5CNsJrb086488 for ; Thu, 12 Jun 2003 16:54:20 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5CNsGbt024124 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 Jun 2003 16:54:21 -0700 Message-ID: <3EE912A2.40107@Royer.com> Date: Thu, 12 Jun 2003 17:54: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: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050407020500070000080605" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050407020500070000080605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Its a BUG created when they merged the Remove and Cancel METHODS Looking through the archive I can only find a 'CAP' REMOVE METHOD that was taken out of CAP, not an iTIP or iCAL properly. Not the same thing. And even if I missed it, that is how the WG bought off iTIP. And that method does work. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050407020500070000080605 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTIyMzU0MTBaMCMGCSqGSIb3DQEJBDEWBBRK 3uHQLr64llS/VOch0liUvi/VPzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEApaJ4F6GawuEF YzPlzg8RdsljAS4w/zKXbBDk2yZ13MKVw9pFEACIYGnjZOrcD5ZviehaFAOTvhSyRpjuOdF/ OL4rnW+n8294/MgcEni1ZHEksSaV2NxbV7oL1cwvYlwXF7tkAYtUIU9kf9DnZsPnTOErk1ZR RxcXxiVCT/qFi5JVFdbK7tCELDsD/8lmk2MbQpLk50+VkF5ulqKBEyRO7a7Oln3IwYpJPGqb CzN4+drMHe3xT3ziZhsW+xd/bJAntXITIM33VrMlFJiYvAlfzw2W6Eic56IebVkjcvAnepM3 Ly3S5OFH4GLfxcIa1T4ToyBkj4Qw08ZX+2AWh+M2VQAAAAAAAA== --------------ms050407020500070000080605-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 13:06:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13120 for ; Fri, 13 Jun 2003 13:06: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 h5DGrnrb062306 for ; Fri, 13 Jun 2003 09:53: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 h5DGrnfj062305 for ietf-calendar-bks; Fri, 13 Jun 2003 09:53:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DGrlrb062300 for ; Fri, 13 Jun 2003 09:53:48 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EE912A2.40107@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CANCEL and SEQUENCE usage MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Fri, 13 Jun 2003 12:56:20 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/13/2003 12:53:39 PM, Serialize complete at 06/13/2003 12:53:39 PM Content-Type: multipart/alternative; boundary="=_alternative 005C826A85256D44_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C826A85256D44_= Content-Type: text/plain; charset="US-ASCII" Lets assume your method of bumping the sequence on CANCEL sending to just the intended invitees and internally bumping all accepts/decline notices. What about the ones you have not received yet. If you had a large meeting and several people were removed over time the sequence would be bumped several times. Now one of the invitees gets back from vacation and accepts the meeting. You now receive and accept with sequence vastly different than your current. The only way to compensate for this is for chair now to keep track of current sequence and effective sequence not counting bumps from cancels. THAT'S STUPID since there IS NO PROBLEM IF YOU DON'T BUMP SEQUENCE ON CANCEL _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/12/2003 07:54 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: CANCEL and SEQUENCE usage Robert_Ransdell@notesdev.ibm.com wrote: > > Its a BUG created when they merged the Remove and Cancel METHODS Looking through the archive I can only find a 'CAP' REMOVE METHOD that was taken out of CAP, not an iTIP or iCAL properly. Not the same thing. And even if I missed it, that is how the WG bought off iTIP. And that method does work. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 005C826A85256D44_= Content-Type: text/html; charset="US-ASCII"
Lets assume your method of bumping the sequence on CANCEL sending to just the intended invitees and internally bumping all accepts/decline notices.
What about the ones you have not received yet.
If you had a large meeting and several people were removed over time the sequence would be bumped several times.
Now one of the invitees gets back from vacation and accepts the meeting.  You now receive and accept with sequence vastly different than your current.


The only way to compensate for this is for chair now to keep track of current sequence and effective sequence not counting bumps from cancels.


THAT'S STUPID since there IS NO PROBLEM IF YOU DON'T BUMP SEQUENCE ON CANCEL
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/12/2003 07:54 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: CANCEL and SEQUENCE usage







Robert_Ransdell@notesdev.ibm.com wrote:
>
> Its a BUG  created when they merged the Remove and Cancel METHODS

Looking through the archive I can only find a 'CAP' REMOVE METHOD
that was taken out of CAP, not an iTIP or iCAL properly.
Not the same thing.

And even if I missed it, that is how the WG bought off iTIP.
And that method does work.

--

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

                We Do Standards - You Need Standards
--=_alternative 005C826A85256D44_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 13:51: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 NAA15587 for ; Fri, 13 Jun 2003 13:51: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 h5DHe1rb064130 for ; Fri, 13 Jun 2003 10:40:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5DHe1fF064129 for ietf-calendar-bks; Fri, 13 Jun 2003 10:40:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DHe0rb064121 for ; Fri, 13 Jun 2003 10:40:00 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5DHdsbt001038 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 13 Jun 2003 10:40:00 -0700 Message-ID: <3EEA0C64.2080207@Royer.com> Date: Fri, 13 Jun 2003 11:39:48 -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: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010404030306020903020302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010404030306020903020302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Lets assume your method of bumping the sequence on CANCEL sending to > just the intended invitees and internally bumping all accepts/decline > notices. > What about the ones you have not received yet. Do them smartly. > If you had a large meeting and several people were removed over time the > sequence would be bumped several times. > Now one of the invitees gets back from vacation and accepts the meeting. > You now receive and accept with sequence vastly different than your > current. Do them smartly. > > The only way to compensate for this is for chair now to keep track of > current sequence and effective sequence not counting bumps from cancels. No - Do them smartly. > > THAT'S STUPID since there IS NO PROBLEM IF YOU DON'T BUMP SEQUENCE ON > CANCEL You can debate how you want it to go in the future. However no matter how stupid you think it is, that is the way it is. And it works. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010404030306020903020302 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTMxNzM5NDhaMCMGCSqGSIb3DQEJBDEWBBT1 rADKD+nBGQrmvETj0l5Abh5XtTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAbFZznY8JfYK4 e0eSULqljqonnTJBjcuCL+OYB5f4alqCMLpJWxxgVheni7o3aJ4A+3PTxwwq6slLJxvIPE3n CbvX0csZywWt/vZEVZ8+zc49gk9vmtajXVVSNEZfZVHv/ceVAWwhzqez6qggbWjgvm9SA2Y9 8ZiNsVDc0wUKkxJyHS10udBLw+LYflBFPa9vUMNkg5tjVvmvx9juFWoP7mGlOITKxgzHp/PM IEk2cR0h46u/bB0zOF9cQltjEm9bJE/dQWTrE9E+PbZOQySL9oPkpIA2/03k+lsfoZepRZi9 FybyoE42e0UiMwTN8wYFvWCAo8oVORZoTpz2kxY3MAAAAAAAAA== --------------ms010404030306020903020302-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 13:56: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 NAA15721 for ; Fri, 13 Jun 2003 13:56: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 h5DHlXrb064340 for ; Fri, 13 Jun 2003 10:47: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 h5DHlX2J064339 for ietf-calendar-bks; Fri, 13 Jun 2003 10:47:33 -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 h5DHlWrb064334 for ; Fri, 13 Jun 2003 10:47:32 -0700 (PDT) (envelope-from arnaud.quillaud@sun.com) 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 h5DHlWYU016293 for ; Fri, 13 Jun 2003 11:47:32 -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 h5DHlWuc008432; Fri, 13 Jun 2003 10:47:32 -0700 (PDT) Received: from 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 <0HGF00LYBLF8G6@mpkmail.eng.sun.com>; Fri, 13 Jun 2003 10:47:32 -0700 (PDT) Date: Fri, 13 Jun 2003 10:47:36 -0700 From: Arnaud Quillaud Subject: Re: Fw: Correct handling of Recurrence-id To: "ietf-calendar@imc.org" Message-id: <3EEA0E38.9010706@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_W/VN/whduQOfzowIGviNQA)" 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: <3EE8F4C6.5010504@Royer.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --Boundary_(ID_W/VN/whduQOfzowIGviNQA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7BIT Doug Royer wrote: > > > Arnaud Quillaud wrote: > >> > >> > > Unless Doug or George can demonstate how to resync, etc >> > using a delta >> > > model I suggest we make a strong WG note to remove the >> > misleading text >> > > from the next revision of 2445 and move on. >> > >> > You do not have to SYNC - simply do a REFRESH and get the >> > latest object >> > version. >> > >> But in Bruce model, you do *not* have to do a REFRESH. That sounds >> like a much simpler mechanism. >> So, what is the advantage of the changing recurrence-id model ? >> Arnaud > > > You are totally hosed if you were not part of SEQUENCE:0 I've asked Bruce about a new attendee being added to the VEVENT (I've included both my question and his response). In his view, the recurrence set (RRULE+RDATE+EXDATE+RDATE) that would be sent to this new attendee would be the original one so there wouldn't be any ambiguity. > > or somehow loose your data. If you loose your data, you're hosed, whatever the model. All you can do is to do a REFRESH, that is, if you still have the ORGANIZER and UID. The REFRESH would work (see above). > > > And when 100% of the original instances change and you > somehow missed an important change. The new instances > will not map to the SEQUENCE:0 instances and you > might apply them incorrectly. You mean, if the organizer change the recurrence set (e.g. change the event from weekly to bi-weekly) ? I guess, Bruce rules needs to be refined to say that the list of recurrence-id refers to the latest recurrence set (RRULE+RDATE-EXRULE-EXDATE) sent by the organizer. Bruce ? BTW, is there a section in iTIP that talks about handling of exceptions on the attendee side, when receiving a REQUEST with a new recurrence set ? For example: 1st REQUEST RRULE: weekly on mondays for ever 2nd REQUEST RECURRENCE-ID=second monday DTSTART=second tuesday 3rd REQUEST RRULE: weekly on wednesday Does the 3rd REQUEST implicitly means cancel of the second tuesday's instance ? Or should the attendee consider it still valid unless it receives a CANCEL ? Thanks, Arnaud --Boundary_(ID_W/VN/whduQOfzowIGviNQA) Content-type: message/rfc822; name="imap-message://arnaudq@thestork.eng.sun.com/ietf-calendar#59" Return-path: 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> for arnaudq@ims-ms-daemon (ORCPT arnaud.quillaud@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 Content-type: multipart/alternative; boundary="Boundary_(ID_Knsmr7yj4wp/o9BgFXQG7A)" 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: --Boundary_(ID_Knsmr7yj4wp/o9BgFXQG7A) Content-type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7BIT 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_Knsmr7yj4wp/o9BgFXQG7A) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT 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_Knsmr7yj4wp/o9BgFXQG7A)-- --Boundary_(ID_W/VN/whduQOfzowIGviNQA) Content-type: message/rfc822; name="imap-message://arnaudq@thestork.eng.sun.com/ietf-calendar#87" Return-path: Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.Eng.Sun.COM [129.146.1.45]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with ESMTP id <0HFK00BUHCGNXE@mpkmail.eng.sun.com> for arnaudq@ims-ms-daemon (ORCPT arnaud.quillaud@sun.com); Tue, 27 May 2003 13:48:23 -0700 (PDT) Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4RKmMKw023038 for ; Tue, 27 May 2003 13:48:23 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by sunmail2.sfbay.sun.com (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4RKmDV18724; Tue, 27 May 2003 13:48:13 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4RKmB3K025863; Tue, 27 May 2003 14:48:12 -0600 (MDT) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP; Tue, 27 May 2003 20:48:04 +0000 (Z) Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP; Tue, 27 May 2003 20:48:04 +0000 (Z) Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Tue, 27 May 2003 20:48:03 +0000 (Z) Received: from above.proper.com (above.proper.com [208.184.76.39]) by relay12.sun.com with ESMTP; Tue, 27 May 2003 20:48:03 +0000 (Z) 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 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) 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 Date: Tue, 27 May 2003 16:22:30 -0400 From: Bruce_Kahn@notesdev.ibm.com Subject: Re: Correct handling of Recurrence-id In-reply-to: <3ECEB990.8080906@ENG.SUN.COM> Sender: owner-ietf-calendar@mail.imc.org To: ietf-calendar@imc.org Message-id: MIME-version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Content-type: multipart/alternative; boundary="Boundary_(ID_yIfcCbPhU9iLfFw8srWXOA)" 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 Precedence: bulk X-Authentication-warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f List-Unsubscribe: List-Archive: List-Id: This is a multipart message in MIME format. --Boundary_(ID_yIfcCbPhU9iLfFw8srWXOA) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT 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... --Boundary_(ID_yIfcCbPhU9iLfFw8srWXOA) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT
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... --Boundary_(ID_yIfcCbPhU9iLfFw8srWXOA)-- --Boundary_(ID_W/VN/whduQOfzowIGviNQA)-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 14:07:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16159 for ; Fri, 13 Jun 2003 14:07: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 h5DHwDrb064737 for ; Fri, 13 Jun 2003 10:58: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 h5DHwD6O064736 for ietf-calendar-bks; Fri, 13 Jun 2003 10:58: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 (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DHwCrb064731 for ; Fri, 13 Jun 2003 10:58:12 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EEA0C64.2080207@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CANCEL and SEQUENCE usage MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Fri, 13 Jun 2003 14:00:24 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/13/2003 01:58:00 PM, Serialize complete at 06/13/2003 01:58:00 PM Content-Type: multipart/alternative; boundary="=_alternative 0062602E85256D44_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0062602E85256D44_= Content-Type: text/plain; charset="US-ASCII" !!!!!!!IT DOES NOT WORK!!!!!!!!! --- THIS HAS BEEN POINTED OUT SEVERAL TIMES IN THE PAST IN 1999 FORWARD. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/13/2003 01:39 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: CANCEL and SEQUENCE usage Robert_Ransdell@notesdev.ibm.com wrote: > > Lets assume your method of bumping the sequence on CANCEL sending to > just the intended invitees and internally bumping all accepts/decline > notices. > What about the ones you have not received yet. Do them smartly. > If you had a large meeting and several people were removed over time the > sequence would be bumped several times. > Now one of the invitees gets back from vacation and accepts the meeting. > You now receive and accept with sequence vastly different than your > current. Do them smartly. > > The only way to compensate for this is for chair now to keep track of > current sequence and effective sequence not counting bumps from cancels. No - Do them smartly. > > THAT'S STUPID since there IS NO PROBLEM IF YOU DON'T BUMP SEQUENCE ON > CANCEL You can debate how you want it to go in the future. However no matter how stupid you think it is, that is the way it is. And it works. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 0062602E85256D44_= Content-Type: text/html; charset="US-ASCII"
!!!!!!!IT DOES NOT WORK!!!!!!!!!   --- THIS HAS BEEN POINTED OUT SEVERAL TIMES IN THE PAST IN 1999 FORWARD.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/13/2003 01:39 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: CANCEL and SEQUENCE usage







Robert_Ransdell@notesdev.ibm.com wrote:
>
> Lets assume your method of bumping the sequence on CANCEL sending to
> just the intended invitees and internally bumping all accepts/decline
> notices.


> What about the ones you have not received yet.

Do them smartly.

> If you had a large meeting and several people were removed over time the
> sequence would be bumped several times.
> Now one of the invitees gets back from vacation and accepts the meeting.
>  You now receive and accept with sequence vastly different than your
> current.

Do them smartly.

>
> The only way to compensate for this is for chair now to keep track of
> current sequence and effective sequence not counting bumps from cancels.

No - Do them smartly.

>
> THAT'S STUPID since there IS NO PROBLEM IF YOU DON'T BUMP SEQUENCE ON
> CANCEL

You can debate how you want it to go in the future. However no
matter how stupid you think it is, that is the way it is. And it works.


--

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

                We Do Standards - You Need Standards
--=_alternative 0062602E85256D44_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 15:10:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19576 for ; Fri, 13 Jun 2003 15:10: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 h5DIxnrb067132 for ; Fri, 13 Jun 2003 11:59: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 h5DIxntk067130 for ietf-calendar-bks; Fri, 13 Jun 2003 11:59:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DIxmrb067125 for ; Fri, 13 Jun 2003 11:59:48 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5DIxXbt001822 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 13 Jun 2003 11:59:45 -0700 Message-ID: <3EEA1F0B.6030502@Royer.com> Date: Fri, 13 Jun 2003 12:59:23 -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: <3EE8F4C6.5010504@Royer.com> <3EEA0E38.9010706@sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020102050401070104040509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020102050401070104040509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Arnaud Quillaud wrote: >> You are totally hosed if you were not part of SEQUENCE:0 > > > I've asked Bruce about a new attendee being added to the VEVENT (I've > included both my question and his response). In his view, the recurrence > set (RRULE+RDATE+EXDATE+RDATE) that would be sent to this new attendee > would be the original one so there wouldn't be any ambiguity. Perhaps his implementations keeps old SEQUENCE / object sets around. I would not bet my CUA on it. And how do you ask for the original object so you can then know those now old RDATEs in the original object? >> >> or somehow loose your data. > > > If you loose your data, you're hosed, whatever the model. All you can do > is to do a REFRESH, that is, if you still have the ORGANIZER and UID. > The REFRESH would work (see above). Yes you can do a REFRESH, however you will get the latest object with the latest SEQUENCE value, not the original. So you will not get the original recurrence set and in that model you will not be able to re-create the original recurence-id set. >> >> >> And when 100% of the original instances change and you >> somehow missed an important change. The new instances >> will not map to the SEQUENCE:0 instances and you >> might apply them incorrectly. > > > You mean, if the organizer change the recurrence set (e.g. change the > event from weekly to bi-weekly) ? > I guess, Bruce rules needs to be refined to say that the list of > recurrence-id refers to the latest recurrence set > (RRULE+RDATE-EXRULE-EXDATE) sent by the organizer. > Bruce ? If it refers to he 'latest recurrence set' - we agree. It can not then ever refer to the 'original' recurrence set unless the 'latest' just happens to be '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 --------------ms020102050401070104040509 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTMxODU5MjNaMCMGCSqGSIb3DQEJBDEWBBT3 L9CUFUUi8xhy0ap9hbqTIQS12DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAi3fLdV30yclf 1ZZ3Lx+XG/yAb3QQNzIdIbm6knYHWp/LugDT3hc7K862WItO030L2CZs0zMIWlLux01+9kZ0 CyF472wEAcD8WEp4O8zMYnuwu9IjBEEpC0zdSuQz2J75b7rpFIcpKRb+mwwjJJW28cJZbJKq mLYh6ChzCFwwfT/6MbWr+vo3+FSa/1MQwSajaAOh3euI2ChvXq+WGCiCXebYe8IhifVY5xv6 YywG062H0pSwwjvVKEFjzuXDE7law5HnsttnOFvqy0Mb4EC9ZwoeC+F3SCeUG0QClUZ1dWzi itxun8A9/ZwlvH6FXtIwz5DzqPrEeIl+bZPqwLXyGgAAAAAAAA== --------------ms020102050401070104040509-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 15:13:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19941 for ; Fri, 13 Jun 2003 15:13: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 h5DJ38rb067296 for ; Fri, 13 Jun 2003 12:03: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 h5DJ378H067295 for ietf-calendar-bks; Fri, 13 Jun 2003 12:03: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 h5DJ36rb067290 for ; Fri, 13 Jun 2003 12:03: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 h5DJ2wbt001865 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 13 Jun 2003 12:03:05 -0700 Message-ID: <3EEA1FDC.7010805@Royer.com> Date: Fri, 13 Jun 2003 13:02: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: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060402060403090408060102" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060402060403090408060102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > !!!!!!!IT DOES NOT WORK!!!!!!!!! --- THIS HAS BEEN POINTED OUT SEVERAL > TIMES IN THE PAST IN 1999 FORWARD. It works just fine in my implementation. It works just fine interoperating with other vendors. If you mean that you do not want to send out new REQUESTS, okay. Or if you mean you do not like to keep track of things rather then send the new REQUESTS, okay. But it works just fine and it is how it is documented. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060402060403090408060102 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTMxOTAyNTJaMCMGCSqGSIb3DQEJBDEWBBRw iRYkG6vlW9xMyGe7o6Wq/kXf1TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYq70COnJ3UhN GKnClOshHmp01o7T1eaBi6Z/5/Whf/eKmhaP6Ir5ceMYMswcA34kzvqaCyBw1zBmP3ixsZ2w dqOf0VZAP6dkYiqxRKtr28ZfJ2flN+UPcjtaeT0ZwMAUEcik4Zayc8ofXhydp+aGw4G7XfBL JquOdCOV3PAt5GV+yXrRhm9fGF9RWaqbBhTLqfKcHboGQs/FcQAMP6BiedE2miZqjYOSkZvg BjoOiW7psxBqNch2yWB2cc4zhs89e+19ykUtDBDJb11nwxvHVZlKBV6GuetV36uqkm9gizoP 3AErk7SFonfL0OEqntLgYN3+YWR5Gp7fBgSpEmz8uAAAAAAAAA== --------------ms060402060403090408060102-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 15:23: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 PAA20533 for ; Fri, 13 Jun 2003 15:23:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DJDprb067987 for ; Fri, 13 Jun 2003 12:13:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5DJDp5b067986 for ietf-calendar-bks; Fri, 13 Jun 2003 12:13:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DJDorb067980 for ; Fri, 13 Jun 2003 12:13:50 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5DJDibt001943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 13 Jun 2003 12:13:50 -0700 Message-ID: <3EEA2262.70304@Royer.com> Date: Fri, 13 Jun 2003 13:13:38 -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: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070208030700080808010202" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070208030700080808010202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > !!!!!!!IT DOES NOT WORK!!!!!!!!! --- THIS HAS BEEN POINTED OUT SEVERAL > TIMES IN THE PAST IN 1999 FORWARD. In addition, there is NO case where bumping the sequence number and sending or re-sending an object breaks 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 --------------ms070208030700080808010202 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTMxOTEzMzhaMCMGCSqGSIb3DQEJBDEWBBT9 CROJTwzQbaZofw3D/SIbZXd6WDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAlJGc0F52QCxi y4Sw6GBV3fiv+HFcE/qX7ey2Q7uvzu94aIW9QFQNBSeiVJb6oSleV8LRzl3HdaxcdSFggyhz a6FjvxrSgeyYURrCQxyz9ylqJtVJ/TRtyCE4QrMVjUwW/h823smmimNCK4do/FNbYkQUNK3o TES6K+GcMUZ8TI2I7ihROW4EXSFw2Sx9cBmUosdsidPRkFc+r1d+kNOAQUWyYIl0mfFzSkQ7 OrpFLFDhGr1c4l4iqaShpzkIbQ3hrP0u9xv/yqR06SrXDkZDDc3A1D2TtrcgLbqoKq2sjyK5 038iQmAtgycLVBD/akfgfkFHA4kfGonDytcmywHbLQAAAAAAAA== --------------ms070208030700080808010202-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 16:15: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 QAA21693 for ; Fri, 13 Jun 2003 16:15: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 h5DK4trb071337 for ; Fri, 13 Jun 2003 13:04: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 h5DK4tVk071336 for ietf-calendar-bks; Fri, 13 Jun 2003 13:04:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DK4srb071331 for ; Fri, 13 Jun 2003 13:04:54 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EEA2262.70304@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CANCEL and SEQUENCE usage MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Fri, 13 Jun 2003 16:07:29 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/13/2003 04:04:55 PM, Serialize complete at 06/13/2003 04:04:55 PM Content-Type: multipart/alternative; boundary="=_alternative 006E029285256D44_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E029285256D44_= Content-Type: text/plain; charset="US-ASCII" In all cases where the sequence is bumped, ALL invitees must be notified of a RESCHEDULE. They must re-accept/decline. All existing responses become invalid. Overhead is way too high for sending an un-invite to one person. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/13/2003 03:13 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: CANCEL and SEQUENCE usage Robert_Ransdell@notesdev.ibm.com wrote: > > !!!!!!!IT DOES NOT WORK!!!!!!!!! --- THIS HAS BEEN POINTED OUT SEVERAL > TIMES IN THE PAST IN 1999 FORWARD. In addition, there is NO case where bumping the sequence number and sending or re-sending an object breaks 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 --=_alternative 006E029285256D44_= Content-Type: text/html; charset="US-ASCII"
In all cases where the sequence is bumped, ALL invitees must be notified of a RESCHEDULE.  They must re-accept/decline.  All existing responses become invalid.   Overhead is way too high for sending an un-invite to one person.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/13/2003 03:13 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: CANCEL and SEQUENCE usage







Robert_Ransdell@notesdev.ibm.com wrote:
>
> !!!!!!!IT DOES NOT WORK!!!!!!!!!   --- THIS HAS BEEN POINTED OUT SEVERAL
> TIMES IN THE PAST IN 1999 FORWARD.


In addition, there is NO case where bumping the sequence
number and sending or re-sending an object breaks 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
--=_alternative 006E029285256D44_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 17:11: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 RAA23260 for ; Fri, 13 Jun 2003 17:11: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 h5DL1Crb073116 for ; Fri, 13 Jun 2003 14:01: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 h5DL1Ct5073115 for ietf-calendar-bks; Fri, 13 Jun 2003 14:01: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 h5DL1Arb073110 for ; Fri, 13 Jun 2003 14:01: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 h5DL13bt002867 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 13 Jun 2003 14:01:11 -0700 Message-ID: <3EEA3B8A.7090407@Royer.com> Date: Fri, 13 Jun 2003 15:00:58 -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: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000506030400030808030808" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000506030400030808030808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > In all cases where the sequence is bumped, ALL invitees must be notified > of a RESCHEDULE. They must re-accept/decline. All existing responses > become invalid. Overhead is way too high for sending an un-invite to > one person. We finally agree - it works, you simply don't like it. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000506030400030808030808 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTMyMTAwNThaMCMGCSqGSIb3DQEJBDEWBBSZ jzyyzgPYDN0XjUZXMoIdPYGIyzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAT4Nqv7JSCpRe 62CHet7OcyBRIIcGcOYv0qnyp/KbgRFwClnnBYRG1USC0RcgCj4Om5P44RA6rqVXtvyItMET S1Xcl6XuoTxzavarkgEyPdWwdGH0F+930t5XozLUGOkVhjaBekJuKoVlFZ5JTBkeQLaLDmp2 JPiVgbDDPwRKWrW9zOEeD+xG+HGM2EUayCmlEAMRODpwKrvHiTgHfaon2ax+QUuYPu38w5uP uyZCUcc96RUC4MdvnSMgHOjB0ZRCjBlsAHR18lpiJJZscratcF04LUP1XW3VkH6s4SlSNIEY wLQcF1kqY3+w0+Ibmr9KeDR9udmFG2f6bkWBuZYlswAAAAAAAA== --------------ms000506030400030808030808-- From owner-ietf-calendar@mail.imc.org Fri Jun 13 19:39:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28515 for ; Fri, 13 Jun 2003 19:39:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DNQurb077229 for ; Fri, 13 Jun 2003 16:26: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 h5DNQu6p077228 for ietf-calendar-bks; Fri, 13 Jun 2003 16:26:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DNQtrb077222 for ; Fri, 13 Jun 2003 16:26:55 -0700 (PDT) (envelope-from arnaud.quillaud@sun.com) 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 h5DNQqLv008431; Fri, 13 Jun 2003 16:26:52 -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 h5DNQqNh023909; Fri, 13 Jun 2003 16:26:52 -0700 (PDT) Received: from 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 <0HGG005C714S8C@mpkmail.eng.sun.com>; Fri, 13 Jun 2003 16:26:52 -0700 (PDT) Date: Fri, 13 Jun 2003 16:26:56 -0700 From: Arnaud Quillaud Subject: Re: Fw: Correct handling of Recurrence-id To: Robert Ransdell/Westford/IBM , ietf-calendar@imc.org Message-id: <3EEA5DC0.60007@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; 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.1) Gecko/20020826 References: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Robert Ransdell/Westford/IBM wrote: > > You can only change individual dates or ADD to the repeat dates. You > can not re-roll the repeat rule. > > If you re-roll the repeat rule. This is a new meeting.. UNID changes That would probably be a good simplification of the protocol but where does that come from ? I don't see anywhere in iCAL/iTIP that the organizer can't change the RRULE. Or did I miss something ? Arnaud > > > > _____________________ > Note: new email address > > tom_ransdell@notesdev.ibm.com > > > *Arnaud Quillaud * > Sent by: owner-ietf-calendar@mail.imc.org > > 06/13/2003 01:47 PM > > To > "ietf-calendar@imc.org" > cc > > Subject > Re: Fw: Correct handling of Recurrence-id > > > > > > > > > Doug Royer wrote: > > > > > > > Arnaud Quillaud wrote: > > > >> > > >> > > Unless Doug or George can demonstate how to resync, etc > >> > using a delta > >> > > model I suggest we make a strong WG note to remove the > >> > misleading text > >> > > from the next revision of 2445 and move on. > >> > > >> > You do not have to SYNC - simply do a REFRESH and get the > >> > latest object > >> > version. > >> > > >> But in Bruce model, you do *not* have to do a REFRESH. That sounds > >> like a much simpler mechanism. > >> So, what is the advantage of the changing recurrence-id model ? > >> Arnaud > > > > > > You are totally hosed if you were not part of SEQUENCE:0 > > I've asked Bruce about a new attendee being added to the VEVENT (I've > included both my question and his response). In his view, the recurrence > set (RRULE+RDATE+EXDATE+RDATE) that would be sent to this new attendee > would be the original one so there wouldn't be any ambiguity. > > > > > or somehow loose your data. > > If you loose your data, you're hosed, whatever the model. All you can do > is to do a REFRESH, that is, if you still have the ORGANIZER and UID. > The REFRESH would work (see above). > > > > > > > And when 100% of the original instances change and you > > somehow missed an important change. The new instances > > will not map to the SEQUENCE:0 instances and you > > might apply them incorrectly. > > > You mean, if the organizer change the recurrence set (e.g. change the > event from weekly to bi-weekly) ? > I guess, Bruce rules needs to be refined to say that the list of > recurrence-id refers to the latest recurrence set > (RRULE+RDATE-EXRULE-EXDATE) sent by the organizer. > Bruce ? > > > > BTW, is there a section in iTIP that talks about handling of exceptions > on the attendee side, when receiving a REQUEST with a new recurrence set ? > For example: > 1st REQUEST > RRULE: weekly on mondays for ever > > 2nd REQUEST > RECURRENCE-ID=second monday > DTSTART=second tuesday > > 3rd REQUEST > RRULE: weekly on wednesday > > Does the 3rd REQUEST implicitly means cancel of the second tuesday's > instance ? Or should the attendee consider it still valid unless it > receives a CANCEL ? > > Thanks, > > Arnaud > > > > ----- Message from Arnaud Quillaud on > Fri, 23 May 2003 17:15:12 -0700 ----- > *To:* > Bruce_Kahn@notesdev.ibm.com > *cc:* > ietf-calendar@imc.org > *Subject:* > Re: Correct handling of Recurrence-id > > > > _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 > > > ----- Message from Bruce_Kahn@notesdev.ibm.com on Tue, 27 May 2003 > 16:22:30 -0400 ----- > *To:* > ietf-calendar@imc.org > *Subject:* > Re: Correct handling of Recurrence-id > > > > > 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... From owner-ietf-calendar@mail.imc.org Fri Jun 13 21:49: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 VAA01678 for ; Fri, 13 Jun 2003 21:49: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 h5E1dqrb080690 for ; Fri, 13 Jun 2003 18:39:52 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5E1dqkR080689 for ietf-calendar-bks; Fri, 13 Jun 2003 18:39:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5E1dorb080684 for ; Fri, 13 Jun 2003 18:39:51 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5E1dlbt004940 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 13 Jun 2003 18:39:52 -0700 Message-ID: <3EEA7CD7.5000801@Royer.com> Date: Fri, 13 Jun 2003 19:39:35 -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: <3EEA5DC0.60007@sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070501070104080500080706" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070501070104080500080706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Arnaud Quillaud wrote: > > Robert Ransdell/Westford/IBM wrote: > >> >> You can only change individual dates or ADD to the repeat dates. You >> can not re-roll the repeat rule. >> >> If you re-roll the repeat rule. This is a new meeting.. UNID changes > > > That would probably be a good simplification of the protocol but where > does that come from ? > I don't see anywhere in iCAL/iTIP that the organizer can't change the > RRULE. Or did I miss something ? It is not in iCAL/iTIP - your right. There is no such restriction or rule. If they want to do that they would have to re-issue all of the REQUESTs so that the CUA's inserted all of the new entries. That method could get tricky if the users do not allow scheduling conflicts. So the ORGANIZER would have to CANCEL them in one pass then re-issues them with the new UID in a second pass. There would be no way to have the CUA automatically issue REPLYs because the CUA would have no way of knowing they were the same object with the UID renamed. You would have hope that they did not re-use the now free time for another meeting between the CANCEL and REQUEST. Any vendor specific data that the CUA stored in the objects that is not populated back to the world that was saved with the object would get tossed out as there would not be a way to re-attach it to the seemingly unrelated UID. And in the CAP world that means that ALL user-local VALARMs and VCARS would be tossed and the CU would have to manually re-insert them back into the new objects. I do not think that is a simplification. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070501070104080500080706 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTQwMTM5MzVaMCMGCSqGSIb3DQEJBDEWBBSf NTOd8zRmrm5rxGHbd6ZDSBo/mzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAio7+i9Bmv+sD yrsB70zSx1A3iuQwNwop6cMOlgLYq2d6cDt/3QJFgQt2dbBuvPj3VqbvUlzKpxVF/TIzrY5b g+lK4/eNWobHh0M56/jqtfRPyfP6PC8K/YQfHjc5uDXW6O+A0iiXM2GhPMRBqmomSsOm0e56 ZIBl9FLfBnbUsykIds3xfcbfoCr4E119wtlQC+/fYYITcpMLTMr9gGw0wPt30K6e3da8lNc9 Tx8wxLnCrLa+TN8DpF54HbJk880djm1ANQTvlIaNNG5A128KG1KmjS/oXHMzIJNCXOKVl8lQ /3ufdsxKIQwgJ2sPgF7VxIMHEGILPtBXWxWqV2ntmAAAAAAAAA== --------------ms070501070104080500080706-- From owner-ietf-calendar@mail.imc.org Sat Jun 14 19:51: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 TAA07777 for ; Sat, 14 Jun 2003 19:51: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 h5ENckrb057361 for ; Sat, 14 Jun 2003 16:38: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 h5ENckmv057360 for ietf-calendar-bks; Sat, 14 Jun 2003 16:38:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ENcfrb057355 for ; Sat, 14 Jun 2003 16:38: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 h5ENcWbt014721 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 14 Jun 2003 16:38:37 -0700 Message-ID: <3EEBB1EB.8010301@Royer.com> Date: Sat, 14 Jun 2003 17:38:19 -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: CAP ABNF Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030000040508030607040602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030000040508030607040602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I am starting to go through the CAP abnf looking for errors. Below is the CAP ABNF from CAP draft-10. The lines are numbered and if you have comments could you include the line number or line number range with your comments. 1 2 calprops = 2*( 3 4 ; 'prodid' and 'version' are both REQUIRED, 5 ; but MUST NOT occur more than once. 6 ; 7 prodid /version / 8 9 ; These are optional, but MUST NOT occur 10 ; more than once. 11 ; 12 calscale / 13 method / 14 cmd / 15 16 ; These are optional, and may occur more 17 ; than once. 18 ; 19 target / other-props ) 20 21 other-props = *(x-prop) *(iana-prop) *(x-prop) 22 23 iana-prop = ; Any property registered by IANA directly or 24 ; included in an RFC that may be applied to 25 ; the component and within the rules published. 26 27 x-prop = ; As defined in [iCAL] 28 29 icalbody = calprops component 30 31 ; If the "VCALENDAR" component contains the "CMD" 32 ; property then the 'component' is optional: 33 ; 34 / calprops ; Which MUST include a "CMD" property 35 36 alarmc = "BEGIN" ":" "VALARM" CRLF 37 alarm-seq 38 other-props 39 (audioprop / dispprop / emailprop / procprop) 40 "END" ":" "VALARM" CRLF 41 42 alarm-seq = "SEQUENCE" alarmseqparams ":" posint0 CRLF 43 44 alarmseqparams = other-params [";" local-param] other-params 45 46 ; Where DIGIT is defined in [iCAL] 47 ; 48 posint0 = 1*DIGIT 49 posint1 = posintfirst 1*DIGIT 50 51 ; A number starting with 1 through 9. 51 ; A number starting with 1 through 9. 52 ; 53 posintfirst = %x31-39 54 55 other-params = *(";" xparam) *(";" iana-params) *(";" xparam) 56 57 iana-params = ; Any parameter registered by IANA directly or 58 ; included in an RFC that may be applied to 59 ; the property and within the rules published. 60 61 trigger = "TRIGGER" 1*(";" enable-param) (trigrel / trigabs) 62 63 capurl = "cap://" csid [ "/" relcalid ] 64 csid = hostport ; As defined in Section 3.2.2 of RFC 2396 65 relcalid = *uric ; As defined in Section 2 of RFC 2396 66 67 cal-query = "SELECT" SP cap-val SP 68 "FROM" SP comp-name SP 69 "WHERE" SP cap-expr 70 71 / "SELECT" SP cap-cols SP 72 "FROM" SP comp-name 73 74 cap-val = cap-cols / param 75 / ( cap-val "," cap-val ) 76 77 ; NOTE: there is NO space around the "," on 78 ; the next line 79 cap-cols = cap-col / ( cap-cols "," cap-col) 80 / "*" 81 82 ; A 'cap-col' is: 83 ; 84 ; Any property name ('cap-prop') found in the component 85 ; named in the 'comp-name' used in the "FROM" clause. 86 ; 87 ; SELECT ORGANIZER FROM VEVENT ... 88 ; 89 ; OR 90 ; 91 ; A component name ('comp-name') of an existing component 92 ; contained inside of the 'comp-name' used in the "FROM" 93 ; clause. 94 ; 95 ; SELECT VALARM FROM VEVENT ... 96 ; 97 ; OR 98 ; 99 ; A component name ('comp-name') of an existing 100 ; component contained inside of the 'comp-name' used 101 ; in the "FROM" clause followed by a property 102 ; name ('cap-prop') to be selected from that component. 103 ; (comp-name "." cap-prop) 104 ; 105 ; SELECT VALARM.TRIGGER FROM VEVENT ... 106 107 cap-col = comp-name 108 / comp-name "." cap-prop 109 / cap-prop 110 111 comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" 112 / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" 113 / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" 114 / x-comp / iana-comp 115 116 cap-prop = ; A property that may be in the 'cap-comp' named 117 ; in the "SELECT" clause. 118 119 cap-expr = "(" cap-expr ")" 120 / cap-term 121 122 cap-term = cap-expr SP cap-logical SP cap-expr 123 / cap-factor 124 125 cap-logical= "AND" / "OR" 126 127 cap-factor = cap-colval SP cap-oper SP col-value 128 / cap-colval SP "NOT LIKE" SP col-value 129 / cap-colval SP "LIKE" SP col-value 130 / cap-colval SP "IS NULL" 131 / cap-colval SP "IS NOT NULL" 132 / col-value SP "NOT IN" cap-colval" 133 / col-value SP "IN" cap-colval" 134 / "STATE()" "=" ( "BOOKED" 135 / "UNPROCESSED" 136 / "DELETED" ) 137 138 cap-colval = cap-col / param 139 140 param = "PARAM(" cap-col "," cap-param ")" 141 142 cap-param = ; Any parameter that may be contained in the cap-col 143 ; in the supplied PARAM() function 144 145 col-value = col-literal 146 / "SELF()" 147 / "CAL-OWNERS()" 148 / "CAL-OWNERS(" cal-address ")" 149 / "CURRENT-TARGET()" 150 151 cal-address = ; A CALID as define by CAP 152 153 col-literal = "'" literal-data "'" 154 155 literal-data = ; Any data that matches the value type of the 156 ; column that is being compared. That is you can 157 ; not compare PRIORITY to "some string" because 158 ; PRIORITY has a value type of integer. If it is 159 ; not preceded by the LIKE element, any '%' and '_' 160 ; characters in the literal data are not treated as 161 ; wildcard characters and do not have to be backslash 162 ; escaped. 163 ; 164 ; OR 165 ; 166 ; If the literal-data is preceded by the LIKE 167 ; element it may also contain the '%' and '_' 168 ; wildcard characters. And if the literal data 169 ; that is comparing contains any '%' or '_' 170 ; characters, they MUST BE backslash escaped as 171 ; described in the notes below in order for them not 172 ; to be treated as wildcard characters. 173 174 cap-oper = "=" 175 / "!=" 176 / "<" 177 / ">" 178 / "<=" 179 / ">=" 180 181 182 SP = ; A single white space ASCII character 183 ; (value in HEX %x20). 184 185 x-comp = ; As defined in [iCAL] section 4.6 186 187 iana-comp = ; As defined in [iCAL] section 4.6 188 189 upn = "@" 190 / [ dot-atom-text ] "@" dot-atom-text 191 192 ; dot-atom-text is defined in RFC 2822 193 194 ; NOTE: "CAL-OWNERS(cal-address)" 195 ; and "NOT CAL-OWNERS(cal-address)" 196 ; are both NOT allowed below. 197 ; 198 upn-filter = "CAL-OWNERS()" / 199 200 "NOT CAL-OWNERS()" / 201 "*" / 202 [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text ) 203 204 ; dot-atom-text is defined in RFC 2822 205 206 action-param = ";" "ACTION" "=" ( "ASK" / "ABORT" ) 207 ; If 'action-param' is supplied then 208 ; 'latency-param' MUST BE supplied. 209 210 enable-param = "ENABLE" "=" boolean 211 212 id-param = ";" "ID" "=" unique-id 213 ; The text value supplied is a unique value 214 ; shared between the CUA and CS to uniquely 215 ; identify the instance of command in the 216 ; the current CUA session. The value has 217 ; no meaning to other CUAs or other sessions. 218 219 unique-id = ; text 220 221 latency-param = ";" "LATENCY" "=" latency-sec 222 ; The value supplied in the time in seconds. 223 ; If 'latency-param' is supplied then 224 ; 'action-param' MUST BE supplied. 225 226 latency-sec = posint1 227 228 local-param = "LOCAL" "=" boolean 229 230 localize-param = ";" "LOCALIZE" "=" beep-localize 231 ; The value supplied MUST BE one value from the initial 232 ; [BEEP] greeting 'localize' attribute specifying 233 ; the locale to use for error messages during 234 ; this instance of the command sent. 235 236 beep-localize = ; text 237 238 option-param = ";" "OPTIONS" "=" cmd-specific 239 240 cmd-specific = ; The value supplied is dependent on the 241 ; CMD value. See the specific CMDs for the 242 ; correct values to use for each CMD. 243 244 allow-conflict = "ALLOW-CONFLICT" other-params ":" boolean CRLF 245 246 attcounter = "ATT-COUNTER" other-params ":" cal-address CRLF 247 248 CALID = "CALID" other-params ":" calid CRLF 249 250 calmaster = "CALMASTER" other-params ":" uri CRLF 251 252 uri = ; IANA registered uri as defined in [iCAL] 253 254 cap-version = "CAP-VERSION" other-params ":" text CRLF 255 256 carid = "CARID" other-params ":" text CRLF 257 258 car-level = "CAR-LEVEL" ":" other-params : car-level-values 259 260 car-level-values = ( "CAR-NONE" / "CAR-MIN" / "CAR-FULL-1" 261 / other-levels ) 262 263 other-levels = ; Any name published in an RFC for a "CAR-LEVEL" 264 ; property value. 265 266 components = "COMPONENTS" other-params ":" comp-list CRLF 267 268 ; All of the following MUST BE supplied in any order. 269 ; 270 comp-list-req = "VCALSTORE" "," "VCALENDAR" "," "VTIMEZONE" "," 271 "VREPLY", "VAGENDA", "STANDARD", "DAYLIGHT" 272 273 ; At least one MUST BE supplied. The same value 274 ; MUST NOT occur more than once. 275 ; 276 comp-list-min = ( "," "VEVENT") / ( "," "VTODO") / ( "," "VJOURNAL" ) 277 278 ; The same value MUST NOT occur 279 ; more than once. 280 ; 281 comp-list-opt = ( "," "VFREEBUSY" ) / ( "," "VALARM" ) 282 ( "," "VCAR" ) / ( "," "VQUERY" ) 283 ( "," x-comp ) / ( "," iana-comp ) 284 285 comp-list = comp-list-req 1*3comp-list-min *comp-list-opt 286 287 288 *("," comp-list-names) comp-name 289 290 csid = "CSID" other-params ":" capurl CRLF 291 292 default-charset = "DEFAULT-CHARSET" other-params ":" text 293 *( "," text) CRLF 294 295 default-locale = "DEFAULT-LOCALE" other-params ":" language 296 *( "," language) CRLF 297 298 language = Text identifying a locale, as defined in [CHARPOL] 299 300 default-tzid = "DEFAULT-TZID" other-params 301 ":" [tzidprefix] text 302 *("," [tzidprefix] text) CRLF 303 304 def-vcars = "DEFAULT-VCARS" other-params ":" text 305 *( "," text ) CRLF 306 307 deny = "DENY" other-params ":" upn-filter CRLF 308 309 expand = "EXPAND" other-params ":" ("TRUE" / "FALSE") CRLF 310 311 grant = "GRANT" other-params ":" upn-filter CRLF 312 313 max-comp-size = "MAX-COMP-SIZE" other-params ":" posint0 CRLF 314 315 mindate = "MINDATE" other-params ":" date-time CRLF 316 317 name = "MULTIPART" other-params ":" text *( "," text) CRLF 318 319 name = "NAME" nameparam ":" text CRLF 320 321 nameparam = other-params [ ";" languageparam ] other-params 322 323 languageparam = ; As defined in [iCAL]. 324 325 owner = "OWNER" other-params ":" upn CRLF 326 327 perm = "PERMISSION" other-params ":" permvalue CRLF 328 329 permvalue = ( "SEARCH" / "CREATE" / "DELETE" / "MODIFY" / all ) 330 331 all = "*" 332 333 query = "QUERY" other-params ":" cal-query CRLF 334 335 queryid = "QUERYID" other-params ":" text CRLF 336 337 rstatus = "REQUEST-STATUS" rstatparam ":" 338 statcode ";" *(statdesc ) ";" *(extdata) 339 340 rstatparam = other-params [";" languageparam] other-params 341 342 statcode = 1*DIGIT *("." 1*DIGIT) 343 ;Hierarchical, numeric return status code 344 345 statdesc = text 346 ;An optional textual status description, content is 347 ;decided by the implementer. May be empty. 348 349 extdata = text 350 ; Textual exception data. For example, the offending 351 ; property name and value or complete property line. 352 353 query-level = "QUERY-LEVEL" other-params 354 ":" ( "CAL-QL-1" / "CAL-QL-NONE") CRLF 355 356 recur-limit = "RECUR-LIMIT" other-params ":" posint1 CRLF 357 358 recur-expand = "RECUR-EXPAND" other-params ":" boolean CRLF 359 360 restrict = "RESTRICTION" other-params ":" cal-query CRLF 361 362 scope = "SCOPE" other-params ":" cal-query CRLF 363 364 stores-expanded = "STORES-EXPANDED" other-params ":" boolean CRLF 365 366 target = "TARGET" other-params ":" capurl CRLF 367 368 transp = "TRANSP" other-params ":" transvalue CRLF 369 370 transvalue 371 = "OPAQUE" ;Blocks or opaque on busy time searches. 372 / "TRANSPARENT" ;Transparent on busy time searches. 373 374 / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time 375 ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects 376 ; can overlap it. 377 378 / "OPAQUE-NOCONFLICT" ; Opaque on busy time 379 ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects 380 ; can overlap it. 381 ; 382 ;Default value is OPAQUE 383 384 agenda = "BEGIN" ":" "VAGENDA" CRLF 385 agendaprop 386 *(icalobject) ; as defined in [iCAL] 387 "END" ":" "VAGENDA" CRLF 388 389 agendaprop = *( 390 ; The following MUST occur exactly once. 391 ; 392 allow-conflict / calid / calscale / created 393 / default-charset / default-locale 394 / default-tzid / last-modified / 395 396 ; The following MUST occur at least once. 397 ; and the value MUST NOT be empty. 398 399 / owner 400 401 ; The following are optional, 402 ; and MAY occur more than once. 403 404 / name / related-to / other-props / x-comp 405 ) 406 407 agendac = "BEGIN" ":" "VAGENDA" CRLF 408 agendacprop 409 *(icalobject) ; as defined in [iCAL] 410 "END" ":" "VAGENDA" CRLF 411 412 agendacprop = *( 413 ; The following MUST occur exactly once. 414 ; 415 allow-conflict / calid / calscale 416 / default-charset / default-locale 417 / default-tzid / 418 419 ; The following MUST occur at least once. 420 ; and the value MUST NOT be empty. 421 ; 422 / owner 423 424 ; The following are optional, 425 ; and MAY occur more than once. 426 ; 427 / name / related-to / other-props / x-comp 428 ) 429 430 calstorec = "BEGIN" ":" "VCALSTORE" CRLF 431 calstoreprop 432 *(vagendac) 433 "END" ":" "VCALSTORE" CRLF 434 435 calstoreprop = *( 436 437 ; the following MUST occur exactly once 438 439 allow-conflict / calscale / calmaster 440 / created / csid / default-charset 441 / default-locale / default-vcars 442 / default-tzid / last-modified 443 444 ; the following are optional, 445 ; and MAY occur more than once 446 447 / name / related-to / other-props / x-comp 448 ) 449 450 carc = "BEGIN" ":" "VCAR" CRLF 451 carprop 1*rightc 452 "END" ":" "VCAR" CRLF 453 454 carprop = 1*( 455 456 ; 'carid' is REQUIRED, 457 ; but MUST NOT occur more than once 458 459 carid / 460 461 ; the following are OPTIONAL, 462 ; and MAY occur more than once 463 464 name / other-props 465 ) 466 467 rightc = "BEGIN" ":" "VRIGHT" CRLF 468 rightprop 469 "END" ":" "VRIGHT" CRLF 470 471 rightprop = 2*( 472 473 ; either 'grant' or 'deny' MUST 474 ; occur at least once 475 ; and MAY occur more than once 476 477 grant / deny / 478 479 ; 'permission' MUST occur at least once 480 ; and MAY occur more than once 481 482 permission / 483 484 ; the following are optional, 485 ; and MAY occur more than once 486 487 scope / restriction / other-props 488 489 ) 490 491 replyc = "BEGIN" ":" "VREPLY" CRLF 492 any-prop-or-comp 493 "END" ":" "VREPLY" CRLF 494 495 any-prop-or-comp = ; Zero or more iana or experimental 496 ; properties and components, in any order. 497 498 queryc = "BEGIN" ":" "VQUERY" CRLF 499 queryprop 500 "END" ":" "VCAR" CRLF 501 502 queryprop = 1*( 503 504 ; 'queryid' is OPTIONAL but MUST NOT occur 505 ; more than once. If the "TARGET" property 506 ; is supplied then the "QUERYID" property 507 ; MUST BE supplied. 508 ; 509 queryid / target 510 511 ; 'expand' is OPTIONAL but MUST NOT occur 512 ; more than once. 513 514 expand 515 516 ; the following are OPTIONAL, and MAY occur 517 ; more than once 518 ; 519 / name / other-props 520 521 ; the following MUST occur at least once. 522 ; 523 / query 524 525 ) 526 527 cmd = "CMD" ( 528 / abort-cmd 529 / continue-cmd 530 / create-cmd 531 / delete-cmd 532 / generate-uid-cmd 533 / get-capability-cmd 534 / identify-cmd 535 / modify-cmd 536 / move-cmd 537 / reply-cmd 538 / search-cmd 539 / set-locale-cmd 540 / other-cmd 541 ) CRLF 542 543 544 other-cmd ; Any command published as an RFC or any 545 ; vendor specific "x-" command. 546 547 option-value = paramtext ; As defined in [iCAL] 548 549 abort-cmd = abortparam ":" "ABORT" 550 551 abortparam = *( 552 553 ; the following are optional, 554 ; but MUST NOT occur more than once 555 556 id-param 557 / localize-param 558 559 ; the following is optional, 560 ; and MAY occur more than once 561 562 / other-params 563 564 ) 565 566 567 The REPLY of any "ABORT" command is: 568 569 abort-reply = "BEGIN" ":" "VCALENDAR" CRLF 570 calprops 571 abort-vreply 572 "END" ":" "VCALENDAR" CRLF 573 574 abort-vreply = "BEGIN" ":" "VREPLY" CRLF 575 request-status 576 other-props 577 "END" ":" "VREPLY" CRLF 578 579 continue-cmd = continueparam ":" "CONTINUE" 580 581 continueparam = *( 582 583 ; the following are optional, 584 ; but MUST NOT occur more than once 585 586 id-param 587 / localize-param 588 / latency-param 589 590 ; the following MUST occur exactly once and only 591 ; when the latency-param has been supplied and 592 ; MUST NOT be supplied if the latency-param is 593 ; not supplied. 594 595 / action-param 596 597 ; the following are optional, 598 ; and MAY occur more than once 599 600 / other-params 601 ) 602 603 The REPLY of any "CONTINUE" command is: 604 605 continue-reply = "BEGIN" ":" "VCALENDAR" CRLF 606 calprops 607 continue-vreply 608 "END" ":" "VCALENDAR" CRLF 609 610 continue-vreply = "BEGIN" ":" "VREPLY" CRLF 611 request-status 612 other-props 613 "END" ":" "VREPLY" CRLF 614 615 create-cmd = createparam ":" "CREATE" 616 617 createparam = *( 618 619 ; the following are optional, 620 ; but MUST NOT occur more than once 621 622 id-param 623 / localize-param 624 / latency-param 625 626 ; the following MUST occur exactly once and only 627 ; when the latency-param has been supplied and 628 ; MUST NOT be supplied if the latency-param is 629 ; not supplied. 630 631 / action-param 632 633 ; the following is optional, 634 ; and MAY occur more than once 635 636 / other-params 637 ) 638 639 create-reply = "BEGIN" ":" "VCALENDAR" CRLF 640 creply-props 641 1*(create-vreply) 642 "END" ":" "VCALENDAR" CRLF 643 644 create-vreply = "BEGIN" ":" "VREPLY" CRLF 645 created-id 646 request-status 647 other-props 648 "END" ":" "VREPLY" CRLF 649 650 ; Where the id is appropriate for the 651 ; type of object created: 652 ; 653 ; VAGENDA = calid 654 ; VALARM = sequence 655 ; VCAR = carid 656 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid 657 ; VQUERY = queryid 658 ; VTIMEZONE = tzid 659 ; x-component = x-id 660 ; 661 created-id = ( calid / carid / uid / queryid / 662 tzid / sequence / x-id) 663 664 x-id = ; An ID for an x-component. 665 666 creply-props = 4*( 667 ; These are REQUIRED and MUST NOT occur 668 ; more than once. 669 ; 670 prodid /version / target / reply-cmd 671 672 ; These are optional, and may occur more 673 ; than once. 674 ; 675 other-props 676 677 create-object = "BEGIN" ":" "VCALENDAR" CRLF 678 ; If 'calprops' contain the "METHOD" property 679 ; then this 'create-object' component MUST 680 ; conform to [iTIP] restrictions. 681 ; 682 ; calprops MUST include 'create-cmd' 683 ; 684 calprops 685 other-props 686 1*(create-comp) 687 "END" ":" "VCALENDAR" CRLF 688 689 ; NOTE: The 'VCALSTORE' component is not included in 690 ; 'create-comp' as it is out of scope for CAP to create 691 ; a new CS. 692 ; 693 create-comp = agendac / carc / queryc 694 / timezonec / freebusyc 695 / eventc / todoc / journalc 696 / iana-comp / x-component 697 698 delete-cmd = deleteparam ":" "DELETE" 699 700 deleteparam = *( 701 702 ; the following are optional, 703 ; but MUST NOT occur more than once 704 ; 705 id-param 706 / localize-param 707 / latency-param 708 / option-param "MARK" 709 710 ; The following MUST occur exactly once and only 711 ; when the latency-param has been supplied and 712 ; MUST NOT be supplied if the latency-param is 713 ; not supplied. 714 ; 715 / action-param 716 717 ; the following is optional, 718 ; and MAY occur more than once 719 ; 720 / other-params 721 ) 722 723 delete-reply = "BEGIN" ":" "VCALENDAR" CRLF 724 calprops ; MUST include 'reply-cmd' 725 *(delete-vreply) 726 "END" ":" "VCALENDAR" CRLF 727 728 729 delete-vreply = "BEGIN" ":" "VREPLY" CRLF 730 deleted-id 731 request-status 732 "END" ":" "VREPLY" CRLF 733 734 ; Where the id is appropriate for the 735 ; type of object deleted: 736 ; 737 ; VAGENDA = calid 738 ; VCAR = carid 739 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid 740 ; VQUERY = queryid 741 ; ALARM = sequence 742 ; VTIMEZONE = tzid 743 ; x-component = x-id 744 ; An instance = uid recurid 745 ; 746 deleted-id = ( calid / carid / uid / uid recurid 747 / queryid / tzid / sequence / x-id ) 748 749 generate-uid-cmd = genuidparam ":" "GENERATE-UID" 750 751 genuidparam = *( 752 753 ; The following are optional, 754 ; but MUST NOT occur more than once. 755 756 id-param 757 / localize-param 758 / latency-param 759 760 ; The following MUST occur exactly once and only 761 ; when the latency-param has been supplied and 762 ; MUST NOT be supplied if the latency-param is 763 ; not supplied. 764 765 / action-param 766 767 ; The following is optional, 768 ; and MAY occur more than once. 769 770 / other-params 771 772 ; The following MUST BE supplied exactly once. 773 ; The value specifies the number of UIDs to 774 ; be returned. 775 776 / option-param posint1 777 778 ) 779 780 gen-reply = "BEGIN" ":" "VCALENDAR" CRLF 781 calprops ; Which MUST include 'reply-cmd' 782 1*(gen-vreply) 783 "END" ":" "VCALENDAR" CRLF 784 785 786 gen-vreply = "BEGIN" ":" "VREPLY" CRLF 787 1*(uid) 788 request-status 789 "END" ":" "VREPLY" CRLF 790 791 get-capability-cmd = capibiltyparam ":" "GET-CAPABILITY" 792 793 capibiltyparam = *( 794 795 ; the following are optional, 796 ; but MUST NOT occur more than once 797 ; 798 id-param / localize-param / latency-param 799 800 ; the following MUST occur exactly once and only 801 ; when the latency-param has been supplied and 802 ; MUST NOT be supplied if the latency-param is 803 ; not supplied. 804 ; 805 / action-param 806 807 ; the following is optional, 808 ; and MAY occur more than once 809 ; 810 / other-params 811 ) 812 813 cap-vreply = "BEGIN" ":" "VCALENDAR" CRLF 814 ; The following properties may be in any order. 815 ; 816 prodid 817 version 818 reply-cmd 819 other-props 820 "BEGIN" ":" "VREPLY" CRLF 821 ; The following properties may be in any order. 822 ; 823 cap-version 824 car-level 825 components 826 stores-expanded 827 maxdate 828 mindate 829 itip-version 830 max-comp-size 831 multipart 832 query-level 833 recur-accepted 834 recur-expand 835 recur-limit 836 other-props 837 "END" ":" "VREPLY" CRLF 838 "END" ":" "VCALENDAR" CRLF 839 840 identify-cmd = identifyparam ":" "IDENTIFY" 841 842 identifyparam = *( 843 844 ; the following are optional, 845 ; but MUST NOT occur more than once 846 847 id-param 848 / localize-param 849 / latency-param 850 851 ; the following MUST occur exactly once and only 852 ; when the latency-param has been supplied and 853 ; MUST NOT be supplied if the latency-param is 854 ; not supplied. 855 856 / action-param 857 858 ; the following is optional, 859 ; and MAY occur more than once 860 861 / other-params 862 863 ; The value is the UPN of the requested 864 ; identity. If not supplied it is a request 865 ; to return to the original authenticated identity. 866 867 / option-param upn 868 869 ) 870 871 modify-cmd = modifyparam ":" "MODIFY" 872 873 modifyparam = *( 874 875 ; the following are optional, 876 ; but MUST NOT occur more than once 877 878 id-param 879 / localize-param 880 / latency-param 881 882 ; the following MUST occur exactly once and only 883 ; when the latency-param has been supplied and 884 ; MUST NOT be supplied if the latency-param is 885 ; not supplied. 886 887 / action-param 888 889 ; the following is optional, 890 ; and MAY occur more than once 891 892 / other-params 893 894 ) 895 896 move-cmd = moveparam ":" "MOVE" 897 898 moveparam = *( 899 900 ; the following are optional, 901 ; but MUST NOT occur more than once 902 903 id-param 904 / localize-param 905 / latency-param 906 907 ; the following MUST occur exactly once and only 908 ; when the latency-param has been supplied and 909 ; MUST NOT be supplied if the latency-param is 910 ; not supplied. 911 912 / action-param 913 914 ; the following is optional, 915 ; and MAY occur more than once 916 917 / other-params 918 919 ) 920 921 move-reply = "BEGIN" ":" "VCALENDAR" CRLF 922 calprops 923 1*(move-vreply) 924 "END" ":" "VCALENDAR" CRLF 925 926 927 move-vreply = "BEGIN" ":" "VREPLY" CRLF 928 move-id 929 request-status 930 "END" ":" "VREPLY" CRLF 931 932 ; Where the id is appropriate for the 933 ; type of object moved: 934 ; 935 ; VAGENDA = calid 936 ; VCAR = carid 937 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid 938 ; VQUERY = queryid 939 ; ALARM = sequence 940 ; An instance = uid recurid 941 ; x-component = x-id 942 ; 943 move-id = ( calid / carid / uid / uid recurid 944 / queryid / tzid / sequence / x-id) 945 946 reply-cmd = replyparam ":" "REPLY" 947 948 replyparam = *( 949 950 ; The 'id' parameter value MUST BE exactly the 951 ; same as the value sent in the original 952 ; CMD property. If the original CMD did 953 ; not have an 'id' parameter, then the 'id' 954 ; MUST NOT be supplied in the REPLY. 955 956 id-param 957 958 ; the following is optional, 959 ; and MAY occur more than once 960 961 / other-params 962 963 ) 964 965 search-cmd = searchparam ":" "SEARCH" 966 967 searchparam = *( 968 969 ; the following are optional, 970 ; but MUST NOT occur more than once 971 972 id-param 972 id-param 973 / localize-param 974 / latency-param 975 976 ; the following MUST occur exactly once and only 977 ; when the latency-param has been supplied and 978 ; MUST NOT be supplied if the latency-param is 979 ; not supplied. 980 981 / action-param 982 983 ; the following is optional, 984 ; and MAY occur more than once 985 986 / other-params 987 988 ) 989 990 setlocale-cmd = setlocaleparam ":" "SET-LOCALE" 991 992 setlocaleparam = *( 993 994 ; the following are optional, 995 ; but MUST NOT occur more than once 996 997 id-param 998 / localize-param 999 / latency-param 1000 / setlocale-option 1001 1002 ; the following MUST occur exactly once and only 1003 ; when the latency-param has been supplied and 1004 ; MUST NOT be supplied if the latency-param is 1005 ; not supplied. 1006 1007 / action-param 1008 1009 ; the following is optional, 1010 ; and MAY occur more than once 1011 1012 / other-params 1013 1014 setlocal-option = option-param newlocale 1015 1016 newlocale = ; Any locale supplied in the initial [BEEP] 1017 ; "greeting" "localize" parameter and 1018 ; and any charset supported by the CS 1019 ; and listed in the DEFAULT-CHARSET property 1020 ; of the VCALSTORE. 1021 1022 ) 1023 1024 setlocale-reply = "BEGIN" ":" "VCALENDAR" CRLF 1025 calprops 1026 1*(setlocale-vreply) 1027 "END" ":" "VCALENDAR" CRLF 1028 1029 setlocale-vreply = "BEGIN" ":" "VREPLY" CRLF 1030 request-status 1031 "END" ":" "VREPLY" CRLF 1032 1033 timeout-cmd = continueparam ":" "TIMEOUT" 1034 1035 timeoutparam = *( 1036 1037 ; the following are optional, 1038 ; but MUST NOT occur more than once 1039 1040 id-param 1041 / localize-param 1042 1043 / other-params 1044 1045 ) 1046 -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030000040508030607040602 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTQyMzM4MTlaMCMGCSqGSIb3DQEJBDEWBBRJ Igy6Xw2mAIXXH3M0W8w1yDLzwTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAWARZ9RFsKznX Wu/x7Hh93pWB+WGdvaL9BmqZBWXQ5Si07uig1DP2bzMz1X94WByZu1ds602/JrDm4w7MgSNm FwxyNYUfAN1tFqLpNFUbzOfcHbQuhJQPO1Xqrd9dwCde3wN+DIaZhAb595eZ75B9ninFZil1 nkbq1IQRecWc/g7vQdFiThm0GU1YMpxZQyYxhwoPmYj+PHLNYvSwCxmz46pvo6oYmWFV1YTn Qgvvk+JlZYG6KMzETo/9AXrqxqe8HJUmobFKtjXUCWlDB5uolwZ/xqMpZsb0hj7uOTpt+Ay4 ZD0fQn9q2uqPrDffk4JcrGYYllUzp0AnMsoZRn7LmQAAAAAAAA== --------------ms030000040508030607040602-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 05:32: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 FAA06289 for ; Mon, 16 Jun 2003 05:32: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 h5G9HSrb083310 for ; Mon, 16 Jun 2003 02:17: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 h5G9HSIJ083309 for ietf-calendar-bks; Mon, 16 Jun 2003 02:17:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.lisanza.net (harrie.inet.it [213.92.1.193]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G9HPrb083272 for ; Mon, 16 Jun 2003 02:17:26 -0700 (PDT) (envelope-from harrie@inet.it) Received: from inet.it (localhost [127.0.0.1]) by localhost.lisanza.net (8.12.9/8.12.6) with ESMTP id h5G9MFwX001346; Mon, 16 Jun 2003 11:22:16 +0200 (CEST) Date: Mon, 16 Jun 2003 11:22:12 +0200 Subject: Re: CAP ABNF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel To: "ietf-calendar@imc.org" From: Harrie Hazewinkel In-Reply-To: <3EEBB1EB.8010301@Royer.com> Message-Id: <0371683E-9FDC-11D7-A4C7-0003934A5A7E@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit HI, I am quit new to this, but something I noticed while implementing a parser for CAPQL. Also the ABNF is not inline with the examples and earlier was said the examples are all valid. See earlier thread with subject "CAP-QUERY ABNF disagrees with examples" and line 136 below. On top of this, I am wondering if an order clause is useful as part of the capql query part. The order now depends on the columns given in the 'SELECT' part 'cap-val', but it is sometimes usefull to be more specific. On Sunday, June 15, 2003, at 01:38 AM, Doug Royer wrote: > > I am starting to go through the CAP abnf looking for errors. Below is > the CAP ABNF from CAP draft-10. > 66 > 67 cal-query = "SELECT" SP cap-val SP > 68 "FROM" SP comp-name SP > 69 "WHERE" SP cap-expr > 70 > 71 / "SELECT" SP cap-cols SP > 72 "FROM" SP comp-name > 73 > 74 cap-val = cap-cols / param > 75 / ( cap-val "," cap-val ) > 76 > 77 ; NOTE: there is NO space around the "," on > 78 ; the next line > 79 cap-cols = cap-col / ( cap-cols "," cap-col) > 80 / "*" > 81 > 82 ; A 'cap-col' is: > 83 ; > 84 ; Any property name ('cap-prop') found in the > component > 85 ; named in the 'comp-name' used in the "FROM" > clause. > 86 ; > 87 ; SELECT ORGANIZER FROM VEVENT ... > 88 ; > 89 ; OR > 90 ; > 91 ; A component name ('comp-name') of an existing > component > 92 ; contained inside of the 'comp-name' used in > the "FROM" > 93 ; clause. > 94 ; > 95 ; SELECT VALARM FROM VEVENT ... > 96 ; > 97 ; OR > 98 ; > 99 ; A component name ('comp-name') of an existing > 100 ; component contained inside of the 'comp-name' > used > 101 ; in the "FROM" clause followed by a property > 102 ; name ('cap-prop') to be selected from that > component. > 103 ; (comp-name "." cap-prop) > 104 ; > 105 ; SELECT VALARM.TRIGGER FROM VEVENT ... > 106 > 107 cap-col = comp-name > 108 / comp-name "." cap-prop > 109 / cap-prop > 110 > 111 comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / > "VFREEBUSY" > 112 / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" > 113 / "VCAR" / "VCALSTORE" / "VQUERY" / > "VTIMEZONE" > 114 / x-comp / iana-comp Why is VRIGHT not a component name?? Since the 'comp-name' is not only used in the CAPQL part I believe it should be. On top of that I was wondering if it would not be usefull to seperate the CAPQL language (ABNF) more from the rest. Meaning that almost anything under 'cal-query' have its own rules and those are not used in the other itmes. To me it sounds also a bit weird that you could create a query for selecting queries. So the "VQUERY" comp-name item looks out of place in that sense. > 115 > 116 cap-prop = ; A property that may be in the 'cap-comp' named > 117 ; in the "SELECT" clause. > 118 > 119 cap-expr = "(" cap-expr ")" > 120 / cap-term > 121 > 122 cap-term = cap-expr SP cap-logical SP cap-expr > 123 / cap-factor > 124 > 125 cap-logical= "AND" / "OR" > 126 > 127 cap-factor = cap-colval SP cap-oper SP col-value > 128 / cap-colval SP "NOT LIKE" SP col-value > 129 / cap-colval SP "LIKE" SP col-value > 130 / cap-colval SP "IS NULL" > 131 / cap-colval SP "IS NOT NULL" > 132 / col-value SP "NOT IN" cap-colval" The above "NOT LIKE", "IS NULL", "IS NOT NULL" and "NOT IN" all have a single space between the 'words' would it no be usefull to lower that requirement?? "NOT LIKE" and "NOT LIKE" (2 spaces) are somehow similar. Just wondering, since I don't see the need for it. > 133 / col-value SP "IN" cap-colval" > 134 / "STATE()" "=" ( "BOOKED" > 135 / "UNPROCESSED" > 136 / "DELETED" ) Are the items BOOKED, UNPROCESSED and DELETED not surrounded with single quotes (') as defined in the examples?? > 137 > 138 cap-colval = cap-col / param > 139 > 140 param = "PARAM(" cap-col "," cap-param ")" > 141 > 142 cap-param = ; Any parameter that may be contained in the > cap-col > 143 ; in the supplied PARAM() function > 144 > 145 col-value = col-literal > 146 / "SELF()" > 147 / "CAL-OWNERS()" > 148 / "CAL-OWNERS(" cal-address ")" > 149 / "CURRENT-TARGET()" > 150 > 151 cal-address = ; A CALID as define by CAP > 152 > 153 col-literal = "'" literal-data "'" > 154 > 155 literal-data = ; Any data that matches the value type of the > 156 ; column that is being compared. That is you > can > 157 ; not compare PRIORITY to "some string" because > 158 ; PRIORITY has a value type of integer. If it > is > 159 ; not preceded by the LIKE element, any '%' > and '_' > 160 ; characters in the literal data are not > treated as > 161 ; wildcard characters and do not have to be > backslash > 162 ; escaped. > 163 ; > 164 ; OR > 165 ; > 166 ; If the literal-data is preceded by the LIKE > 167 ; element it may also contain the '%' and '_' > 168 ; wildcard characters. And if the literal data > 169 ; that is comparing contains any '%' or '_' > 170 ; characters, they MUST BE backslash escaped as > 171 ; described in the notes below in order for > them not > 172 ; to be treated as wildcard characters. > 173 > 174 cap-oper = "=" > 175 / "!=" > 176 / "<" > 177 / ">" > 178 / "<=" > 179 / ">=" > 180 > 181 > 182 SP = ; A single white space ASCII character > 183 ; (value in HEX %x20). Also here, would this be not easier when multiple white space characters are allowed?? Just wondering. regards, Harrie From owner-ietf-calendar@mail.imc.org Mon Jun 16 11:33: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 LAA17984 for ; Mon, 16 Jun 2003 11:33: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 h5GFK7rb007476 for ; Mon, 16 Jun 2003 08:20: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 h5GFK74T007475 for ietf-calendar-bks; Mon, 16 Jun 2003 08:20:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GFK5rb007469 for ; Mon, 16 Jun 2003 08:20:06 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EEA3B8A.7090407@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CANCEL and SEQUENCE usage MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Mon, 16 Jun 2003 11:22:38 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/16/2003 11:19:46 AM, Serialize complete at 06/16/2003 11:19:46 AM Content-Type: multipart/alternative; boundary="=_alternative 0053EE5185256D47_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053EE5185256D47_= Content-Type: text/plain; charset="US-ASCII" NO. It does not work. I tried Outlook, that wrote exactly to the spec. They are FUBAR'd and you can not re-invite someone that you have removed. NOTES does not currently; Nor will it ever code to this BUG in the spec and bump the sequence on a CANCEL and thus break workflow. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/13/2003 05:00 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: CANCEL and SEQUENCE usage Robert_Ransdell@notesdev.ibm.com wrote: > > In all cases where the sequence is bumped, ALL invitees must be notified > of a RESCHEDULE. They must re-accept/decline. All existing responses > become invalid. Overhead is way too high for sending an un-invite to > one person. We finally agree - it works, you simply don't like it. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 0053EE5185256D47_= Content-Type: text/html; charset="US-ASCII"
NO.   It does not work.   I tried Outlook, that wrote exactly to the spec.  They are FUBAR'd and you can not re-invite someone that you have removed.

NOTES does not currently;   Nor will it ever code to this BUG in the spec and bump the sequence on a CANCEL and thus break workflow.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/13/2003 05: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: CANCEL and SEQUENCE usage







Robert_Ransdell@notesdev.ibm.com wrote:
>
> In all cases where the sequence is bumped, ALL invitees must be notified
> of a RESCHEDULE.  They must re-accept/decline.  All existing responses
> become invalid.   Overhead is way too high for sending an un-invite to
> one person.


We finally agree - it works, you simply don't like it.


--

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

                We Do Standards - You Need Standards
--=_alternative 0053EE5185256D47_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 12:09: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 MAA19384 for ; Mon, 16 Jun 2003 12:09: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 h5GG0Qrb008569 for ; Mon, 16 Jun 2003 09:00: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 h5GG0Qno008568 for ietf-calendar-bks; Mon, 16 Jun 2003 09:00:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GG0Orb008563 for ; Mon, 16 Jun 2003 09:00: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 h5GG0Jbt021927 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 16 Jun 2003 09:00:25 -0700 Message-ID: <3EEDE98D.6010603@Royer.com> Date: Mon, 16 Jun 2003 10:00:13 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP ABNF - ORDER/sort References: <0371683E-9FDC-11D7-A4C7-0003934A5A7E@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020806020304070201060507" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020806020304070201060507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: > > On top of this, I am wondering if an order clause is > useful as part of the capql query part. The order > now depends on the columns given in the 'SELECT' part > 'cap-val', but it is sometimes usefull to be more specific. This WG has decided that SORT is to be removed in the -11 version of the spec. I have removed it in the sources. I submitted an individual draft (should be showing up soon) that has a sort-extension. 'ORDER' could be added as an add on to that. I do agree that sorting is needed. The WG decided that they do not want it in the base spec. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020806020304070201060507 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTYxNjAwMTRaMCMGCSqGSIb3DQEJBDEWBBQp T0KpQongFqR2ZSNg3lwfMlqCMDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAU24YwM4FuMuo ok4aTFZJW5ZMiwX8GWv6KOdbYs9m47s2kb5KZMOoviwvqvxC3q5KFXyJeMxveloM/lGds4UP wVj2o3tYlbWKw/NyvO26IIe8YFcTCJG8jpGKm+FZb3GAJkg/ul6REhpR54RSDJlMMyveLl/H OEvOWiQZ0LU7Jgvk0j+vKaV19TSoIJqC8ct3/WzmM7q+ztF/HmHF7QoSX9qnZ0juHK8J6m+8 LSwIWNUCrIRCgHyvmt3lS/3h8xyFlHLnlAALtEGBfrKOMbeE2xKOAf4/PTjSmvZXLyccSu2U c5pG1A+6SA++gzYV5MmPAxxeu4lQqrG2Fsz2XYfQ8QAAAAAAAA== --------------ms020806020304070201060507-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 12:12: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 MAA19455 for ; Mon, 16 Jun 2003 12:12: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 h5GG3Erb008655 for ; Mon, 16 Jun 2003 09:03: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 h5GG3E0i008654 for ietf-calendar-bks; Mon, 16 Jun 2003 09:03: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 h5GG3Crb008648 for ; Mon, 16 Jun 2003 09:03: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 h5GG37bt021953 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 16 Jun 2003 09:03:13 -0700 Message-ID: <3EEDEA36.8040808@Royer.com> Date: Mon, 16 Jun 2003 10:03: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" Subject: Re: CAP ABNF - previous posts References: <0371683E-9FDC-11D7-A4C7-0003934A5A7E@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000806020206030504070908" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000806020206030504070908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: > > HI, > > I am quit new to this, but something I noticed while > implementing a parser for CAPQL. > Also the ABNF is not inline with the examples and earlier > was said the examples are all valid. See earlier thread > with subject "CAP-QUERY ABNF disagrees with examples" > and line 136 below. Yes and thanks. I wanted to put all of the ABNF together and hopefully provoke additional comments. As ABNF is a bit painful to edit and write, I wanted as many comments as possible before editing into -11. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000806020206030504070908 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTYxNjAzMDJaMCMGCSqGSIb3DQEJBDEWBBTL KAxCwQQGDVjUmr/fJINM1lCVgDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAfm7466C5TfcO +3i2Epy/htYy5jXA4pbJ9kGd4zk174pmbSfQfJZEnthlXcbHYbD0kgDyI3UJkIVJqXK6i3Se nVRrv8NU978jd4/oHuDYMnMAR+ncugBnuCTaaoWOTULKCxW+G0c9FBuZuJAQVvEaglXi3CcY CdRd5hMQt4CXTW1Gv2Q8TrUy4h1GYScGHR8V5sg8SIi8Mr9Sr5mBJKan2/j+YSyEgYwaVbsu K1a+qVV0otUO+SZ+EnAbnwT05+McG9xwMGgGWWgMIrnn9cO7xtmShhT+MQQL+5rMWhv/pWhP oMMOSVu0FIRUaAdTYwjFYjyVRMJ8SmVR0h1UAhxbCAAAAAAAAA== --------------ms000806020206030504070908-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 12:13: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 MAA19478 for ; Mon, 16 Jun 2003 12:13: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 h5GFv5rb008494 for ; Mon, 16 Jun 2003 08:57: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 h5GFv5QV008493 for ietf-calendar-bks; Mon, 16 Jun 2003 08:57: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 h5GFv4rb008487 for ; Mon, 16 Jun 2003 08:57: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 h5GFuwbt021899 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 16 Jun 2003 08:57:04 -0700 Message-ID: <3EEDE8BF.6010204@Royer.com> Date: Mon, 16 Jun 2003 09:56:47 -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: CANCEL and SEQUENCE usage References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080102070004000901060403" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080102070004000901060403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > NO. It does not work. I tried Outlook, that wrote exactly to the > spec. They are FUBAR'd and you can not re-invite someone that you have > removed. I am not sure what you are saying is invalid. Are you saying that if you bump the SEQUENCE and re-issues REQUESTS, the Outlook clients says NO? My tests show that it works. So I do not understand what you are saying fails. > NOTES does not currently; Nor will it ever code to this BUG in the > spec and bump the sequence on a CANCEL and thus break workflow. So you are saying that if I ever bump the SEQUENCE number for other reasons that NOTES can never do a CANCEL? Or are you saying that if you ever CANCEL someone that you can never bump the SEQUENCE? Or are you saying that if you need to CANCEL and do something else that you feel needs to bump the sequence, that NOTES can not handle that? Or are you saying that you are going to make sure that NOTES is not conferment with iCal/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 --------------ms080102070004000901060403 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTYxNTU2NDdaMCMGCSqGSIb3DQEJBDEWBBRJ c3urDfofoZJ8anPIyM8rK2fadDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAavsdb5IhOvr0 1jOCMAgGjHslY4/CJ8v6e6hfCkm6IYeQ3inwxdoLwGbTDmHM3ma8Pu/U+fOsVjkB6Di0SCGa pG1bbjQ9bJIPwretBhFZZI6ZQ6coSyGaL4IZzHPf59d+kdQFEgYZUF0Wdar290Jq60cWitJb JLWg4DkmSsNfDQ+qDxIwwSp4qeZ9H+l/0UATpJLSzxmxy792NxKwa1yt5QDGdmFp8sAvcjop ccFhVeSHJxalUKDw5PyTBXvVuhm1Cw+s3pm+H04wtwKJR48qr0lpweyBvZx3X8jXnnLfXQoW yQqHsiRRTSPA0mAud8wqFG7o+bpTGA1/oRtO2Jxk3AAAAAAAAA== --------------ms080102070004000901060403-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 12:14: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 MAA19517 for ; Mon, 16 Jun 2003 12:14: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 h5GG5Vrb008754 for ; Mon, 16 Jun 2003 09:05: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 h5GG5VcW008753 for ietf-calendar-bks; Mon, 16 Jun 2003 09:05:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GG5Trb008748 for ; Mon, 16 Jun 2003 09:05:30 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5GG5Dbt021972 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 16 Jun 2003 09:05:25 -0700 Message-ID: <3EEDEAB3.40205@Royer.com> Date: Mon, 16 Jun 2003 10:05: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: CAP ABNF - VRIGHT References: <0371683E-9FDC-11D7-A4C7-0003934A5A7E@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000004060701000809080800" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000004060701000809080800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: > > Why is VRIGHT not a component name?? > Since the 'comp-name' is not only used in the CAPQL part I believe it > should be. Thanks - it was an error that it was not included. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000004060701000809080800 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTYxNjA1MDhaMCMGCSqGSIb3DQEJBDEWBBQZ eQ6DqX3e4T8GU7s/VwCQtjbdnTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAfZgde5Y8ClH4 UmbmntO1StYnrVdJs9S+p3Ouu22U234GC6tKmItHrFD22wNc/QKYXFs5jQzd0vCnZ2bYiynD +JdpYQaj6a4zkuJ9AUuJhXsWqWcPIl968vJfa0mmpf0D9QiwbTTCpac/dHf9i+F6uoFYvU2W JGY9TE7Vsg6Nu+1Lb9RCmShxEZGq04y5MrAvsHsF0BTSMyEgUUmdxdw0TlGqFAzZ6hOW8+uz imJn/YP6+v505wzZduSLm2vfhLsf6S5zqTbIFEJ4fKpwlRnnnT9E13+hZ2ASqF7lcEZFMClY gcb3VSXPX9SsE8JpliIIaDLCp2yP5Cue0Nlf3sW29AAAAAAAAA== --------------ms000004060701000809080800-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 12:16: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 MAA19539 for ; Mon, 16 Jun 2003 12:16: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 h5GG8mrb008879 for ; Mon, 16 Jun 2003 09: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 h5GG8mMK008878 for ietf-calendar-bks; Mon, 16 Jun 2003 09:08: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 h5GG8lrb008873 for ; Mon, 16 Jun 2003 09:08: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 h5GG8fbt021992 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 16 Jun 2003 09:08:47 -0700 Message-ID: <3EEDEB83.8090107@Royer.com> Date: Mon, 16 Jun 2003 10:08:35 -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: CAP ABNF - SP vs spaces. References: <0371683E-9FDC-11D7-A4C7-0003934A5A7E@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040306010706010604090601" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040306010706010604090601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: > > The above "NOT LIKE", "IS NULL", "IS NOT NULL" and "NOT IN" > all have a single space between the 'words' would it no be usefull > to lower that requirement?? "NOT LIKE" and "NOT LIKE" (2 spaces) > are somehow similar. > Just wondering, since I don't see the need for it. The text specifically says 'single space'. It opened up the debate for tabs, CR, LF, and other white space. So it was limited to a single space. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040306010706010604090601 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTYxNjA4MzVaMCMGCSqGSIb3DQEJBDEWBBQ3 J7DtbwNj9kQdynsv0riUhZToEzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAGoCtBmSA2YGJ zC8lsnwxR+veRTzFV1bAsp6oIPHbpsi23kTaaGMsTVEJ6C0rmf43mwC/3tleHjOChv4EUNFA 5aWj7F2AR7n/8rkcFvzNp+ah8nxIq7Ac9AkUJvjNAqs0T82alXCFAml3f9J6ABWyJuFxynZ+ uny8ZPTVNsJdr27JHlGQS1nYJrHOrrg46eT7S5Viy49e2Bg3K8lDL513k0VEwGr+LUfl6GDw K5woS5+vid8daXaXVhu3qvAYyHORD2fL3gVvQVkHUOm2Fv9MfwVOeBntVU9ggUi8HgVBK74z /BSNMg0YMvjOvKw+5iUtYcjvVZZX++R9tmWZJYZySgAAAAAAAA== --------------ms040306010706010604090601-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 12:17: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 MAA19587 for ; Mon, 16 Jun 2003 12:17: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 h5GGAPrb008915 for ; Mon, 16 Jun 2003 09:10:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5GGAP3X008914 for ietf-calendar-bks; Mon, 16 Jun 2003 09:10: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 h5GGANrb008909 for ; Mon, 16 Jun 2003 09:10: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 h5GGAJbt022028 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 16 Jun 2003 09:10:24 -0700 Message-ID: <3EEDEBE5.5090703@Royer.com> Date: Mon, 16 Jun 2003 10:10: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: CAP ABNF - single quotes missing, BOOKED,... References: <0371683E-9FDC-11D7-A4C7-0003934A5A7E@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030004080608080903050000" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030004080608080903050000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: > > Are the items BOOKED, UNPROCESSED and DELETED not surrounded with > single quotes (') as defined in the examples?? Error - thanks. I'll fix it. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030004080608080903050000 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTYxNjEwMTNaMCMGCSqGSIb3DQEJBDEWBBSS umy+iOa3U3jVTSEm7h6y+sWNujBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYDKvzxEOZytU lxKlAdFhO8ZG9llsACGQRM8yUzBqrrflMRWqsbJg3UX5dxHOQ/yVUg+QUnQqd0/fZKuN6yZL Tm7qPCQ3ZrOMdk5YvTJr6HhKON2UXyi+Xu9wVUxCjA+aNZf3BytieESghr/LrGvcak0PJYE1 ZYmjAE4KAHitZm0vPNOljZwOWbitj53jipccUIGSTJ7CYNPJL3b8PJXS5gghJdE+tzLBH+oI Vp6bInaClrKJxiy7CjDdCFRi4REC/RuAYrAzz45/CWEJIGnkGLAvkZibcaFAi2j+Wg3mEdIl CX5SWm/jXIo+iDFHU36jZ5ZpMSErjbzItMN20baZUwAAAAAAAA== --------------ms030004080608080903050000-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 14:15: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 OAA23923 for ; Mon, 16 Jun 2003 14:15: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 h5GI5Erb016402 for ; Mon, 16 Jun 2003 11:05: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 h5GI5E4c016401 for ietf-calendar-bks; Mon, 16 Jun 2003 11:05:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GI5Drb016395 for ; Mon, 16 Jun 2003 11:05:13 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EEDE8BF.6010204@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CANCEL and SEQUENCE usage MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Mon, 16 Jun 2003 14:07:35 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/16/2003 02:04:45 PM, Serialize complete at 06/16/2003 02:04:45 PM Content-Type: multipart/alternative; boundary="=_alternative 0063085985256D47_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063085985256D47_= Content-Type: text/plain; charset="US-ASCII" No I'm saying as Chair I will not bump the sequence number on a cancel (uninvite to an individual); just like I would not bump the sequence number if I was inviting an additional invitee. The only time I bump the sequence number is on a reschedule. This makes the invite of an additional invitee consistent. I can re-invite the person who I accidentally uninvited without issuing a Reschedule to all the attendees forcing them to re-accept/decline. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/16/2003 11:56 AM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: CANCEL and SEQUENCE usage Robert_Ransdell@notesdev.ibm.com wrote: > > NO. It does not work. I tried Outlook, that wrote exactly to the > spec. They are FUBAR'd and you can not re-invite someone that you have > removed. I am not sure what you are saying is invalid. Are you saying that if you bump the SEQUENCE and re-issues REQUESTS, the Outlook clients says NO? My tests show that it works. So I do not understand what you are saying fails. > NOTES does not currently; Nor will it ever code to this BUG in the > spec and bump the sequence on a CANCEL and thus break workflow. So you are saying that if I ever bump the SEQUENCE number for other reasons that NOTES can never do a CANCEL? Or are you saying that if you ever CANCEL someone that you can never bump the SEQUENCE? Or are you saying that if you need to CANCEL and do something else that you feel needs to bump the sequence, that NOTES can not handle that? Or are you saying that you are going to make sure that NOTES is not conferment with iCal/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 --=_alternative 0063085985256D47_= Content-Type: text/html; charset="US-ASCII"
No I'm saying as Chair I will not bump the sequence number on a cancel  (uninvite to an individual); just like I would not bump the sequence number if I was inviting an additional invitee.  The only time I bump the sequence number is on a reschedule. This makes the invite of an additional invitee consistent.  I can re-invite the person who I accidentally uninvited without issuing a Reschedule to all the attendees forcing them to re-accept/decline.

_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/16/2003 11:56 AM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: CANCEL and SEQUENCE usage







Robert_Ransdell@notesdev.ibm.com wrote:
>
> NO.   It does not work.   I tried Outlook, that wrote exactly to the
> spec.  They are FUBAR'd and you can not re-invite someone that you have
> removed.

I am not sure what you are saying is invalid. Are you saying
that if you bump the SEQUENCE and re-issues REQUESTS, the Outlook
clients says NO? My tests show that it works. So I do not understand
what you are saying fails.


> NOTES does not currently;   Nor will it ever code to this BUG in the
> spec and bump the sequence on a CANCEL and thus break workflow.

So you are saying that if I ever bump the SEQUENCE number for other
reasons that NOTES can never do a CANCEL? Or are you saying that
if you ever CANCEL someone that you can never bump the SEQUENCE?
Or are you saying that if you need to CANCEL and do something
else that you feel needs to bump the sequence, that NOTES
can not handle that? Or are you saying that you are going
to make sure that NOTES  is not conferment with iCal/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
--=_alternative 0063085985256D47_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 18:19: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 SAA06470 for ; Mon, 16 Jun 2003 18:19: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 h5GM8frb025050 for ; Mon, 16 Jun 2003 15:08: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 h5GM8fcX025049 for ietf-calendar-bks; Mon, 16 Jun 2003 15:08: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-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GM8erb025044 for ; Mon, 16 Jun 2003 15:08:40 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EEA5DC0.60007@sun.com> To: Arnaud Quillaud , ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Mon, 16 Jun 2003 18:11:12 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/16/2003 06:08:37 PM, Serialize complete at 06/16/2003 06:08:37 PM Content-Type: multipart/alternative; boundary="=_alternative 0079562A85256D47_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079562A85256D47_= Content-Type: text/plain; charset="US-ASCII" Since there would be no mapping of existing repeat dates to the new dates generated by the new rule, this is equivalent to a NEW meeting. Thus you must assign a new UNID. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Arnaud Quillaud Sent by: owner-ietf-calendar@mail.imc.org 06/13/2003 07:26 PM To Robert Ransdell/Westford/IBM , ietf-calendar@imc.org cc Subject Re: Fw: Correct handling of Recurrence-id Robert Ransdell/Westford/IBM wrote: > > You can only change individual dates or ADD to the repeat dates. You > can not re-roll the repeat rule. > > If you re-roll the repeat rule. This is a new meeting.. UNID changes That would probably be a good simplification of the protocol but where does that come from ? I don't see anywhere in iCAL/iTIP that the organizer can't change the RRULE. Or did I miss something ? Arnaud > > > > _____________________ > Note: new email address > > tom_ransdell@notesdev.ibm.com > > > *Arnaud Quillaud * > Sent by: owner-ietf-calendar@mail.imc.org > > 06/13/2003 01:47 PM > > To > "ietf-calendar@imc.org" > cc > > Subject > Re: Fw: Correct handling of Recurrence-id > > > > > > > > > Doug Royer wrote: > > > > > > > Arnaud Quillaud wrote: > > > >> > > >> > > Unless Doug or George can demonstate how to resync, etc > >> > using a delta > >> > > model I suggest we make a strong WG note to remove the > >> > misleading text > >> > > from the next revision of 2445 and move on. > >> > > >> > You do not have to SYNC - simply do a REFRESH and get the > >> > latest object > >> > version. > >> > > >> But in Bruce model, you do *not* have to do a REFRESH. That sounds > >> like a much simpler mechanism. > >> So, what is the advantage of the changing recurrence-id model ? > >> Arnaud > > > > > > You are totally hosed if you were not part of SEQUENCE:0 > > I've asked Bruce about a new attendee being added to the VEVENT (I've > included both my question and his response). In his view, the recurrence > set (RRULE+RDATE+EXDATE+RDATE) that would be sent to this new attendee > would be the original one so there wouldn't be any ambiguity. > > > > > or somehow loose your data. > > If you loose your data, you're hosed, whatever the model. All you can do > is to do a REFRESH, that is, if you still have the ORGANIZER and UID. > The REFRESH would work (see above). > > > > > > > And when 100% of the original instances change and you > > somehow missed an important change. The new instances > > will not map to the SEQUENCE:0 instances and you > > might apply them incorrectly. > > > You mean, if the organizer change the recurrence set (e.g. change the > event from weekly to bi-weekly) ? > I guess, Bruce rules needs to be refined to say that the list of > recurrence-id refers to the latest recurrence set > (RRULE+RDATE-EXRULE-EXDATE) sent by the organizer. > Bruce ? > > > > BTW, is there a section in iTIP that talks about handling of exceptions > on the attendee side, when receiving a REQUEST with a new recurrence set ? > For example: > 1st REQUEST > RRULE: weekly on mondays for ever > > 2nd REQUEST > RECURRENCE-ID=second monday > DTSTART=second tuesday > > 3rd REQUEST > RRULE: weekly on wednesday > > Does the 3rd REQUEST implicitly means cancel of the second tuesday's > instance ? Or should the attendee consider it still valid unless it > receives a CANCEL ? > > Thanks, > > Arnaud > > > > ----- Message from Arnaud Quillaud on > Fri, 23 May 2003 17:15:12 -0700 ----- > *To:* > Bruce_Kahn@notesdev.ibm.com > *cc:* > ietf-calendar@imc.org > *Subject:* > Re: Correct handling of Recurrence-id > > > > _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 > > > ----- Message from Bruce_Kahn@notesdev.ibm.com on Tue, 27 May 2003 > 16:22:30 -0400 ----- > *To:* > ietf-calendar@imc.org > *Subject:* > Re: Correct handling of Recurrence-id > > > > > 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 0079562A85256D47_= Content-Type: text/html; charset="US-ASCII"
Since there would  be no mapping of existing repeat dates to the new dates generated by the new rule, this is equivalent to a NEW meeting.  Thus you must assign a new UNID.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


Arnaud Quillaud <arnaud.quillaud@sun.com>
Sent by: owner-ietf-calendar@mail.imc.org

06/13/2003 07:26 PM

To
Robert Ransdell/Westford/IBM <Robert_Ransdell@notesdev.ibm.com>, ietf-calendar@imc.org
cc
Subject
Re: Fw: Correct handling of Recurrence-id






Robert Ransdell/Westford/IBM wrote:

>
> You can only change individual dates or ADD to the repeat dates.  You
> can not re-roll the repeat rule.
>
> If you re-roll the repeat rule.  This is a new meeting.. UNID changes


That would probably be a good simplification of the protocol but where
does that come from ?
I don't see anywhere in iCAL/iTIP that the organizer can't change the
RRULE. Or did I miss something ?

Arnaud

>
>
>
> _____________________
> Note: new email address
>
> tom_ransdell@notesdev.ibm.com
>
>
> *Arnaud Quillaud <arnaud.quillaud@sun.com>*
> Sent by: owner-ietf-calendar@mail.imc.org
>
> 06/13/2003 01:47 PM
>
> To
> "ietf-calendar@imc.org" <ietf-calendar@imc.org>
> cc
>
> Subject
> Re: Fw: Correct handling of Recurrence-id
>
>
>
>
>
>
>
>
> Doug Royer wrote:
>
> >
> >
> > Arnaud Quillaud wrote:
> >
> >>  >
> >>  > > Unless Doug or George can demonstate how to resync, etc
> >>  > using a delta
> >>  > > model I suggest we make a strong WG note to remove the
> >>  > misleading text
> >>  > > from the next revision of 2445 and move on.
> >>  >
> >>  > You do not have to SYNC - simply do a REFRESH and get the
> >>  > latest object
> >>  > version.
> >>  >
> >> But in Bruce model, you do *not* have to do a REFRESH. That sounds
> >> like a much simpler mechanism.
> >> So, what is the advantage of the changing recurrence-id model ?
> >> Arnaud
> >
> >
> > You are totally hosed if you were not part of SEQUENCE:0
>
> I've asked Bruce about a new attendee being added to the VEVENT (I've
> included both my question and his response). In his view, the recurrence
> set (RRULE+RDATE+EXDATE+RDATE) that would be sent to this new attendee
> would be the original one so there wouldn't be any ambiguity.
>
> >
> > or somehow loose your data.
>
> If you loose your data, you're hosed, whatever the model. All you can do
> is to do a REFRESH, that is, if you still have the ORGANIZER and UID.
> The REFRESH would work (see above).
>
> >
> >
> > And when 100% of the original instances change and you
> > somehow missed an important change. The new instances
> > will not map to the SEQUENCE:0 instances and you
> > might apply them incorrectly.
>
>
> You mean, if the organizer change the recurrence set (e.g. change the
> event from weekly to bi-weekly) ?
> I guess, Bruce rules needs to be refined to say that the list of
> recurrence-id  refers to the latest recurrence set
> (RRULE+RDATE-EXRULE-EXDATE) sent by the organizer.
> Bruce ?
>
>
>
> BTW, is there a section in iTIP that talks about handling of exceptions
> on the attendee side, when receiving a REQUEST with a new recurrence set ?
> For example:
> 1st REQUEST
> RRULE: weekly on mondays for ever
>
> 2nd REQUEST
> RECURRENCE-ID=second monday
> DTSTART=second tuesday
>
> 3rd REQUEST
> RRULE: weekly on wednesday
>
> Does the 3rd REQUEST implicitly means cancel of the second tuesday's
> instance ? Or should the attendee consider it still valid unless it
> receives a CANCEL ?
>
> Thanks,
>
> Arnaud
>
>
>
> ----- Message from Arnaud Quillaud <Arnaud.Quillaud@Eng.Sun.COM> on
> Fri, 23 May 2003 17:15:12 -0700 -----
> *To:*
> Bruce_Kahn@notesdev.ibm.com
> *cc:*
> ietf-calendar@imc.org
> *Subject:*
> Re: Correct handling of Recurrence-id
>
>
>
> _Bruce_Kahn@notesdev.ibm.com_ <mailto: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_
> <mailto: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
>
>
> ----- Message from Bruce_Kahn@notesdev.ibm.com on Tue, 27 May 2003
> 16:22:30 -0400 -----
> *To:*
> ietf-calendar@imc.org
> *Subject:*
> Re: Correct handling of Recurrence-id
>
>
>
>
> 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 0079562A85256D47_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 16 19:33:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08506 for ; Mon, 16 Jun 2003 19:33:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GNO9rb027345 for ; Mon, 16 Jun 2003 16:24:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5GNO9bC027344 for ietf-calendar-bks; Mon, 16 Jun 2003 16:24: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 h5GNO8rb027339 for ; Mon, 16 Jun 2003 16:24: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 h5GNO4bt025580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 16 Jun 2003 16:24:09 -0700 Message-ID: <3EEE5187.90908@Royer.com> Date: Mon, 16 Jun 2003 17:23: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: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060006000001090404010702" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060006000001090404010702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Since there would be no mapping of existing repeat dates to the new > dates generated by the new rule, this is equivalent to a NEW meeting. > Thus you must assign a new UNID. I think this proposal will fix the incompatibilities and fix the problem of mid-object-existance joining by attendees from organizers CUAs which fix the recurrence-id to sequence zero. For organizer CUAs that can only generate sequence zero recurrence-ids and a recurrence rule change occurs. If sent to an attendee CUA that only assumes a sequence zero recurrence-id, there will be no problem as the organizer CUA will CANCEL and re-REQUEST on recurrence rule changes. Any CU specific data in the CS for that UID will be lost at the attendee end. If sent to an attendee CUA that assumes recurrence-id is tied to the sequence number, there will be no problem as the organizer CUA will CANCEL and re-REQUEST on recurrence rule changes. Any CU specific data in the CS for that UID will be lost at the attendee end. For organizer CUAs that tie the recurrence-id to the sequence number and a recurrence rule change occurs: If sent to an attendee CUA that only assumes sequence zero recurrence-id, there will be no problem as the attendee CUA will be unable to map the recurrence-id to the sequence zero object on recurrence rule changes, AND the attendee CUA will be able to tell that the new object has recurrence rule change, and then it must do a REFRESH. They should throw away their version of the object and use the new object returned from the organizer pretending it is sequence zero. No CU specific data in the CS for that UID need be lost. If sent to a an attendee CUA that assumes recurrence-id is tied to the sequence number, there will be no problem. No CU specific data in the CS for that UID will be lost. When implementing a CUA if you are going to assume that the recurrence-id is always tied to sequence zero, then simply doing a REFRESH should solve the problem if you pretend that whatever sequence you get back from the REFRESH is sequence zero. This will also allow mid-existince objects to be joined by CUA/attendees that assume that recurrence-id is tied to sequence zero. Without this assumption, there is no way to ever have an ATTENDEE join mid object existence as they would never be able to process recurrence-ids. I think this solves the problem for everyone. Comments? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060006000001090404010702 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTYyMzIzNTFaMCMGCSqGSIb3DQEJBDEWBBQg ljHJTxVFqoQwnY6wyw6XuaPerjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAi2XREECV6NWV xu90E+EWq0sM2RmL/6ZsfjYGsC4BO3o4YN7qTkuNPq9xNpNrB0OJBEZudFdqH47vJ0MR8toC Cy/KdnSe2AHda+v0QQcs+FghRzkhEoNKjprhH95oPPcwVMIu69lpH8bmNgXImK8Ag3orhpsS OvinTqf3uPBl0qBvJmj9EReOOminbQwt3DE+5qd3ti5mwvll8sjn0E4bOvAp1pDvMgljCQlH eBTroZStJA10fhcJVjk5rrGN+9YTX5TgWIKzq4GngdLm6l4upvvnoWOhqs8KbYKXlJlrlK8C Olh95QEJ6OaBFiDtzsBcQG1qBvCMdMHGN+FCgrEwcwAAAAAAAA== --------------ms060006000001090404010702-- From owner-ietf-calendar@mail.imc.org Tue Jun 17 08:06:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08934 for ; Tue, 17 Jun 2003 08:06: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 h5HBtqrb080551 for ; Tue, 17 Jun 2003 04:55:52 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5HBtqop080550 for ietf-calendar-bks; Tue, 17 Jun 2003 04:55:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HBtprb080544 for ; Tue, 17 Jun 2003 04:55:52 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08168; Tue, 17 Jun 2003 07:55:51 -0400 (EDT) Message-Id: <200306171155.HAA08168@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-royer-cap-notify-00.txt Date: Tue, 17 Jun 2003 07:55:51 -0400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CAP notification of upcoming VEVENTs, VTODOs or any changes Author(s) : D. Royer Filename : draft-royer-cap-notify-00.txt Pages : 8 Date : 2003-6-16 This memo describes a method used to ask for and receive notifications. These notifications will be the direct result of a stored VALARM and the notifications or changes to components or the store and are represented in iCalendar format. This is an extensions to CAP. This memo includes a new CAP command types of 'REQUEST-NOTIFY', 'NOTIFICATION', and 'CANCEL-NOTIFY', a new property of 'OBSERVER', a new component 'NOTIFICATION', CAP capabilities of 'CAN-NOTIFY', 'NOTIFY-UPDATES', and 'ALLOW-NOTIFY-BOT'. A 'REQUEST-NOTIFY' command is a request to add an observer to an component in the 'TARGET' calendar. In addition the 'REQUEST-NOTIFY' command can alert the CUA of changes to specific components or in the calendar or calendar store. Everything is subject to VCAR restrictions. These are asynchronous notifications must be advertised by the CS and requested by the CUA. This memo discusses how to transport them using CAP. In addition if the CS and CUA support the 'NOTIFY-UPDATES' capability, then the CS will send 'NOTIFICATION' components to the CUA describing the UIDs or TARGETS that have changed since the currently authenticated CU was last connected allowing for easier synchronization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-cap-notify-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-cap-notify-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-cap-notify-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075152.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-royer-cap-notify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-royer-cap-notify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075152.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Tue Jun 17 08:51: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 IAA08935 for ; Tue, 17 Jun 2003 08:06: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 h5HBtmrb080540 for ; Tue, 17 Jun 2003 04:55: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 h5HBtmkq080539 for ietf-calendar-bks; Tue, 17 Jun 2003 04:55:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HBtkrb080534 for ; Tue, 17 Jun 2003 04:55:47 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08152; Tue, 17 Jun 2003 07:55:46 -0400 (EDT) Message-Id: <200306171155.HAA08152@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-royer-cap-sort-00.txt Date: Tue, 17 Jun 2003 07:55:46 -0400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CAP (Calendar Access Protocol) sorting extension Author(s) : D. Royer Filename : draft-royer-cap-sort-00.txt Pages : 10 Date : 2003-6-16 Small devices may not have sufficient memory to store and then sort query results from a CAP server. This memo suggests an expendable CAP CAPABILITY extension called 'CAP-SORT' and a new parameters 'SORT' and 'LOCALE'. This memo specifies an optional minimum sort order and and locale sort extension. These extensions will only effect CUA's that have specifically requested these extensions be used in the session or for specific queries. The reader should be familiar with the CAP protocol prior to reading this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-cap-sort-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-cap-sort-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-cap-sort-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-royer-cap-sort-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-royer-cap-sort-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075143.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Wed Jun 18 08:33: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 IAA29967 for ; Wed, 18 Jun 2003 08:33: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 h5ICDvrb074427 for ; Wed, 18 Jun 2003 05:13:57 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5ICDvkq074426 for ietf-calendar-bks; Wed, 18 Jun 2003 05:13:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.lisanza.net (harrie.inet.it [213.92.1.193]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ICDtrb074421 for ; Wed, 18 Jun 2003 05:13:56 -0700 (PDT) (envelope-from harrie@inet.it) Received: from inet.it (localhost [127.0.0.1]) by localhost.lisanza.net (8.12.9/8.12.6) with ESMTP id h5ICIswX001634; Wed, 18 Jun 2003 14:18:59 +0200 (CEST) Date: Wed, 18 Jun 2003 14:18:52 +0200 Subject: draft-royer-cap-sort-00 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-calendar@imc.org, Harrie Hazewinkel To: Doug@royer.com From: Harrie Hazewinkel Content-Transfer-Encoding: 7bit Message-Id: <05D6C693-A187-11D7-A4C7-0003934A5A7E@inet.it> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit HI Doug, I read the sorting draft you propose and here are some comment. Some comments are just text issues, but some are issues I believe are not resolved or not understood by me. Harrie PS: I copied the calsh list, since it is related and useful if others comment also. > CAP (Calendar Access Protocol) sorting extension. > draft-royer-cap-sort-00 > 1. Introduction > > The CALSCH working group decided that sorting would not be in the > initial release of CAP. This memo defines extension to CAP for defines an extension (readability) > sorting. > > This is an extension to the CAP "GET-CAPABILITY" command result set. This extension (Not sure, if the above sentence makes sense here) > A CS that supports this extension supplies the "CAP-SORT" property > in 'supplies' -> 'MUST supply' (Use keyword of rfc 2119) > its "GET-CAPABILITY" reply supplying the versions of sorting the CS > supports. > > If the CUA wishes to have the results sorted it must return to the > CS > a valid "CAP-SORT" property value. The CUA can return the > "CAP-SORT" > value in one of two ways: > > (1) Supply the "CAP-SORT" property as one of the values returned by > the CUA in its "GET-CAPABILITY" reply to the CS. The contents of > the > "CAP-SORT" sent by the CUA must be from the set supplied to it from > the CS "GET-CAPABILITY" command reply "CAP-SORT" property value. > > (2) Supply the "SORT" parameter to a "QUERY" property using one of > the values returned in the "CAP-SORT" properly supplied by the CS. I am not getting this completely. In particular, who (CS or CUA) is sending what on request and in response of. > > 2. MINIMUM-SORT value > > If the CS supplies "MINIMUM-SORT" as one of its values it returns in > a "CAP-SORT" property value and the CUA sends "MINIMUM-SORT" as one > of its values in a "CAP-SORT" property value or in a "SORT" > parameter > value then it is defined to cause the CS to perform sorting as > defined in this section. 'then it is defined to cause the CS to perform sorting as' -> 'then the CS MUST perform sorting as' > > If supplied as described above to a "QUERY" property, then the query > results will be sorted as defined the three sections that follow. 'defined the' -> 'defined in the' > 2.1 Ordering of Numeric Results > > Sorting will take place in the order the columns are supplied in the 'will take' -> 'MUST take' > QUERY command. The CS MUST sort at least the first column. The CS > MAY sort additional columns. I can see the order when columns are asked for by specification in the query, but how about the '*'?? I would also think that it could be useful to sort on not requested columns. This part of text applies to section 2.2 also I believe. If so, I would suggest moving it in section 2.0. > 2.2 Ordering of Date/Date-Time Results > > Date and date time values will be sorted by their equivalent value > in 'will be' -> 'SHOULD be' (Use the keywords as defined in RFC2119) > UTC. No matter what the returned time zone in the result set > returns. This is so that if multiple components are returned each > in > a unique time zone, the results will be sorted in UTC. This does > not 'will be' -> 'MUST be' > mean the values MUST BE converted to UTC in the data returned to the 'MUST BE' -> 'MUST be' > CUA. It means the CS must do the sort in UTC. 'must' -> 'MUST' > > > If the cap-cols is only "*" and nothing else and the result set has > a > DTSTART, then: > > If EXPAND=FALSE sorting will be by the "DTSTART" property value > ascending as if it were in UTC. > > If EXPAND=TRUE sorting will be by the "RECURRENCE-ID" property value > ascending as if it were in UTC. "EXPAND" seems to come out of no where. 'EXPAND=..' -> the > > If one or more "DTSTART" or "RECURRENCE-ID" property values in > multiple components have exactly the same value, the order for those > matching components is unspecified. > > If the selected component(s) do not contain a "DTSTART" property or > a > "RECURRENCE-ID" property, then the order is unspecified. > > If an instance does not have a "RECURRENCE-ID" property and the > query > compares "RECURRENCE-ID" properties (comparing a RECURRENCE-ID to > the > date or date/time of a single instance object), then the CS MUST > compare the "DTSTART" property value as if it were a "RECURRENCE-ID" > even for single instance objects that do not contain a "RECURRENCE- > ID" property. > > A component with a DATE and no TIME value is returned before objects > with both a DATE and TIME value when the dates of those two (or > more) > objects are the same, sorted by date. I believe that the order within a DATE is unspecified, correct?? I also believe that the above part from "select '*'" is more generic and applies to the numeric sorting. > > 3. LOCALE-SORT value > > If the CS supplies "LOCALE-SORT" as one of its values it returned in > a "CAP-SORT" property value and the CUA sends "LOCALE-SORT" as one > of > its values in a "CAP-SORT" property value or in a "SORT" parameter > value then it is defined to cause the CS to perform sorting as > defined in this section. > > Values are sorted according to the locale sorting order as specified > in the command. Or the value set by the latest "SET-LOCALE" CAP > command, Or the value of the "DEFAULT-LOCALE" property if supplied > by > the CUA in its "GET-CAPABILITY" reply to the CS. Or the calendar > locale if known. Or the CS locale if the calendar does not have any > locale set. And the locale to use for the sort is determined in > that > order. > > If supplied as described above to a "QUERY" property, then the > locale > to be used in sorting. Maybe it is my lack of understanding, but I don't get this. > > 4. LOCALE parameter > > Parameter Name: LOCALE > > Purpose: To specify the locale to be used. > > Format Definition: The property parameter is defined by the > following > notation: > > > ; paramtext is defined in RFC2445 > ; > localeparam = "LOCALE" "=" paramtext > > > Description: Defined the locale to be used. Why repeating the purpose (almost)?? > > > 6. CAP-SORT property > > Property Name: CAP-SORT > > Purpose: This property defines the calendar scale used for the > calendar information specified in the iCalendar object. This makes no sense to me. It looks to me an exact copy and paste from CALSCALE in rfc 2445. Is this intended?? > > Value Type: TEXT > > Property Parameters: Non-standard property parameters can be > specified on this property. > > Conformance: Property can be specified in an iCalendar object. > > Description: ?? There is none? > > Format Definition: The property is defined by the following > notation: > > > cap-sort = "CAP-SORT" capsortparam ":" capsortvalue CRLF > > capsortparam = *(";" xparam) > > capsortvalue = sorttype *("," sorttype) How is a sorttype defined?? I cannot find this in rfc 2455. Another thing that crossed my mind was, what if I sort on STATE?? What would be the order?? ALthough, this approach allows sorting, but I believe the implementation is way more complex then when added to CAPQL. Just a personal thought, since the WG has decided SORTING is not part of CAPQL. Harrie From owner-ietf-calendar@mail.imc.org Wed Jun 18 09:47: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 JAA06839 for ; Wed, 18 Jun 2003 09:47: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 h5IDU8rb079047 for ; Wed, 18 Jun 2003 06:30: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 h5IDU7YE079046 for ietf-calendar-bks; Wed, 18 Jun 2003 06:30:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IDU6rb079041 for ; Wed, 18 Jun 2003 06:30:07 -0700 (PDT) (envelope-from bobmah@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h5IDU6cJ027108 for ; Wed, 18 Jun 2003 09:30:06 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h5IDU6pR013701 for ; Wed, 18 Jun 2003 09:30:06 -0400 (EDT) Received: from [66.93.190.32] (dsl093-190-032.nyc2.dsl.speakeasy.net [66.93.190.32]) (authenticated bits=0) (User authenticated as bobmah@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h5IDU5U9001164 for ; Wed, 18 Jun 2003 09:30:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: Date: Wed, 18 Jun 2003 09:30:04 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Next Meeting? Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Can I ask how many of you are planning on attending the July meeting? I will be attending, although Pat won't be able to make it. I'm interested in what sort of turn out we're likely to have... Thanks. -Bob From owner-ietf-calendar@mail.imc.org Wed Jun 18 13:27: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 NAA17344 for ; Wed, 18 Jun 2003 13:27: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 h5IHBGrb094118 for ; Wed, 18 Jun 2003 10:11:16 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5IHBGNh094115 for ietf-calendar-bks; Wed, 18 Jun 2003 10:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IHBErb094110 for ; Wed, 18 Jun 2003 10:11:14 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EEE5187.90908@Royer.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_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Wed, 18 Jun 2003 13:07:38 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/18/2003 01:11:08 PM, Serialize complete at 06/18/2003 01:11:08 PM Content-Type: multipart/alternative; boundary="=_alternative 005DC92785256D49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DC92785256D49_= Content-Type: text/plain; charset="US-ASCII" I don't really consider this a fix since A RESCHEDULE without anyway to map, is not really a reschedule. Also this does not fix the BUG of changing recurrence-id's on a reschedule. You have never given a valid counter example for changeable recurrence-id's to Bruce Kahn's valid example of how fixed recurrence-id work. This issue can not be closed until unless it is proven that changeable recurrence-id's work. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/16/2003 07:23 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: Fw: Correct handling of Recurrence-id Robert_Ransdell@notesdev.ibm.com wrote: > > Since there would be no mapping of existing repeat dates to the new > dates generated by the new rule, this is equivalent to a NEW meeting. > Thus you must assign a new UNID. I think this proposal will fix the incompatibilities and fix the problem of mid-object-existance joining by attendees from organizers CUAs which fix the recurrence-id to sequence zero. For organizer CUAs that can only generate sequence zero recurrence-ids and a recurrence rule change occurs. If sent to an attendee CUA that only assumes a sequence zero recurrence-id, there will be no problem as the organizer CUA will CANCEL and re-REQUEST on recurrence rule changes. Any CU specific data in the CS for that UID will be lost at the attendee end. If sent to an attendee CUA that assumes recurrence-id is tied to the sequence number, there will be no problem as the organizer CUA will CANCEL and re-REQUEST on recurrence rule changes. Any CU specific data in the CS for that UID will be lost at the attendee end. For organizer CUAs that tie the recurrence-id to the sequence number and a recurrence rule change occurs: If sent to an attendee CUA that only assumes sequence zero recurrence-id, there will be no problem as the attendee CUA will be unable to map the recurrence-id to the sequence zero object on recurrence rule changes, AND the attendee CUA will be able to tell that the new object has recurrence rule change, and then it must do a REFRESH. They should throw away their version of the object and use the new object returned from the organizer pretending it is sequence zero. No CU specific data in the CS for that UID need be lost. If sent to a an attendee CUA that assumes recurrence-id is tied to the sequence number, there will be no problem. No CU specific data in the CS for that UID will be lost. When implementing a CUA if you are going to assume that the recurrence-id is always tied to sequence zero, then simply doing a REFRESH should solve the problem if you pretend that whatever sequence you get back from the REFRESH is sequence zero. This will also allow mid-existince objects to be joined by CUA/attendees that assume that recurrence-id is tied to sequence zero. Without this assumption, there is no way to ever have an ATTENDEE join mid object existence as they would never be able to process recurrence-ids. I think this solves the problem for everyone. Comments? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.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 005DC92785256D49_= Content-Type: text/html; charset="US-ASCII"
I don't really consider this a fix since A RESCHEDULE without anyway to map, is not really a reschedule.
Also this does not fix the  BUG of changing recurrence-id's on a reschedule.  You have never given a valid counter example for changeable recurrence-id's to Bruce Kahn's valid example of how fixed recurrence-id work.  This issue can not be closed until unless it is proven that changeable  recurrence-id's work.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/16/2003 07:23 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: Fw: Correct handling of Recurrence-id







Robert_Ransdell@notesdev.ibm.com wrote:
>
> Since there would  be no mapping of existing repeat dates to the new
> dates generated by the new rule, this is equivalent to a NEW meeting.
>  Thus you must assign a new UNID.

I think this proposal will fix the incompatibilities and fix the
problem of mid-object-existance joining by attendees from organizers
CUAs which fix the recurrence-id to sequence zero.

For organizer CUAs that can only generate sequence zero recurrence-ids
and a recurrence rule change occurs.

 If sent to an attendee CUA that only assumes a sequence zero recurrence-id,
 there will be no problem as the organizer CUA will CANCEL and re-REQUEST
 on recurrence rule changes. Any CU specific data in the CS for that UID
 will be lost at the attendee end.

 If sent to an attendee CUA that assumes recurrence-id is tied to
 the sequence number, there will be no problem as the organizer CUA will
 CANCEL and re-REQUEST on recurrence rule changes. Any CU specific data
 in the CS for that UID will be lost at the attendee end.

For organizer CUAs that tie the recurrence-id to the sequence number
and a recurrence rule change occurs:

 If sent to an attendee CUA that only assumes sequence zero recurrence-id,
 there will be no problem as the attendee CUA will be unable to map the
 recurrence-id to the sequence zero object on recurrence rule changes,
 AND the attendee CUA will be able to tell that the new object has recurrence
 rule change, and then it must do a REFRESH. They should throw away their
 version of the object and use the new object returned from the organizer
 pretending it is sequence zero. No CU specific data in the CS for
 that UID need be lost.

 If sent to a an attendee CUA that assumes recurrence-id is tied to
 the sequence number, there will be no problem. No CU specific data
 in the CS for that UID will be lost.


When implementing a CUA if you are going to assume that the recurrence-id
is always tied to sequence zero, then simply doing a REFRESH should
solve the problem if you pretend that whatever sequence you get back
from the REFRESH is sequence zero. This will also allow mid-existince
objects to be joined by CUA/attendees that assume that recurrence-id
is tied to sequence zero. Without this assumption, there is no way
to ever have an ATTENDEE join mid object existence as they would never
be able to process recurrence-ids.

I think this solves the problem for everyone. Comments?

--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.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 005DC92785256D49_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 18 16:13: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 QAA27108 for ; Wed, 18 Jun 2003 16:13: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 h5IJsVrb001050 for ; Wed, 18 Jun 2003 12:54: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 h5IJsUbN001049 for ietf-calendar-bks; Wed, 18 Jun 2003 12:54: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 h5IJsTrb001042 for ; Wed, 18 Jun 2003 12:54: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 h5IJsNOR004701 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 18 Jun 2003 12:54:29 -0700 Message-ID: <3EF0C369.8000402@Royer.com> Date: Wed, 18 Jun 2003 13:54:17 -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="------------ms000209000805050104070601" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000209000805050104070601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > I don't really consider this a fix since A RESCHEDULE without anyway to > map, is not really a reschedule. There is a way to re-map, tie the sequence number to the recurrence-id. OR when they do not map, do a REFRESH. Any CUA needs to be able to do a REFRESH anyway if things get out of sync for any reason including recurrence-id issues. > Also this does not fix the BUG of changing recurrence-id's on a > reschedule. I know of no bug except in implementations that do not do a REFRESH when they get out of sync for what ever reason. The recurrence rules being out of sync is just one of the many reasons to do a REFRESH. > You have never given a valid counter example for changeable > recurrence-id's to Bruce Kahn's valid example of how fixed recurrence-id > work. This issue can not be closed until unless it is proven that > changeable recurrence-id's work. I do not work for you or Bruce. I do not *have* to give you anything. I have participated in various internet and IETF calendaring working groups since 1978. And did participate in the discussions on this topic and others and I will continue to participate in the discussions. Bruces example showed why is it broken to tie recurrence-id to sequence zero. And he stated in his emails that attendees can not join later if they can not figure out the sequence zero recurrence-id's. Bruces examples did not show that tying the recurrence-id to the sequence number failed, he stated that that is not they way he does it and in his views that is the way it should be. And he did not dispute that doing a REFRESH to get the latest copy breaks users that do not already have the original sequence zero object. He also does not dispute that there is no way to ever get the sequence zero object if that is not the current sequence. And you seem to agree that doing a REFRESH and starting with that copy works, but you do not like it. Recurrence-id's work when you tie them to the sequence number. You simply refuse to acknowledge that it works for others and you simply refuse to and have declared on this list that your product will never change. That's your choice. Demanding that iCal and iTIP change because you do not want to change is not going to convince anyone. Or declaring that it is a bug because some number of vendors do it one way or another way also does not solve the problem. The resolution to this problem that I sent works. Use it or not. However for those that tie the recurrence-id to the sequence number, they CAN and DO allow recurrence rule changes for the same UID. For those that do tie it to sequence zero only, it can be made to work ny doing a REFRESH. I tested it. Do or do not do it, but do not expect me or others to reduce the features in our code simply because you declare it is a bug. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000209000805050104070601 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTgxOTU0MThaMCMGCSqGSIb3DQEJBDEWBBTc b5VW1b+arz7z7CbO2gOp1AKmrDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEALZLzXK2aP0bk C9n2h8QRA0PgBiOxr51ly/Ym6w05AXO4pux+xw6aJw08QE/iFS1EFmozl04HRK+ge2tmxnmj pZ/B6jzZ1YU0bxEP9hgNgGjrRE+c2kvh+Tp+ycJebTQ/EUSGwg4fyQA/jsSo4fjI93fPAZgA 7NtD5sAPteksQRPRHrDfMn9j9ExWqscPLYBAnr0KYjQDtolf1YESjUw2co8YH6p6HWRf1M5u TtNx3s6dOAzVNTLRjanJbZKHfYAwMqj9i6jUwBmqddn8ZSYPOZD7YP5XvBiXfMXATSOW6/B/ FhEo0kEGLIvk2PWQv/pbFhyNOI0kJi0ybaX/i5ofYAAAAAAAAA== --------------ms000209000805050104070601-- From owner-ietf-calendar@mail.imc.org Wed Jun 18 17:38:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01170 for ; Wed, 18 Jun 2003 17:38:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ILGorb005341 for ; Wed, 18 Jun 2003 14:16: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 h5ILGoGg005340 for ietf-calendar-bks; Wed, 18 Jun 2003 14:16:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ILGorb005334 for ; Wed, 18 Jun 2003 14:16:50 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EF0C369.8000402@Royer.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_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Wed, 18 Jun 2003 17:01:29 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/18/2003 05:16:51 PM, Serialize complete at 06/18/2003 05:16:51 PM Content-Type: multipart/alternative; boundary="=_alternative 007331B685256D49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007331B685256D49_= Content-Type: text/plain; charset="US-ASCII" There was nothing broken about Bruce's example. I'm assuming since you do not want to defend your use of recurrence-id's and since all existing iCalendar products on the market that I know of, use fixed recurrence-id, that the correct usage is fixed recurrence-id's. Any other use is incompatible. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/18/2003 03:54 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: Fw: Correct handling of Recurrence-id Robert_Ransdell@notesdev.ibm.com wrote: > > I don't really consider this a fix since A RESCHEDULE without anyway to > map, is not really a reschedule. There is a way to re-map, tie the sequence number to the recurrence-id. OR when they do not map, do a REFRESH. Any CUA needs to be able to do a REFRESH anyway if things get out of sync for any reason including recurrence-id issues. > Also this does not fix the BUG of changing recurrence-id's on a > reschedule. I know of no bug except in implementations that do not do a REFRESH when they get out of sync for what ever reason. The recurrence rules being out of sync is just one of the many reasons to do a REFRESH. > You have never given a valid counter example for changeable > recurrence-id's to Bruce Kahn's valid example of how fixed recurrence-id > work. This issue can not be closed until unless it is proven that > changeable recurrence-id's work. I do not work for you or Bruce. I do not *have* to give you anything. I have participated in various internet and IETF calendaring working groups since 1978. And did participate in the discussions on this topic and others and I will continue to participate in the discussions. Bruces example showed why is it broken to tie recurrence-id to sequence zero. And he stated in his emails that attendees can not join later if they can not figure out the sequence zero recurrence-id's. Bruces examples did not show that tying the recurrence-id to the sequence number failed, he stated that that is not they way he does it and in his views that is the way it should be. And he did not dispute that doing a REFRESH to get the latest copy breaks users that do not already have the original sequence zero object. He also does not dispute that there is no way to ever get the sequence zero object if that is not the current sequence. And you seem to agree that doing a REFRESH and starting with that copy works, but you do not like it. Recurrence-id's work when you tie them to the sequence number. You simply refuse to acknowledge that it works for others and you simply refuse to and have declared on this list that your product will never change. That's your choice. Demanding that iCal and iTIP change because you do not want to change is not going to convince anyone. Or declaring that it is a bug because some number of vendors do it one way or another way also does not solve the problem. The resolution to this problem that I sent works. Use it or not. However for those that tie the recurrence-id to the sequence number, they CAN and DO allow recurrence rule changes for the same UID. For those that do tie it to sequence zero only, it can be made to work ny doing a REFRESH. I tested it. Do or do not do it, but do not expect me or others to reduce the features in our code simply because you declare it is a bug. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.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 007331B685256D49_= Content-Type: text/html; charset="US-ASCII"
There was nothing broken about Bruce's example.  I'm assuming since you do not want to defend your use of recurrence-id's and since all existing iCalendar products on the market that I know of, use fixed recurrence-id, that the correct usage is fixed recurrence-id's.  Any other use is incompatible.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/18/2003 03:54 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: Fw: Correct handling of Recurrence-id







Robert_Ransdell@notesdev.ibm.com wrote:
>
> I don't really consider this a fix since A RESCHEDULE without anyway to
> map, is not really a reschedule.

There is a way to re-map, tie the sequence number to the recurrence-id.
OR when they do not map, do a REFRESH. Any CUA needs to be able
to do a REFRESH anyway if things get out of sync for any reason
including recurrence-id issues.

> Also this does not fix the  BUG of changing recurrence-id's on a
> reschedule.

I know of no bug except in implementations that do not do a REFRESH
when they get out of sync for what ever reason. The recurrence rules
being out of sync is just one of the many reasons to do a REFRESH.

> You have never given a valid counter example for changeable
> recurrence-id's to Bruce Kahn's valid example of how fixed recurrence-id
> work.  This issue can not be closed until unless it is proven that
> changeable  recurrence-id's work.

I do not work for you or Bruce. I do not *have* to give you anything.
I have participated in various internet and IETF calendaring
working groups since 1978. And did participate in the discussions
on this topic and others and I will continue to participate in the
discussions.

Bruces example showed why is it broken to tie recurrence-id to
sequence zero. And he stated in his emails that attendees can
not join later if they can not figure out the sequence zero recurrence-id's.
Bruces examples did not show that tying the recurrence-id to the
sequence number failed, he stated that that is not they way he
does it and in his views that is the way it should be. And he
did not dispute that doing a REFRESH to get the latest copy breaks
users that do not already have the original sequence zero object.
He also does not dispute that there is no way to ever get the
sequence zero object if that is not the current sequence. And
you seem to agree that doing a REFRESH and starting with that
copy works, but you do not like it.

Recurrence-id's work when you tie them to the sequence number. You simply
refuse to acknowledge that it works for others and you simply refuse to
and have declared on this list that your product will never change.
That's your choice. Demanding that iCal and iTIP change because you do
not want to change is not going to convince anyone. Or declaring that
it is a bug because  some number of vendors do it one way or another
way also does not solve the problem.

The resolution to this problem that I sent works. Use it or not. However
for those that tie the recurrence-id to the sequence number, they CAN and DO
allow recurrence rule changes for the same UID. For those that
do tie it to sequence zero only, it can be made to work ny doing a REFRESH.
I tested it. Do or do not do it, but do not expect me or others to reduce
the features in our code simply because you declare it is a bug.

--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.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 007331B685256D49_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 18 18:12: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 SAA03162 for ; Wed, 18 Jun 2003 18:12: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 h5ILwTrb007165 for ; Wed, 18 Jun 2003 14:58: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 h5ILwTV9007164 for ietf-calendar-bks; Wed, 18 Jun 2003 14:58: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 h5ILwSrb007158 for ; Wed, 18 Jun 2003 14:58:28 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5ILwLOR005755 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 18 Jun 2003 14:58:29 -0700 Message-ID: <3EF0E077.70105@Royer.com> Date: Wed, 18 Jun 2003 15:58: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: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030101010504080308060202" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030101010504080308060202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > There was nothing broken about Bruce's example. Perhaps you missed Bruces posts where he declared that there is no way for an attendee to join if they do not have sequence zero when tying the recurrence-id only to sequence zero? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030101010504080308060202 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTgyMTU4MTZaMCMGCSqGSIb3DQEJBDEWBBSG vKeknjBK07WvPGqqUgxnuM2A0jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYVL3T2N/Sfze ZtBbNN5uWwVQr2rnLHMwmHYLXbedsd+3JhKf5WTlCJsrcHdU2NL/OiX+1KyEYBwJgTIasEF+ YZ5qlCNRjSMfeID1noviJba8q97IKeTx3GnTEI1lrgZo1vwbuMo90SetHEOf1AwJDRVCipvi LwoOQIALIMiqpbwgjCYJlpeny9zvblxzWe1MWINJ7031eMsMzaKqZoN/ggVXRaos7k7FsGO0 iOP4472KT2c4aF7vadMBgAz6JVQaOCCYmjXVJoI0GHb4VMFy6oBugBFk/EVTytxSRQT2K0B6 akwvz6ExNtAmOQIUX26SZIXYya+I2fpvfMAm0oa1IAAAAAAAAA== --------------ms030101010504080308060202-- From owner-ietf-calendar@mail.imc.org Wed Jun 18 18:12: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 SAA03165 for ; Wed, 18 Jun 2003 18:12: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 h5ILt5rb007037 for ; Wed, 18 Jun 2003 14:55: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 h5ILt5u6007036 for ietf-calendar-bks; Wed, 18 Jun 2003 14:55:05 -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 h5ILt3rb007030 for ; Wed, 18 Jun 2003 14:55:04 -0700 (PDT) (envelope-from satyanarayana.vempati@sun.com) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5ILt4YU026711 for ; Wed, 18 Jun 2003 15:55:05 -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 h5ILt4aL011820 for ; Wed, 18 Jun 2003 14:55:04 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HGP00AYX67SEQ@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Wed, 18 Jun 2003 14:55:04 -0700 (PDT) Date: Wed, 18 Jun 2003 14:59:56 -0700 From: Satya Vempati Subject: RE: Fw: Correct handling of Recurrence-id To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Y+ZwecI5meRZlROVT0/svA)"; DIFFERENCES=Content-Language Content-language: en-USA Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_Y+ZwecI5meRZlROVT0/svA) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT How do you handle the case of changed RRULE with recurrence-id and SEQUENCE:0? If the RRULEs change, you wouldn't have a RECURRENCE-ID that you can refer to. -----Original Message----- From: Robert_Ransdell@notesdev.ibm.com [mailto:Robert_Ransdell@notesdev.ibm.com] Sent: Wednesday, June 18, 2003 2:01 PM To: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id There was nothing broken about Bruce's example. I'm assuming since you do not want to defend your use of recurrence-id's and since all existing iCalendar products on the market that I know of, use fixed recurrence-id, that the correct usage is fixed recurrence-id's. Any other use is incompatible. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/18/2003 03:54 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: Fw: Correct handling of Recurrence-id Robert_Ransdell@notesdev.ibm.com wrote: > > I don't really consider this a fix since A RESCHEDULE without anyway to > map, is not really a reschedule. There is a way to re-map, tie the sequence number to the recurrence-id. OR when they do not map, do a REFRESH. Any CUA needs to be able to do a REFRESH anyway if things get out of sync for any reason including recurrence-id issues. > Also this does not fix the BUG of changing recurrence-id's on a > reschedule. I know of no bug except in implementations that do not do a REFRESH when they get out of sync for what ever reason. The recurrence rules being out of sync is just one of the many reasons to do a REFRESH. > You have never given a valid counter example for changeable > recurrence-id's to Bruce Kahn's valid example of how fixed recurrence-id > work. This issue can not be closed until unless it is proven that > changeable recurrence-id's work. I do not work for you or Bruce. I do not *have* to give you anything. I have participated in various internet and IETF calendaring working groups since 1978. And did participate in the discussions on this topic and others and I will continue to participate in the discussions. Bruces example showed why is it broken to tie recurrence-id to sequence zero. And he stated in his emails that attendees can not join later if they can not figure out the sequence zero recurrence-id's. Bruces examples did not show that tying the recurrence-id to the sequence number failed, he stated that that is not they way he does it and in his views that is the way it should be. And he did not dispute that doing a REFRESH to get the latest copy breaks users that do not already have the original sequence zero object. He also does not dispute that there is no way to ever get the sequence zero object if that is not the current sequence. And you seem to agree that doing a REFRESH and starting with that copy works, but you do not like it. Recurrence-id's work when you tie them to the sequence number. You simply refuse to acknowledge that it works for others and you simply refuse to and have declared on this list that your product will never change. That's your choice. Demanding that iCal and iTIP change because you do not want to change is not going to convince anyone. Or declaring that it is a bug because some number of vendors do it one way or another way also does not solve the problem. The resolution to this problem that I sent works. Use it or not. However for those that tie the recurrence-id to the sequence number, they CAN and DO allow recurrence rule changes for the same UID. For those that do tie it to sequence zero only, it can be made to work ny doing a REFRESH. I tested it. Do or do not do it, but do not expect me or others to reduce the features in our code simply because you declare it is a bug. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.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_Y+ZwecI5meRZlROVT0/svA) Content-id: 0 Content-type: TEXT/html; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT
How do you handle the case of changed RRULE with recurrence-id and SEQUENCE:0? If the RRULEs change, you wouldn't have a RECURRENCE-ID that you can refer to.
-----Original Message-----
From: Robert_Ransdell@notesdev.ibm.com [mailto:Robert_Ransdell@notesdev.ibm.com]
Sent: Wednesday, June 18, 2003 2:01 PM
To: ietf-calendar@imc.org
Subject: Re: Fw: Correct handling of Recurrence-id


There was nothing broken about Bruce's example.  I'm assuming since you do not want to defend your use of recurrence-id's and since all existing iCalendar products on the market that I know of, use fixed recurrence-id, that the correct usage is fixed recurrence-id's.  Any other use is incompatible.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/18/2003 03:54 PM
Please respond to
ietf-calendar@imc.org

To
ietf-calendar@imc.org
cc
Subject
Re: Fw: Correct handling of Recurrence-id







Robert_Ransdell@notesdev.ibm.com wrote:
>
> I don't really consider this a fix since A RESCHEDULE without anyway to
> map, is not really a reschedule.

There is a way to re-map, tie the sequence number to the recurrence-id.
OR when they do not map, do a REFRESH. Any CUA needs to be able
to do a REFRESH anyway if things get out of sync for any reason
including recurrence-id issues.

> Also this does not fix the  BUG of changing recurrence-id's on a
> reschedule.

I know of no bug except in implementations that do not do a REFRESH
when they get out of sync for what ever reason. The recurrence rules
being out of sync is just one of the many reasons to do a REFRESH.

> You have never given a valid counter example for changeable
> recurrence-id's to Bruce Kahn's valid example of how fixed recurrence-id
> work.  This issue can not be closed until unless it is proven that
> changeable  recurrence-id's work.

I do not work for you or Bruce. I do not *have* to give you anything.
I have participated in various internet and IETF calendaring
working groups since 1978. And did participate in the discussions
on this topic and others and I will continue to participate in the
discussions.

Bruces example showed why is it broken to tie recurrence-id to
sequence zero. And he stated in his emails that attendees can
not join later if they can not figure out the sequence zero recurrence-id's.
Bruces examples did not show that tying the recurrence-id to the
sequence number failed, he stated that that is not they way he
does it and in his views that is the way it should be. And he
did not dispute that doing a REFRESH to get the latest copy breaks
users that do not already have the original sequence zero object.
He also does not dispute that there is no way to ever get the
sequence zero object if that is not the current sequence. And
you seem to agree that doing a REFRESH and starting with that
copy works, but you do not like it.

Recurrence-id's work when you tie them to the sequence number. You simply
refuse to acknowledge that it works for others and you simply refuse to
and have declared on this list that your product will never change.
That's your choice. Demanding that iCal and iTIP change because you do
not want to change is not going to convince anyone. Or declaring that
it is a bug because  some number of vendors do it one way or another
way also does not solve the problem.

The resolution to this problem that I sent works. Use it or not. However
for those that tie the recurrence-id to the sequence number, they CAN and DO
allow recurrence rule changes for the same UID. For those that
do tie it to sequence zero only, it can be made to work ny doing a REFRESH.
I tested it. Do or do not do it, but do not expect me or others to reduce
the features in our code simply because you declare it is a bug.

--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.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_Y+ZwecI5meRZlROVT0/svA)-- From owner-ietf-calendar@mail.imc.org Thu Jun 19 14:05: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 OAA05871 for ; Thu, 19 Jun 2003 14:05:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JHpJrb094657 for ; Thu, 19 Jun 2003 10:51: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 h5JHpJTI094656 for ietf-calendar-bks; Thu, 19 Jun 2003 10:51:19 -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 h5JHpIrb094648 for ; Thu, 19 Jun 2003 10:51:18 -0700 (PDT) (envelope-from arnaud.quillaud@sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5JHpF4Z020980 for ; Thu, 19 Jun 2003 10:51:15 -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 h5JHpFNh008491; Thu, 19 Jun 2003 10:51:15 -0700 (PDT) Received: from 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 <0HGQ00H6PPLE6S@mpkmail.eng.sun.com>; Thu, 19 Jun 2003 10:51:15 -0700 (PDT) Date: Thu, 19 Jun 2003 10:51:14 -0700 From: Arnaud Quillaud Subject: Re: Fw: Correct handling of Recurrence-id To: ietf-calendar@imc.org Message-id: <3EF1F812.9050502@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; 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.1) Gecko/20020826 References: <3EEE5187.90908@Royer.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Your proposal might solves the problem of changing the recurrence rule. But it doesn't solve the more severe interoperability problem of mismatching interpretations of the recurrence-id: If the dtstart of one instance is changed once and the organizer/attendee UAs have different interpretations of what the recurrence-id should be, *even if all the requests arrive in the right order without any lost*, the workflow is broken from now on. Of course a REFRESH from the attendee could probably straighten the situation, but then it seems that REFRESH is the magic solution to all the ambiguities of the iCAL/iTIP spec. If the attendee UI needs to do a REFRESH, even when nothing goes wrong, why should the organizer UI bother with sending individual REQUESTs when an instance changes ? Why not send the whole object all the time ? Instead of trying to get the 2 to coexist, I think we really should settle one way or the other. My experience with iCAL/iTIP is that there are other areas where interoperability is made difficult by the openness of the current specs (e.g. the flexibility of the rrule grammar). Is there any effort going on to amend or add an "interoperability recommendations" document to the protocol ? With CAP coming into the picture soon, I think it is quite important to have its foundations (iCAL/iTIP/iMIP) straightened up. For example, to go back to our beloved RECURRENCE-ID, CAP makes several references to it in some critical sections of the spec. If we leave the RECURRENCE-ID as defined today (i.e. undefined), it means that the CAP interoperability is doomed from the beginning. Thanks, Arnaud Doug Royer wrote: > > > Robert_Ransdell@notesdev.ibm.com wrote: > >> >> Since there would be no mapping of existing repeat dates to the new >> dates generated by the new rule, this is equivalent to a NEW meeting. >> Thus you must assign a new UNID. > > > I think this proposal will fix the incompatibilities and fix the > problem of mid-object-existance joining by attendees from organizers > CUAs which fix the recurrence-id to sequence zero. > > For organizer CUAs that can only generate sequence zero recurrence-ids > and a recurrence rule change occurs. > > If sent to an attendee CUA that only assumes a sequence zero > recurrence-id, > there will be no problem as the organizer CUA will CANCEL and re-REQUEST > on recurrence rule changes. Any CU specific data in the CS for that UID > will be lost at the attendee end. > > If sent to an attendee CUA that assumes recurrence-id is tied to > the sequence number, there will be no problem as the organizer CUA will > CANCEL and re-REQUEST on recurrence rule changes. Any CU specific data > in the CS for that UID will be lost at the attendee end. > > For organizer CUAs that tie the recurrence-id to the sequence number > and a recurrence rule change occurs: > > If sent to an attendee CUA that only assumes sequence zero > recurrence-id, > there will be no problem as the attendee CUA will be unable to map the > recurrence-id to the sequence zero object on recurrence rule changes, > AND the attendee CUA will be able to tell that the new object has > recurrence > rule change, and then it must do a REFRESH. They should throw away their > version of the object and use the new object returned from the organizer > pretending it is sequence zero. No CU specific data in the CS for > that UID need be lost. > > If sent to a an attendee CUA that assumes recurrence-id is tied to > the sequence number, there will be no problem. No CU specific data > in the CS for that UID will be lost. > > > When implementing a CUA if you are going to assume that the recurrence-id > is always tied to sequence zero, then simply doing a REFRESH should > solve the problem if you pretend that whatever sequence you get back > from the REFRESH is sequence zero. This will also allow mid-existince > objects to be joined by CUA/attendees that assume that recurrence-id > is tied to sequence zero. Without this assumption, there is no way > to ever have an ATTENDEE join mid object existence as they would never > be able to process recurrence-ids. > > I think this solves the problem for everyone. Comments? > From owner-ietf-calendar@mail.imc.org Thu Jun 19 15:49:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15193 for ; Thu, 19 Jun 2003 15:49:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JJcNrb098275 for ; Thu, 19 Jun 2003 12:38: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 h5JJcNdP098274 for ietf-calendar-bks; Thu, 19 Jun 2003 12:38:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JJcMrb098262 for ; Thu, 19 Jun 2003 12:38:22 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5JJcJOR017090 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 19 Jun 2003 12:38:22 -0700 Message-ID: <3EF2111B.3020202@Royer.com> Date: Thu, 19 Jun 2003 13:38: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: Fw: Correct handling of Recurrence-id References: <3EEE5187.90908@Royer.com> <3EF1F812.9050502@sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030500020607010206010705" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030500020607010206010705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Arnaud Quillaud wrote: > > Your proposal might solves the problem of changing the recurrence rule. > But it doesn't solve the more severe interoperability problem of > mismatching interpretations of the recurrence-id: > If the dtstart of one instance is changed once and the > organizer/attendee UAs have different interpretations of what the > recurrence-id should be, *even if all the requests arrive in the right > order without any lost*, the workflow is broken from now on. > > Of course a REFRESH from the attendee could probably straighten the > situation, but then it seems that REFRESH is the magic solution to all > the ambiguities of the iCAL/iTIP spec. If the attendee UI needs to do a > REFRESH, even when nothing goes wrong, why should the organizer UI > bother with sending individual REQUESTs when an instance changes ? When any of RRULE, EXRULE, RDATE, or EXDATE changes, you must bump the SEQUENCE number anyway. Then your going to have to send new REQUESTS to all ATTENDEEs anyway. ... > Why not send the whole object all the time ? ...So yes. I have spent much time reviewing the years of archives over the last week or so, I can not find (until the recent proposals), any conversations that said you must re-issue a UID on recurrence rule changes. I believe it was the intent of this WG to be able to evolve the recurrence rules with UIDs over time. And it works as long as you tie recurrence-id to the sequence number. There also have not been any posts that I can find (except the recent proposals) that said you can CANCEL or update the recurrence rules without bumping the sequence number. I think they are a red herring as this WG did already solve that problem. > Instead of trying to get the 2 to coexist, I think we really should > settle one way or the other. I agree that would be best. Fixating the recurrence-id to sequence zero prevents the recurrence rules from ever changing and will make CAP VCARs, NOTIFICATIONS, local CU VALARMs break in CAP. So I just do not see how that will work. So we would have two choices, invent a new iTIP method that says UID-old == UID-new. But that is not necessary, just use the sequence, that is one reason it was invented. In fact iCAL says: ...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. ... Note that 'SEQUENCE' *is* in the text. The argument that was given is 'I do not want to force CUA's to have to do REPLYs' is also bogus for two reasons. (1) The ORGANIZER-CUA is NOT required to send REQUESTs for SEQUENCE number updates unless it feels it needs to and (2) the ATTENDEE CUA can be written to detect what changes and act automatically to some changes. A CUA should be able to detect that any recurrence rule changed and do a REFRESH whenever it gets lost. I just do not see that as difficult. Forcing the world to never be able to update recurrence rules seems like the choice not to make. > My experience with iCAL/iTIP is that there are other areas where > interoperability is made difficult by the openness of the current specs > (e.g. the flexibility of the rrule grammar). Is there any effort going > on to amend or add an "interoperability recommendations" document to the > protocol ? Not in any formal way. > With CAP coming into the picture soon, I think it is quite important to > have its foundations (iCAL/iTIP/iMIP) straightened up. For example, to > go back to our beloved RECURRENCE-ID, CAP makes several references to it > in some critical sections of the spec. If we leave the RECURRENCE-ID as > defined today (i.e. undefined), it means that the CAP interoperability > is doomed from the beginning. I dispute that it is undefined :-) I think the dispute is how it is defined. That does bring up another point. CUAs that fix their recurrence-id to sequence zero will never be able to fetch objects by date/time range with EXPAND=TRUE or FALSE. *Unless* they just happen to have sequence zero laying around in their CS. Changing any recurrence rule requires the SEQUENCE number to be bumped and at that point the CUAs could just (as you state above) send the entire new object. We could specify that as a SHOULD. Then this specific problem goes away (I think). > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030500020607010206010705 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTkxOTM4MDNaMCMGCSqGSIb3DQEJBDEWBBTa Ybv7wR7wXSSsGGKAd2UYVi6QLDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAW1Qqanuff1M5 6uap/Xg8IoqNUtfYWh4qwF95B3zn2wJmrXUk852/e0sYSOuB2oYWnT0/rqODzgJC06X4orMG nDO3v+Uz3tBW7raDzTz34UQxk1/lRHloVvGwqQpWQBFMWJ7IbsRmmeiRgJfeuKm6gTZa+nu2 +G6G8Lj6E9+nMSe0Vc3fO1OEvkov+7ledBeEDConTbSlyKS6UKvRi7RFVfB8pseUhsxTJKzM s8FOfKb12Dw2pH1QuzvkHRrLTC/NHyqmQUb+QDfPUWPdGTcV/EG4NjubbidksBgbFtRygn66 /JuaDbJNHZ/B1zBp/jCR+ITMH9GVAsCp3K7HAamTegAAAAAAAA== --------------ms030500020607010206010705-- From owner-ietf-calendar@mail.imc.org Thu Jun 19 16:50: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 QAA17696 for ; Thu, 19 Jun 2003 16:50: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 h5JKg1rb002241 for ; Thu, 19 Jun 2003 13:42:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JKg1ot002240 for ietf-calendar-bks; Thu, 19 Jun 2003 13:42:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JKg0rb002225 for ; Thu, 19 Jun 2003 13:42:00 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EE8DD80.9030300@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP ABNF: queryc is only used in 1 command? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 19 Jun 2003 16:39:09 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/19/2003 04:41:45 PM, Serialize complete at 06/19/2003 04:41:45 PM Content-Type: multipart/alternative; boundary="=_alternative 007138F485256D4A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007138F485256D4A_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 06/12/2003 04:07:28 PM: > > The string 'CAP-QL' is not in CAP. > I did say CAP-QL but that was NOT the cited ABNF. Here the relevant snippet in case you cant find it: 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 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 007138F485256D4A_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 06/12/2003 04:07:28 PM:

>
> The string 'CAP-QL' is not in CAP.
>

I did say CAP-QL but that was NOT the cited ABNF.  Here the relevant snippet in case you cant find it:

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
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 007138F485256D4A_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 19 16:50: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 QAA17697 for ; Thu, 19 Jun 2003 16:50: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 h5JKg1rb002242 for ; Thu, 19 Jun 2003 13:42:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JKg1iA002239 for ietf-calendar-bks; Thu, 19 Jun 2003 13:42:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JKg0rb002226 for ; Thu, 19 Jun 2003 13:42:00 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EE8DD80.9030300@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP ABNF: queryc is only used in 1 command? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 19 Jun 2003 16:37:04 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/19/2003 04:41:45 PM, Serialize complete at 06/19/2003 04:41:45 PM Content-Type: multipart/alternative; boundary="=_alternative 0071086085256D4A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071086085256D4A_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 06/12/2003 04:07:28 PM: > The string 'CAP-QL' is not in CAP. Finally I agree w/Doug on something... I dont know where I got CAP-QL from, probably reading an earlier draft (the original query lingua Frank & Doug proposed was CAP-QL because it wasnt, and still isnt, SQL). My original posting was about cal-query and that most definitely IS in the draft. Go reread my original posting and perhaps you can reply to it... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0071086085256D4A_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 06/12/2003 04:07:28 PM:
> The string 'CAP-QL' is not in CAP.
Finally I agree w/Doug on something...  I dont know where I got CAP-QL from, probably reading an earlier draft (the original query lingua Frank & Doug proposed was CAP-QL because it wasnt, and still isnt, SQL).

My original posting was about cal-query and that most definitely IS in the draft.  Go reread my original posting and perhaps you can reply to it...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0071086085256D4A_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 19 17:16: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 RAA18885 for ; Thu, 19 Jun 2003 17:16: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 h5JL7Krb003140 for ; Thu, 19 Jun 2003 14:07: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 h5JL7KWK003138 for ietf-calendar-bks; Thu, 19 Jun 2003 14:07: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 h5JL7Irb003133 for ; Thu, 19 Jun 2003 14:07: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 h5JL7FOR017797 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 19 Jun 2003 14:07:19 -0700 Message-ID: <3EF225FA.6080601@Royer.com> Date: Thu, 19 Jun 2003 15:07: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: CAP ABNF: queryc is only used in 1 command? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050106030706090009070100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050106030706090009070100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 'cal-query' is used in properties (QUERY , RESTRICTION, SCOPE) , not sure what you mean by only in one command. Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 06/12/2003 04:07:28 PM: > > > > > The string 'CAP-QL' is not in CAP. > > > > I did say CAP-QL but that was NOT the cited ABNF. Here the relevant > snippet in case you cant find it: > > 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 > > 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 --------------ms050106030706090009070100 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTkyMTA3MDZaMCMGCSqGSIb3DQEJBDEWBBTC fnfwKda/ehcroAmXklk2bhw31jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAVljcN5akEWBP VilqXVAYklD/4TpVu7esF8R9S7jIlpJuMzk3SO1uFMMz+hNM7MA0LJh5Q12HhsmeRxtbiiCq VFeCxBMvr3Cxofb1kmckyZkFM8YxF6ibeaV85G7FgTjUPIdC5UDFfMM7DXZDHBCZ3pkeHRVv RWMeMiE1D4j0+Z25glzlNFNOvc2Hit67Z5lSpd5wsSuOuKPlyhOOggAEFRmeFUjuzIaDF+UU h2rRjHztWFUbHcIXLExocel9lsO/To8foSkMlit0dDdz9M3KH9xQyWveeqTGC3tASRJFVkki i5INdXvqe4o3cHC+NyklpoGUXG8FiwvNDuaMHOxYdwAAAAAAAA== --------------ms050106030706090009070100-- From owner-ietf-calendar@mail.imc.org Thu Jun 19 17:40:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19982 for ; Thu, 19 Jun 2003 17:40:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JLUPrb004084 for ; Thu, 19 Jun 2003 14:30: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 h5JLUP8o004083 for ietf-calendar-bks; Thu, 19 Jun 2003 14:30: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-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JLUOrb004075 for ; Thu, 19 Jun 2003 14:30:24 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EF0C369.8000402@Royer.com> To: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 19 Jun 2003 17:22:05 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/19/2003 05:30:25 PM, Serialize complete at 06/19/2003 05:30:25 PM Content-Type: multipart/alternative; boundary="=_alternative 0075277485256D4A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075277485256D4A_= Content-Type: text/plain; charset="US-ASCII" Doug repined on 06/18/2003 03:54:17 PM: > There is a way to re-map, tie the sequence number to the recurrence-id. > OR when they do not map, do a REFRESH. Any CUA needs to be able > to do a REFRESH anyway if things get out of sync for any reason > including recurrence-id issues. SHOW ME HOW A REFRESH IN A DELTA MODEL WORKS! If you miss 1 reschedule you cannot ever recover no matter what voodoo you _THINK_ or _CLAIM_ happens. Show us otherwise! Ive already demonstrated how it fails but perhaps your Kung Fu is stronger. Show us... > > Also this does not fix the BUG of changing recurrence-id's on a > > reschedule. > > I know of no bug except in implementations that do not do a REFRESH > when they get out of sync for what ever reason. Not sure what you're claiming to be true here but a REFRESH is an iTIP message that an invitee sends to the Organizer. Its only mandated use in iTIP is for the case where the ADD method from the Organizer is NOT supported. There is nothing claming or implying that an invitee need do a REFRESH back to the Organizer in any other case. Since a REQUEST message is fully self contained and thus not reliant on any other message and since iTIP Section 2.1.5 clearly says that "the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values." I have to question your assertion here. If the higher SEQUENCE obsoletes the lower ones then WHY would the invitee need/want to do a REFRESH in response to, say, a SEQUENCE difference of 2?? The higher one they have obsoletes the one they currently have PLUS the missed one. So what use is the REFRESH from the invitee?? It only results in a duplicate of the higher SEQUENCE REFRESH being sent. You can keep repeating "Just do a REFRESH" but unlike a Nike commercial that does not solve anything nor make me buy into it. Show us how it does. Please!! > I do not work for you or Bruce. I do not *have* to give you anything. You do have to be able to back up your claims at least if you want anyone to take them seriously. Repeating them ad naseum w/o any examples though does will not make it true. > I have participated in various internet and IETF calendaring > working groups since 1978. And did participate in the discussions > on this topic and others and I will continue to participate in the > discussions. Then why wont you show us the iTIP on how a REFRESH will recover from a missed SEQUENCE in your 'delta' view of things?! Could it be because you cannot because it doesn't?? > Bruces example showed why is it broken to tie recurrence-id to > sequence zero. Huh?? My examples have why the absolute models works and why a delta model wont work. Thats all. > Bruces examples did not show that tying the recurrence-id to the > sequence number failed My examples showed how keeping a fixed RECURRENCE-ID works and trying to rewrite the RECURRENCE-ID will not. If you missed that Ill be glad to show you again. In the mean time Id really appreciate it if you could stick to the issues and not duck them when you cannot show how it works. I think Ive been more than patient and I certainly wont let the issue just drop since its a key interoperability issue. > And he > did not dispute that doing a REFRESH to get the latest copy breaks > users that do not already have the original sequence zero object. What are you smoking out there Doug?!?! If the RECURRNECE-ID NEVER EVER EVER changes (a claim Ive made all along) then it does NOT require an invitee to know the SEQUENCE:0 RECURRENCE-ID for a particular instance in order to process the latest REQUEST at, say, SEQUENCE:10. The RECURRENCE-ID never changes so its the same at SEQUENCE:0 as it is at SEQUENCE:10 as is at SEQUENCE:100523. As such, the invitee has NO problem keeping in sync w/the Organizer. In _YOUR_ (and Georges too) view of things though the RECURRNECE-ID changes with each reschedule (paraphrased a bit but I can get you the exact quote if you really need it). As such the invitee ABSOLUTELY, POSITIVELY MUST have ALL (repeat _ALL_) of the reschedule REQUESTS from 0 thru 100523 in order to properly stay in sync w/the Organizer! Otherwise they cannot recalculate the RECURRENCE-ID each time! Nothing you wish for or claim (but cannot demonstrate here) will change that. Sorry... > He also does not dispute that there is no way to ever get the > sequence zero object if that is not the current sequence. The absolute model does NOT require that. Why do you think it does? Since RECURRENCE-ID does not change why does the invitee need to have the SEQUENCE:0 version of it when the current one is SEQUENCE:5?? I dont get it? Actually I do; you're the one who doesnt... > Recurrence-id's work when you tie them to the sequence number. Go read iTIP Section 2.1.5 again (or for the first time?). You dont tie them together. UID/RECURRENCE-ID is the primary key to find the particular instance. THEN you use SEQUENCE to see if you know that 'version' of the instance. Not the other way around... Is this not clear?? > You simply > refuse to acknowledge that it works for others and you simply refuse to > and have declared on this list that your product will never change. We cannot acknoledge that it works because it doesn't. You can easily send a message saying it does but you have yet to show the actual iTIP that demonstrates it using your view of the way things should work. How about showing actual iTIP fragments of how your model can recover from a missed REQUEST and then perhaps there would be something for us to actually acknowledge... > Or declaring that > it is a bug because some number of vendors do it one way or another > way also does not solve the problem. Hahaha. I didnt realize you were a part time comic! I really needed that to lighten my end of day. Thanks. > The resolution to this problem that I sent works. What did you send? I havent seen anything that remotely approaches iTIP fragments on how it works. Did I miss 'em?? > However > for those that tie the recurrence-id to the sequence number, Are going to be in a world of hirt when they try to interoperate with other vendors that do adhere to the actual RFCs since they clearly did not read and understand Section 2.1.5 of iTIP on how to do sequencing of messages, etc. > I tested it. Great, you tested it with yourself and that proves what? Did you try testing with other products that support iCal like Notes, Organzier, Outlook, Exchange or Evolution? Or better yet could you cut/paste the iTIP into a WG message so the rest of us can evaluate it? Id love to see how your homogenous system handles missed REQUESTS. Please show us! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0075277485256D4A_= Content-Type: text/html; charset="US-ASCII"
Doug repined on 06/18/2003 03:54:17 PM:
> There is a way to re-map, tie the sequence number to the recurrence-id.
> OR when they do not map, do a REFRESH. Any CUA needs to be able
> to do a REFRESH anyway if things get out of sync for any reason
> including recurrence-id issues.
SHOW ME HOW A REFRESH IN A DELTA MODEL WORKS!  If you miss 1 reschedule you cannot ever recover no matter what voodoo you _THINK_ or _CLAIM_ happens.  Show us otherwise!  Ive already demonstrated how it fails but perhaps your Kung Fu is stronger.  Show us...

> > Also this does not fix the  BUG of changing recurrence-id's on a
> > reschedule.
>
> I know of no bug except in implementations that do not do a REFRESH
> when they get out of sync for what ever reason.

Not sure what you're claiming to be true here but a REFRESH is an iTIP message that an invitee sends to the Organizer.  Its only mandated use in iTIP is for the case where the ADD method from the Organizer is NOT supported.  There is nothing claming or implying that an invitee need do a REFRESH back to the Organizer in any other case.  Since a REQUEST message is fully self contained and thus not reliant on any other message and since iTIP Section 2.1.5 clearly says that "the highest numeric value for the "SEQUENCE" property obsoletes all other revisions of the component with lower values." I have to question your assertion here.  

If the higher SEQUENCE obsoletes the lower ones then WHY would the invitee need/want to do a REFRESH in response to, say, a SEQUENCE difference of 2??  The higher one they have obsoletes the one they currently have PLUS the missed one.  So what use is the REFRESH from the invitee??  It only results in a duplicate of the higher SEQUENCE REFRESH being sent.

You can keep repeating "Just do a REFRESH" but unlike a Nike commercial that does not solve anything nor make me buy into it.  Show us how it does.  Please!!

> I do not work for you or Bruce. I do not *have* to give you anything.
You do have to be able to back up your claims at least if you want anyone to take them seriously.  Repeating them ad naseum w/o any examples though does will not make it true.

> I have participated in various internet and IETF calendaring
> working groups since 1978. And did participate in the discussions
> on this topic and others and I will continue to participate in the
> discussions.
Then why wont you show us the iTIP on how a REFRESH will recover from a missed SEQUENCE in your 'delta' view of things?!  Could it be because you cannot because it doesn't??

> Bruces example showed why is it broken to tie recurrence-id to
> sequence zero.

Huh??  My examples have why the absolute models works and why a delta model wont work.  Thats all.  

> Bruces examples did not show that tying the recurrence-id to the
> sequence number failed

My examples showed how keeping a fixed RECURRENCE-ID works and trying to rewrite the RECURRENCE-ID will not.  If you missed that Ill be glad to show you again.

In the mean time Id really appreciate it if you could stick to the issues and not duck them when you cannot show how it works.  I think Ive been more than patient and I certainly wont let the issue just drop since its a key interoperability issue.

>                                                            And he
> did not dispute that doing a REFRESH to get the latest copy breaks
> users that do not already have the original sequence zero object.

What are you smoking out there Doug?!?!  If the RECURRNECE-ID NEVER EVER EVER changes (a claim Ive made all along) then it does NOT require an invitee to know the SEQUENCE:0 RECURRENCE-ID for a particular instance in order to process the latest REQUEST at, say, SEQUENCE:10.  

The RECURRENCE-ID never changes so its the same at SEQUENCE:0 as it is at SEQUENCE:10 as is at SEQUENCE:100523.  As such, the invitee has NO problem keeping in sync w/the Organizer.

In _YOUR_ (and Georges too) view of things though the RECURRNECE-ID changes with each reschedule (paraphrased a bit but I can get you the exact quote if you really need it).  As such the invitee ABSOLUTELY, POSITIVELY MUST have ALL (repeat _ALL_) of the reschedule REQUESTS from 0 thru 100523 in order to properly stay in sync w/the Organizer!  Otherwise they cannot recalculate the RECURRENCE-ID each time!  Nothing you wish for or claim (but cannot demonstrate here) will change that.  Sorry...

> He also does not dispute that there is no way to ever get the
> sequence zero object if that is not the current sequence.

The absolute model does NOT require that.  Why do you think it does?  Since RECURRENCE-ID does not change why does the invitee need to have the SEQUENCE:0 version of it when the current one is SEQUENCE:5??  I dont get it?  Actually I do; you're the one who doesnt...

> Recurrence-id's work when you tie them to the sequence number.

Go read iTIP Section 2.1.5 again (or for the first time?).  You dont tie them together.  UID/RECURRENCE-ID is the primary key to find the particular instance.  THEN you use SEQUENCE to see if you know that 'version' of the instance.  Not the other way around...  Is this not clear??

>                                                               You simply
> refuse to acknowledge that it works for others and you simply refuse to
> and have declared on this list that your product will never change.
We cannot acknoledge that it works because it doesn't.  You can easily send a message saying it does but you have yet to show the actual iTIP that demonstrates it using your view of the way things should work.

How about showing actual iTIP fragments of how your model can recover from a missed REQUEST and then perhaps there would be something for us to actually acknowledge...

>                                                  Or declaring that
> it is a bug because  some number of vendors do it one way or another
> way also does not solve the problem.
Hahaha.  I didnt realize you were a part time comic!  I really needed that to lighten my end of day.  Thanks.

> The resolution to this problem that I sent works.

What did you send?  I havent seen anything that remotely approaches iTIP fragments on how it works.  Did I miss 'em??

>                                                                    However
> for those that tie the recurrence-id to the sequence number,

Are going to be in a world of hirt when they try to interoperate with other vendors that do adhere to the actual RFCs since they clearly did not read and understand Section 2.1.5 of iTIP on how to do sequencing of messages, etc.

> I tested it.

Great, you tested it with yourself and that proves what?  

Did you try testing with other products that support iCal like Notes, Organzier, Outlook, Exchange or Evolution?  

Or better yet could you cut/paste the iTIP into a WG message so the rest of us can evaluate it?  Id love to see how your homogenous system handles missed REQUESTS.  Please show us!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0075277485256D4A_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 19 18:09: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 SAA22279 for ; Thu, 19 Jun 2003 18:09: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 h5JM0erb005356 for ; Thu, 19 Jun 2003 15:00:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JM0dDp005355 for ietf-calendar-bks; Thu, 19 Jun 2003 15:00:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JM0drb005349 for ; Thu, 19 Jun 2003 15:00:39 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EEBB1EB.8010301@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP ABNF MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 19 Jun 2003 17:37:56 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/19/2003 06:00:38 PM, Serialize complete at 06/19/2003 06:00:38 PM Content-Type: multipart/alternative; boundary="=_alternative 00769AE685256D4A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00769AE685256D4A_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 06/14/2003 07:38:19 PM: > I am starting to go through the CAP abnf looking for errors. Below is > the CAP ABNF from CAP draft-10. Why is it that only the CREATE command has the queryc in it and NO other command does (as part of the create-comp bit of the command)? To me that means that only the CREATE command can have a BEGIN:VQUERY...END:VQUERY in it. As such no other commands can have VQUERYs in them. Now that cant be true can 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 00769AE685256D4A_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 06/14/2003 07:38:19 PM:
> I am starting to go through the CAP abnf looking for errors. Below is
> the CAP ABNF from CAP draft-10.
Why is it that only the CREATE command has the queryc in it and NO other command does (as part of the create-comp bit of the command)?  To me that means that only the CREATE command can have a BEGIN:VQUERY...END:VQUERY in it.  As such no other commands can have VQUERYs in them.  Now that cant be true can 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 00769AE685256D4A_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 19 18:25: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 SAA23500 for ; Thu, 19 Jun 2003 18:25: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 h5JMH2rb006018 for ; Thu, 19 Jun 2003 15:17:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JMH22q006016 for ietf-calendar-bks; Thu, 19 Jun 2003 15:17:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JMH0rb006011 for ; Thu, 19 Jun 2003 15:17:00 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5JMGwOR018412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 19 Jun 2003 15:17:01 -0700 Message-ID: <3EF23651.90905@Royer.com> Date: Thu, 19 Jun 2003 16:16:49 -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="------------ms060205050106070707060408" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060205050106070707060408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug repined on 06/18/2003 03:54:17 PM: > > There is a way to re-map, tie the sequence number to the recurrence-id. > > OR when they do not map, do a REFRESH. Any CUA needs to be able > > to do a REFRESH anyway if things get out of sync for any reason > > including recurrence-id issues. > > SHOW ME HOW A REFRESH IN A DELTA MODEL WORKS! If you miss 1 reschedule > you cannot ever recover no matter what voodoo you _THINK_ or _CLAIM_ > happens. Show us otherwise! Ive already demonstrated how it fails but > perhaps your Kung Fu is stronger. Show us... So Bruce, what do YOU expect to get back from a REFRESH? An unrelated object? A another UID object? Or a voodoo doll :-) Or the entire object you asked for? I really do not understand why you think that a REFRESH will not get you the object you ask be sent. You have not shown any examples of how a REFRESH returns bogus data. You have not shown any examples of how the results of a REFRESH are anything un-usable. If you do a REFRESH on UID:1, you get back the UID:1 object in its latest and most up to date state. Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060205050106070707060408 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTkyMjE2NDlaMCMGCSqGSIb3DQEJBDEWBBTg k+0sqwDGFTEW/RFrGu6SVTHSyzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAEv/KT14mKTrd ZI1JH41Khrx12RfvVgB0sTYP2Qr/LYoUzzhh1HXqcpdhy+AwRwObEqsC5IsH7uaiZWtyTAAM sFzc+kZCVceGfIbGc6Gb3xyj54WTgFtjAtdrsFQGPCX94UoGSw3Gq4JV6yG+7GL8lidyO//g MSgLgWEy9h0k3XGUG/EigZHEOfPn7IPkBgFntQq9gH7HdpvWft9+DsjdnKeGBqM2OpUzq+R7 90TJ53fH3lLEChy1Lu0gbS0WU4yP+qZJRCBFucC7noGdkz28zmKTSXcMGJxI4tmQqsK8fxnr 4gLyWYZQN1ejRfkXiHRLEgzdHzLjAqKKcjDyhHYLSQAAAAAAAA== --------------ms060205050106070707060408-- From owner-ietf-calendar@mail.imc.org Thu Jun 19 18:32: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 SAA23724 for ; Thu, 19 Jun 2003 18:32: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 h5JMP9rb006219 for ; Thu, 19 Jun 2003 15:25: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 h5JMP97N006218 for ietf-calendar-bks; Thu, 19 Jun 2003 15:25: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 h5JMP8rb006213 for ; Thu, 19 Jun 2003 15:25: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 h5JMP5OR018475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 19 Jun 2003 15:25:09 -0700 Message-ID: <3EF2383C.9060202@Royer.com> Date: Thu, 19 Jun 2003 16:25: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: CAP ABNF References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030404030103050201070208" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030404030103050201070208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yep. Search is missing a 'search-comp'. Thanks Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 06/14/2003 07:38:19 PM: > > I am starting to go through the CAP abnf looking for errors. Below is > > the CAP ABNF from CAP draft-10. > > Why is it that only the CREATE command has the queryc in it and NO other > command does (as part of the create-comp bit of the command)? To me > that means that only the CREATE command can have a > BEGIN:VQUERY...END:VQUERY in it. As such no other commands can have > VQUERYs in them. Now that cant be true can it?? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030404030103050201070208 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTkyMjI1MDBaMCMGCSqGSIb3DQEJBDEWBBTo NtAxiddejbl6sNv14dIe4dcTOTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAqC6L6PcgJbN1 yW/E5VdRU3qGchyGJ4/1pdMywlMrjEuO7q14SL7nVn+wbOy75KjzibvLUA6h8+amW1BwuWIz kgZo83DuShqtNYybGXVuLrmMDeLVtEi3XDXHOFOw5cacVfG3qpV5NUrOWOi5mCYedF5rRexw eQrND5SR9SNvJU1BQxicB9qrLjPdjxHx0BF2yyYwTCSZ3Pxl4DZvGvicOHjk9A4K6vyYeGW0 jacmODG2esjYgPgUp60ehoJalxHy7IOr2+PHhidnngadg0x5xThVmYgLu0mF3DvkHcsHJB/8 oiJeWIlc3mrvyQXhlmobleeyUy3J4pordqu62vFb6wAAAAAAAA== --------------ms030404030103050201070208-- From owner-ietf-calendar@mail.imc.org Fri Jun 20 18:28:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13047 for ; Fri, 20 Jun 2003 18:28: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 h5KMDGrb004785 for ; Fri, 20 Jun 2003 15:13:16 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5KMDGsj004784 for ietf-calendar-bks; Fri, 20 Jun 2003 15:13:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KMDGrb004779 for ; Fri, 20 Jun 2003 15:13:16 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EF2383C.9060202@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP ABNF MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 20 Jun 2003 17:56:25 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/20/2003 06:13:16 PM, Serialize complete at 06/20/2003 06:13:16 PM Content-Type: multipart/alternative; boundary="=_alternative 00784B0485256D4B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00784B0485256D4B_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 06/19/2003 06:25:00 PM: > Yep. > > Search is missing a 'search-comp'. Dont forget other commands like DELETE or MOVE etc. ("I want to delete all VTODOs that are 'Complete'", "Move all the VEVENTS with CATEGORY:REDCROSS to my other Calendar", etc) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear! --=_alternative 00784B0485256D4B_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 06/19/2003 06:25:00 PM:
> Yep.
>
> Search is missing a 'search-comp'.

Dont forget other commands like DELETE or MOVE etc.  ("I want to delete all VTODOs that are 'Complete'", "Move all the VEVENTS with CATEGORY:REDCROSS to my other Calendar", etc)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear! --=_alternative 00784B0485256D4B_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 20 18:40: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 SAA13314 for ; Fri, 20 Jun 2003 18:40: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 h5KMV2rb005386 for ; Fri, 20 Jun 2003 15:31:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5KMV2ea005385 for ietf-calendar-bks; Fri, 20 Jun 2003 15:31:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KMV1rb005380 for ; Fri, 20 Jun 2003 15:31:01 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EF225FA.6080601@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP ABNF: queryc is only used in 1 command? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 20 Jun 2003 18:28:39 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/20/2003 06:31:00 PM, Serialize complete at 06/20/2003 06:31:00 PM Content-Type: multipart/alternative; boundary="=_alternative 007B3E7F85256D4B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B3E7F85256D4B_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 06/19/2003 05:07:06 PM: > 'cal-query' is used in properties (QUERY , RESTRICTION, SCOPE) , not sure > what you mean by only in one command. How many 'commands' (under Section 10.x) use cal-query in them? That is, what commands can use QUERY in them? Just 1: CREATE (by create-object containing create-comp wich contains queryc which containes queryprop which is the only ABNF to contain query in it; the ABNF query that is). That means NO OTHER COMMAND can use a BEGIN:VQUERY...END:VQUERY in it! Of course that assumes you can find where create-object is used ANYWHERE in the draft other than where its defined: ABNF for a "CREATE" object is: create-object = "BEGIN" ":" "VCALENDAR" CRLF ; If 'calprops' contain the "METHOD" property ... DELETE does not have the ability to have a cal-query in it. Neither does MOVE. Neither does any other command where you may expect to be able to search for any particular entry or set of entires. That means you have no way in the current ABNF to DELETE the VEVENT with UID:12345@royer.com. It also means the example under the DELETE command is wrong: Example to delete a "VEVENT" component with "UID" value of 'abcd12345' from the calendar "relcald-22" from the current CS: C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: TARGET:relcalid-22 C: CMD;ID:"random but unique per CUA":DELETE C: BEGIN:VQUERY C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345' C: END:VQUERY C: END:VCALENDAR The same goes for the example under MODIFY: Example: C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//someone's prodid C: TARGET:my-cal C: CMD:ID=unique-mod:MODIFY C: BEGIN:VQUERY <- Query to select data set. C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58' C: END:VQUERY C: BEGIN:VEVENT <- Start of old data. and the list goes on. Commands that cannot select any data sets to act on are really useful. I was hoping it was just me not seeing it in the ABNF but I doubt that now... This is not the first time Ive asked yet it seems that noone else has attempted to confirm that all the ABNF nodes are used in all the right places still. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 007B3E7F85256D4B_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 06/19/2003 05:07:06 PM:
> 'cal-query' is used in  properties (QUERY , RESTRICTION, SCOPE) , not sure
> what you mean by only in one command.
How many 'commands' (under Section 10.x) use cal-query in them?  That is, what commands can use QUERY in them?

Just 1: CREATE (by create-object containing create-comp wich contains queryc which containes queryprop which is the only ABNF to contain query in it; the ABNF query that is).  That means NO OTHER COMMAND can use a BEGIN:VQUERY...END:VQUERY in it!  Of course that assumes you can find where create-object is used ANYWHERE in the draft other than where its defined:

ABNF for a "CREATE" object is:

create-object = "BEGIN" ":" "VCALENDAR" CRLF
             ; If 'calprops' contain the "METHOD" property
...              

DELETE does not have the ability to have a cal-query in it.  Neither does MOVE.  Neither does any other command where you may expect to be able to search for any particular entry or set of entires.  

That means you have no way in the current ABNF to DELETE the VEVENT with UID:12345@royer.com.  It also means the example under the DELETE command is wrong:

Example to delete a "VEVENT" component with "UID" value of 'abcd12345' from the calendar "relcald-22" from the current CS:

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: TARGET:relcalid-22
C: CMD;ID:"random but unique per CUA":DELETE
C: BEGIN:VQUERY
C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345'
C: END:VQUERY
C: END:VCALENDAR
The same goes for the example under MODIFY:

  Example:

 C: Content-Type: text/calendar
 C:
 C: BEGIN:VCALENDAR
 C: VERSION:2.0
 C: PRODID:-//someone's prodid
 C: TARGET:my-cal
 C: CMD:ID=unique-mod:MODIFY
 C: BEGIN:VQUERY                   <- Query to select data set.
 C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58'
 C: END:VQUERY
 C: BEGIN:VEVENT                   <- Start of old data.
 
and the list goes on.

Commands that cannot select any data sets to act on are really useful.    I was hoping it was just me not seeing it in the ABNF but I doubt that now...  This is not the first time Ive asked yet it seems that noone else has attempted to confirm that all the ABNF nodes are used in all the right places still.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 007B3E7F85256D4B_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 20 19:47: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 TAA14682 for ; Fri, 20 Jun 2003 19:47: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 h5KNZRrb008660 for ; Fri, 20 Jun 2003 16:35:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5KNZRLA008659 for ietf-calendar-bks; Fri, 20 Jun 2003 16:35:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KNZQrb008654 for ; Fri, 20 Jun 2003 16:35:26 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EF23651.90905@Royer.com> To: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 20 Jun 2003 19:21:25 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/20/2003 07:35:23 PM, Serialize complete at 06/20/2003 07:35:23 PM Content-Type: multipart/alternative; boundary="=_alternative 0080132585256D4B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0080132585256D4B_= Content-Type: text/plain; charset="US-ASCII" Doug penned on 06/19/2003 06:16:49 PM: > > SHOW ME HOW A REFRESH IN A DELTA MODEL WORKS! If you miss 1 reschedule > > you cannot ever recover no matter what voodoo you _THINK_ or _CLAIM_ > > happens. Show us otherwise! Ive already demonstrated how it fails but > > perhaps your Kung Fu is stronger. Show us... > > So Bruce, what do YOU expect to get back from a REFRESH? I expect to get a REQUEST with the matching UID/RECURRNECE-ID at the latest SEQUENCE value. If you are not clear on the use of REFRESH then go reread iTIP, Section 3.2.6 REFRESH. It says: 3.2.6 REFRESH The "REFRESH" method in a "VEVENT" calendar component is used by "Attendees" of an existing event to request an updated description from the event "Organizer". The "REFRESH" method must specify the "UID" property of the event to update. A recurrence instance of an event may be requested by specifying the "RECURRENCE-ID" property corresponding to the associated event. The "Organizer" responds with the latest description and version of the event. It pretty clearly descibes it use I think. Its not vague on what the Organzier is to send back either: "the latest description and version of the event". So, if Im invited to an instance of a repeating entry and I send you a REFRESH I expect you to send me the REQUEST for that UID/RECURRENCE-ID at the current SEQUENCE. So if the instance is currently at SEQUENCE:10 then I expect your CUA to send me SEQUENCE:10. Not SEQUENCE:0. Not SEQUENCE:5. Just for SEQUENCE:10. If I were to use a delta model where the RECURRENCE-ID value changed every time the SEQUENCE did (to match the new DTSTART as you claim) and I was currently at SEQUENCE:5 then just how would your CUA sending me the SEQUENCE:10 REQUEST help me to get back in sync?? In order to match the RECURRENCE-ID I MUST have the SEQUENCE:6 DTSTART, the SEQUENCE:7 DTSTART, the SEQUENCE:8 DTSTART and the SEQUENCE:9 DTSTART (and apply them in order) before I could use the SEQUENCE:10 REQUEST to find the right instance. Thats 5 REQUESTs at different SEQUENCEs, NOT 1. > Or the entire object you asked for? And how do I match the SEQUENCE:10 RECURRENCE-ID in the REQUEST you send back to the SEQUENCE:5 RECURRENCE-ID that I currently have??? HOW!?!? It is physically NOT possible. > I really do not understand why you think that a REFRESH will > not get you the object you ask be sent. Still do not see it?? Besides I think you keep forgetting / ignoring the fact that iTIP says in 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. (The text under 3.4.2 REQUEST for VTODOs properly includes "SEQUENCE" too but thats an already known omission in 3.2.2.) For the case of repeating entrys you should replace "UID" with "UID"/"RECURRENCE-ID" in the text above to be consistant with "To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties" from Section 2.1.5 So, if I have UID:12345, RECURRENCE-ID:20030619T150000Z, SEQUENCE:5 and I opt to ask you to REFRESH it and you send me UID:12345, RECURRENCE-ID:20030625T173000Z, SEQUENCE:10 I will find that I do not know the UID/RECURRENCE-ID primary key (Section 2.1.5) and thus I take the former action described above and treat it like a new request (same UID, different instance!). Now I have 2 instances of UID:12345 on my calendar but only 1 is actually supposed to be there. No matter what I send to you regarding UID:12345, RECURRENCE-ID:20030619T150000Z, SEQUENCE:5 instance, Ill never be able to do anything more with it (except let it block my busytime on my calendar) since by your description its got a stale RECURRENCE-ID and I have no way to get to the current RECURRNECE-ID that I can see. > You have not shown any examples of how a REFRESH returns bogus data. Its not bogus data on a REFRESH; its that the REQUEST that the REFRESH triggers provides the REFRESH sender with any means of resycing! > You have not shown any examples of how the results of a REFRESH > are anything un-usable. Twice I have. You have yet to even once show any iTIP fragments of how I can resync if I miss one intermediate rescheduling REQUEST. 3 weeks and counting (or is it 4 now)... > If you do a REFRESH on UID:1, you get back the UID:1 object > in its latest and most up to date state. If Im only invited to an instance (or subset of instances) then would you send me the entire set now in response to my REFRESH? Gee, that means Im now invited to all instances and not just 1 or a subset! What a wonderful way to party crash. Ill keep that in mind when we do the next CalConnect... Please show me how an invitee to a single instance or subset of instances will be able to resync to UID:1 if they are at SEQUENCE:1 and you are currently at SEQUENCE:5? Also, you seem to have a problem w/the concept of primary and secondary keys as described in iTIP Section 2.1.5. For repeating instances the primary key used to see if you already have that instance is the UID/RECURRNECE-ID pair. As such, in order for the CUA to determine if they have the REQUEST or not (per the cited 3.2.2 REQUEST text above) the CUA uses the UID/RECURRENCE-ID pair to look for the instance. If its found then its an existing instance and we can proceed to step 2 under 2.1.5 and use SEQUENCE. If its not found then its a new REQUEST and we do not need to worry about the rest of Section 2.1.5 since this is the first copy of that instance we've seen. If the UID/RECURRENCE-ID pair is found then the CUA applys step 2 and checks the SEQUENCE of the found instnace w/that of the REQUEST. If the REQUESTs is higher, its newer and thus obsoletes the one we have and so it should be presented to the CU. If the REQUESTs is lower, its older and thus obsoleted by the copy we already have and so it can be safely ignored and disposed of. If the SEQUENCEs are the same then we proceed to step 3 and check the DTSTAMP values. You seem to think that A) SEQUENCE should be used to determine the validity of RECURRENCE-ID (since you've said RECURRENCE-ID changes each SEQUENCE), B) that the SEQUENCE for every instance is shared (ala UID) or C) both A) and B). A can be clearly shown incorrect by (re) reading iTIP Section 2.1.5 on primary and secondary keys. (Common sense: If you change the keys on your house door, will the old keys work to let you in? If you change the key on your hash will you get to the same bucket every time? Of course not...) B is not something thats written anywhere in any of the RFCs and was never in any draft! If you did this then rescheduling any 1 instance of a repeat set would mean the instant invalidation of _all_ other instances and having to renegotation their status all over again! I would hope that that would be clear but perhaps not. Im heading out now but I hope to see some iTIP fragments on Monday showing us how resycing a single instance after a missed SEQUENCE change or two is possible... Given Dougs insistance on this being possible I would tink that it would be a piece of cake to show besides just a simple UID:1. 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 0080132585256D4B_= Content-Type: text/html; charset="US-ASCII"
Doug penned on 06/19/2003 06:16:49 PM:
> > SHOW ME HOW A REFRESH IN A DELTA MODEL WORKS!  If you miss 1 reschedule
> > you cannot ever recover no matter what voodoo you _THINK_ or _CLAIM_
> > happens.  Show us otherwise!  Ive already demonstrated how it fails but
> > perhaps your Kung Fu is stronger.  Show us...
>
> So Bruce, what do YOU expect to get back from a REFRESH?
I expect to get a REQUEST with the matching UID/RECURRNECE-ID at the latest SEQUENCE value.  If you are not clear on the use of REFRESH then go reread iTIP, Section 3.2.6 REFRESH.  It says:

3.2.6 REFRESH

  The "REFRESH" method in a "VEVENT" calendar component is used by
  "Attendees" of an existing event to request an updated description
  from the event "Organizer". The "REFRESH" method must specify the
  "UID" property of the event to update. A recurrence instance of an
  event may be requested by specifying the "RECURRENCE-ID" property
  corresponding to the associated event. The "Organizer" responds with
  the latest description and version of the event.

It pretty clearly descibes it use I think.  Its not vague on what the Organzier is to send back either: "the latest description and version of the event".  

So, if Im invited to an instance of a repeating entry and I send you a REFRESH I expect you to send me the REQUEST for that UID/RECURRENCE-ID at the current SEQUENCE.  So if the instance is currently at SEQUENCE:10 then I expect your CUA to send me SEQUENCE:10.  Not SEQUENCE:0.  Not SEQUENCE:5.  Just for SEQUENCE:10.

If I were to use a delta model where the RECURRENCE-ID value changed every time the SEQUENCE did (to match the new DTSTART as you claim) and I was currently at SEQUENCE:5 then just how would your CUA sending me the SEQUENCE:10 REQUEST help me to get back in sync??  

In order to match the RECURRENCE-ID I MUST have the SEQUENCE:6 DTSTART, the SEQUENCE:7 DTSTART, the SEQUENCE:8 DTSTART and the SEQUENCE:9 DTSTART (and apply them in order) before I could use the SEQUENCE:10 REQUEST to find the right instance.  Thats 5 REQUESTs at different SEQUENCEs, NOT 1.

> Or the entire object you asked for?
And how do I match the SEQUENCE:10 RECURRENCE-ID in the REQUEST you send back to the SEQUENCE:5 RECURRENCE-ID that I currently have???  HOW!?!?  It is physically NOT possible.

> I really do not understand why you think that a REFRESH will
> not get you the object you ask be sent.
Still do not see it??

Besides I think you keep forgetting / ignoring the fact that iTIP says in 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.

(The text under 3.4.2 REQUEST for VTODOs properly includes "SEQUENCE" too but thats an already known omission in 3.2.2.)  For the case of repeating entrys you should replace "UID" with "UID"/"RECURRENCE-ID" in the text above to be consistant with "To reference an instance of a recurring component, the primary key is composed of the "UID" and the "RECURRENCE-ID" properties" from Section 2.1.5

So, if I have UID:12345, RECURRENCE-ID:20030619T150000Z, SEQUENCE:5 and I opt to ask you to REFRESH it and you send me UID:12345, RECURRENCE-ID:20030625T173000Z, SEQUENCE:10 I will find that I do not know the UID/RECURRENCE-ID primary key (Section 2.1.5) and thus I take the former action described above and treat it like a new request (same UID, different instance!).  Now I have 2 instances of UID:12345 on my calendar but only 1 is actually supposed to be there.

No matter what I send to you regarding UID:12345, RECURRENCE-ID:20030619T150000Z, SEQUENCE:5 instance, Ill never be able to do anything more with it (except let it block my busytime on my calendar) since by your description its got a stale RECURRENCE-ID and I have no way to get to the current RECURRNECE-ID that I can see.

> You have not shown any examples of how a REFRESH returns bogus data.
Its not bogus data on a REFRESH; its that the REQUEST that the REFRESH triggers provides the REFRESH sender with any means of resycing!

> You have not shown any examples of how the results of a REFRESH
> are anything un-usable.
Twice I have.  You have yet to even once show any iTIP fragments of how I can resync if I miss one intermediate rescheduling REQUEST.  3 weeks and counting (or is it 4 now)...

> If you do a REFRESH on UID:1, you get back the UID:1 object
> in its latest and most up to date state.
If Im only invited to an instance (or subset of instances) then would you send me the entire set now in response to my REFRESH?  Gee, that means Im now invited to all instances and not just 1 or a subset!  What a wonderful way to party crash.  Ill keep that in mind when we do the next CalConnect...  

Please show me how an invitee to a single instance or subset of instances will be able to resync to UID:1 if they are at SEQUENCE:1 and you are currently at SEQUENCE:5?

Also, you seem to have a problem w/the concept of primary and secondary keys as described in iTIP Section 2.1.5.  For repeating instances the primary key used to see if you already have that instance is the UID/RECURRNECE-ID pair.  As such, in order for the CUA to determine if they have the REQUEST or not (per the cited 3.2.2 REQUEST text above) the CUA uses the UID/RECURRENCE-ID pair to look for the instance.  If its found then its an existing instance and we can proceed to step 2 under 2.1.5 and use SEQUENCE.  If its not found then its a new REQUEST and we do not need to worry about the rest of Section 2.1.5 since this is the first copy of that instance we've seen.

If the UID/RECURRENCE-ID pair is found then the CUA applys step 2 and checks the SEQUENCE of the found instnace w/that of the REQUEST.  If the REQUESTs is higher, its newer and thus obsoletes the one we have and so it should be presented to the CU.  If the REQUESTs is lower, its older and thus obsoleted by the copy we already have and so it can be safely ignored and disposed of.  If the SEQUENCEs are the same then we proceed to step 3 and check the DTSTAMP values.

You seem to think that A) SEQUENCE should be used to determine the validity of RECURRENCE-ID (since you've said RECURRENCE-ID changes each SEQUENCE), B) that the SEQUENCE for every instance is shared (ala UID) or C) both A) and B).

A can be clearly shown incorrect by (re) reading iTIP Section 2.1.5 on primary and secondary keys.  (Common sense: If you change the keys on your house door, will the old keys work to let you in?  If you change the key on your hash will you get to the same bucket every time? Of course not...)

B is not something thats written anywhere in any of the RFCs and was never in any draft!  If you did this then rescheduling any 1 instance of a repeat set would mean the instant invalidation of _all_ other instances and having to renegotation their status all over again!  I would hope that that would be clear but perhaps not.

Im heading out now but I hope to see some iTIP fragments on Monday showing us how resycing a single instance after a missed SEQUENCE change or two is possible...  Given Dougs insistance on this being possible I would tink that it would be a piece of cake to show besides just a simple UID:1.

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 0080132585256D4B_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 20 20:57:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15671 for ; Fri, 20 Jun 2003 20:57: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 h5L0YRrb010070 for ; Fri, 20 Jun 2003 17:34: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 h5L0YRsG010069 for ietf-calendar-bks; Fri, 20 Jun 2003 17:34:27 -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 h5L0YQrb010064 for ; Fri, 20 Jun 2003 17:34:26 -0700 (PDT) (envelope-from arnaud.quillaud@sun.com) 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 h5L0YS7U014171; Fri, 20 Jun 2003 18:34:28 -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 h5L0YSGq028131; Fri, 20 Jun 2003 17:34:28 -0700 (PDT) Received: from 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 <0HGT00AO62XF2K@mpkmail.eng.sun.com>; Fri, 20 Jun 2003 17:34:28 -0700 (PDT) Date: Fri, 20 Jun 2003 17:34:28 -0700 From: Arnaud Quillaud Subject: Re: Fw: Correct handling of Recurrence-id To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Message-id: <3EF3A814.2000708@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; 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.1) Gecko/20020826 References: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Bruce_Kahn@notesdev.ibm.com wrote: > > Doug penned on 06/19/2003 06:16:49 PM: > > > SHOW ME HOW A REFRESH IN A DELTA MODEL WORKS! If you miss 1 > reschedule > > > you cannot ever recover no matter what voodoo you _THINK_ or _CLAIM_ > > > happens. Show us otherwise! Ive already demonstrated how it > fails but > > > perhaps your Kung Fu is stronger. Show us... > > > > So Bruce, what do YOU expect to get back from a REFRESH? > > I expect to get a REQUEST with the matching UID/RECURRNECE-ID at the > latest SEQUENCE value. If you are not clear on the use of REFRESH > then go reread iTIP, Section 3.2.6 REFRESH. It says: ... Maybe there is some misunderstanding here. My guess is that Doug means "Do a REFRESH with just the UID" when you seem to think "REFRESH with UID/RECURRENCE-ID". Doug ? Of course then, what does a REFRESH with just the UID mean ? Do we all agree that, in the case of a recurring event, it means: "Send me back the whole object: master object with any existing exceptions" ? Arnaud From owner-ietf-calendar@mail.imc.org Fri Jun 20 20:57: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 UAA15674 for ; Fri, 20 Jun 2003 20:57:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5L0b2rb010112 for ; Fri, 20 Jun 2003 17:37:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5L0b2SO010111 for ietf-calendar-bks; Fri, 20 Jun 2003 17:37:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5L0b1rb010106 for ; Fri, 20 Jun 2003 17:37:01 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5L0avOR031694 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 20 Jun 2003 17:37:02 -0700 Message-ID: <3EF3A89F.6040709@Royer.com> Date: Fri, 20 Jun 2003 18:36:47 -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="------------ms090406020405080206070509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090406020405080206070509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug penned on 06/19/2003 06:16:49 PM: > > > SHOW ME HOW A REFRESH IN A DELTA MODEL WORKS! If you miss 1 > reschedule > > > you cannot ever recover no matter what voodoo you _THINK_ or _CLAIM_ > > > happens. Show us otherwise! Ive already demonstrated how it fails > but > > > perhaps your Kung Fu is stronger. Show us... > > > > So Bruce, what do YOU expect to get back from a REFRESH? > > I expect to get a REQUEST with the matching UID/RECURRNECE-ID at the > latest SEQUENCE value. ... > ... > > If I were to use a delta model where the RECURRENCE-ID value changed > every time the SEQUENCE did (to match the new DTSTART as you claim) and > I was currently at SEQUENCE:5 then just how would your CUA sending me > the SEQUENCE:10 REQUEST help me to get back in sync?? Simple, at that point the ATTENDEE CUA can throw all of the same UID data away and use the sequence:10 data it just got. Nothing to 'sync'. Problem solved as the ORGANIZERs copy *is the valid copy* of the data. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090406020405080206070509 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjEwMDM2NDdaMCMGCSqGSIb3DQEJBDEWBBRS Sl21Iwg5Ht7+BCbEiwK8ycJVjjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAWw8ZfRJHXhkm Kx3OL5cOQAebCCio4P5klI5ZLz9NAhhRKUnwJvHVYQG9yT46RgwDkUhKFsh/v2BwNFl8MoQF L7plQnWEIyu8XR9FLlYGEwGTWrWJl9jGz4zKE3IV1usc30JGSzNGPxfXqY4rUC0LWbObHG1e jtyITCrwYHrMFwuc0TUSPPN0wec2bjHdP0WNS6ZKREC/EB15o0IzZVMYnKlieS4VNPtweNGx uv0yAC4ewZADnTvAHiRwKXRWsS4niBOSvKJB8aVQcMylrI50WLFZQModwtwgzUl5jOuS/zQd iwQ5gysPl2yIKCkdIh2roc43Fww6tIK/J2Jgv3HdfAAAAAAAAA== --------------ms090406020405080206070509-- From owner-ietf-calendar@mail.imc.org Fri Jun 20 21:56: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 VAA16797 for ; Fri, 20 Jun 2003 21:56: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 h5L1iUrb012009 for ; Fri, 20 Jun 2003 18:44: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 h5L1iUwo012008 for ietf-calendar-bks; Fri, 20 Jun 2003 18:44: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 h5L1iSrb012003 for ; Fri, 20 Jun 2003 18:44:28 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5L1iQOR032216 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 20 Jun 2003 18:44:30 -0700 Message-ID: <3EF3B870.4080603@Royer.com> Date: Fri, 20 Jun 2003 19:44:16 -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: <3EF3A814.2000708@sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070100060409000205050504" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070100060409000205050504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Arnaud Quillaud wrote: > > Bruce_Kahn@notesdev.ibm.com wrote: > >> >> Doug penned on 06/19/2003 06:16:49 PM: >> > > SHOW ME HOW A REFRESH IN A DELTA MODEL WORKS! If you miss 1 >> reschedule >> > > you cannot ever recover no matter what voodoo you _THINK_ or _CLAIM_ >> > > happens. Show us otherwise! Ive already demonstrated how it >> fails but >> > > perhaps your Kung Fu is stronger. Show us... >> > >> > So Bruce, what do YOU expect to get back from a REFRESH? >> >> I expect to get a REQUEST with the matching UID/RECURRNECE-ID at the >> latest SEQUENCE value. If you are not clear on the use of REFRESH >> then go reread iTIP, Section 3.2.6 REFRESH. It says: > > > ... > Maybe there is some misunderstanding here. My guess is that Doug means > "Do a REFRESH with just the UID" ... > Doug ? Yes. > Of course then, what does a REFRESH with just the UID mean ? It gets you the entire UID recurrence rules and all. > Do we all agree that, in the case of a recurring event, it means: "Send > me back the whole object: master object with any existing exceptions" ? Yes. When you get out of sync for any reason do a REFRESH/UID and no recurence-id. Correct. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070100060409000205050504 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjEwMTQ0MTZaMCMGCSqGSIb3DQEJBDEWBBQf hvHVWWZAiWrUCCKhW00NMQSVhDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAA/gjTH0zIqBl VU5tCDRZS6EWBvrt2H6IIFguX/9Ubc5kEHmwYuruyKwFgvxVzkr45ylkrbRqZlLNEvYOIR3y rX3ZTf6Eg9oMYtYeoPxluN5Z7uRz50SJDtbz3mvuIeqpMOXd3SIEpEyUZGv+Nq+eB4of85qU PTdAoTjZhN49Y9ZYK5HlZVs8My6ohZ6RkquoqfnYSlAM8Y9HANyYnx2nGP4+27pSjABDAUsj F5SqfjmP0tarlUT63+9Yv9BfE8+oxRCjqPtM49rW48weslauU9/AUT+XoPwk1che/oCmy1pk fhas4oluYKY0rDOZafdWkc63TRxBbTvEm6ON6jdnvAAAAAAAAA== --------------ms070100060409000205050504-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 04:54: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 EAA13195 for ; Mon, 23 Jun 2003 04:54: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 h5N8Oorb028647 for ; Mon, 23 Jun 2003 01:24: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 h5N8Oont028646 for ietf-calendar-bks; Mon, 23 Jun 2003 01:24:50 -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 h5N8Omrb028635 for ; Mon, 23 Jun 2003 01:24:49 -0700 (PDT) (envelope-from acampi@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 210) id B160115567; Mon, 23 Jun 2003 10:24:43 +0200 (CEST) Date: Mon, 23 Jun 2003 10:24:43 +0200 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: Craig Johnson , ietf-calendar@imc.org Subject: Re: Default TARGET Message-ID: <20030623082443.GB91250@inet.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: I'm slowly catching up with wg activity so sorry for resurrecting old threads... On Thu, Jun 12, 2003 at 02:57:15PM -0400, Bruce_Kahn@notesdev.ibm.com wrote: > > 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. > > I think we should fix up the draft and NOT default TARGET. Heres why: > [...] > I see lots of questions / concerns about data safety and usability and the > only real cost trade off is "9 octets + strlen(relcalid)" vs cleaning up > the ABNF in CAP. I for one like it clearly spelled out in the text/ABNF > since the savings is not likely to be that big anyway (compared to the > cost of going "off box" to the CS, etc). I would vote for fixing the text > and not defaulting anything! I agree with Bruce here. I don't see any compelling reason to default the TARGET while all worries Bruce expressed are very real. 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 Mon Jun 23 11:36:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25219 for ; Mon, 23 Jun 2003 11:36: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 h5NFNcrb062737 for ; Mon, 23 Jun 2003 08:23:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NFNcEu062736 for ietf-calendar-bks; Mon, 23 Jun 2003 08:23:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NFNWrb062731 for ; Mon, 23 Jun 2003 08:23:37 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EF3A814.2000708@sun.com> To: Arnaud Quillaud Cc: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 23 Jun 2003 11:15:45 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/23/2003 11:23:23 AM, Serialize complete at 06/23/2003 11:23:23 AM Content-Type: multipart/alternative; boundary="=_alternative 00537A0C85256D4E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00537A0C85256D4E_= Content-Type: text/plain; charset="US-ASCII" Arnaud wrote on 06/20/2003 08:34:28 PM: > Maybe there is some misunderstanding here. My guess is that Doug means > "Do a REFRESH with just the UID" when you seem to think "REFRESH with > UID/RECURRENCE-ID". My examples have been how do I resync a particular UID/RECURRENCE-ID all along. Thats what "If Im only invited to an instance (or subset of instances) then would you send me the entire set now in response to my REFRESH?" means. As I noted in my last posting, if Doug sends me a REQUEST for the entire sequence then all of a sudden Im invited to all instances and not just 1. Thats NOT the proper action to take clearly is it?? Sending a REFRESH that describes the entire UID does not work for someone whose only coming to a particular instance or a subset of the entire set. Cant no matter how ya slice it. > Of course then, what does a REFRESH with just the UID mean ? 2446 is not vague on this at least to me. It says: 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. It means a refresh to either a non-repeating entry or the entire set defined by the UID. This should not be ambiguous. Ive already responded how it works in the absolute model (that was ~3 weeks ago) but it seems that Doug thinks that a REFRESH w/o any RECURRECE-ID info it in response to my UID/RECURRENCE-ID REFRESH requst will solve the problem. It cant for those not invited to the entire set; unless you want to now include them on all the instances... %^| > Do we all agree that, in the case of a recurring event, it means: "Send > me back the whole object: master object with any existing exceptions" ? 2446 says: The "Organizer" responds with the latest description and version of the event. The discrepancy is what the "master object" is or perhaps its unclear to some that if the REFRESH is for a particular UID/RECURRENCE-ID then the REQUEST that is expected back should be for that RECURRENCE-ID. This also does not cover the orphaning of the earlier RECURRENCE-ID either if it changes for each reschedule per Dougs suggestion. This has gone on for way too long and I think Doug and others are forgetting several important points so Ill try to get us refocused: 1: We _had_ this kind of disucssion back in ~July 1999 and we all agreed then that RECURRENCE-ID does NOT change! Go check the archives and look for Dan Hickmans thread. 2: Dougs/Georges entire design philosphy is based on _1_ paragraph in 2445 that contradicts _several_ others in 2445 and 2446. The paragraph that they seem to be fixated on for justifying changing RECURRENCE-IDs is one that was left in from the initial model where we did have a delta model. After we (the WG) took a hard look at how workflow was effected and impacted by trying to recover from missed messages we found we COULD NOT use a delta model. Go ask the original authors of 2445/2446 if you dont believe me! 3: The 3rd paragraph under the 4.8.4.4 Recurrence ID Description on p. 108 contradicts the 4th (which I claim is residual to the delta model) in that it says that RECURRENCE-ID does not change. However it is in total agreement with 2446's Section 2.1.5 Message Sequencing where it describes using UID/RECURRENCE-ID as the primary key to find the instance in question (so you can THEN use SEQUENCE to determine if the message is older or newer). It is also in total agreement with the text under 2446's Section 3.2.2 REQUEST where it describes how to determine if this is a new invitation or an update (2nd paragraph after the bulleted list). So are all these _other_ paragraphs WRONG too? Its just common sense that if the primary key changes (ie: RECURRENCE-ID) then you are NOT referring to the same instance. Doug keeps talking about using SEQUENCE to check the RECURRENCE-ID value but no matter what he wants thats BACKWARDS from the clear and unambiguious steps defined in 2.1.5 for message sequencing. 4: The authors of the original RFCs have already implemented and interop tested their products (several products really) along with anyone else who has done an engine so far. Did we all get the model wrong or is someone new just trying to change it now based on a bit of residual prose? The standards are ~255 pages combined so its not unlikely that 1 paragraph could get overlooked in the change from delta to absolute that we did. Other mistakes happened and this is just one more. 5: It can easily be demonstrated that its not possible to resync a single instance or subset of instances if the RECURRENCE-ID changes and a single reschedule was missed. No delta model solution exists to cover this and thats just one reason why we long ago changed the underlying model from delta to absolute. This entire discussion has merely pointed out that we need to remove the 4th paragraph under the Detailed Description of RECURRENCE-ID in 2445 so that its totally unambiguous that 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... --=_alternative 00537A0C85256D4E_= Content-Type: text/html; charset="US-ASCII"
Arnaud wrote on 06/20/2003 08:34:28 PM:
> Maybe there is some misunderstanding here.  My guess is that Doug means
> "Do a REFRESH with just the UID" when you seem to think "REFRESH with
> UID/RECURRENCE-ID".
My examples have been how do I resync a particular UID/RECURRENCE-ID all along.  Thats what "If Im only invited to an instance (or subset of instances) then would you send me the entire set now in response to my REFRESH?" means.  

As I noted in my last posting, if Doug sends me a REQUEST for the entire sequence then all of a sudden Im invited to all instances and not just 1.  Thats NOT the proper action to take clearly is it??

Sending a REFRESH that describes the entire UID does not work for someone whose only coming to a particular instance or a subset of the entire set.  Cant no matter how ya slice it.  

> Of course then, what does a REFRESH with just the UID mean ?
2446 is not vague on this at least to me.  It says:

   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.

It means a refresh to either a non-repeating entry or the entire set defined by the UID.  This should not be ambiguous.  Ive already responded how it works in the absolute model (that was ~3 weeks ago) but it seems that Doug thinks that a REFRESH w/o any RECURRECE-ID info it in response to my UID/RECURRENCE-ID REFRESH requst will solve the problem.  It cant for those not invited to the entire set; unless you want to now include them on all the instances... %^|

> Do we all agree that, in the case of a recurring event, it means: "Send
> me back the whole object: master object with any existing exceptions" ?
2446 says:

                                       The "Organizer" responds with
  the latest description and version of the event.

The discrepancy is what the "master object" is or perhaps its unclear to some that if the REFRESH is for a particular UID/RECURRENCE-ID then the REQUEST that is expected back should be for that RECURRENCE-ID.  This also does not cover the orphaning of the earlier RECURRENCE-ID either if it changes for each reschedule per Dougs suggestion.  

This has gone on for way too long and I think Doug and others are forgetting several important points so Ill try to get us refocused:

1: We _had_ this kind of disucssion back in ~July 1999 and we all agreed then that RECURRENCE-ID does NOT change!  Go check the archives and look for Dan Hickmans thread.

2: Dougs/Georges entire design philosphy is based on _1_ paragraph in 2445 that contradicts _several_ others in 2445 and 2446.  The paragraph that they seem to be fixated on for justifying changing RECURRENCE-IDs is one that was left in from the initial model where we did have a delta model.  After we (the WG) took a hard look at how workflow was effected and impacted by trying to recover from missed messages we found we COULD NOT use a delta model.  Go ask the original authors of 2445/2446 if you dont believe me!

3: The 3rd paragraph under the 4.8.4.4 Recurrence ID Description on p. 108 contradicts the 4th (which I claim is residual to the delta model) in that it says that RECURRENCE-ID does not change.  However it is in total agreement with 2446's Section 2.1.5 Message Sequencing where it describes using UID/RECURRENCE-ID as the primary key to find the instance in question (so you can THEN use SEQUENCE to determine if the message is older or newer).  It is also in total agreement with the text under 2446's Section 3.2.2 REQUEST where it describes how to determine if this is a new invitation or an update (2nd paragraph after the bulleted list).  So are all these _other_ paragraphs WRONG too?  Its just common sense that if the primary key changes (ie: RECURRENCE-ID) then you are NOT referring to the same instance.  Doug keeps talking about using SEQUENCE to check the RECURRENCE-ID value but no matter what he wants thats BACKWARDS from the clear and unambiguious steps defined in 2.1.5 for message sequencing.

4: The authors of the original RFCs have already implemented and interop tested their products (several products really) along with anyone else who has done an engine so far.  Did we all get the model wrong or is someone new just trying to change it now based on a bit of residual prose?  The standards are ~255 pages combined so its not unlikely that 1 paragraph could get overlooked in the change from delta to absolute that we did.  Other mistakes happened and this is just one more.

5: It can easily be demonstrated that its not possible to resync a single instance or subset of instances if the RECURRENCE-ID changes and a single reschedule was missed.  No delta model solution exists to cover this and thats just one reason why we long ago changed the underlying model from delta to absolute.

This entire discussion has merely pointed out that we need to remove the 4th paragraph under the Detailed Description of RECURRENCE-ID in 2445 so that its totally unambiguous that 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... --=_alternative 00537A0C85256D4E_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 12:38: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 MAA27982 for ; Mon, 23 Jun 2003 12:38: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 h5NGNWrb064924 for ; Mon, 23 Jun 2003 09:23: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 h5NGNWp4064923 for ietf-calendar-bks; Mon, 23 Jun 2003 09:23:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NGNUrb064918 for ; Mon, 23 Jun 2003 09:23:30 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5NGNDOR017820 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 23 Jun 2003 09:23:24 -0700 Message-ID: <3EF7296C.7080401@Royer.com> Date: Mon, 23 Jun 2003 10:23: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: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090806080405060207090002" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090806080405060207090002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Arnaud wrote on 06/20/2003 08:34:28 PM: > > Maybe there is some misunderstanding here. My guess is that Doug means > > "Do a REFRESH with just the UID" when you seem to think "REFRESH with > > UID/RECURRENCE-ID". > > My examples have been how do I resync a particular UID/RECURRENCE-ID all > along. Thats what "If Im only invited to an instance (or subset of > instances) then would you send me the entire set now in response to my > REFRESH?" means. It is not needed, do a full (not recurrence-id) REFRESH and you are back in sync. No code needs to be written that you would not have already needed to write. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090806080405060207090002 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjMxNjIzMDhaMCMGCSqGSIb3DQEJBDEWBBSq tTFGsgSfQaRQIMfFRB9bJq+lCjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAJwnzj9P5dnft lU3OlqTjk5o/Zo+JnQTxtRMKZ5pUEknWL8S1tn8a1qRdkUnRpUJj9ot53t2qdsfuPKKneMNm c41UcpuZok4v0chbEV7vAnZvGt50HeQnrcdWAxQNgLRs1NUo/p1fdyjXnj9zAH6ZmOHD2rn/ p3NDjevGGinQLD0WnkozS99u0YbSnuaOgsC00DKvh+qwkOBabl7jrMWrbZDLxAswJ/su9Zho O587jpywgSFwVmJzwoHJV78vkfEgoQjVNo9155Gw5YZbolvjoK5/iFbutOD+Y8SxV+vIZBWI JMmT2cEF/7cMH2+88zfbXk/J3l37tHQHRS4tRiLhNwAAAAAAAA== --------------ms090806080405060207090002-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 13:51: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 NAA01002 for ; Mon, 23 Jun 2003 13:51: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 h5NHbwrb071860 for ; Mon, 23 Jun 2003 10:37:58 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NHbwAt071859 for ietf-calendar-bks; Mon, 23 Jun 2003 10:37:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NHbvrb071853 for ; Mon, 23 Jun 2003 10:37:58 -0700 (PDT) (envelope-from cco@asitturnsout.org) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 1FBBD8D792 for ; Mon, 23 Jun 2003 10:37:58 -0700 (PDT) From: "Chris Olds" To: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id Date: Mon, 23 Jun 2003 10:37:58 -0700 Message-Id: <20030623165751.M57912@asitturnsout.org> In-Reply-To: References: <3EF3A814.2000708@sun.com> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 23 Jun 2003 11:15:45 -0400, Bruce_Kahn wrote > Arnaud wrote on 06/20/2003 08:34:28 PM: > > Maybe there is some misunderstanding here. My guess is that Doug means > > "Do a REFRESH with just the UID" when you seem to think "REFRESH with > > UID/RECURRENCE-ID". > > My examples have been how do I resync a particular UID/RECURRENCE-ID > all along. Thats what "If Im only invited to an instance (or subset > of instances) then would you send me the entire set now in response > to my REFRESH?" means. None of the CUAs I have expose the ability to do this, but I would expect that any CUA capable of inviting someone to a subset of a set of meetings (recurring or otherwise) would be able to keep track of this. As a result, the organizer's CUA would be able to send the current state of the subset I had been invited to (in reality, for privacy reasons, I would expect that it would completely conceal from me that I was only invited to a subset). > As I noted in my last posting, if Doug sends me a REQUEST for the > entire sequence then all of a sudden Im invited to all instances and > not just 1. Thats NOT the proper action to take clearly is it?? > > Sending a REFRESH that describes the entire UID does not work for > someone whose only coming to a particular instance or a subset of > the entire set. Cant no matter how ya slice it. The (modest) additional complexity of making this work must be implemented in the organizer's CUA, but it works just fine. Pegging the RECURRANCE-ID to the values of SEQ=0 is the more brittle mode - how can I add instances to a set w/o issuing a new UID in that case? This is clearly an anticipated action, but it breaks SEQ=0 semantics by adding an instance that cannot be addressed by RECURRENCE-ID if those values are fixed at SEQ=0. Forcing a new UID to be allocated is contrary to the described workflows, and would reqire cancelling the sequence and issuing a new REQUEST with the new UID in order to work at all. Making RECURRENCE-ID depend on the UID and SEQUENCE is not a delta model. Since the current state of the REQUEST can always be obtained via REFRESH, any attendee CUA that finds itself out of synch can recover with one pair of messages. Pinning RECURRENCE-ID values to SEQUENCE 0 requires attendee CUAs to do complex tracking of the mapping of RECURRENCE-IDs to instances as the event evolves, and what I think of when I hear the term 'delta model'. It is easy to find series of updates that make RECURRENCE_IDs ambiguous, and easy to have instances with no valid (according to this model) RECURRENCE-ID. While this view appears to agree with Doug, it is based on my own reading of iTIP. It wouldn't surprise me if many other people held this view, but arent' saying anything because of the tenor of many of Bruce's messages. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Mon Jun 23 14:15: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 OAA02205 for ; Mon, 23 Jun 2003 14:15: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 h5NI37rb073027 for ; Mon, 23 Jun 2003 11:03: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 h5NI37Ev073026 for ietf-calendar-bks; Mon, 23 Jun 2003 11:03:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NI34rb073017 for ; Mon, 23 Jun 2003 11:03:05 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EF7296C.7080401@Royer.com> To: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 23 Jun 2003 13:54:04 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/23/2003 02:03:02 PM, Serialize complete at 06/23/2003 02:03:02 PM Content-Type: multipart/alternative; boundary="=_alternative 00624C5B85256D4E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00624C5B85256D4E_= Content-Type: text/plain; charset="US-ASCII" Doug persisted on 06/23/2003 12:23:08 PM: > It is not needed, do a full (not recurrence-id) REFRESH and you are > back in sync. My example was for someone who is NOT invited to the entire set. Examples are: guest speakers for monthly team meetings, one-time presenters for regular meetings (ie: design review boards), Proxys / Delegates, etc. Do you expect to just invite them to all instances if they do a REFRESH for the UID/RECURRENCE-ID you invited them to? After all you previously sent a REQUEST for a particular UID/RECURRENCE-ID and they for some reason decided to REFRESH (per your suggestion). Now they get a REQUEST for all instances?? They are _not_ invited to all so why send a new REQUEST for the entire set now rather than the instance they just got invited to? PLUS this entire suggestion is predicated on using SEQUENCE to find the RECURRENCE-ID/UID pair when sequencing the REQUESTs the invitee receives. HOWEVER that is BACKWARDS from 2446's description in Section 2.1.5 Message Sequencing. This section of iTIP is not ambiguous so I dont know why some keep trying to use SEQUENCE to determine the validity of RECURRENCE-ID; thats clearly contrary to Section 2.1.5. I dont know why Doug thinks that a new REQUEST will solve the problem because it has a higher SEQUENCE when SEQUENCE is used as the secondary key to matching the REQUEST to the instance that currently exists. SEQUENCE is the secondary key to determine if for the instance found using a particular UID/RECURRENCE-ID pair (primary key) can be safely ignored or not. By changing the RECURRENCE-ID part of the primary key you can never consistantly find the same instance! Never! This also means that rescheduling a particular instance alone is not doable since you seem to think that sending the entire set is the answer and it is not. By reving RECURRENCE-ID and SEQUENCE for a particular instance as you reschedule it you cannot recover from a missed REQUEST! Nothing said so far has shown otherwise. Also, the "just do a REFRESH" is predicated on some unknown trigger action on the users part. iTIP only mandates/defines the use of REFRESH for the case of ADD not being supported. iTIP also clearly says that for a given UID[/RECURRENCE-ID] the SEQUENCE value is used to determine if a message is obsolete or not since the message is supposed to be totally self contained. This is iTIPO section 2.1.5, not some unknown or wishful thinking. It also does not factor in the behaviour described about distinguishing a reschedule from a new request. Since iTIP also clearly says in 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. and the restriction table says: RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. So, if a user gets 2 REQUESTS with the same UID but different RECURRENCE-IDs then they treat them as 2 separate invitations to 2 separate instances. If the Organzer wants to reschedule a particular instance they would use the same RECURRENCE-ID (not disputed by anyone) with a higher SEQUENCE value (per Section 2.1.5). However its NOT possible to miss 1 REQUEST for a particular RECURRENCE-ID and properly match find the correct instance if the RECURRENCE-ID changes per Dougs suggestion. This means that message sequencing MUST be done by SEQUENCE then UID/RECURRENCE-ID in order to even try and do the request vs reschedule distinction. This though is contrary to Sections 2.1.5 and the text above. If RECURRENCE-ID never changes then there is no danger of misidentifying an instance because the behaviour from Sections 2.1.5 and 3.2.2 works perfectly. The proper instance is found and it does not matter if 1 (or 100) reschedule were missed. It doesn't because the newer SEQUENCE "obsoletes all other revisions of the component with lower values" and because the UID/RECURRENCE-ID is found and matched (per Section 3.2.2 above) the CUA can properly tell to ignore the old REQUEST. NO need for any REFRESH. No need to try and resync; the newest SEQUENCE _does_ that by the virtue that its the most recent copy. Per the text from iTIP 3.2.2 REQUEST above each reschedule with a new RECURRENCE-ID and SEQUENCE (BUT for the same instance as Doug suggests) would be treated as a NEW invitation and NOT a reschedule. As such the CUA will now think there are 2 instances Im invited to when infact I just missed just 1 REQUEST that rescheduled the instance. Since I shouldn't ever have to do a REFRESH when I get a new REQUEST, I would never think that Im invited to just 1 instance rather than to 2 (or more). Each missed reschedule would result in more 'orphans' being added to my calendar and unless I though that a REFRESH was in order (cause still TBD as to why I think that) Id never be able to recover properly even if I got a full REQUEST again (as was suggested). All of Dougs & Georges logic is based on 1 paragraph in 2445 and it ignores the conflicting paragraph before it PLUS all of the conflicts it has with 2446. If Doug wants to build something to this model then I wont stop him. Ive already tried to correct the problem but since I dont work with or for Doug thats the best I can do. I hope others take the analytical approach to this (and read my previous msg on this) before jumping off the cliff too. Doug's been around since nearly the beginning so I dont know why he didnt speak up back in 1999 when we first discussed if RECURRENCE-ID changes or not... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00624C5B85256D4E_= Content-Type: text/html; charset="US-ASCII"
Doug persisted on 06/23/2003 12:23:08 PM:
> It is not needed, do a full (not recurrence-id) REFRESH and you are
> back in sync.

My example was for someone who is NOT invited to the entire set.  Examples are: guest speakers for monthly team meetings, one-time presenters for regular meetings (ie: design review boards), Proxys / Delegates, etc.  

Do you expect to just invite them to all instances if they do a REFRESH for the UID/RECURRENCE-ID you invited them to?  After all you previously sent a REQUEST for a particular UID/RECURRENCE-ID and they for some reason decided to REFRESH (per your suggestion).  Now they get a REQUEST for all instances??  They are _not_ invited to all so why send a new REQUEST for the entire set now rather than the instance they just got invited to?

PLUS this entire suggestion is predicated on using SEQUENCE to find the RECURRENCE-ID/UID pair when sequencing the REQUESTs the invitee receives.  HOWEVER that is BACKWARDS from 2446's description in Section 2.1.5 Message Sequencing.  This section of iTIP is not ambiguous so I dont know why some keep trying to use SEQUENCE to determine the validity of RECURRENCE-ID; thats clearly contrary to Section 2.1.5.  I dont know why Doug thinks that a new REQUEST will solve the problem because it has a higher SEQUENCE when SEQUENCE is used as the secondary key to matching the REQUEST to the instance that currently exists.  SEQUENCE is the secondary key to determine if for the instance found using a particular UID/RECURRENCE-ID pair (primary key) can be safely ignored or not.  By changing the RECURRENCE-ID part of the primary key you can never consistantly find the same instance!  Never!

This also means that rescheduling a particular instance alone is not doable since you seem to think that sending the entire set is the answer and it is not.  By reving RECURRENCE-ID and SEQUENCE for a particular instance as you reschedule it you cannot recover from a missed REQUEST!  Nothing said so far has shown otherwise.

Also, the "just do a REFRESH" is predicated on some unknown trigger action on the users part.  iTIP only mandates/defines the use of REFRESH for the case of ADD not being supported.  iTIP also clearly says that for a given UID[/RECURRENCE-ID] the SEQUENCE value is used to determine if a message is obsolete or not since the message is supposed to be totally self contained.  This is iTIPO section 2.1.5, not some unknown or wishful thinking.  

It also does not factor in the behaviour described about distinguishing a reschedule from a new request.  Since iTIP also clearly says in 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.
and the restriction table says:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise it
                           MUST NOT be present.
So, if a user gets 2 REQUESTS with the same UID but different RECURRENCE-IDs then they treat them as 2 separate invitations to 2 separate instances.  If the Organzer wants to reschedule a particular instance they would use the same RECURRENCE-ID (not disputed by anyone) with a higher SEQUENCE value (per Section 2.1.5).  

However its NOT possible to miss 1 REQUEST for a particular RECURRENCE-ID and properly match find the correct instance if the RECURRENCE-ID changes per Dougs suggestion.  This means that message sequencing MUST be done by SEQUENCE then UID/RECURRENCE-ID in order to even try and do the request vs reschedule distinction.  This though is contrary to Sections 2.1.5 and the text above.

If RECURRENCE-ID never changes then there is no danger of misidentifying an instance because the behaviour from Sections 2.1.5 and 3.2.2 works perfectly.  The proper instance is found and it does not matter if 1 (or 100) reschedule were missed.  It doesn't because the newer SEQUENCE "obsoletes all other revisions of the component with lower values" and because the UID/RECURRENCE-ID is found and matched (per Section 3.2.2 above) the CUA can properly tell to ignore the old REQUEST.  NO need for any REFRESH.  No need to try and resync; the newest SEQUENCE _does_ that by the virtue that its the most recent copy.

Per the text from iTIP 3.2.2 REQUEST above each reschedule with a new RECURRENCE-ID and SEQUENCE (BUT for the same instance as Doug suggests) would be treated as a NEW invitation and NOT a reschedule.  As such the CUA will now think there are 2 instances Im invited to when infact I just missed just 1 REQUEST that rescheduled the instance.  Since I shouldn't ever have to do a REFRESH when I get a new REQUEST, I would never think that Im invited to just 1 instance rather than to 2 (or more).  Each missed reschedule would result in more 'orphans' being added to my calendar and unless I though that a REFRESH was in order (cause still TBD as to why I think that) Id never be able to recover properly even if I got a full REQUEST again (as was suggested).  

All of Dougs & Georges logic is based on 1 paragraph in 2445 and it ignores the conflicting paragraph before it PLUS all of the conflicts it has with 2446.   If Doug wants to build something to this model then I wont stop him.  Ive already tried to correct the problem but since I dont work with or for Doug thats the best I can do.  I hope others take the analytical approach to this (and read my previous msg on this) before jumping off the cliff too.  Doug's been around since nearly the beginning so I dont know why he didnt speak up back in 1999 when we first discussed if RECURRENCE-ID changes or not...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00624C5B85256D4E_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 16:18: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 QAA08695 for ; Mon, 23 Jun 2003 16:18: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 h5NJxTrb077988 for ; Mon, 23 Jun 2003 12:59: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 h5NJxSmR077987 for ietf-calendar-bks; Mon, 23 Jun 2003 12:59:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJxRrb077982 for ; Mon, 23 Jun 2003 12:59: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 h5NJxGOR019827 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 23 Jun 2003 12:59:25 -0700 Message-ID: <3EF75C0F.6090903@Royer.com> Date: Mon, 23 Jun 2003 13:59: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: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070501000908000906000403" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070501000908000906000403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug persisted on 06/23/2003 12:23:08 PM: > > It is not needed, do a full (not recurrence-id) REFRESH and you are > > back in sync. > > My example was for someone who is NOT invited to the entire set. > Examples are: guest speakers for monthly team meetings, one-time > presenters for regular meetings (ie: design review boards), Proxys / > Delegates, etc. > .... That has NOTHING to do with the problem. If ATTENDEE X asks for a REFRESH, send him what *he* is expected to see. We discussed this prior to iTIP being released. All ATTENDEEs do *not* have to have the same copy of a UID. Just send them what *they* need to see as the ORGANIZER would need to understand that anyway. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070501000908000906000403 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjMxOTU5MTFaMCMGCSqGSIb3DQEJBDEWBBRs WrZ2ylC7bRCnnMUhsjeVfKcH8TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAm7KM65A+cvF3 y/PIoHo4geGE7ixn3HfbZ4iQn9wLuZQWNRGdXsVRZhPjpt/pqmnriSK2wTmCeXf2587V71Lx QwfoZbxpaPP4ljfl1P3jxnMqw5fjzNyqYtkJP+q5a0CUKH5SwNYhwM4hONAo0eM8MmJxaa6V c9MDrdun0swb9voSaN10gp3ci43Wy+7lwr972DMynPHgIgYaX59L2Lru+3taLvKS6Z0iLwaN Dddx51xu410ztmkXNPwXzh4RwlRqgCYU9/oa9luOGPK9BZki7sh+ZMdk8z+ZRlyfVHX9F/Ok kwHbGU4vPX+IGIKEBGNaQ7glwTQefqt3cdhp9CV9HQAAAAAAAA== --------------ms070501000908000906000403-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 16:33:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09092 for ; Mon, 23 Jun 2003 16:33:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NKL4rb079798 for ; Mon, 23 Jun 2003 13:21: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 h5NKL4uh079797 for ietf-calendar-bks; Mon, 23 Jun 2003 13:21: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-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NKL2rb079785 for ; Mon, 23 Jun 2003 13:21:02 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <20030623165751.M57912@asitturnsout.org> To: "Chris Olds" Cc: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 23 Jun 2003 16:05:01 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/23/2003 04:20:53 PM, Serialize complete at 06/23/2003 04:20:53 PM Content-Type: multipart/alternative; boundary="=_alternative 006DF55485256D4E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006DF55485256D4E_= Content-Type: text/plain; charset="US-ASCII" Chris wrote on 06/23/2003 01:37:58 PM: > None of the CUAs I have expose the ability to do this, but I would expect that > any CUA capable of inviting someone to a subset of a set of meetings > (recurring or otherwise) would be able to keep track of this. Not sure what you mean by "expose the ability to do this". Do you mean invite only to a subset? Lotus Organizer and Lotus Notes do this and have done it for years (since R4.5 actually). Im pretty sure that Microsoft Outlook and Microsoft Exchange have that ability too since we tested with them. > As a result, > the organizer's CUA would be able to send the current state of the subset I > had been invited to (in reality, for privacy reasons, I would expect that it > would completely conceal from me that I was only invited to a subset). The concealing bits are orthogonal to the problem that arises from Dougs example. The simple fact is that if I send a REFRESH for a UID/RECURRENCE-ID then Id expect a REQUEST for that UID/RECURRENCE-ID. If the Organizer turns around and sends me a REQUEST for the entire set then all of a sudden Ive been 'promted' from a single instance (or subset of instances) to all instances. Is this the proper behaviour? I think not. > > As I noted in my last posting, if Doug sends me a REQUEST for the > > entire sequence then all of a sudden Im invited to all instances and > > not just 1. Thats NOT the proper action to take clearly is it?? > > > > Sending a REFRESH that describes the entire UID does not work for > > someone whose only coming to a particular instance or a subset of > > the entire set. Cant no matter how ya slice it. > > The (modest) additional complexity of making this work must be implemented in > the organizer's CUA, but it works just fine. Please show me how if RECURRENCE-ID changes as SEQUENCE changes that you can properly identify a missed reschedule REQUEST from a new invitation to another instance. As I noted before, if Im at UID:12345, RECURRENCE-ID:XXXX, SEQUENCE:1 and I send a REFRESH to the Organzier who is at SEQUENCE:10 then what should be sent back to me? If the RECURRENCE-ID changed every SEQUENCE then the Organzier _should_ send me a REQUEST for UID:12345, RECURRENCE-ID:YYYY, SEQUENCE:10. This however, per iTIP Section 3.2.2 will look like a new invitation to a new instance to me since I do not already know that UID/RECURRENCE-ID. As such I now have 2 instances on my calendar, not 1. How can I ever hope to resync my UID:12345, RECURRENCE-ID:XXXX, SEQUENCE:1 to the UID:12345, RECURRENCE-ID:YYYY, SEQUENCE:10 if a REQUEST the Organizer sends in response to the REFRESH will always be the "latest description and version of the event."? It sounds as if Dougs (and Chriss) answer is that the Organzier would send a REQUEST for the entire set but thats not viable unless you are adding a user to all instances... Clearly thats not was the invitee expects nor what the Organizer wants. > Pegging the RECURRANCE-ID to the > values of SEQ=0 is the more brittle mode - how can I add instances to a set > w/o issuing a new UID in that case? We have not dealt w/the ADD case, just the simple missed REQUEST case. Lets resolve the simple case before trying to digress to others shall we? > Forcing a new UID to be > allocated is contrary to the described workflows, and would reqire cancelling > the sequence and issuing a new REQUEST with the new UID in order to > work at all. Huh?? You must be talking about something someone else said. Ive never talked about reassigning UIDs. > Making RECURRENCE-ID depend on the UID and SEQUENCE is not a delta model. Sorry but if the RECURRENCE-ID changes ever SEQUENCE then in order for you to properly tell what the RECURRENCE-ID for SEQUENCE:1003 is, you MUST have all prior SEQUENCE values to properly change the RECURRENCE-ID to DTSTART @ SEQUENCE:1, DTSTART @ SEQUENCE:2, ..., DTSTART @ SEQUENCE:1002 before you can try to match the RECURRENCE-ID for SEQUENCE:1003. How is this not a delta model? Also, if the RECURRENCE-ID changes every SEQUENCE then iTIP Section 2.1.5 is wrong since it clearly uses UID & RECURRENCE-ID to find the instance before it uses SEQUENCE. > Since the current state of the REQUEST can always be obtained via REFRESH, any > attendee CUA that finds itself out of synch can recover with one > pair of messages. Ok, just just what would cause a CU think they are "out of sync"? A new REQUEST for a new UID/RECURRENCE-ID? Why should that matter; its just a new invitation (per iTIP Section 3.2.2 REQUEST). A REQUEST with a SEQUENCE that is more than 1 off? Why should that matter; its just an update to an existing entry and since by iTIP Section 2.1.5 the newer/higher SEQUENCE "obsoletes all other revisions of the component with lower values." Thus any missed SEQUENCE is inconsequential because that missed SEQUENCE is ALSO obsoleted. This is not true for the case where RECURRENCE-IDs change per SEQUENCE. PLUS rekeying RECURRENCE-IDs every SEQUENCE is contrary to the entire design philosphy of iTIP Section 2.1.5 since it makes RECURRECE-ID dependent on SEQUENCE and not the other way around. > Pinning RECURRENCE-ID values to SEQUENCE 0 requires attendee CUAs to do > complex tracking of the mapping of RECURRENCE-IDs to instances as the event > evolves, and what I think of when I hear the term 'delta model'. Why? The Organzier can gave the attendees the RECURRENCE-IDs in _any_ REQUEST, not just SEQUENCE:0. As such by simply applying the sequencing rules under Section 2.1.5 and the logic described in 3.2.2 its never an issue since the RECURRENCE-ID never changes. No matter where the instance goes in time and the number of reschedules it gets or the number of missed reschedules on any invitees part its trivial to simply look at the REQUEST, grab the UID/RECURRENCE-ID from it, find the instance if it already exists and then compare the SEQUENCE the attendee has with the one on the REQUEST. From there its easy to if the The term delta model was applied because the RECURRENCE-ID changes SEQUENCE thus in order to match the RECURRENCE-ID at SEQUENCE:10 you MUST be able to follow the changes with each SEQUENCE value before 10 by adopting the DTSTART at each SEQUENCE. This was much like the original early drafts we had in iCalendar / iTIP until we found we had resync issues for missed cases. > It is easy > to find series of updates that make RECURRENCE_IDs ambiguous, and easy to have > instances with no valid (according to this model) RECURRENCE-ID. No matter where you move the instance to, if the RECURRENCE-ID never changes then its trival to unambiguously find it at any point in the workflow process (at any SEQUENCE value). Ths same cannot be said for when RECURRENCE-ID changes per SEQUENCE since by iTIP only the latest version would ever be sent. Thus no amount of REFRESH/REQUEST thrashing will result in properly resyncing an instance or subset of instances since you cannot accurately indentify the instances in question. > It wouldn't surprise me if many other people held this view, but arent' > saying anything because of the tenor of many of Bruce's messages. You should be happy that Franks no longer active here. Im tame compared to him... My agressive tenor is due to several factors including that this was something the WG already covered ~4 years ago and we long ago agreed that 'delta was bad' because of insurmountable problems like resycing instances or subsets of repeat sets. Hey, are you suggesting I try decaf??! 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 006DF55485256D4E_= Content-Type: text/html; charset="US-ASCII"
Chris wrote on 06/23/2003 01:37:58 PM:
> None of the CUAs I have expose the ability to do this, but I would expect that
> any CUA capable of inviting someone to a subset of a set of meetings
> (recurring or otherwise) would be able to keep track of this.  

Not sure what you mean by "expose the ability to do this".  Do you mean invite only to a subset?  Lotus Organizer and Lotus Notes do this and have done it for years (since R4.5 actually).  Im pretty sure that Microsoft Outlook and Microsoft Exchange have that ability too since we tested with them.

>                                                               As a result,
> the organizer's CUA would be able to send the current state of the subset I
> had been invited to (in reality, for privacy reasons, I would expect that it
> would completely conceal from me that I was only invited to a subset).
The concealing bits are orthogonal to the problem that arises from Dougs example.  The simple fact is that if I send a REFRESH for a UID/RECURRENCE-ID then Id expect a REQUEST for that UID/RECURRENCE-ID.  If the Organizer turns around and sends me a REQUEST for the entire set then all of a sudden Ive been 'promted' from a single instance (or subset of instances) to all instances.  Is this the proper behaviour?  I think not.

> > As I noted in my last posting, if Doug sends me a REQUEST for the
> > entire sequence then all of a sudden Im invited to all instances and
> > not just 1. Thats NOT the proper action to take clearly is it??
> >
> > Sending a REFRESH that describes the entire UID does not work for
> > someone whose only coming to a particular instance or a subset of
> > the entire set. Cant no matter how ya slice it.
>
> The (modest) additional complexity of making this work must be implemented in
> the organizer's CUA, but it works just fine.  

Please show me how if RECURRENCE-ID changes as SEQUENCE changes that you can properly identify a missed reschedule REQUEST from a new invitation to another instance.

As I noted before, if Im at UID:12345, RECURRENCE-ID:XXXX, SEQUENCE:1 and I send a REFRESH to the Organzier who is at SEQUENCE:10 then what should be sent back to me?  If the RECURRENCE-ID changed every SEQUENCE then the Organzier _should_ send me a REQUEST for UID:12345, RECURRENCE-ID:YYYY, SEQUENCE:10.  This however, per iTIP Section 3.2.2 will look like a new invitation to a new instance to me since I do not already know that UID/RECURRENCE-ID.  As such I now have 2 instances on my calendar, not 1.  

How can I ever hope to resync my UID:12345, RECURRENCE-ID:XXXX, SEQUENCE:1 to the UID:12345, RECURRENCE-ID:YYYY, SEQUENCE:10 if a REQUEST the Organizer sends in response to the REFRESH will always be the "latest description and version of the event."?   It sounds as if Dougs (and Chriss) answer is that the Organzier would send a REQUEST for the entire set but thats not viable unless you are adding a user to all instances...  Clearly thats not was the invitee expects nor what the Organizer wants.

>                                              Pegging the RECURRANCE-ID to the
> values of SEQ=0 is the more brittle mode - how can I add instances to a set
> w/o issuing a new UID in that case?  

We have not dealt w/the ADD case, just the simple missed REQUEST case.  Lets resolve the simple case before trying to digress to others shall we?

>                                                       Forcing a new UID to be
> allocated is contrary to the described workflows, and would reqire cancelling
> the sequence and issuing a new REQUEST with the new UID in order to
> work at all.
Huh??  You must be talking about something someone else said.  Ive never talked about reassigning UIDs.

> Making RECURRENCE-ID depend on the UID and SEQUENCE is not a delta model.

Sorry but if the RECURRENCE-ID changes ever SEQUENCE then in order for you to properly tell what the RECURRENCE-ID for SEQUENCE:1003 is, you MUST have all prior SEQUENCE values to properly change the RECURRENCE-ID to DTSTART @ SEQUENCE:1, DTSTART @ SEQUENCE:2, ..., DTSTART @ SEQUENCE:1002 before you can try to match the RECURRENCE-ID for SEQUENCE:1003.  How is this not a delta model?

Also, if the RECURRENCE-ID changes every SEQUENCE then iTIP Section 2.1.5 is wrong since it clearly uses UID & RECURRENCE-ID to find the instance before it uses SEQUENCE.

> Since the current state of the REQUEST can always be obtained via REFRESH, any
> attendee CUA that finds itself out of synch can recover with one
> pair of messages.
Ok, just just what would cause a CU think they are "out of sync"?  

A new REQUEST for a new UID/RECURRENCE-ID?  Why should that matter; its just a new invitation (per iTIP Section 3.2.2 REQUEST).  

A REQUEST with a SEQUENCE that is more than 1 off?  Why should that matter; its just an update to an existing entry and since by iTIP Section 2.1.5 the newer/higher SEQUENCE "obsoletes all other revisions of the component with lower values."  Thus any missed SEQUENCE is inconsequential because that missed SEQUENCE is ALSO obsoleted.

This is not true for the case where RECURRENCE-IDs change per SEQUENCE.  PLUS rekeying RECURRENCE-IDs every SEQUENCE is contrary to the entire design philosphy of iTIP Section 2.1.5 since it makes RECURRECE-ID dependent on SEQUENCE and not the other way around.

> Pinning RECURRENCE-ID values to SEQUENCE 0 requires attendee CUAs to do
> complex tracking of the mapping of RECURRENCE-IDs to instances as the event
> evolves, and what I think of when I hear the term 'delta model'.

Why?  

The Organzier can gave the attendees the RECURRENCE-IDs in _any_ REQUEST, not just SEQUENCE:0.  As such by simply applying the sequencing rules under Section 2.1.5 and the logic described in 3.2.2 its never an issue since the RECURRENCE-ID never changes.  No matter where the instance goes in time and the number of reschedules it gets or the number of missed reschedules on any invitees part its trivial to simply look at the REQUEST, grab the UID/RECURRENCE-ID from it, find the instance if it already exists and then compare the SEQUENCE the attendee has with the one on the REQUEST.  From there its easy to if the

The term delta model was applied because the RECURRENCE-ID changes SEQUENCE thus in order to match the RECURRENCE-ID at SEQUENCE:10 you MUST be able to follow the changes with each SEQUENCE value before 10 by adopting the DTSTART at each SEQUENCE.  This was much like the original early drafts we had in iCalendar / iTIP until we found we had resync issues for missed cases.

>                                                                    It is easy
> to find series of updates that make RECURRENCE_IDs ambiguous, and easy to have
> instances with no valid (according to this model) RECURRENCE-ID.
No matter where you move the instance to, if the RECURRENCE-ID never changes then its trival to unambiguously find it at any point in the workflow process (at any SEQUENCE value).  Ths same cannot be said for when RECURRENCE-ID changes per SEQUENCE since by iTIP only the latest version would ever be sent.  Thus no amount of REFRESH/REQUEST thrashing will result in properly resyncing an instance or subset of instances since you cannot accurately indentify the instances in question.

>         It wouldn't surprise me if many other people held this view, but arent'
> saying anything because of the tenor of many of Bruce's messages.
You should be happy that Franks no longer active here.  Im tame compared to him...

My agressive tenor is due to several factors including that this was something the WG already covered ~4 years ago and we long ago agreed that 'delta was bad' because of insurmountable problems like resycing instances or subsets of repeat sets.  Hey, are you suggesting I try decaf??!

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 006DF55485256D4E_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 16:41: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 QAA09333 for ; Mon, 23 Jun 2003 16:41: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 h5NKVRrb080323 for ; Mon, 23 Jun 2003 13:31: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 h5NKVRtw080322 for ietf-calendar-bks; Mon, 23 Jun 2003 13:31:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NKVQrb080316 for ; Mon, 23 Jun 2003 13:31:26 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) In-Reply-To: <3EF75C0F.6090903@Royer.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_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Mon, 23 Jun 2003 16:22:16 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/23/2003 04:31:15 PM, Serialize complete at 06/23/2003 04:31:15 PM Content-Type: multipart/alternative; boundary="=_alternative 006F97B685256D4E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F97B685256D4E_= Content-Type: text/plain; charset="US-ASCII" Since you are not sending the entire Rule since that person was only invited to a single instance, you must reference it with the recurrence-id . That recurrence-id must the fixed recurrence-id of when rule was created or this invitee will have no way to map it to what is currently on his/her calendar. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/23/2003 03:59 PM Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: Fw: Correct handling of Recurrence-id Bruce_Kahn@notesdev.ibm.com wrote: > > Doug persisted on 06/23/2003 12:23:08 PM: > > It is not needed, do a full (not recurrence-id) REFRESH and you are > > back in sync. > > My example was for someone who is NOT invited to the entire set. > Examples are: guest speakers for monthly team meetings, one-time > presenters for regular meetings (ie: design review boards), Proxys / > Delegates, etc. > .... That has NOTHING to do with the problem. If ATTENDEE X asks for a REFRESH, send him what *he* is expected to see. We discussed this prior to iTIP being released. All ATTENDEEs do *not* have to have the same copy of a UID. Just send them what *they* need to see as the ORGANIZER would need to understand that anyway. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.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 006F97B685256D4E_= Content-Type: text/html; charset="US-ASCII"
Since you are not sending the entire Rule since that person was only invited to a single instance, you must reference it with the recurrence-id.  That recurrence-id must the fixed recurrence-id of when rule was created or this invitee will have no way to map it to what is currently on his/her calendar.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

06/23/2003 03:59 PM
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: Fw: Correct handling of Recurrence-id







Bruce_Kahn@notesdev.ibm.com wrote:
>
> Doug persisted on 06/23/2003 12:23:08 PM:
>  > It is not needed, do a full (not recurrence-id) REFRESH and you are
>  > back in sync.
>
> My example was for someone who is NOT invited to the entire set.
>  Examples are: guest speakers for monthly team meetings, one-time
> presenters for regular meetings (ie: design review boards), Proxys /
> Delegates, etc.  
> ....

That has NOTHING to do with the problem. If ATTENDEE X asks for a REFRESH,
send him what *he* is expected to see. We discussed this prior to iTIP
being released. All ATTENDEEs do *not* have to have the same copy of
a UID. Just send them what *they* need to see as the ORGANIZER would
need to understand that anyway.

--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.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 006F97B685256D4E_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 17:01: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 RAA10119 for ; Mon, 23 Jun 2003 17:01: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 h5NKq0rb082462 for ; Mon, 23 Jun 2003 13: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 h5NKq0Zr082461 for ietf-calendar-bks; Mon, 23 Jun 2003 13: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 h5NKpwrb082451 for ; Mon, 23 Jun 2003 13:51:58 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5NKplOR020258 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 23 Jun 2003 13:51:56 -0700 Message-ID: <3EF7685A.9090604@Royer.com> Date: Mon, 23 Jun 2003 14:51:38 -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="------------ms050302090709050108080703" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050302090709050108080703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > > The concealing bits are orthogonal to the problem that arises from Dougs > example. The simple fact is that if I send a REFRESH for a > UID/RECURRENCE-ID then Id expect a REQUEST for that UID/RECURRENCE-ID. > If the Organizer turns around and sends me a REQUEST for the entire set > then all of a sudden Ive been 'promted' from a single instance (or > subset of instances) to all instances. Is this the proper behaviour? I > think not. At what point did I or anyone say that if you ask for just one recurrence-id that the organizer would send you everything? I can find NO instance of that statement for which you are replying. If you ask for RECURRENCE-ID:x and what you get back is a valid object with a SEQUENCE:, then you will AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE, you MUST do a REFRESH for the ENTIRE object (REFRESH with out RECURRENCE-ID). Else you would not have a CLUE what the object is supposed to look like. If the SEQUENCE number is the same as you have, then RECURRENCE-ID MUST MATCH as each time a recurrence rule changes, you MUST update the SEQUENCE number, so if they are the same then one thing you know is that NONE of the recurrence rules changed and the RECURRENCE-ID is valid. If the SEQUENCE number is LARGER than you have, one of the reasons MAY be because someone changed a recurrence rule and per iCAL/iTIP the sequence number gets bumped. > Please show me how if RECURRENCE-ID changes as SEQUENCE changes that you > can properly identify a missed reschedule REQUEST from a new invitation > to another instance. Its NOT relevant, if WHATEVER you get back has a larger SEQUENCE number than you have, you are going to have to do a FULL REFRESH anyway. Then the ORGANIZER will send you *your* latest object. And if the SEQUENCE number IS the same, then by definition in iCAL/iTIP, the recurrence rules MUST NOT have changed. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050302090709050108080703 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjMyMDUxMzhaMCMGCSqGSIb3DQEJBDEWBBRz tdSV+prqeae5OzS9bXwoGqWzJzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAtKbScY0vDl0z 6yxKJfqNPyIJyzbc61HyRjCD4pzuclf6Uonlj8QvQHZaxnPFMVjHStQnRNwlPEVwor+aL7Af ctbxL9foQjUQ19WZIjRvqETVrcnTrD9vCNSW11dZL1F5uRmXKdfkr3yOXVoYoblYzZl+PNps P8CfcOpmNVlWcCmsevSMz1nKutZ+EF1kee3vg99LN09AdSuFgXTTyimPsIajeHTiH+JL4CIU 5UP6J6XOWNVizLIp3vNxrwrscCi6tsKLy6ARX+VjN3x6r3aopLsrFth0CeaDaN+igNZ21fZ9 H1kHtjzZnw+qgsEV3l9vqv643K0cfjNNT3B+pVuZUgAAAAAAAA== --------------ms050302090709050108080703-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 17:08: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 RAA10474 for ; Mon, 23 Jun 2003 17: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 h5NKwYrb082708 for ; Mon, 23 Jun 2003 13:58: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 h5NKwXcO082707 for ietf-calendar-bks; Mon, 23 Jun 2003 13:58: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 h5NKwWrb082702 for ; Mon, 23 Jun 2003 13:58: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 h5NKwLOR020299 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 23 Jun 2003 13:58:30 -0700 Message-ID: <3EF769E8.8030104@Royer.com> Date: Mon, 23 Jun 2003 14:58:16 -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="------------ms060902050706050402070008" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060902050706050402070008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Since you are not sending the entire Rule since that person was only > invited to a single instance, you must reference it with the > recurrence-id. That recurrence-id must the fixed recurrence-id of when > rule was created or this invitee will have no way to map it to what is > currently on his/her calendar. No, per iCAL/iTIP the SEQUENCE number in what the ATTENDEE gets must match, if what you get is a SEQUENCE number larger than what you have then you MUST do a REFRESH as one of the reasons the ORGANIZER MUST bump the SEQUENCE number is a change in any recurrence rule. If the SEQUENCE number is the same then by definition, none of the recurrence rules could have changed. It has nothing what so ever to do with how many people are invited to which instances. There is NO requirement that the ORGANIZER send the same object to each ATTENDEE, so it has NO impact on RECURRENCE-ID other than if the SEQUENCE number is larger or not. > That recurrence-id must the fixed recurrence-id of when > rule was created or this invitee will have no way to map it to what is > currently on his/her calendar. iCAL specificly says that if a recurrence rule changes you MUST bump the SEQUENCE number, so that is simply not true. ... 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. ... It does NOT say that it is fixed at the SEQUENCE zero value. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060902050706050402070008 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjMyMDU4MTZaMCMGCSqGSIb3DQEJBDEWBBSX EwKMzTuWTtdA5S9IV4YDaMCgsDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAen+soxL1YsUY uWw+RtxJR0z7ywe+NqEUWzFSqYkimmW4lOsAikRtSawUI0YdYVbfyvaWm+Uczr6IajyUUxO+ 7ELXxXW0syMGtRnpDCpEoMM6reQFM+pxiC4O12BzkZLWA9zxbFtQNRoZoplyKmXCWkAZAWZt 5PZTfNYoktB5COe/bQ/cb1z0A4mjEZIizcalm3eRJRr4/Y6Tb+NWuVdy09QT4U8BIqTue0Ta 43BW0TrtN9Y7t7H3V0D3gX55pmBzDRhQOWBRFLxgOQk016OA0tjBgY6gwU4zBaxUpBPgAF+y kO5L7m25asSDRAiqI/nPr1i46T2midBwX/TTAYbGvwAAAAAAAA== --------------ms060902050706050402070008-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 18:23: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 SAA13463 for ; Mon, 23 Jun 2003 18:23:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NMCFrb085780 for ; Mon, 23 Jun 2003 15:12: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 h5NMCFR8085779 for ietf-calendar-bks; Mon, 23 Jun 2003 15:12:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NMCErb085774 for ; Mon, 23 Jun 2003 15:12:14 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3EF7685A.9090604@Royer.com> MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id X-Mailer: Lotus Notes Build V70_05282003NP May 28, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 23 Jun 2003 17:45:47 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/23/2003 06:11:59 PM, Serialize complete at 06/23/2003 06:11:59 PM Content-Type: multipart/alternative; boundary="=_alternative 00772F0D85256D4E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00772F0D85256D4E_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 06/23/2003 04:51:38 PM: > At what point did I or anyone say that if you ask for just one > recurrence-id that the organizer would send you everything? > I can find NO instance of that statement for which you are replying. That exact word for word statement was not made by anyone. You have been saying (and you did not disagree w/Arnaud) that in response to a REFRESH a REQUEST with just UID would be sent. Ive been asking you to please show me how a REQUEST in response to my REFRESH for UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5 would work if the instance is now at SEQUENCE:10 in the Organziers calendar. Since the RECURRENCE-ID changes with ever SEQUENCE change (you've said that continuously this entire thread) then exactly what will be in the new REQUEST that gets sent? However Id like to be clear on this before I go further: Do you think that the REQUEST that gets sent in response to the REFRESH (UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5) should have a RECURRENCE-ID value in it or not? > If you ask for RECURRENCE-ID:x and what you get back is a > valid object with a SEQUENCE:, then you will > AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE, > you MUST do a REFRESH for the ENTIRE object (REFRESH with out RECURRENCE-ID). Says who?!? There is NOTHING in any of the RFCs to indicate this! iTIP is quite clear on how to distinguish a new invite from a reschedule: 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 you need to treat "UID" above as "UID/RECURRENCE-ID" just as described in Section 2.1.5 of iTIP. As such the above clearly says that if the UID/RECURRENCE-ID does not exist in my calendar then the REQUEST is a new invitation. Otherwise its an update. There is didly about "If the SEQUENCE value is not 'off by one' then all bets are off and the Attendee MUST issue a REFRESH to get back in sync." (NOT EVEN REMOTELY paraphrased!). As bullet 2 of Section 2.1.5 plainly says: 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. Since SEQUENCE:1000 obsoletes ALL SEQUENCE values below it what gives you the impression that if "you get back is a valid object with a SEQUENCE:, then you will AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE, you MUST do a REFRESH for the ENTIRE object"?? > Else you would not have a CLUE what the object is supposed to look like. Sure you do. The SEQUENCE:1000 REQUEST is fully intact and obsoletes ALL prior SEQUENCE REQUESTSs so I can use it as it appears in the stream. Why coudln't I?? Is the object faulty? Is it incomplete? Is it inaccurate? No. The bullet clearly says "obsoletes all other revisions of the component with lower values." As such I dont see why you think otherwise... > If the SEQUENCE number is the same as you have, then RECURRENCE-ID STOP! You are not reading Section 2.1.5 correctly! SEQUENCE is NOT a precursor to RECURRENCE-ID. Secondary keys do not have precedence over primary keys! > > Please show me how if RECURRENCE-ID changes as SEQUENCE changes that you > > can properly identify a missed reschedule REQUEST from a new invitation > > to another instance. > > Its NOT relevant, if WHATEVER you get back has a larger SEQUENCE number > than you have, you are going to have to do a FULL REFRESH anyway. What do you mean by "FULL REFRESH"?? Isn't that a REQUEST with just the UID and NO RECURRENCE-ID in it? Nah, cant be since you just said you've never said that. So please tell me what iTIP properties are in a "FULL REFRESH" when I send a REFRESH on UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5? Will it have a RECURRENCE-ID in it or not? > Then > the ORGANIZER will send you *your* latest object. Again, if Im invited to single instance of the set or a subset of the entire set then WHAT EXACTLY is in that new REQUEST that gets sent?? If it has a RECURRENCE-ID in it then how do I match it to my existing RECURRENCE-ID:XXXXX, SEQUENCE:5 if the actual instance is now at SEQUENCE:10 since by your logic the RECURRENCE-ID would be different?? How??? The only way to get rid of that UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5 REQUEST is to provide some means to remove it and Ive seen nothing so far in any of your responses describing exactly how. The Organizer is going to send a new REQUEST so far Ive seen NO exact example of what gets sent. It sounds to me as if Doug and others think that SEQUENCE is across all instances of the repeat set. Please say its not true... 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 00772F0D85256D4E_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 06/23/2003 04:51:38 PM:
> At what point did I or anyone say that if you ask for just one
> recurrence-id that the organizer would send you everything?
> I can find NO instance of that statement for which you are replying.
That exact word for word statement was not made by anyone.  You have been saying (and you did not disagree w/Arnaud) that in response to a REFRESH a REQUEST with just UID would be sent.

Ive been asking you to please show me how a REQUEST in response to my REFRESH for UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5 would work if the instance is now at SEQUENCE:10 in the Organziers calendar.  Since the RECURRENCE-ID changes with ever SEQUENCE change (you've said that continuously this entire thread) then exactly what will be in the new REQUEST that gets sent?  

However Id like to be clear on this before I go further: Do you think that the REQUEST that gets sent in response to the REFRESH (UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5) should have a RECURRENCE-ID value in it or not?

> If you ask for RECURRENCE-ID:x and what you get back is a
> valid object with a SEQUENCE:<larger-than-you-have>, then you will
> AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE,
> you MUST do a REFRESH for the ENTIRE object (REFRESH with out RECURRENCE-ID).

Says who?!?  There is NOTHING in any of the RFCs to indicate this!  iTIP is quite clear on how to distinguish a new invite from a reschedule:

   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 you need to treat "UID" above as "UID/RECURRENCE-ID" just as described in Section 2.1.5 of iTIP.  As such the above clearly says that if the UID/RECURRENCE-ID does not exist in my calendar then the REQUEST is a new invitation.  Otherwise its an update.  There is didly about "If the SEQUENCE value is not 'off by one' then all bets are off and the Attendee MUST issue a REFRESH to get back in sync." (NOT EVEN REMOTELY paraphrased!).  

As bullet 2 of Section 2.1.5 plainly says:

   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.

Since SEQUENCE:1000 obsoletes ALL SEQUENCE values below it what gives you the impression that if "you get back is a valid object with a SEQUENCE:<larger-than-you-have>, then you will AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE, you MUST do a REFRESH for the ENTIRE object"??

> Else you would not have a CLUE what the object is supposed to look like.
Sure you do.  The SEQUENCE:1000 REQUEST is fully intact and obsoletes ALL prior SEQUENCE REQUESTSs so I can use it as it appears in the stream.  Why coudln't I??  Is the object faulty?  Is it incomplete?  Is it inaccurate?  No.  The bullet clearly says "obsoletes all other revisions of the component with lower values."  As such I dont see why you think otherwise...

> If the SEQUENCE number is the same as you have, then RECURRENCE-ID

STOP!  You are not reading Section 2.1.5 correctly!  SEQUENCE is NOT a precursor to RECURRENCE-ID.  Secondary keys do not have precedence over primary keys!  

> > Please show me how if RECURRENCE-ID changes as SEQUENCE changes that you
> > can properly identify a missed reschedule REQUEST from a new invitation
> > to another instance.
>
> Its NOT relevant, if WHATEVER you get back has a larger SEQUENCE number
> than you have, you are going to have to do a FULL REFRESH anyway.

What do you mean by "FULL REFRESH"??  Isn't that a REQUEST with just the UID and NO RECURRENCE-ID in it?  Nah, cant be since you just said you've never said that.  So please tell me what iTIP properties are in a "FULL REFRESH" when I send a REFRESH on UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5?  Will it have a RECURRENCE-ID in it or not?

> Then
> the ORGANIZER will send you *your* latest object.
Again, if Im invited to single instance of the set or a subset of the entire set then WHAT EXACTLY is in that new REQUEST that gets sent??  If it has a RECURRENCE-ID in it then how do I match it to my existing RECURRENCE-ID:XXXXX, SEQUENCE:5 if the actual instance is now at SEQUENCE:10 since by your logic the RECURRENCE-ID would be different??  How???

The only way to get rid of that UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5 REQUEST is to provide some means to remove it and Ive seen nothing so far in any of your responses describing exactly how.  The Organizer is going to send a new REQUEST so far Ive seen NO exact example of what gets sent.  

It sounds to me as if Doug and others think that SEQUENCE is across all instances of the repeat set.  Please say its not true...  

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 00772F0D85256D4E_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 23 19:02:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14527 for ; Mon, 23 Jun 2003 19:02:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NMr3rb087293 for ; Mon, 23 Jun 2003 15: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 h5NMr3BS087292 for ietf-calendar-bks; Mon, 23 Jun 2003 15:53:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NMr2rb087287 for ; Mon, 23 Jun 2003 15:53:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5NMr0OR021358 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 23 Jun 2003 15:53:03 -0700 Message-ID: <3EF784C3.8060003@Royer.com> Date: Mon, 23 Jun 2003 16:52: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: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000100010300090005060005" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000100010300090005060005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 06/23/2003 04:51:38 PM: > > At what point did I or anyone say that if you ask for just one > > recurrence-id that the organizer would send you everything? > > I can find NO instance of that statement for which you are replying. > > That exact word for word statement was not made by anyone. You have > been saying (and you did not disagree w/Arnaud) that in response to a > REFRESH a REQUEST with just UID would be sent. > Ive been asking you to please show me how a REQUEST in response to my > REFRESH for UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5 would work if the > instance is now at SEQUENCE:10 in the Organziers calendar. Since the > RECURRENCE-ID changes with ever SEQUENCE change (you've said that > continuously this entire thread) then exactly what will be in the new > REQUEST that gets sent? I have answerd that three times. Unless there is some new technical point. I consder this a user error and this point closed as it works as documented. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000100010300090005060005 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjMyMjUyNTFaMCMGCSqGSIb3DQEJBDEWBBQI q5XQ4gC4fT0zTqvLeW2XDw2bwzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAbVcDCxg0C4pC HD/A1sOB07nexyPBhK5AQDMq+k+Y9W8T/04n7lzveDHplCL4BrLhA7fFdAMIymT9oUloVUd8 hhbH0uEpS/cg/mXtVa1X5j2jNQyzlr4tn1N83On6Kgk478TKcCRXpqGDoYXjOYG2F/ZDvtNz UD+bJncBD3QYRjisCaBpVpN9+4LTu+0UvckC4s6HnDZ11cUtJz0/BsNM2G6Qf5sgxcnkSebp DOyQt6RLK17P9SUuCrdb4v1T/B4u1OzOvdWR5Z16hrKjeMUC/ggJQyqd/WbNupIAeHfiT97o l4xWBPIb+T+y9dpMmJmsnXHc6kBUDf4McGdr5BvE2AAAAAAAAA== --------------ms000100010300090005060005-- From owner-ietf-calendar@mail.imc.org Tue Jun 24 13:18: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 NAA25200 for ; Tue, 24 Jun 2003 13:18:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OH4Irb078373 for ; Tue, 24 Jun 2003 10:04: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 h5OH4Isj078372 for ietf-calendar-bks; Tue, 24 Jun 2003 10:04:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OH4Grb078365 for ; Tue, 24 Jun 2003 10:04:17 -0700 (PDT) (envelope-from Robert_Ransdell@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: Fw: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M2_06022003 June 02, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Tue, 24 Jun 2003 12:57:27 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/24/2003 01:04:17 PM, Serialize complete at 06/24/2003 01:04:17 PM Content-Type: multipart/alternative; boundary="=_alternative 005CD76D85256D4F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CD76D85256D4F_= Content-Type: text/plain; charset="US-ASCII" opps auto-reply did not go to correct address _____________________ Note: new email address tom_ransdell@notesdev.ibm.com ----- Forwarded by Robert Ransdell/Westford/IBM on 06/24/2003 12:53 PM ----- Robert Ransdell/Westford/IBM 06/24/2003 10:51 AM To "Chris Olds" @LOTUS cc Subject Re: Fw: Correct handling of Recurrence-id Chris Olds wrote >> None of the CUAs I have expose the ability to do this (send invite to an instance).... The two largest commercial calendar systems in the world, Lotus Notes and Microsoft Outlook, both have the ability to only invited to an instance. Both use fixed RECURRENCE-ID's as described in the iCalendar specification when sending to the internet. Chris Olds wrote >>It wouldn't surprise me if many other people held this view, but arent' >>saying anything because of the tenor of many of Bruce's messages. You got to be kidding. Doug is not talking about redefining some minor properties of iCalendar. He is talking about redefining the basic keys upon which iCalendar is based. He is talking about killing iCalendar as a viable internet standard. Bruce has patiently explained with examples why Doug's definition of RECURRENCE-ID's can not work and why a REQUEST in response to a Refresh request when the invitee is only invited to a subset of the repeat meetings can not work unless the RECURRENCE-ID's are fixed. Doug on the other hand has never supplied any complete examples of his model. He just keeps saying the mantra REFRESH. Now I ask you which one who is annoying? _____________________ Note: new email address tom_ransdell@notesdev.ibm.com "Chris Olds" Sent by: owner-ietf-calendar@mail.imc.org 06/23/2003 01:37 PM To ietf-calendar@imc.org cc Subject Re: Fw: Correct handling of Recurrence-id On Mon, 23 Jun 2003 11:15:45 -0400, Bruce_Kahn wrote > Arnaud wrote on 06/20/2003 08:34:28 PM: > > Maybe there is some misunderstanding here. My guess is that Doug means > > "Do a REFRESH with just the UID" when you seem to think "REFRESH with > > UID/RECURRENCE-ID". > > My examples have been how do I resync a particular UID/RECURRENCE-ID > all along. Thats what "If Im only invited to an instance (or subset > of instances) then would you send me the entire set now in response > to my REFRESH?" means. None of the CUAs I have expose the ability to do this, but I would expect that any CUA capable of inviting someone to a subset of a set of meetings (recurring or otherwise) would be able to keep track of this. As a result, the organizer's CUA would be able to send the current state of the subset I had been invited to (in reality, for privacy reasons, I would expect that it would completely conceal from me that I was only invited to a subset). > As I noted in my last posting, if Doug sends me a REQUEST for the > entire sequence then all of a sudden Im invited to all instances and > not just 1. Thats NOT the proper action to take clearly is it?? > > Sending a REFRESH that describes the entire UID does not work for > someone whose only coming to a particular instance or a subset of > the entire set. Cant no matter how ya slice it. The (modest) additional complexity of making this work must be implemented in the organizer's CUA, but it works just fine. Pegging the RECURRANCE-ID to the values of SEQ=0 is the more brittle mode - how can I add instances to a set w/o issuing a new UID in that case? This is clearly an anticipated action, but it breaks SEQ=0 semantics by adding an instance that cannot be addressed by RECURRENCE-ID if those values are fixed at SEQ=0. Forcing a new UID to be allocated is contrary to the described workflows, and would reqire cancelling the sequence and issuing a new REQUEST with the new UID in order to work at all. Making RECURRENCE-ID depend on the UID and SEQUENCE is not a delta model. Since the current state of the REQUEST can always be obtained via REFRESH, any attendee CUA that finds itself out of synch can recover with one pair of messages. Pinning RECURRENCE-ID values to SEQUENCE 0 requires attendee CUAs to do complex tracking of the mapping of RECURRENCE-IDs to instances as the event evolves, and what I think of when I hear the term 'delta model'. It is easy to find series of updates that make RECURRENCE_IDs ambiguous, and easy to have instances with no valid (according to this model) RECURRENCE-ID. While this view appears to agree with Doug, it is based on my own reading of iTIP. It wouldn't surprise me if many other people held this view, but arent' saying anything because of the tenor of many of Bruce's messages. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) --=_alternative 005CD76D85256D4F_= Content-Type: text/html; charset="US-ASCII"
opps  auto-reply did not go to correct address
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com
----- Forwarded by Robert Ransdell/Westford/IBM on 06/24/2003 12:53 PM -----
Robert Ransdell/Westford/IBM

06/24/2003 10:51 AM

To
"Chris Olds" <cco@asitturnsout.org>@LOTUS
cc
Subject
Re: Fw: Correct handling of Recurrence-idLink




Chris Olds wrote
>> None of the CUAs I have expose the ability to do this (send invite to an instance)....

The two largest commercial calendar systems in the world, Lotus Notes and Microsoft Outlook,  both have the ability to  only invited to an instance.  Both use fixed RECURRENCE-ID's as described in the iCalendar specification when sending to the internet.

Chris Olds wrote
>>It wouldn't surprise me if many other people held this view, but arent'
>>saying anything because of the tenor of many of Bruce's messages.

You got to be kidding.  Doug is not talking about redefining some minor properties of iCalendar.  He is talking about redefining the basic keys upon which iCalendar is based.  He is talking about killing iCalendar as a viable internet standard.  Bruce has patiently explained with examples why Doug's definition of RECURRENCE-ID's can not work and why a REQUEST in response to a Refresh request when the invitee is only invited to a subset of the repeat meetings can not work unless the RECURRENCE-ID's are fixed.  Doug on the other hand has never supplied any complete examples of his model.  He just keeps saying the mantra REFRESH.   Now I ask you which one who is annoying?


_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


"Chris Olds" <cco@asitturnsout.org>
Sent by: owner-ietf-calendar@mail.imc.org

06/23/2003 01:37 PM

To
ietf-calendar@imc.org
cc
Subject
Re: Fw: Correct handling of Recurrence-id






On Mon, 23 Jun 2003 11:15:45 -0400, Bruce_Kahn wrote
> Arnaud wrote on 06/20/2003 08:34:28 PM:
> > Maybe there is some misunderstanding here.  My guess is that Doug means
> > "Do a REFRESH with just the UID" when you seem to think "REFRESH with
> > UID/RECURRENCE-ID".
>
> My examples have been how do I resync a particular UID/RECURRENCE-ID
> all along.  Thats what "If Im only invited to an instance (or subset
> of instances) then would you send me the entire set now in response
> to my REFRESH?" means.

None of the CUAs I have expose the ability to do this, but I would expect that
any CUA capable of inviting someone to a subset of a set of meetings
(recurring or otherwise) would be able to keep track of this.  As a result,
the organizer's CUA would be able to send the current state of the subset I
had been invited to (in reality, for privacy reasons, I would expect that it
would completely conceal from me that I was only invited to a subset).

> As I noted in my last posting, if Doug sends me a REQUEST for the
> entire sequence then all of a sudden Im invited to all instances and
> not just 1. Thats NOT the proper action to take clearly is it??
>
> Sending a REFRESH that describes the entire UID does not work for
> someone whose only coming to a particular instance or a subset of
> the entire set. Cant no matter how ya slice it.

The (modest) additional complexity of making this work must be implemented in
the organizer's CUA, but it works just fine.  Pegging the RECURRANCE-ID to the
values of SEQ=0 is the more brittle mode - how can I add instances to a set
w/o issuing a new UID in that case?  This is clearly an anticipated action,
but it breaks SEQ=0 semantics by adding an instance that cannot be addressed
by RECURRENCE-ID if those values are fixed at SEQ=0.  Forcing a new UID to be
allocated is contrary to the described workflows, and would reqire cancelling
the sequence and issuing a new REQUEST with the new UID in order to work at all.

Making RECURRENCE-ID depend on the UID and SEQUENCE is not a delta model.
Since the current state of the REQUEST can always be obtained via REFRESH, any
attendee CUA that finds itself out of synch can recover with one pair of messages.

Pinning RECURRENCE-ID values to SEQUENCE 0 requires attendee CUAs to do
complex tracking of the mapping of RECURRENCE-IDs to instances as the event
evolves, and what I think of when I hear the term 'delta model'.  It is easy
to find series of updates that make RECURRENCE_IDs ambiguous, and easy to have
instances with no valid (according to this model) RECURRENCE-ID.

While this view appears to agree with Doug, it is based on my own reading of
iTIP.  It wouldn't surprise me if many other people held this view, but arent'
saying anything because of the tenor of many of Bruce's messages.

   /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)
--=_alternative 005CD76D85256D4F_=-- From owner-ietf-calendar@mail.imc.org Tue Jun 24 15:37: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 PAA06674 for ; Tue, 24 Jun 2003 15: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 h5OJQbrb087012 for ; Tue, 24 Jun 2003 12:26:37 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OJQbuA087011 for ietf-calendar-bks; Tue, 24 Jun 2003 12:26:37 -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 h5OJQZrb087004 for ; Tue, 24 Jun 2003 12:26:36 -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 h5OJQXOR031916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 24 Jun 2003 12:26:36 -0700 Message-ID: <3EF8A5E0.6000508@Royer.com> Date: Tue, 24 Jun 2003 13:26: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: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080500010503070600070605" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080500010503070600070605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > You got to be kidding. Doug is not talking about redefining some minor > properties of iCalendar. He is talking about redefining the basic keys > upon which iCalendar is based. I have been polite. I am talking about you actually reading the specs and stopping the self proclaimed declarations and whining by you and Bruce that it is not the way you want things to be done. iCal is clear, the RECURRENCE-ID is tied to the UID/SEQUENCE set. That *IS* what the text if iCal says and you simply refuse to debate the facts. Your or Bruce have never shown it does not work. You simply have stated that you do not want to do it that way. There is NO such need to do it that way. Do it the documented way and it works. And it works with other vendors. Declaring that YOU must throw away a UID because some recurrence rule changes is a bug in your code not in ours. > He is talking about killing iCalendar as > a viable internet standard. Simply bogus. A HUGE percentage of my income is based on several IETF standards including CALSCH and proposed standards. Your or Bruce's proclamations I see as vendor specific requirements not interested in CALSCH, but in making the world unable to update recurrence rules and I suspect because your product can not do that without your implementation issuing a new UID. Guess what, I can not find any major vendors product that has that limitation. > Bruce has patiently explained with examples > why Doug's definition of RECURRENCE-ID's can not work and why a REQUEST > in response to a Refresh request when the invitee is only invited to a > subset of the repeat meetings can not work unless the RECURRENCE-ID's > are fixed. No he has not. He has simply shown that his examples of doing it that way does not work. And as far as I can tell it is simply a way to not have to update the sequence number. He has NOT shown that iCal or iTIP is broken. Just that the way he (and you?) want to do it does not work. You and he repeatedly refused to reply to factual comments about the text within iCal or iTIP. You simply declare that because your product does not interact with another product when doing it as documented (perhaps because your product can not?), that it is busted. No it is not, my code works and I suspect other have code that works. Simply update you code or use the work around I provided that I also tested and it works. > Doug on the other hand has never supplied any complete > examples of his model. He just keeps saying the mantra REFRESH. Now I > ask you which one who is annoying? I do not have to supply any examples, simply read the text in iCAL and iTIP as THAT is the way of doing it. Bruce admits his examples do not work past SEQUENCE:0. And you and Bruce keep ignoring the text within iCal and iTIP. Yes I believe you, your code is not compliant to iCal if in fact you do it that way. Simply because you or Bruce declare things as true does not make them true. Recurrence-ID works as documented. And I will say it again - DO A REFRESH and if you get partial update with a new sequence number == DO A REFRESH. IT works - it *IS* tested. Debate that fact. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080500010503070600070605 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjQxOTI2MjRaMCMGCSqGSIb3DQEJBDEWBBQ9 2TH8WSRXKOanJ8K/rMNVl63viTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAeNJ4oSx3JLuB s29wFNyYkLubZeCU2y+bCfm6X/zBRvvoV/kutGnWjwVL0d9mPf6J6Y00I+U6vo4GUyzc3cmI dQWDm8m6icMO0Qw/K2Vbx0v63PocrF6xc8coNXBo9I5yw0nW+JFN5Fn9vd2P1naR5/REOxsB EcxdEyK2M0velfUPp8Pm11y44eEC3qqkNhtOWi1kizO+ZLuWTb9BPmGGwPWjalTvc8hfgKg/ ihkV6eBCOPMxpGvodmnaGzvceGiunQxsb5nox2rrBt0fm8z2hWoRWW1D8C3J1IcWh0Dt1+Q7 6kXgV/wPSS2c8t0NvR6mGgFx4oevJ/61tJzHBTahDgAAAAAAAA== --------------ms080500010503070600070605-- From owner-ietf-calendar@mail.imc.org Tue Jun 24 18:02: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 SAA12911 for ; Tue, 24 Jun 2003 18:02: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 h5OLFjrb093944 for ; Tue, 24 Jun 2003 14:15:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OLFjPL093943 for ietf-calendar-bks; Tue, 24 Jun 2003 14:15:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OLFhrb093937 for ; Tue, 24 Jun 2003 14:15:43 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5OLFfOR000387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 24 Jun 2003 14:15:44 -0700 Message-ID: <3EF8BF74.4020802@Royer.com> Date: Tue, 24 Jun 2003 15:15: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: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040006050207010800040500" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040006050207010800040500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > If you ask for RECURRENCE-ID:x and what you get back is a > > valid object with a SEQUENCE:, then you will > > AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE, > > you MUST do a REFRESH for the ENTIRE object (REFRESH with out > RECURRENCE-ID). > > Says who?!? There is NOTHING in any of the RFCs to indicate this! iTIP > is quite clear on how to distinguish a new invite from a reschedule: Perhaps your version of iTIP is missing the sections below: From iTIP: 4.7.2 Bad RECURRENCE-ID Component instances are identified by the combination of "UID", "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request to an "Attendee", there are three cases in which an instance cannot be found. They are: 1. The component with the referenced "UID" and "RECURRENCE-ID" has been found but the "SEQUENCE" number in the calendar store does not match that of the ITIP message. 2. The component with the referenced "UID" has been found, the "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be found. 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not support recurrences. In case (1), two things can happen. If the "SEQUENCE" number of the "Attendee's" instance is larger than that in the "Organizer's" message then the "Attendee" is receiving an out-of-sequence message and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" instance is smaller, then the "Organizer" is sending out a newer version of the component and the "Attendee's" version needs to be updated. Since one or more updates have been missed, the "Attendee" SHOULD send a "REFRESH" message to the "Organizer" to get an updated version of the event. 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. In case (3), the limitations of the "Attendee's" CUA makes it impossible to match an instance other than the single instance scheduled. In this case, the "Attendee" need not send a "REFRESH" to the "Organizer". The example below shows a sequence in which an "Attendee" sends a "REFRESH" to the "Organizer". ... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040006050207010800040500 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjQyMTE1MzJaMCMGCSqGSIb3DQEJBDEWBBRo TbRhT6pd4Vevw4aTbBnszX72fDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAOZDOA3XpwRx5 l9pcCOwg2FG1IzEGereqgCcUr1KBbvHhIuy6q2EzOPfrzPaEfZ23imiEVc8R1GXSLbPTa3O+ na95/tXHNK53W8i+tlDcbHm4jLi2IAOSYgsmEAN6axQLuPk565MDllP4mi+j6Fcxga/lOrAx 3iwNLuAIkxxIeEv8Yz2XLjskcQDdMXxEy4Oo0A8lR+Y2Pyh8G1aOSMOu3XzQxOIXISTt6Mch nmWlsWGo5FVersjfHBCznoWUqWj1ActgVejY6EtS3XmI7cBvj7mHE95AiC13cxeVfko7hQ5L x/hJy5Y57G4Ws3HcFyQWSTTNaSumDQRh2Z3oIpoWUwAAAAAAAA== --------------ms040006050207010800040500-- From owner-ietf-calendar@mail.imc.org Tue Jun 24 21:34: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 VAA01913 for ; Tue, 24 Jun 2003 21:34: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 h5ONW6rb098195 for ; Tue, 24 Jun 2003 16:32: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 h5ONW5Uo098194 for ietf-calendar-bks; Tue, 24 Jun 2003 16:32:05 -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 h5ONW4rb098186 for ; Tue, 24 Jun 2003 16:32:04 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5ONW1Ko004140 for ; Tue, 24 Jun 2003 16:32:01 -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 h5ONW1aJ026289 for ; Tue, 24 Jun 2003 16:32:01 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HH0000EHEPDCG@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Tue, 24 Jun 2003 16:32:01 -0700 (PDT) Date: Tue, 24 Jun 2003 16:32:01 -0700 From: Satya Vempati Subject: RE: Fw: Correct handling of Recurrence-id To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lv/nyY5Ok3CmY8WnvF2qHQ)"; DIFFERENCES=Content-Language Content-language: en-USA Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_lv/nyY5Ok3CmY8WnvF2qHQ) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT Is it possible to get one or more of the original authors of iCAL/iTIP to clarify how RECURRENCE-IDs should be handled? -----Original Message----- From: Doug Royer [mailto:Doug@royer.com] Sent: Tuesday, June 24, 2003 2:16 PM To: ietf-calendar@imc.org Subject: Re: Fw: Correct handling of Recurrence-id Bruce_Kahn@notesdev.ibm.com wrote: > > If you ask for RECURRENCE-ID:x and what you get back is a > > valid object with a SEQUENCE:, then you will > > AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE, > > you MUST do a REFRESH for the ENTIRE object (REFRESH with out > RECURRENCE-ID). > > Says who?!? There is NOTHING in any of the RFCs to indicate this! iTIP > is quite clear on how to distinguish a new invite from a reschedule: Perhaps your version of iTIP is missing the sections below: From iTIP: 4.7.2 Bad RECURRENCE-ID Component instances are identified by the combination of "UID", "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request to an "Attendee", there are three cases in which an instance cannot be found. They are: 1. The component with the referenced "UID" and "RECURRENCE-ID" has been found but the "SEQUENCE" number in the calendar store does not match that of the ITIP message. 2. The component with the referenced "UID" has been found, the "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be found. 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not support recurrences. In case (1), two things can happen. If the "SEQUENCE" number of the "Attendee's" instance is larger than that in the "Organizer's" message then the "Attendee" is receiving an out-of-sequence message and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" instance is smaller, then the "Organizer" is sending out a newer version of the component and the "Attendee's" version needs to be updated. Since one or more updates have been missed, the "Attendee" SHOULD send a "REFRESH" message to the "Organizer" to get an updated version of the event. 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. In case (3), the limitations of the "Attendee's" CUA makes it impossible to match an instance other than the single instance scheduled. In this case, the "Attendee" need not send a "REFRESH" to the "Organizer". The example below shows a sequence in which an "Attendee" sends a "REFRESH" to the "Organizer". ... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --Boundary_(ID_lv/nyY5Ok3CmY8WnvF2qHQ) Content-id: 0 Content-type: TEXT/html; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT Is it possible to get one or more of the original authors of iCAL/iTIP to clarify how RECURRENCE-IDs should be handled?
-----Original Message-----
From: Doug Royer [mailto:Doug@royer.com]
Sent: Tuesday, June 24, 2003 2:16 PM
To: ietf-calendar@imc.org
Subject: Re: Fw: Correct handling of Recurrence-id
Bruce_Kahn@notesdev.ibm.com wrote:
> > If you ask for RECURRENCE-ID:x and what you get back is a
> > valid object with a SEQUENCE:<larger-than-you-have>, then you will
> > AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE,
> > you MUST do a REFRESH for the ENTIRE object (REFRESH with out
> RECURRENCE-ID).
>
> Says who?!? There is NOTHING in any of the RFCs to indicate this! iTIP
> is quite clear on how to distinguish a new invite from a reschedule:
Perhaps your version of iTIP is missing the sections below:
From iTIP:
4.7.2 Bad RECURRENCE-ID
Component instances are identified by the combination of "UID",
"RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request
to an "Attendee", there are three cases in which an instance cannot
be found. They are:
1. The component with the referenced "UID" and "RECURRENCE-ID" has
been found but the "SEQUENCE" number in the calendar store does
not match that of the ITIP message.
2. The component with the referenced "UID" has been found, the
"SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
found.
3. The "UID" and "SEQUENCE" numbers are found but the CUA does not
support recurrences.
In case (1), two things can happen. If the "SEQUENCE" number of the
"Attendee's" instance is larger than that in the "Organizer's"
message then the "Attendee" is receiving an out-of-sequence message
and MUST ignore it. If the "SEQUENCE" number of the "Attendee's"
instance is smaller, then the "Organizer" is sending out a newer
version of the component and the "Attendee's" version needs to be
updated. Since one or more updates have been missed, the "Attendee"
SHOULD send a "REFRESH" message to the "Organizer" to get an updated
version of the event.
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.
In case (3), the limitations of the "Attendee's" CUA makes it
impossible to match an instance other than the single instance
scheduled. In this case, the "Attendee" need not send a "REFRESH" to
the "Organizer".
The example below shows a sequence in which an "Attendee" sends a
"REFRESH" to the "Organizer".
...
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@Royer.com | Office: (208)612-INET
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
--Boundary_(ID_lv/nyY5Ok3CmY8WnvF2qHQ)-- From owner-ietf-calendar@mail.imc.org Tue Jun 24 22:07: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 WAA02921 for ; Tue, 24 Jun 2003 22:07: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 h5P1rcrb002032 for ; Tue, 24 Jun 2003 18:53:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5P1rcWo002031 for ietf-calendar-bks; Tue, 24 Jun 2003 18:53:38 -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 h5P1rbrb002010 for ; Tue, 24 Jun 2003 18:53:37 -0700 (PDT) (envelope-from JParker@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Tue, 24 Jun 2003 19:51:36 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Tue, 24 Jun 2003 19:52:31 -0600 From: "Jay Parker" To: Subject: Re: Fw: Correct handling of Recurrence-id Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartE0BF2A4F.0__=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=__PartE0BF2A4F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Doug, RFC2446 section 2.1.5 seems to agree with Bruce. "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." 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. 4. In situations where the "UID" and "SEQUENCE" properties match, the "DTSTAMP" property is used as the tie-breaker. The component with the latest "DTSTAMP" overrides all others. Similarly, for "Attendee" responses where the "UID" property values match and the "SEQUENCE" property values match, the response with the latest "DTSTAMP" overrides all others. Rule 1. clearly states that the primary key is composed of *BOTH* the UID *AND* the RECURRENCE-ID properties. 4.7.2 also implies agreement with this by listing all three properties UID, RECURRENCE-ID and SEQUENCE in that order. 4.7.2 further refers to out-of-sequence messages as versioning problems; this also agrees with Bruce's description. I'm having difficulty understanding your previous statement that "Only when the SEQUENCE number and UID are known does RECURRENCE-ID have any meaning". The RFC indicates that the RECURRENCE-ID is usable with just the UID (i.e. without the sequence) since I can get the latest SEQUENCE by doing a refresh of the UID/RECURRENCE-ID. I'm also having difficulty understanding your affirmative response to the observation that you need SEQUENCE to determine RECURRENCE-ID. Could you explain why you believe this to be the case? This seems to be in direct contradiction to using RECURRENCE-ID as part of the primary key and SEQUENCE as the secondary key. Regards, Jay >>> Doug@royer.com 6/24/2003 3:15:32 PM >>> > > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > If you ask for RECURRENCE-ID:x and what you get back is a > > > valid object with a SEQUENCE:, then you will > > > AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE, > > > you MUST do a REFRESH for the ENTIRE object (REFRESH with out > > RECURRENCE-ID). > > > > Says who?!? There is NOTHING in any of the RFCs to indicate this! iTIP > > is quite clear on how to distinguish a new invite from a reschedule: > > Perhaps your version of iTIP is missing the sections below: > From iTIP: > > > 4.7.2 Bad RECURRENCE-ID > > Component instances are identified by the combination of "UID", > "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request > to an "Attendee", there are three cases in which an instance cannot > be found. They are: > > 1. The component with the referenced "UID" and "RECURRENCE-ID" has > been found but the "SEQUENCE" number in the calendar store does > not match that of the ITIP message. > > 2. The component with the referenced "UID" has been found, the > "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be > found. > > 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not > support recurrences. > > In case (1), two things can happen. If the "SEQUENCE" number of the > "Attendee's" instance is larger than that in the "Organizer's" > message then the "Attendee" is receiving an out-of-sequence message > and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" > instance is smaller, then the "Organizer" is sending out a newer > version of the component and the "Attendee's" version needs to be > updated. Since one or more updates have been missed, the "Attendee" > SHOULD send a "REFRESH" message to the "Organizer" to get an updated > version of the event. > > 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. > > In case (3), the limitations of the "Attendee's" CUA makes it > impossible to match an instance other than the single instance > scheduled. In this case, the "Attendee" need not send a "REFRESH" to > the "Organizer". > > The example below shows a sequence in which an "Attendee" sends a > "REFRESH" to the "Organizer". > > ... > > > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-INET > http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > --=__PartE0BF2A4F.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: 8bit
Doug,
 
RFC2446 section 2.1.5 seems to agree with Bruce.
 
"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
       lo! wer values."
   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.

   4.  In situations where the "UID" and "SEQUENCE" properties match,
       the "DTSTAMP" property is used as the tie-breaker. The component
       with the latest "DTSTAMP" overrides all others. Similarly, for
       "Attendee" responses where the "UID" property values match and
&nbs! p;      the "SEQUENCE" property values match, the response with the
       latest "DTSTAMP" overrides all others.

Rule 1. clearly states that the primary key is composed of *BOTH* the UID *AND* the RECURRENCE-ID properties. 
 
4.7.2 also implies agreement with this by listing all three properties UID, RECURRENCE-ID and SEQUENCE in that order.  4.7.2 further refers to out-of-sequence messages as versioning problems; this also agrees with Bruce's description.
 
I'm having difficulty understanding your previous statement that "Only when the SEQUENCE number and UID are known does RECURRENCE-ID have any meaning".  The RFC indicates that the RECURRENCE-ID is usable with just the UID (i.e. without the sequence) since I can get the latest SEQUENCE by doing a refresh of the UID/RECURRENCE-ID.
 
I'm also having difficulty understanding your affirmative response to the observation that you need SEQUENCE to determine RECURRENCE-ID.  Could you explain why you believe this to be the case?  This seems to be in direct contradiction to using RECURRENCE-ID as part of the primary key and SEQUENCE as the secondary key.
 
Regards,
Jay
 


>>> Doug@royer.com 6/24/2003 3:15:32 PM >>>
>
>
> Bruce_Kahn@notesdev.ibm.com wrote:
>
>  >  > If you ask for RECURRENCE-ID:x and what you get back is a
>  >  > valid object with a SEQUENCE:<larger-than-you-have>, then you will
>  >  > AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE,
>  >  > you MUST do a REFRESH for the ENTIRE object (REFRESH with out
>  > RECURRENCE-ID).
>  >
>  > Says who?!?  There is NOTHING in any of the RFCs to indicate this!  iTIP
>  > is quite clear on how to distinguish a new invite from a reschedule:
> 
>  Perhaps your version of iTIP is missing the sections below:
>  From iTIP:
> 
> 
>  4.7.2 Bad RECURRENCE-ID
>  
>&nb! sp;     Component instances are identified by the combination of "UID",
>      "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request
>      to an "Attendee", there are three cases in which an instance cannot
>      be found.  They are:
>  
>      1.  The component with the referenced "UID" and "RECURRENCE-ID" has
>          been found but the "SEQUENCE" number in the calendar store does
>          not match that of the ITIP message.
>  
>      2.  The component with the referenced "UID" has been found, the
>          "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
> &n! bsp;        found.
>&! nbsp;&nb sp;
>      3.  The "UID" and "SEQUENCE" numbers are found but the CUA does not
>          support recurrences.
>  
>      In case (1), two things can happen. If the "SEQUENCE" number of the
>      "Attendee's" instance is larger than that in the "Organizer's"
>      message then the "Attendee" is receiving an out-of-sequence message
>      and MUST ignore it.  If the "SEQUENCE" number of the "Attendee's"
>      instance is smaller, then the "Organizer" is sending out a newer
>      version of the component and the "Attendee's" version needs to be
>      updated. Since one or more updates have been missed, the "Attendee"
>     ! ; SHOULD send a "REFRESH" message to the "Organizer" to get an updated
>      version of the event.
>  
>      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.
>  
>      In case (3), the limitations of the "Attendee's" CUA makes it
>      impossible to match an instance other than the single instance
>     scheduled. In this case, the "Attendee" need not send a "REFRESH" to
>    &n! bsp; the "Organizer".
>  
>  &! nbsp;&nb sp;  The example below shows a sequence in which an "Attendee" sends a
>      "REFRESH" to the "Organizer".
>  
>      ...
> 
> 
> 
>  --
>  
>    Doug Royer                     |   http://INET-Consulting.com
>    -------------------------------|-----------------------------
>    Doug@Royer.com                 | Office: (208)612-INET
>    http://Royer.com/People/Doug   |    Fax: (866)594-8574
>       &n! bsp;                           |   Cell: (208)520-4044
>  
>                   We Do Standards - You Need Standards
> 
--=__PartE0BF2A4F.0__=-- From owner-ietf-calendar@mail.imc.org Tue Jun 24 22:28:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03428 for ; Tue, 24 Jun 2003 22:28: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 h5P2HTrb002645 for ; Tue, 24 Jun 2003 19:17: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 h5P2HTl2002644 for ietf-calendar-bks; Tue, 24 Jun 2003 19:17: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 h5P2HSrb002639 for ; Tue, 24 Jun 2003 19:17:28 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5P2HMOR002589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 24 Jun 2003 19:17:28 -0700 Message-ID: <3EF90629.1090207@Royer.com> Date: Tue, 24 Jun 2003 20:17: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: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606080800010209070409" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090606080800010209070409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > ...Both use fixed RECURRENCE-ID's as described in the iCalendar > specification when sending to the internet. Which RFC are you claming says that? You have never cited any such text. You simply declare that you *think* that one sentence means that and you disregard ALL opposing text in iCAL and iTIP which when you combine obviously can NOT mean that all recurrence id's are tied to sequence zero - no such text exists. It is NOT in 2445, 2446, 2447, CAP-draft, or any CALSCH or individual draft that I can find. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090606080800010209070409 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjUwMjE3MTNaMCMGCSqGSIb3DQEJBDEWBBTH 5Tbr2TZ7UYUqZgyDs9jiBpXNDjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAbrUHTXDnFI6Q Ubh0DDKDCFOYCp76vf5p9ygV/6UjWR3DVqEgTHFIdHK8V0t+oygG/Kt8ygult4YTeAVL3VBa jba9KL+EYon2Za7NtpwqqikYBpe1VFweCoH2q4w5qFOaZdlh0Ew1ebrkRMlPe2qrWCAG0sAb CHOO0eEN1flce8ZmSZPZMXJrtNyJc+lkADHyL7M/0VRf2evvkUGtiaK5YDsnLkw+X9t9gZlU PxS4u5Z8eNfN2UYHw4tDf8vF8eYw+0DBZBm3NO7gqV/24rMisU+DwGuVeOsOZGw+9GC7xZOt zJ9+Ah86bJJma2imEynOhpCLOD+sCC+0oERbv/+GtgAAAAAAAA== --------------ms090606080800010209070409-- From owner-ietf-calendar@mail.imc.org Tue Jun 24 22:51: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 WAA03902 for ; Tue, 24 Jun 2003 22:51: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 h5P2Zjrb003142 for ; Tue, 24 Jun 2003 19:35:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5P2ZjK7003141 for ietf-calendar-bks; Tue, 24 Jun 2003 19:35:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P2Zhrb003135 for ; Tue, 24 Jun 2003 19:35:44 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h5P2ZgOR002707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 24 Jun 2003 19:35:45 -0700 Message-ID: <3EF90A6E.7010304@Royer.com> Date: Tue, 24 Jun 2003 20:35: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: Fw: Correct handling of Recurrence-id References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070907070408090806090304" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070907070408090806090304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit No where in the text below does it say that recurrence-id is tied to sequence:0, other parts of the spec specifically say that it is NOT. The text you cited is for processing order of incoming out of order objects. Jay Parker wrote: > Doug, > > RFC2446 section 2.1.5 seems to agree with Bruce. > > "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 > lo! wer values." > 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. > > 4. In situations where the "UID" and "SEQUENCE" properties match, > the "DTSTAMP" property is used as the tie-breaker. The component > with the latest "DTSTAMP" overrides all others. Similarly, for > "Attendee" responses where the "UID" property values match and > &nbs! p; the "SEQUENCE" property values match, the response with the > latest "DTSTAMP" overrides all others. > > Rule 1. clearly states that the primary key is composed of *BOTH* the > UID *AND* the RECURRENCE-ID properties. FOR SORTING incoming objects. > 4.7.2 also implies agreement with this by listing all three > properties UID, RECURRENCE-ID and SEQUENCE in that order. 4.7.2 further > refers to out-of-sequence messages as versioning problems; this also > agrees with Bruce's description. The implication does not exist and is exactly opposite to the specific text in iCAL and iTIP. The text you cite is for determining the processing and ordering of objects - read the section title. The rule (3.) that you cite also says that the old objects are 'obsolete'. Plus if you tie the recurrence-id to sequence zero - you can NEVER change any recurrence rule. Which also is directly opposed to the text in iTIP which specifically says that you can do that: 4.4.2 Modify A Recurring Instance In this example the "Organizer" issues a recurring meeting. Later the "Organizer" changes an instance of the event by changing the "DTSTART" property. Note the use of "RECURRENCE-ID" property and "SEQUENCE" property in the second request. You will also note from the example provided that the object being modified just happens to be sequence zero, and it is updating the object (changing the recurrence id) and per the text itself 'changes an instance' of the even to SEQUENCE:1 . That entire section assumes that you CAN update a recurrence rule. If you tie the recurrence-id to sequence:0, then your hosed and can NEVER do another update. > I'm having difficulty understanding your previous statement that "Only > when the SEQUENCE number and UID are known does RECURRENCE-ID have any > meaning". The RFC indicates that the RECURRENCE-ID is usable with just > the UID (i.e. without the sequence) since I can get the latest SEQUENCE > by doing a refresh of the UID/RECURRENCE-ID. From iCAL: 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. It does not say that you can ignore sequence if not zero. And it does not say 'just kidding, ignore SEQUENCE and only use zero'. > I'm also having difficulty understanding your affirmative response to > the observation that you need SEQUENCE to determine RECURRENCE-ID. > Could you explain why you believe this to be the case? This seems to be > in direct contradiction to using RECURRENCE-ID as part of the primary > key and SEQUENCE as the secondary key. Same as above. For CUA's that fix the recurrence-id to SEQUENCE zero they MUST do a REFRESH to get the latest object - else they will NEVER have a clue what the object instances are - unless the just happen to be the same. For implementations that want to throw away the UID and start from scratch when a recurrence rule is updated, that is compliant to iCAL and iTIP - it just breaks users local alarms. Implementations that do not throw away the UID when recurrence id changes are also compliant. If you want to throw away the UID on recurrence id changes, then in order to intemperate with implementations that do not, simply do a REFRESH when you get any partial update and then pretend that what you get back is sequence zero. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070907070408090806090304 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MjUwMjM1MjZaMCMGCSqGSIb3DQEJBDEWBBTV i6NwY+SE81pBR/PxadwaJ30vXjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAVIygU/Sy6OgM RLVIfs1upIuOsIGsz0b+UdDCdZHslgIWg4RatXDV6nqr03VQeKQYuHpBe8JMQwWVvp+uf3tK J0GgeWEj3D1ryKPulJJ9ktqPVInYvop7jU81izkoopASSEJ93cTjKTNK183Y1z4Gkh1kLXAO w5AG3LsF6TOpXanXMToeRqqT+eBAzQNDucd+N8YbXvSEgHOOufP5XA3iIh4V++8AumT9qLsP aWQGMgHlLWyKxnmI9RiJkOJaCeq1aETalU1QhjcQN3sdXZjmxllLQ6TThPcatU57NO8Cw/DM TUjYKTbGJl5qSlUmOkAERN3qL1OQkUVFGeTWhsmDDQAAAAAAAA== --------------ms070907070408090806090304-- From owner-ietf-calendar@mail.imc.org Thu Jun 26 18:15: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 SAA25045 for ; Thu, 26 Jun 2003 18:15: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 h5QLxNrb076703 for ; Thu, 26 Jun 2003 14:59:23 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5QLxN9U076702 for ietf-calendar-bks; Thu, 26 Jun 2003 14:59:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QLxMrb076697 for ; Thu, 26 Jun 2003 14:59:22 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: Re: Correct handling of Recurrence-id MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_06182003NP June 18, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 26 Jun 2003 17:55:34 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/26/2003 05:59:11 PM, Serialize complete at 06/26/2003 05:59:11 PM Content-Type: multipart/alternative; boundary="=_alternative 007893E085256D51_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007893E085256D51_= Content-Type: text/plain; charset="US-ASCII" On 5/27/2003 04:22:30AST I replied: > 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. Actually as some have noted privatley this is not necessary. Given the prose in iTIP above and the text from Section 3.2.2 REQUEST, all that is necessary to do is send an iTIP REQUEST message with the current instances in it. This is legal since it contains the current description of each of the instances the invitee is effectively up to date with the Organzier. The relevant bit from iTIP Sections 3.2.2 REQUEST is: The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component. so by another valid way to invite someone is to just send the current version of each instance (assuming a fixed RECURRENCE-ID that is). Since the UID/RECURRENCE-ID are not on the invitees calendar they are treated as new invitations and workflow can begin. Had an invitee already been invited to other instances then they are unaffected and only the remaining instance defintiions need be sent. Of course its possible to send all instance defintions and then the invitees CUA could use the rules in Section 2.1.5 to match the UID / RECURRENCE-ID / SEQUENCE / DTSTAMP values to decide what to do w/the REQUEST. The other way I described it also works but could mistakenly make some think that the CUA must preserve both the SEQUENCE:0 definition and then all the current ones and thats not necessary. Both ways will achieve the same effect. Does this jive with your expectations Arnaud? 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 007893E085256D51_= Content-Type: text/html; charset="US-ASCII"
On 5/27/2003 04:22:30AST I replied:
> 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.

Actually as some have noted privatley this is not necessary.  

Given the prose in iTIP above and the text from Section 3.2.2 REQUEST, all that is necessary to do is send an iTIP REQUEST message with the current instances in it.  This is legal since it contains the current description of each of the instances the invitee is effectively up to date with the Organzier.  The relevant bit from iTIP Sections 3.2.2 REQUEST is:

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

so by another valid way to invite someone is to just send the current version of each instance (assuming a fixed RECURRENCE-ID that is).  Since the UID/RECURRENCE-ID are not on the invitees calendar they are treated as new invitations and workflow can begin.  Had an invitee already been invited to other instances then they are unaffected and only the remaining instance defintiions need be sent.  Of course its possible to send all instance defintions and then the invitees CUA could use the rules in Section 2.1.5 to match the UID / RECURRENCE-ID / SEQUENCE / DTSTAMP values to decide what to do w/the REQUEST.

The other way I described it also works but could mistakenly make some think that the CUA must preserve both the SEQUENCE:0 definition and then all the current ones and thats not necessary.  Both ways will achieve the same effect.

Does this jive with your expectations Arnaud?
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 007893E085256D51_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 30 11:07: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 LAA29751 for ; Mon, 30 Jun 2003 11:07: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 h5UErnFK066706 for ; Mon, 30 Jun 2003 07:53: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 h5UErngZ066705 for ietf-calendar-bks; Mon, 30 Jun 2003 07:53:49 -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 h5UErlFK066700 for ; Mon, 30 Jun 2003 07:53:48 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: CAP draft - last call, etc. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Mon, 30 Jun 2003 10:53:51 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 06/30/2003 10:53:49 AM, Serialize complete at 06/30/2003 10:53:49 AM Content-Type: multipart/alternative; boundary="=_alternative 0051D75785256D55_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0051D75785256D55_= Content-Type: text/plain; charset="us-ascii" Well, there's been a lot of traffic going on about all sort of issues and topics. However, it came to a halt when one note came up with what may be a "show-stopper." So, I think we need to make a decision here. Do we take items that are too hard to fix, remove them, and put in an addendum that says "the following items need to be resolved in the next version"? Or do we try to take a stab at fixing them. We need to get a version of CAP into RFC status. We need to get people interoperating so we can see what's really working and what's really hosed badly. I asked for a last call and that didn't work. We really do need to get this out the door. Therefore, I'm once again asking for a last hard look at what can stay and what needs to go in the current CAP draft. If it's broken and needs a lot of work - it goes out. I am going to go back over the last year's threads and see what I can determine are the big issues. I'll post a note to the list with the items and will ask for a "hm" from the list as to whether the item stays or goes. If it goes, we'll need help changing the draft to remove all text regarding that topic. If you disagree with the items I post - say so. If you agree with the items - say so. That way I know people are reading the list and will agree with what we produce as the final draft. Cool? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0051D75785256D55_= Content-Type: text/html; charset="us-ascii"
Well, there's been a lot of traffic going on about all sort of issues and topics.  However, it came to a halt when one note came up with what may be a "show-stopper."  So, I think we need to make a decision here.  Do we take items that are too hard to fix, remove them, and put in an addendum that says "the following items need to be resolved in the next version"?  Or do we try to take a stab at fixing them.  We need to get a version of CAP into RFC status.  We need to get people interoperating so we can see what's really working and what's really hosed badly.  I asked for a last call and that didn't work.  We really do need to get this out the door.  Therefore, I'm once again asking for a last hard look at what can stay and what needs to go in the current CAP draft.  If it's broken and needs a lot of work - it goes out.  I am going to go back over the last year's thr! eads and see what I can determine are the big issues.  I'll post a note to the list with the items and will ask for a "hm" from the list as to whether the item stays or goes.  If it goes, we'll need help changing the draft to remove all text regarding that topic.

If you disagree with the items I post - say so.  If you agree with the items - say so.  That way I know people are reading the list and will agree with what we produce as the final draft.  

Cool?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0051D75785256D55_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 30 23:30:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28157 for ; Mon, 30 Jun 2003 23:30: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 h613J4FK092985 for ; Mon, 30 Jun 2003 20:19: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 h613J4VE092984 for ietf-calendar-bks; Mon, 30 Jun 2003 20:19:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h613J2FK092978 for ; Mon, 30 Jun 2003 20:19:02 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h613J0OR023662 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 30 Jun 2003 20:19:03 -0700 Message-ID: <3F00FD9C.8080201@Royer.com> Date: Mon, 30 Jun 2003 21:18: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: CAP draft - last call, etc. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000103090105020805020505" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000103090105020805020505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Items that will be changed in the -11 version of the draft. (1) Sorting is out per this WG. (I submitted my own add on draft). (2) The ABNF will be fixed per the email on this WG. (3) Various typos sent to me and this list. (4) CS to generate FREEBUSY data (NOT CUA). As of the San Francisco IETF meeting (-10 release) there have been no other new CAP issues that seem to have reach consensus. The only new issue seems to be if TARGET will default and I did not think that made it past a couple of questions and opinions sent to the list. Unless I missed something, all of the other issues are all iCal/iTIP/iMIP issues. PLEASE SPEAK UP if you think that something else should make the -11 version of the draft - I AM EDITING IT NOW. Still To do: (I) Beep profile. (II) Document the 1:1 or 1:MANY replies. Item (II) was discussed in S.F. and the thoughts were that you would bundle all single TARGET replies in one blob, and for each unique TARGET in the CS reply, the CS would send another blob of data. pregen@egenconsulting.com wrote: > > Well, there's been a lot of traffic going on about all sort of issues > and topics. However, it came to a halt when one note came up with what > may be a "show-stopper." So, I think we need to make a decision here. > Do we take items that are too hard to fix, remove them, and put in an > addendum that says "the following items need to be resolved in the next > version"? Or do we try to take a stab at fixing them. We need to get a > version of CAP into RFC status. We need to get people interoperating so > we can see what's really working and what's really hosed badly. I asked > for a last call and that didn't work. We really do need to get this out > the door. Therefore, I'm once again asking for a last hard look at what > can stay and what needs to go in the current CAP draft. If it's broken > and needs a lot of work - it goes out. I am going to go back over the > last year's thr! eads and see what I can determine are the big issues. > I'll post a note to the list with the items and will ask for a "hm" > from the list as to whether the item stays or goes. If it goes, we'll > need help changing the draft to remove all text regarding that topic. > > If you disagree with the items I post - say so. If you agree with the > items - say so. That way I know people are reading the list and will > agree with what we produce as the final draft. > > Cool? > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000103090105020805020505 Content-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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA3MDEwMzE4NTJaMCMGCSqGSIb3DQEJBDEWBBRj l+/Q8Z/wPGZBYJtpct4v9E0yoDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAWmVDfv2+7NX6 x8Ch2OIa6HVtxBHws1idTm44Xr35b3f5JOCbHQMqugbS3KTziSSdYzdxQtY61O54oCSWYurj Ujn5hmkdST5sN+h+tdSNJ1ycFjGB3Pg0ISy29T6mpqm1JAWGEk/6Xuv1rTQUfs7bIYFgOuIV pCWF7vEd/7GLLdFiYjX6AQpGjmewj/w1/e8krdgiKjb+0GR3Bd9g4c3//Y1a1LbtL/+e7VCF zn75UVcr7fnVLJXKso1wKcdEtyNCATOnh52C+/QeMSXLzG5SenpNid+qSaXblXx1FN0HpP3+ ile12THyQp4u9A+ls1+MlSuYxw/bj+wYwd+32UVy7AAAAAAAAA== --------------ms000103090105020805020505--