From owner-ietf-calendar@mail.imc.org Mon May 6 17:05:07 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06712 for ; Mon, 6 May 2002 17:05:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g46KsZS00804 for ietf-calendar-bks; Mon, 6 May 2002 13:54:35 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46KsXL00800 for ; Mon, 6 May 2002 13:54:33 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g46KsSOL023475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 6 May 2002 13:54:33 -0700 (PDT) Message-ID: <3CD6ED7D.DA140853@Royer.com> Date: Mon, 06 May 2002 14:54:21 -0600 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-31 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Editors notes 8-MAY-02 Content-Type: multipart/mixed; boundary="------------A2B65274F605E684541496A3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A2B65274F605E684541496A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (long) You will not see these changes below until we push a new version of the draft. If the chairs are okay with it, I can publish on a web site the interm-working-version? I spent some more time working on and catching up to all of the WG comments that have not been acted upon. I added several things - many edits. Some were implied on the WG list, others were explicit: Mandated that the CAPABILITIES reply always be in UTF-8. This allows CUA's to determine the LOCALE's and CHARSET's the CS supports. Without this requirement, there is NO way to determine which charset and locale the CAPABILITIES the CS is running at the moment (Thus making the command unreadable to the CS and the reply unreadable to the CUA). This was not explicitly discussed. But there have been NO proposals as this seemed as good as any. Mandated that upon initial connection, the CS be using the UTF-8 charset. There needed to be a MUST charset specified and a starting point to switch (see below). Added a requirement that the CUA AND CS can only send data using the locales defined in the initial beep greeting. Not explicitly talked about on the list. Added a CHARSET command so that CUA's can change the charset to one of the ones returned in CAPABILITIES and mandated that the charset command AND reply always be in UTF-8. Without this there was NO way to switch charsets at all. As the MIME header is NOT sufficient. You can't read the MIME header charset setting if it is already in another charset. This was so that the CUA can change and use any charset supported by both the CS and CUA. Without this command there was no way to switch from/to UTF-8. This had been debated in the past. Mostly asian concerts about wanting to use their popular charset. This adds that discussed capability to CAP. Included in the charset command is a locale (LANG) property that allows the CUA to specify both the charset and locale the CUA and CS use. And that the values MUST BE from the BEEP greeting and CS capabilities replied. Like this: CMD:charset LANGUAGE:xx_yy CHARSET:zz We DID talk about being able to do this, there was not specific proposal - I added the above to CAP and you will see it in the next release. Added several defaults values to the VCALSTORE and VAGENDA properties lists. There needed to be default for LANG and LOCALE as discussed on the list. No specifics were proposed and without them, the CUA had no way to know which ones the CS supported. Plus there was no need to force all VAGENDAs on a CS to be in the same locale and charset - *IF* the CS supports more than one charset/locale. If the CS only supports UTF-8, then those will just be set to UTF-8. I again trimmed down the restriction tables and specified which section in iCal, iTIP, iMIP, or CAP information is specified in. This was because it was simply duplicate information and the comments were getting long explaining what was already explained in another rfc or section of CAP. I removed almost all of the BEEP headers and footers from the examples. We use BEEP, that was already explained in the CAP. I started to update the reply codes (more TBD). I changed OWNER to OWNER() so there were not two ways to specify the owner. I changed NONOWNER to NONOWNER() - same as above. I changed 'user@*' to say 'Not recommended". I would like to say "not valid". Per the list discussion. I added missing property, parameter, and value definitions in their own sections - (more TBD). I edited the change control to say 'submit draft for RFC approval...' There has been no justification for a 'method reviewer' and there has been much debate about how to structure it. So I changed it to what every other RFC does - tell them to generate an RFC. If they want to add to 2445, then follow those procedures. -------- (amplification of stuff above) I added "DEFAULT-CHARSET" to the VCALSTORE - needed if you need to know. I added "DEFAULT-LOCALE" to the VCALSTORE - needed if you need to know. I added "RELATED-TO" to the VCALSTORE - per list talk months ago. I added "DEFAULT-CHARSET to the VAGENDA - needed if you need to know. I added "DEFAULT-LOCALE" to the VAGENDA - needed if you need to know. I put in "RELATED-TO" to the VAGENDA - per list talk months ago. --------- Next: I am going to re-arrange CAP so the definitions of the new properties, parameters, and values exist prior to their usage. -Doug --------------A2B65274F605E684541496A3 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;27136 fn:Doug Royer end:vcard --------------A2B65274F605E684541496A3-- From owner-ietf-calendar@mail.imc.org Mon May 6 17:45:49 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08523 for ; Mon, 6 May 2002 17:45:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g46LZZh03017 for ietf-calendar-bks; Mon, 6 May 2002 14:35:35 -0700 (PDT) Received: from postman.incentivesystems.com (Postman.IncentiveSystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46LZXL03013 for ; Mon, 6 May 2002 14:35:34 -0700 (PDT) To: "ietf-calendar@imc.org" Subject: Re: Editors notes 8-MAY-02 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 6 May 2002 17:48:19 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 05/06/2002 05:48:27 PM, Serialize complete at 05/06/2002 05:48:27 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >You will not see these changes below until we push a new version >of the draft. If the chairs are okay with it, I can publish >on a web site the interm-working-version? If you've got the interim version, wouldn't it be just as easy to submit it as an I-D? It'd be good for anybody looking in the I-D repository to see the latest version. >Mandated that the CAPABILITIES reply always be in UTF-8. Makes sense to me. >I changed 'user@*' to say 'Not recommended". I would like >to say "not valid". Per the list discussion. I think you're right; it should be invalid--it's just as weak as anonymous. >I edited the change control to say 'submit draft for RFC approval...' >There has been no justification for a 'method reviewer' and >there has been much debate about how to structure it. So I changed >it to what every other RFC does - tell them to generate an RFC. I like it (not that I think that will surprise anybody ;-). /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |"What a plan! Simple, yet insane!" -- _Monsters, Inc._ | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri May 10 13:11:56 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05581 for ; Fri, 10 May 2002 13:11:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4AH1lJ04678 for ietf-calendar-bks; Fri, 10 May 2002 10:01:47 -0700 (PDT) Received: from ossex1.ossinc.net ([63.227.51.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AH1jL04674 for ; Fri, 10 May 2002 10:01:46 -0700 (PDT) Received: by ossex1.corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 11:04:34 -0600 Message-ID: <8D96EDA0AC04D31197B400A0C96C1480044C9332@ossex1.corp.webb.net> From: Jim Ray To: "'ietf-calendar@imc.org'" Subject: Adding CAP extensions to xCal Date: Fri, 10 May 2002 11:04:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there any plan underway that will add the CAP extensions to iCalendar in xCal? The reason I'm asking is I'm doing research for using Jabber as a transport layer for Calendaring. Thanks. Jim Ray From owner-ietf-calendar@mail.imc.org Fri May 10 13:39:55 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07423 for ; Fri, 10 May 2002 13:39:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4AHYE605600 for ietf-calendar-bks; Fri, 10 May 2002 10:34:14 -0700 (PDT) Received: from postman.incentivesystems.com (Postman.IncentiveSystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AHYCL05594 for ; Fri, 10 May 2002 10:34:12 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Adding CAP extensions to xCal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 10 May 2002 13:47:12 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 05/10/2002 01:47:18 PM, Serialize complete at 05/10/2002 01:47:18 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Is there any plan underway that will add the CAP extensions to iCalendar in >xCal? The XML representation of iCalendar will have to be an isomorphism. This means that, once it's defined, it will automatically inherit any extensions. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |The voices say I'm not schizophrenic, but they're not sure about| |you. | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri May 10 13:52:15 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08015 for ; Fri, 10 May 2002 13:52:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4AHkI805936 for ietf-calendar-bks; Fri, 10 May 2002 10:46:18 -0700 (PDT) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AHkHL05931 for ; Fri, 10 May 2002 10:46:17 -0700 (PDT) Received: from jsoft.com (IDENT:bjmk9OrSu0+Y9kqAA1toVoKk1qD1sfdU@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g4AHeuP13205; Fri, 10 May 2002 12:40:56 -0500 Message-ID: <3CDC0628.6010009@jsoft.com> Date: Fri, 10 May 2002 12:40:56 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Ray CC: "'ietf-calendar@imc.org'" Subject: Re: Adding CAP extensions to xCal References: <8D96EDA0AC04D31197B400A0C96C1480044C9332@ossex1.corp.webb.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim, Feel free to send me some email with some details on what you are looking for. This mailing list is focusing on getting CAP out. Once that happens, xCal and other things will be more active. Gary Jim Ray wrote: > Is there any plan underway that will add the CAP extensions to iCalendar in > xCal? The reason I'm asking is I'm doing research for using Jabber as a > transport layer for Calendaring. > > Thanks. > > Jim Ray From owner-ietf-calendar@mail.imc.org Fri May 10 15:57:22 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14836 for ; Fri, 10 May 2002 15:57:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4AJodG24612 for ietf-calendar-bks; Fri, 10 May 2002 12:50:39 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AJocL24608 for ; Fri, 10 May 2002 12:50:38 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g4AJoYgw005178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 10 May 2002 12:50:39 -0700 (PDT) Message-ID: <3CDC2480.236D0931@Royer.com> Date: Fri, 10 May 2002 13:50:24 -0600 From: Doug Royer Reply-To: "'ietf-calendar@imc.org'" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-31 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Adding CAP extensions to xCal References: <8D96EDA0AC04D31197B400A0C96C1480044C9332@ossex1.corp.webb.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms29181125210C370BF2A41662" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms29181125210C370BF2A41662 Content-Type: multipart/mixed; boundary="------------5C03E3E38385FBF6580FFACC" This is a multi-part message in MIME format. --------------5C03E3E38385FBF6580FFACC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim Ray wrote: > > Is there any plan underway that will add the CAP extensions to iCalendar in > xCal? The reason I'm asking is I'm doing research for using Jabber as a > transport layer for Calendaring. The CAP commands will always be in CAP format. It is possible that a draft will be written that will allow xCal to optionally be transported in CAP. -Doug --------------5C03E3E38385FBF6580FFACC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;27136 fn:Doug Royer end:vcard --------------5C03E3E38385FBF6580FFACC-- --------------ms29181125210C370BF2A41662 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA1MTAxOTUwMjRaMCMGCSqGSIb3DQEJ BDEWBBQpI5m7MecR08gpGz3m0HTIweI2bTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgDmhvLr0oEYVEH4kl9yE8ieMCRYwAJDfQFkFiROS/OEoYsYo XuMPSJ4eQkOCgmpWDVH9fd4NTwdJd3b6hZiqzn2wvj/RUYG0e3P9me7vCnYNh/KFuiASoPCI RdGeXEWuq6v/6eHY+dAAmuKvRF7AncJ80xUU6NVKk4qSg6OQaefl --------------ms29181125210C370BF2A41662-- From owner-ietf-calendar@mail.imc.org Tue May 14 18:13:51 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09444 for ; Tue, 14 May 2002 18:13:50 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4EM3iP21459 for ietf-calendar-bks; Tue, 14 May 2002 15:03:44 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EM3ZL21452 for ; Tue, 14 May 2002 15:03:36 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA07287; Tue, 14 May 2002 18:03:36 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA29183; Tue, 14 May 2002 18:03:30 -0400 (EDT) Received: from [66.92.67.186] (BOB.MIT.EDU [18.18.1.170]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA04856; Tue, 14 May 2002 18:03:25 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 14 May 2002 18:03:20 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Re: Yokahama Cc: Pat Egen 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 7:08 PM -0400 4/25/02, pregen@egenconsulting.com wrote: >We are trying to determine how many people will be in Yokahama. If >you are planning on attending this meeting, please post to the list. Folks- We've yet to see any indication that anyone from this WG will be present in Yokahama. If there are folks intending to go, it would be appreciated if you could raise your hands. We have not yet requested a meeting slot... If we want to meet, we need to make our intentions known. ("Maybe" is an acceptable response in this instance) Thanks. -Bob From owner-ietf-calendar@mail.imc.org Fri May 17 10:38:58 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15959 for ; Fri, 17 May 2002 10:38:57 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4HEJbg00976 for ietf-calendar-bks; Fri, 17 May 2002 07:19:37 -0700 (PDT) Received: from mail.samsungcontact.com ([195.89.159.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HEJZL00964 for ; Fri, 17 May 2002 07:19:36 -0700 (PDT) Received: from mail.samsungcontact.com (root@localhost) by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g4HEJZ905652 for ; Fri, 17 May 2002 15:19:35 +0100 Received: from samsungcontact.com (markspace.demon.co.uk 158.152.7.170) by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0) via ESMTP; Fri, 17 May 2002 15:19:36 +0100 (BST) Message-ID: <3CE5116D.2060605@samsungcontact.com> Date: Fri, 17 May 2002 15:19:25 +0100 From: Mark Davidson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Obtaining a users freebusy data. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have been reading the CAP spec (ver 7) and attempting to create some example cases that could be used to add the use of a CAP server to a client. I have become stuck with the problem of obtaining FREEBUSY data. I can see several ways of resolving the problem, but am unsure which to follow. The case is: Get todays freebusy data from calendar markcal1, where today is 17th May 2002 in London. 1) You could create an iTip freebusy request containing a VFREEBUSY REQUEST, and expect the server to give you an iTip reply containing a VFREEBUSY object with FREEBUSY properties. 2) You could search for VFREEBUSY components that have DTSTART and DTEND properties in the correct range. 3) You could search for VEVENT and VTODO components with DTSTART and DTEND properties in the correct range, that are booked and not transparent. Is the server expecting the client to store VFREEBUSY data, or is it calculating it from the event data it already knows? Thanks Mark Davidson From owner-ietf-calendar@mail.imc.org Fri May 17 11:20:36 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17327 for ; Fri, 17 May 2002 11:20:35 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4HF3oJ02419 for ietf-calendar-bks; Fri, 17 May 2002 08:03:50 -0700 (PDT) Received: from postman.incentivesystems.com (Postman.IncentiveSystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HF3nL02413 for ; Fri, 17 May 2002 08:03:49 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Obtaining a users freebusy data. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 17 May 2002 11:16:58 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 05/17/2002 11:17:18 AM, Serialize complete at 05/17/2002 11:17:18 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >1) You could create an iTip freebusy request containing a VFREEBUSY >REQUEST, and expect the server to give you an iTip reply containing a >VFREEBUSY >object with FREEBUSY properties. I think this is the correct approach, because it's the one that's likely to work with minimal privileges--I'm more likely to let you submit an iTIP request than to let you actually search my calendar. It's also a good idea because you can reuse the code for anybody you can reach via iTIP--say, if you don't know my cap: address, but you do have my email address, you can send me an iMIP message. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Two words that inspire the same feeling of dread are synominous. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Wed May 22 16:24:26 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28948 for ; Wed, 22 May 2002 16:24:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MKCQI26949 for ietf-calendar-bks; Wed, 22 May 2002 13:12:26 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MKCLL26942 for ; Wed, 22 May 2002 13:12:25 -0700 (PDT) To: ietf-calendar@imc.org Subject: Yokahama meeting MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 22 May 2002 16:05:30 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 05/22/2002 04:12:28 PM, Serialize complete at 05/22/2002 04:12:28 PM Content-Type: multipart/alternative; boundary="=_alternative 006E5E3485256BC1_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E5E3485256BC1_= Content-Type: text/plain; charset="us-ascii" Based on the lack of responses to the list regarding Yokahama, Bob and I have decided to not hold a session for the CALSCH working group in Yokahama. However, we can still continue to work on drafts on the list and can submit them - we just can not have any "in person" interim meetings. So, keep those cards and letters coming. bob and I are going to review the sparse activity to see if the ball is in our court to state items are "complete." If anyone thinks a topic still needs discussion, please say so on the list. thanks for your support. --=_alternative 006E5E3485256BC1_= Content-Type: text/html; charset="us-ascii"
Based on the lack of responses to the list regarding Yokahama, Bob and I have decided to not hold a session for the CALSCH working group in Yokahama.  However, we can still continue to work on drafts on the list and can submit them - we just can not have any "in person" interim meetings.  So, keep those cards and letters coming.  bob and I are going to review the sparse activity to see if the ball is in our court to state items are "complete."  If anyone thinks a topic still needs discussion, please say so on the list.

thanks for your support. --=_alternative 006E5E3485256BC1_=-- From owner-ietf-calendar@mail.imc.org Wed May 22 17:58:45 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03982 for ; Wed, 22 May 2002 17:58:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MLqr800220 for ietf-calendar-bks; Wed, 22 May 2002 14:52:53 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MLqqL00216 for ; Wed, 22 May 2002 14:52:52 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g4MLqmHZ006607 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 May 2002 14:52:53 -0700 (PDT) Message-ID: <3CEC1303.EC8061D@Royer.com> Date: Wed, 22 May 2002 15:52:03 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: discussion METHOD References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE2BDB84675442200F091278A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msE2BDB84675442200F091278A Content-Type: multipart/mixed; boundary="------------2016E5FA4DAFC60E64255187" This is a multi-part message in MIME format. --------------2016E5FA4DAFC60E64255187 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > If anyone thinks a topic still > needs discussion, please say so on the list. I have spent hours working on the draft cleaning up the multiple identical statements and such. I am now moving the property/component/value type definitions to the front of the spec - like iCalendar. After the last post from Steve, I looked closer at the METHOD property in the objects and I still feel that we do not need to put METHOD in the objects. This will keep METHOD 100% pure iTIP (yet we can still query for objects by METHOD). The only thing we really want to know is if the objects are 'BOOKED', 'UNPROCESSED', or marked 'DELETED'. And So I added (I can still remove it :-), STATE() to the query language. SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' SELECT * FROM VEVENT WHERE STATE() = 'DELETED' The 'state' also does not need to be specified as belonging to an object as it will NEVER go over the wire. As 100% of all *iTIP* objects deposited are UNPROCESSED, 100% of all objects modified to DELETE state (still working out the syntax for this). are in the DELETED state. And 100% of all other objects are in effect BOOKED (including VCARs, {CS,VCALSTORE,VAGENDA} properties) So you would CMD:CREATE any object. If it has a METHOD, then it MUST BE an iTIP object, so it is deposited and its 'state' is 'UNPROCESSED'. If it does not have a METHOD in it, then its state is BOOKED. And I am thing of adding a parameter to the DELETE command: CMD:DELETE <- Remove the object from the store. CMD;opt=markfor:DELETE <- Mark it as state DELETED. I would think that a huge amount of the time using the STATE() method would get you what you want (You can still also use date constraints with it). Also, If you query for METHOD = '', then the CS MUST get you the objects that were deposited into the CS with that method in their VCALENDAR object and CAP only needs to specify that the CS MUST remember their METHOD and not how the CS remembers. This also slightly simplifies synchronization where pass one must be get pending iTIP requests (UNPROCESSED). Comments? --------------2016E5FA4DAFC60E64255187 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;27136 fn:Doug Royer end:vcard --------------2016E5FA4DAFC60E64255187-- --------------msE2BDB84675442200F091278A Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA1MjIyMTUyMDZaMCMGCSqGSIb3DQEJ BDEWBBSV6z1WqWdjOdJKGyP8nPMASKLqrjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgEXIP/YA636s7u6fpD4UsB/ACK+YogsG4VsHWMJ3yhAWVlXE qlZqQYuFaSfI7aErVBP/CwHbtgpUD1vEoej0T9kof6rJ60z8v2/2QFnL7s1eRnnUUYEY7Ud7 8Jl2NsPCAzaLqFu3Qp6o7IgLrczITMF+WRheFUQWwQIl6DG3OQSM --------------msE2BDB84675442200F091278A-- From owner-ietf-calendar@mail.imc.org Thu May 23 07:26:10 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04376 for ; Thu, 23 May 2002 07:26:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NBImW22823 for ietf-calendar-bks; Thu, 23 May 2002 04:18:48 -0700 (PDT) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NBIlL22819 for ; Thu, 23 May 2002 04:18:47 -0700 (PDT) Received: from jsoft.com (IDENT:2SsXRFNkArBn6+xh/MlCorl4XTFN9pfK@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g4NBFvT01231 for ; Thu, 23 May 2002 06:15:57 -0500 Message-ID: <3CECCF6D.2080902@jsoft.com> Date: Thu, 23 May 2002 06:15:57 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: discussion METHOD References: <3CEC1303.EC8061D@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Could you make a copy of the draft available Doug? Gary Doug Royer wrote: > pregen@egenconsulting.com wrote: > >> If anyone thinks a topic still >>needs discussion, please say so on the list. > > > I have spent hours working on the draft cleaning up > the multiple identical statements and such. I am now > moving the property/component/value type definitions > to the front of the spec - like iCalendar. > > After the last post from Steve, I looked closer at the > METHOD property in the objects and I still feel that > we do not need to put METHOD in the objects. This > will keep METHOD 100% pure iTIP (yet we can still query > for objects by METHOD). > > The only thing we really want to know is if the objects > are 'BOOKED', 'UNPROCESSED', or marked 'DELETED'. And > So I added (I can still remove it :-), STATE() to the query > language. > > SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' > > SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' > > SELECT * FROM VEVENT WHERE STATE() = 'DELETED' > > The 'state' also does not need to be specified as belonging > to an object as it will NEVER go over the wire. As 100% of > all *iTIP* objects deposited are UNPROCESSED, 100% of all objects > modified to DELETE state (still working out the syntax for this). > are in the DELETED state. And 100% of all other objects are > in effect BOOKED (including VCARs, {CS,VCALSTORE,VAGENDA} properties) > > So you would CMD:CREATE any object. > If it has a METHOD, then it MUST BE an iTIP object, > so it is deposited and its 'state' is 'UNPROCESSED'. > > If it does not have a METHOD in it, then its state is BOOKED. > > And I am thing of adding a parameter to the DELETE command: > > CMD:DELETE <- Remove the object from the store. > > CMD;opt=markfor:DELETE <- Mark it as state DELETED. > > I would think that a huge amount of the time using the STATE() > method would get you what you want (You can still also use date > constraints with it). > > Also, If you query for METHOD = '', then > the CS MUST get you the objects that were deposited into > the CS with that method in their VCALENDAR object and CAP > only needs to specify that the CS MUST remember their METHOD > and not how the CS remembers. > > This also slightly simplifies synchronization where pass one must be > get pending iTIP requests (UNPROCESSED). > > Comments? From owner-ietf-calendar@mail.imc.org Thu May 23 10:24:59 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12029 for ; Thu, 23 May 2002 10:24:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NEFGK01932 for ietf-calendar-bks; Thu, 23 May 2002 07:15:16 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NEFFL01920 for ; Thu, 23 May 2002 07:15:15 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g4NEFAHZ008318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 23 May 2002 07:15:15 -0700 (PDT) Message-ID: <3CECF93C.2E765A74@Royer.com> Date: Thu, 23 May 2002 08:14:20 -0600 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: discussion METHOD References: <3CEC1303.EC8061D@Royer.com> <3CECCF6D.2080902@jsoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA43E50157D5A906F6D6E9401" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msA43E50157D5A906F6D6E9401 Content-Type: multipart/mixed; boundary="------------F77432C2BC980489368A2B7B" This is a multi-part message in MIME format. --------------F77432C2BC980489368A2B7B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Frederick wrote: > > Could you make a copy of the draft available Doug? > > Gary Yes, as soon as it is ready the other editors and I will publish it. --------------F77432C2BC980489368A2B7B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;27136 fn:Doug Royer end:vcard --------------F77432C2BC980489368A2B7B-- --------------msA43E50157D5A906F6D6E9401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA1MjMxNDE0MjBaMCMGCSqGSIb3DQEJ BDEWBBSSvN+BJg2yozMHQWuTKTIT5m4WSzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgFPDK6bAUhEayJdOe8Ve3TbU3SJYP42F6l3jbeOf4iyznHyI X4dohSKbheVK/sHoo+c8eac8kWgAHxbDf+VvjOgU6+hUwf94rC8ZXbl2hATtFKaX9jwXKaID zFXM273sdbHnwROHa7pPRAh7GWfvaxAM3Z1cUdTGOIuqsGH0mUxT --------------msA43E50157D5A906F6D6E9401-- From owner-ietf-calendar@mail.imc.org Fri May 24 15:07:56 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10882 for ; Fri, 24 May 2002 15:07:56 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4OIxcJ24113 for ietf-calendar-bks; Fri, 24 May 2002 11:59:38 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OIxbL24109 for ; Fri, 24 May 2002 11:59:37 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g4OIxYkY025403 for ; Fri, 24 May 2002 14:59:34 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g4OIxUr21713 for ; Fri, 24 May 2002 14:59:30 -0400 (EDT) Message-ID: <3CEE8E75.E1423D67@steltor.com> Date: Fri, 24 May 2002 15:03:17 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: STATE() [Was: discussion METHOD] References: <3CEC1303.EC8061D@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > The 'state' also does not need to be specified as belonging > to an object as it will NEVER go over the wire. On the contrary, the state of a component should be sent on the wire to the CUA, such that the CUA can easily find out the state of components returned for an arbitrary search. Otherwise, the CUA will be forced to perform multiple search commands (i.e., one for each state) when a single search could do. What's wrong with Steve's proposition of specifying the state explicitly in the component? Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Fri May 24 15:07:57 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10896 for ; Fri, 24 May 2002 15:07:57 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4OIxau24108 for ietf-calendar-bks; Fri, 24 May 2002 11:59:36 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OIxZL24104 for ; Fri, 24 May 2002 11:59:36 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g4OIxWkY025406 for ; Fri, 24 May 2002 14:59:32 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g4OIxWr21719 for ; Fri, 24 May 2002 14:59:32 -0400 (EDT) Message-ID: <3CEE8E76.EF530E60@steltor.com> Date: Fri, 24 May 2002 15:03:18 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CMD;opt=markfor:DELETE [Was: discussion METHOD] References: <3CEC1303.EC8061D@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > And I am thing of adding a parameter to the DELETE command: > > CMD:DELETE <- Remove the object from the store. > > CMD;opt=markfor:DELETE <- Mark it as state DELETED. We should be cautious about mixing the state of a component with the fact that it has been mark for removal. For instance, with my email client, if I delete an "Unread" email message (i.e., add the flag "Deleted" to it) and that I later undelete this message (i.e., remove the flag "Deleted") the email message will still be marked as "Unread". The fact that a component has been mark for removal would be better handled by a property which could easily be maintained by CMD:MODIFY. I don't see the need for a new command, nor an option to an existing command. I can think of many ways of implementing this in iCalendar. Here's a few: 1- Two properties: STATE:UNPROCESSED DELETED:TRUE 2- One property with a parameter: STATE;DELETED=TRUE:UNPROCESSED 3- One multi-value / multi-instance property: STATE:UNPROCESSED STATE:DELETED or STATE:UNPROCESSED,DELETED Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Fri May 24 15:27:26 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11363 for ; Fri, 24 May 2002 15:27:25 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4OJL4Q24597 for ietf-calendar-bks; Fri, 24 May 2002 12:21:04 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OJL3L24593 for ; Fri, 24 May 2002 12:21:03 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g4OJL0kY025674 for ; Fri, 24 May 2002 15:21:00 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g4OJL0r27265 for ; Fri, 24 May 2002 15:21:00 -0400 (EDT) Message-ID: <3CEE937E.FE9C7CE2@steltor.com> Date: Fri, 24 May 2002 15:24:46 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Questions to answer for the METHOD issue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just to make sure we are all on the same page about the current issue to solve, here's the questions I think we need to answer: A- Mary wants to invite Bob to a meeting. Q1: What is the format of the iCalendar object Mary needs to send to the CS to deposit a calendar invitation in Bob's agenda? B- Bob wants to find all the calendar invitations he did not already processed. Q2: What is the format of the iCalendar object Bob needs to send to the CS to get all unprocessed calendar invitations? Q3: In which format will the iCalendar objects of the unprocessed calendar invitations be returned to Bob? Can someone provide *complete* iCalendar objects for all 3 questions? Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Fri May 24 15:49:01 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12195 for ; Fri, 24 May 2002 15:49:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OJgmr25063 for ietf-calendar-bks; Fri, 24 May 2002 12:42:48 -0700 (PDT) Received: from postman.incentivesystems.com (Postman.IncentiveSystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OJglL25059 for ; Fri, 24 May 2002 12:42:47 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Questions to answer for the METHOD issue MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 24 May 2002 15:43:29 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 05/24/2002 03:44:33 PM, Serialize complete at 05/24/2002 03:44:33 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >A- Mary wants to invite Bob to a meeting. > > Q1: What is the format of the iCalendar object > Mary needs to send to the CS to deposit a > calendar invitation in Bob's agenda? iTIP. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |I'm on a Mission From God to Save The World from megalomania! | |(Question: which God? Answer: Milhouse, God of Humility. You | |probably haven't heard of him; he doesn't put himself forward.) | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri May 24 15:52:15 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12317 for ; Fri, 24 May 2002 15:52:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OJlEf25148 for ietf-calendar-bks; Fri, 24 May 2002 12:47:14 -0700 (PDT) Received: from royer2.royer.com (IDENT:0knIz47Xmzt6/YI66f26brysqJ0UTDG0@royer2.royer.com [4.23.9.160]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OJlCL25144 for ; Fri, 24 May 2002 12:47:12 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer2.royer.com (8.12.2/8.12.2) with ESMTP id g4OJlAmj011584 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 24 May 2002 12:47:14 -0700 Message-ID: <3CEE989D.6EA47E7E@Royer.com> Date: Fri, 24 May 2002 13:46:37 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-31 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CMD;opt=markfor:DELETE [Was: discussion METHOD] References: <3CEC1303.EC8061D@Royer.com> <3CEE8E76.EF530E60@steltor.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms14B8C15F4F680EF8FDE05D3A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms14B8C15F4F680EF8FDE05D3A Content-Type: multipart/mixed; boundary="------------28A30264AE77457333786ED8" This is a multi-part message in MIME format. --------------28A30264AE77457333786ED8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > And I am thing of adding a parameter to the DELETE command: > > > > CMD:DELETE <- Remove the object from the store. > > > > CMD;opt=markfor:DELETE <- Mark it as state DELETED. > The fact that a component has been mark for removal would be > better handled by a property which could easily be maintained > by CMD:MODIFY. I don't see the need for a new command, nor an > option to an existing command. We have in the past decided that there would not be a way to 'un-delete' so it is not the same comparison. The only reason that the DELETE state exists is so that the 2nd and up synchronization processes can tell if something has already been done. Example the 1st synchronization tells the CS that object A is marked for delete. The the 2nd and up synchronization's will know to delete their copies of A. Without a marked for delete, the 2nd and up synchronization will 'think' that their copies of A are new to the CS and re-create them in the CS. No new command has been proposed. CMD was the replacement for the XML command headers. There is NO property to use the MODIFY command with, we removed the conception that METHOD was contained in the object. > I can think of many ways of implementing this in iCalendar. > Here's a few: All three of your proposals define a new property - STATE. There is no reason for a new property. A CUA marks an object for delete, so that other CUAs (or the same one later) will know a specific object has been considered. And STATE() only has meaning with respect to one particular CS. STATE() has NO meaning to any iTIP other object and STATE() has no meaning between CUAs. I have not proposed anything new. DELETE already existed as did CMD (by chair proclamation that the XML command was out). I did not add or modify the meaning of DELETE. Nor did I propose any new properties. I simply am looking for a way for a CUA to tell the CS; "delete this object, and remember you did so that synchronization works later". --------------28A30264AE77457333786ED8 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-29152 fn:Doug Royer end:vcard --------------28A30264AE77457333786ED8-- --------------ms14B8C15F4F680EF8FDE05D3A Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA1MjQxOTQ2NDJaMCMGCSqGSIb3DQEJ BDEWBBTLQJbFM09V+Xe7ZBh2/9OPWjIbLDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgHjs45dSjIoaYxrIsvDoWmniN2m2DRDF69CbXT4B8AHRk22p nxRApEUcugP26TJKwi6b8ouW0VEQ6hpDbXRTDPgM2S81CWJroraDlTpZPZ0wF2mdmO6UmQ8+ iRyYCWkj0/9RMYWwftdIonEiNajRAO62D9SSrMi/OyMuIhFrjFis --------------ms14B8C15F4F680EF8FDE05D3A-- From owner-ietf-calendar@mail.imc.org Fri May 24 15:59:38 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12521 for ; Fri, 24 May 2002 15:59:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OJsnG25294 for ietf-calendar-bks; Fri, 24 May 2002 12:54:49 -0700 (PDT) Received: from royer2.royer.com (IDENT:b0D7h+gh8TEr6Z9HYfprNr12ZKPqACwW@royer2.royer.com [4.23.9.160]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OJslL25290 for ; Fri, 24 May 2002 12:54:47 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer2.royer.com (8.12.2/8.12.2) with ESMTP id g4OJslmj011624 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 24 May 2002 12:54:49 -0700 Message-ID: <3CEE9A6B.3BB8D832@Royer.com> Date: Fri, 24 May 2002 13:54:19 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-31 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Questions to answer for the METHOD issue References: <3CEE937E.FE9C7CE2@steltor.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms26FD2A41AB3754101937A59E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms26FD2A41AB3754101937A59E Content-Type: multipart/mixed; boundary="------------9DB1E64CFCA211189B131CAB" This is a multi-part message in MIME format. --------------9DB1E64CFCA211189B131CAB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Just to make sure we are all on the same page about > the current issue to solve, here's the questions I > think we need to answer: > > A- Mary wants to invite Bob to a meeting. > > Q1: What is the format of the iCalendar object > Mary needs to send to the CS to deposit a > calendar invitation in Bob's agenda? METHOD:REQUEST > B- Bob wants to find all the calendar invitations > he did not already processed. > > Q2: What is the format of the iCalendar object > Bob needs to send to the CS to get all > unprocessed calendar invitations? SELECT * FROM VAGENDA WHERE STATE() = 'UNPROCESSED' > Q3: In which format will the iCalendar objects > of the unprocessed calendar invitations be > returned to Bob? 100% of all 'UNPROCESSED' iCalendar objects are iTIP objects. --------------9DB1E64CFCA211189B131CAB Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-29152 fn:Doug Royer end:vcard --------------9DB1E64CFCA211189B131CAB-- --------------ms26FD2A41AB3754101937A59E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA1MjQxOTU0MTlaMCMGCSqGSIb3DQEJ BDEWBBTjArnrgWjAMYq1OQ5gGlv49wooBjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgASIGTKUPKJhL1y4ZXKDHzU1YggP9Fq6cRgCJcWCp8fOTSAy SK53//Ksn+1BTUWNuVsmgLFSTGMe7Jsoh2k2DhDE737uos5S36NYOky7YQKB3W+9LVZXudbT VPsnXG3+o6EG1osBgoW6/0cPaHKAkELeUd50t1AjtVKFkM7PJYs7 --------------ms26FD2A41AB3754101937A59E-- From owner-ietf-calendar@mail.imc.org Fri May 24 16:10:54 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12792 for ; Fri, 24 May 2002 16:10:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OK4WV25493 for ietf-calendar-bks; Fri, 24 May 2002 13:04:32 -0700 (PDT) Received: from postman.incentivesystems.com (Postman.IncentiveSystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OK4UL25489 for ; Fri, 24 May 2002 13:04:30 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: CMD;opt=markfor:DELETE [Was: discussion METHOD] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 24 May 2002 16:05:12 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 05/24/2002 04:06:16 PM, Serialize complete at 05/24/2002 04:06:16 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >The only reason that the DELETE state exists is so that >the 2nd and up synchronization processes can tell if something >has already been done. Hmm. But then how does any CUA know when it's safe to delete the component for real? Is a CS going to be leaking disk space over time, unable ever to delete anything? Perhaps a component in DELETE state should have no properties other than its UID? /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Whose cruel idea was it for the word "lisp" to have an "S" in it?| \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri May 24 17:18:05 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15060 for ; Fri, 24 May 2002 17:18:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OLCFU26758 for ietf-calendar-bks; Fri, 24 May 2002 14:12:15 -0700 (PDT) Received: from royer2.royer.com (IDENT:ATV22vImW629T3X19CG9JNaClnK/d2Og@royer2.royer.com [4.23.9.160]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OLCCL26750 for ; Fri, 24 May 2002 14:12:12 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer2.royer.com (8.12.2/8.12.2) with ESMTP id g4OLCBmj012029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 24 May 2002 14:12:14 -0700 Message-ID: <3CEEAC8E.6ADBC31B@Royer.com> Date: Fri, 24 May 2002 15:11:42 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-31 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CMD;opt=markfor:DELETE [Was: discussion METHOD] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAA10554D6F981B1A38F9D3CE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msAA10554D6F981B1A38F9D3CE Content-Type: multipart/mixed; boundary="------------7118885644B967841AB80737" This is a multi-part message in MIME format. --------------7118885644B967841AB80737 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >The only reason that the DELETE state exists is so that > >the 2nd and up synchronization processes can tell if something > >has already been done. > > Hmm. But then how does any CUA know when it's safe to delete the > component for real? Is a CS going to be leaking disk space over time, > unable ever to delete anything? Yes that is an issue. The problem is that the CS will never know how many CUAs need to synchronize, and over what period of time. Only the CUA or CU will ever know. We just need to provide a way for the CUA to remove the object, and a way for the CUA to specify that an object is marked for removal. We do not need to specify when the physical removal is done. When to remove the object is a policy decision and not a protocol issue. > Perhaps a component in DELETE state should have no properties other than > its UID? No - duplication of objects; If you get invited twice (once on the xx-group mailing list and another on the yy-group mailing list.) You need to know that a METHOD:REQUEST was deleted with the same contents, so the 2nd -> up CUA will not ask the CU again when they see the 2nd copy of the same vevent - when they had already replied "NO". So you would need to not only know the UID, but the METHOD and the contents. Perhaps some of the contents could be removed, but I don't think we need to decide that until any synchronization draft. So this is another CUA <-> CS synchronization issue. We deferred the synchronization solution for another draft. And only required that CAP allow for synchronization. We had discussed and concluded it only meant marking an object for deletion and the ability to upload/download new or changed VAGENDA contents. The only unanswered questions on this issue are: o How do you know that an object is marked for delete. By fetching with the STATE() = 'DELETED' clause. If they come back with a METHOD, then they are 'marked for delete' iTIP objects. If they come back without a METHOD, then they are marked for delete booked objects. o How do you mark an object for deletion. A special CMD? CMD:MARKDELETED A paramater to the DELETE command? CMD;opt=markfor:DELETE o Make the default to just fetch booked components so that you have to explicitly ask for deleted or unprocessed objects? --------------7118885644B967841AB80737 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-29152 fn:Doug Royer end:vcard --------------7118885644B967841AB80737-- --------------msAA10554D6F981B1A38F9D3CE Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA1MjQyMTExNDJaMCMGCSqGSIb3DQEJ BDEWBBROBtQDXhbPJaNUPGOVqqrq0OCz2jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgHDS7ZLRs7tNmVWcFO/ONTysXSRI78/INLIRL/GJm7I7JJ4Z DfYuoZAuUKrg1iiLNQp9hXrOQ97bq+ViXv2Qh/UUstvT5FmFNB75bn4issWfb3FQ9bNd5q2A dq7V+GYCGWFyPOmUDI4Bjvpkl5roYrLQrpUbTzFF6jPtbEGcLauQ --------------msAA10554D6F981B1A38F9D3CE-- From owner-ietf-calendar@mail.imc.org Fri May 24 18:59:20 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18555 for ; Fri, 24 May 2002 18:59:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OMr1i28476 for ietf-calendar-bks; Fri, 24 May 2002 15:53:01 -0700 (PDT) Received: from postman.incentivesystems.com (Postman.IncentiveSystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OMr0L28472 for ; Fri, 24 May 2002 15:53:00 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: CMD;opt=markfor:DELETE [Was: discussion METHOD] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 24 May 2002 18:53:39 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 05/24/2002 06:54:46 PM, Serialize complete at 05/24/2002 06:54:46 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Yes that is an issue. The problem is that the CS will never >know how many CUAs need to synchronize, and over what period >of time. > >Only the CUA or CU will ever know. I'd say only the CU--none of the CUAs will know, since they don't know about each other. The CU has to know when every CUA has synced up, and purge their CS only when it's safe. That *might* be acceptable, in the common case where the CU has only 1-2 CUAs syncing; but I'm afraid it's going to be a pain for users with more sophisticated setups (or less sophisticated brains). /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Whose cruel idea was it for the word "lisp" to have an "S" in it?| \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri May 24 19:50:03 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20208 for ; Fri, 24 May 2002 19:50:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4ONhTo29759 for ietf-calendar-bks; Fri, 24 May 2002 16:43:29 -0700 (PDT) Received: from royer2.royer.com (IDENT:4naSOyt0yut1vxaaUPFdT9AMri8x5Z7U@royer2.royer.com [4.23.9.160]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ONhSL29755 for ; Fri, 24 May 2002 16:43:28 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer2.royer.com (8.12.2/8.12.2) with ESMTP id g4ONhSj1014798 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 24 May 2002 16:43:31 -0700 Message-ID: <3CEED003.F6B908BD@Royer.com> Date: Fri, 24 May 2002 17:42:59 -0600 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-31 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: CMD;opt=markfor:DELETE [Was: discussion METHOD] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms52D6219A9D261CB808CBEA3A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms52D6219A9D261CB808CBEA3A Content-Type: multipart/mixed; boundary="------------20D13BE53305CDFFBF0076DD" This is a multi-part message in MIME format. --------------20D13BE53305CDFFBF0076DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > I'd say only the CU--none of the CUAs will know, since they don't know > about each other. The CU has to know when every CUA has synced up, and > purge their CS only when it's safe. That *might* be acceptable, in the > common case where the CU has only 1-2 CUAs syncing; but I'm afraid it's > going to be a pain for users with more sophisticated setups (or less > sophisticated brains). I agree. Some sites might have a I'll clean up the marked for delete objects after xx months or something. Again this would be a CUA-BOT anyway. --------------20D13BE53305CDFFBF0076DD Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-29152 fn:Doug Royer end:vcard --------------20D13BE53305CDFFBF0076DD-- --------------ms52D6219A9D261CB808CBEA3A Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA1MjQyMzQyNTlaMCMGCSqGSIb3DQEJ BDEWBBS1uMFcsAsIkcWxSxvsvCgRz3X+azBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgDDYKaeSCHJ1jQkqbXgKNSv2Cdn5WAbUHfGSpzy8y65tJku0 ySjPyDb3K1ZQYp67pzR9DxlB3BQLblTC41waX2OVyEtnrFqVhcTFpS9uHO0edq38/DGD+oBe VTRJUgK/Sh0okYNo2ndFaYGEuUDsBZIiEwF33N5rwZ9vggdmGrLm --------------ms52D6219A9D261CB808CBEA3A-- From owner-ietf-calendar@mail.imc.org Mon May 27 09:21:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18380 for ; Mon, 27 May 2002 09:21:21 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4RD6Zf08664 for ietf-calendar-bks; Mon, 27 May 2002 06:06:35 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RD6YJ08657 for ; Mon, 27 May 2002 06:06:34 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g4RD6TkY004301 for ; Mon, 27 May 2002 09:06:29 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g4RD6Sr11530 for ; Mon, 27 May 2002 09:06:29 -0400 (EDT) Message-ID: <3CF23039.15F34D95@steltor.com> Date: Mon, 27 May 2002 09:10:17 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Questions to answer for the METHOD issue References: <3CEE937E.FE9C7CE2@steltor.com> <3CEE9A6B.3BB8D832@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > B- Bob wants to find all the calendar invitations > > he did not already processed. > > > > Q2: What is the format of the iCalendar object > > Bob needs to send to the CS to get all > > unprocessed calendar invitations? > > SELECT * FROM VAGENDA WHERE STATE() = 'UNPROCESSED' In your previous post you specified that the following query (SELECT * FROM VEVENT) would return all unprocessed VEVENT components : SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' How can the query you specified here (SELECT * FROM VAGENDA) also return all unprocessed VEVENT components? The STATE() function is ambiguous. It is not clear to which object it applies. We don't need a new function in CAP-QL to solve the issue at hand. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Mon May 27 09:27:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18452 for ; Mon, 27 May 2002 09:27:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4RDJqD10137 for ietf-calendar-bks; Mon, 27 May 2002 06:19:52 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RDJpJ10131 for ; Mon, 27 May 2002 06:19:51 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g4RDJgkY004462 for ; Mon, 27 May 2002 09:19:42 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g4RDJfr15792 for ; Mon, 27 May 2002 09:19:42 -0400 (EDT) Message-ID: <3CF23353.F4CFCDCF@steltor.com> Date: Mon, 27 May 2002 09:23:31 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Questions to answer for the METHOD issue References: <3CEE937E.FE9C7CE2@steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Just to make sure we are all on the same page about > the current issue to solve, here's the questions I > think we need to answer: I had ask people to provide *complete* iCalendar objects for all 3 questions, yet no one did. How can we reach consensus with vague answers? Anyway, here's a proposal with *complete* iCalendar objects. > A- Mary wants to invite Bob to a meeting. > > Q1: What is the format of the iCalendar object > Mary needs to send to the CS to deposit a > calendar invitation in Bob's agenda? BEGIN:VCALENDAR VERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN BEGIN:VCOMMAND CMD:CREATE CMDID:abc123 TARGET:cap://cal/bob-relcalid BEGIN:VITIP VERSION:2.0 PRODID:-//TOTO/MyCalendar//EN X-FOO:bar METHOD:REQUEST BEGIN:VEVENT UID:abcd12345 ORGAGNIZER:cap://cal/mary-relcalid ATTENDEE;PARTSTAT=ACCEPTED:cap://cal/mary-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal/bob-relcalid DTSTART:20010920T180000Z DTEND:20010920T190000Z SUMMARY:Mary invites Bob END:VEVENT END:VITIP END:VCOMMAND END:VCALENDAR The VCOMMAND component, which was used in draft-05, is reinstated essentially for the same reasons it was first introduced in draft-05. In a nutshell, this component allow us to use the property CMD, CMDID and TARGET without breaking the iCalendar syntax specified in RFC 2445 (i.e., these 3 properties aren't allowed directly in a VCALENDAR component). A new VITIP component is introduced to allow iTIP objects to easily be contained in VAGENDA components. This new component solves the issue about where the METHOD property should be "stored", or more precisely (since CAP doesn't specify how components should be stored) how to search for components based on their METHOD. The introduction of this new VITIP component also solves the issue about where the properties VERSION, PRODID, CALSCALE and X-PROP should be stored and how they can be queried. All these properties can now be stored in VITIP components. > B- Bob wants to find all the calendar invitations > he did not already processed. > > Q2: What is the format of the iCalendar object > Bob needs to send to the CS to get all > unprocessed calendar invitations? BEGIN:VCALENDAR VERSION:2.0 PRODID:-//ABC/AnyCalendar//EN BEGIN:VCOMMAND CMD:SEARCH CMDID:def456 TARGET:cap://cal/bob-relcalid BEGIN:VQUERY QUERY:SELECT * FROM VITIP WHERE METHOD = 'REQUEST' END:VQUERY END:VCOMMAND END:VCALENDAR > Q3: In which format will the iCalendar objects > of the unprocessed calendar invitations be > returned to Bob? BEGIN:VCALENDAR VERSION:2.0 PRODID:-//XYZZY/CalendarServer//EN BEGIN:VRESULT CMDID:def456 REQUEST-STATUS:2.0 TARGET:cap://cal/bob-relcalid BEGIN:VITIP VERSION:2.0 PRODID:-//TOTO/MyCalendar//EN X-FOO:bar METHOD:REQUEST BEGIN:VEVENT UID:abcd12345 ORGAGNIZER:cap://cal/mary-relcalid ATTENDEE;PARTSTAT=ACCEPTED:cap://cal/mary-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal/bob-relcalid DTSTART:20010920T180000Z DTEND:20010920T190000Z SUMMARY:Mary invites Bob END:VEVENT END:VITIP END:VRESULT END:VCALENDAR A new component VRESULT is introduced to allow us to use the property CMDID, REQUEST-STATUS and TARGET without breaking the iCalendar syntax specified in RFC 2445 (i.e., these 3 properties aren't allowed directly in a VCALENDAR component). Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Mon May 27 10:56:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19980 for ; Mon, 27 May 2002 10:56:54 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4REnll12277 for ietf-calendar-bks; Mon, 27 May 2002 07:49:47 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4REnkJ12273 for ; Mon, 27 May 2002 07:49:46 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g4REngkY005574 for ; Mon, 27 May 2002 10:49:42 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g4REngr12323 for ; Mon, 27 May 2002 10:49:42 -0400 (EDT) Message-ID: <3CF2486B.3A005EB5@steltor.com> Date: Mon, 27 May 2002 10:53:31 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CMD;opt=markfor:DELETE [Was: discussion METHOD] References: <3CEC1303.EC8061D@Royer.com> <3CEE8E76.EF530E60@steltor.com> <3CEE989D.6EA47E7E@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > The fact that a component has been mark for removal would be > > better handled by a property which could easily be maintained > > by CMD:MODIFY. I don't see the need for a new command, nor an > > option to an existing command. > > We have in the past decided that there would not be a way > to 'un-delete' so it is not the same comparison. The CAP Requirements document only deferred how to undelete a calendar (Section 4.3.1). > There is NO property to use the MODIFY command with, we > removed the conception that METHOD was contained in the object. You did propose "to remove the conception that METHOD was contained in the object." But that has not been agreed on the list yet. > I have not proposed anything new. DELETE already existed > as did CMD (by chair proclamation that the XML command was out). > I did not add or modify the meaning of DELETE. Nor did I propose > any new properties. I don't understand why you think I'm against proposing something new. Adding an option to an existing command is something new. We need to propose something new. Otherwise we wouldn't be having this debate about how to solve the issue at hand. > I simply am looking for a way for a CUA > to tell the CS; "delete this object, and remember you did so > that synchronization works later". I'm looking for the same thing. Except that I don't want to force CUA to perform multiple search commands when a single one could do. With your proposal CUA will have to perform a search command to get the 'BOOKED' components, another search command to get the 'UNPROCESSED' components and yet another one for the 'DELETED' components. By returning a property in iCalendar object to specify whether they are DELETED or not CUA will be able to perform a single (1) search command instead of three (3). No need for a new option to an existing command, nor any new function to the query language. All that is required to solve the issue is one new property that can be modified with CMD:MODIFY and queried with CMD:SEARCH. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue May 28 09:03:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16705 for ; Tue, 28 May 2002 09:03:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4SCrKu21087 for ietf-calendar-bks; Tue, 28 May 2002 05:53:20 -0700 (PDT) Received: from postman.incentivesystems.com (Postman.IncentiveSystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SCrJJ21080 for ; Tue, 28 May 2002 05:53:19 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Questions to answer for the METHOD issue MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 28 May 2002 08:54:55 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 05/28/2002 08:55:16 AM, Serialize complete at 05/28/2002 08:55:16 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I had ask people to provide *complete* iCalendar objects >for all 3 questions, yet no one did. How can we reach >consensus with vague answers? We already have consensus on this issue. It's embodied in RFC-2446. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Illiterate? Write today for free help! | \========================================================/ From owner-ietf-calendar@mail.imc.org Tue May 28 10:11:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19501 for ; Tue, 28 May 2002 10:11:42 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4SDwEI24983 for ietf-calendar-bks; Tue, 28 May 2002 06:58:14 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SDwDJ24979 for ; Tue, 28 May 2002 06:58:13 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g4SDw8kY013621 for ; Tue, 28 May 2002 09:58:09 -0400 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g4SDw6r23086 for ; Tue, 28 May 2002 09:58:08 -0400 (EDT) Message-ID: <3CF38DBB.DEE06217@steltor.com> Date: Tue, 28 May 2002 10:01:31 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Questions to answer for the METHOD issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > >I had ask people to provide *complete* iCalendar objects > >for all 3 questions, yet no one did. How can we reach > >consensus with vague answers? > > We already have consensus on this issue. It's embodied in RFC-2446. RFC-2446 doesn't say anything about the properties TARGET, CMD and CMDID. So how can you say that it's embodied in RFC-2446? All the examples I've seen so far breaks RFC-2446. Futhermore, I haven't seen a message from the chairs stating that we had reached consensus on this issue. Perhaps you could elaborate on what you think we have consensus on. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue May 28 12:55:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24747 for ; Tue, 28 May 2002 12:55:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4SGjVk05472 for ietf-calendar-bks; Tue, 28 May 2002 09:45:31 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SGjUJ05467 for ; Tue, 28 May 2002 09:45:30 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g4SGjQkY016109 for ; Tue, 28 May 2002 12:45:26 -0400 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g4SGjQr12854 for ; Tue, 28 May 2002 12:45:26 -0400 (EDT) Subject: Re: Questions to answer for the METHOD issue From: Patrice Lapierre To: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 May 2002 12:45:16 -0400 Message-Id: <1022604316.14375.8.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tue, 2002-05-28 at 08:54, John Stracke wrote: > > >I had ask people to provide *complete* iCalendar objects > >for all 3 questions, yet no one did. How can we reach > >consensus with vague answers? > > We already have consensus on this issue. It's embodied in RFC-2446. How does iTIP help us with question 2 and 3? Without answering question 2 and 3 how can you be sure that pure iTIP is an acceptable answer to question 1? In his message of April 18th, 2002, Steve Mansour was in fact trying to find an answer to question 1 to help him solves question 2 and 3. Steve Mansour wrote : > > [...] > > is the WORKFLOWSTATE automatically added when we write > the request to the calstore? Or do we require the CUA > to specifically add the WORKFLOWSTATE property? This issue needs to be treated as a whole.